This is a Draft document of a Internordic academic and research network backbone that will support many logical networks as long as they are needed. This network is open for both CONS and CNLS OSI network services and other new developments in the future while providing the best possible services to the users today. The project was named X.EARN since it originally started from the early EARN migration ideas to X.25 but the result turned up to be even more open network that can accommodate X.25 but doesn't have it's limitations. The lifespan of the network is estimated to be about 3-5 years since you can't realistically plan longer in the computer and networking business anyway. There has been some developments after this document was written but the main part is still valid. Maybe later a more up to date version will appear which might be after the network is stabilised in production... Some of the major changes and developments that have happened to date (which is 1988-05-03) are: - Name of the network shall be NORDUnet (old project name X.EARN no longer used) - All four countries have agreed on funding both steps - Internordic and US 64K lines have been ordered - New European connections will be set up when the situation clears itself. We are ready to carry EARN/Eunet/RARE/COSINE CONS network services using standard X.25 PLP over ISO 8802 when they are ready and OSI CNLS NS will probably be available very soon. - NSFNET application has been prepared and sent (step 2 started early) - Implementation phase has started and project groups set up - Vitalink TRANSLAN bridges and Cisco Routers have been selected - G-BOX solution is welcomed for EARN if tailored to our needs; some other solutions are still under study - Don't look too much on the costs, even we don't know them exactly yet, although we certainly can afford at least the basic network now - DECNET can most probably be harmonised and joined commonly to SPAN and HEPNET - Using few B-class IP numbers rather than many C-class is better for Internet routing Appendixes are yet missing from this electronic version that was edited from the original MacWrite document by Harri K. Salminen. Please join NDNNET-I list available from LISTSERV at FINHUTC in EARN if you want to receive new information when it's available. PRELIMINARY VERSION 1988-03-23 X.EARN Report by: Mats Brunell, NORDUNET Jan Engvald Lunds, Data Central Harri Salminen, FUNET Jan P. Soerensen, UNI-C Roald Torbergsen, RUNIT Contents Chapter Page 1 Introduction 3 2 Definition of desired services 4 3 Proposed solution, summary 5 4 Technical aspects 9 5 PTT-situation 16 6 Management and operational requirements 17 7 Costs 19 8 Time-scale and implementation plan 22 Appendix: Figure 24 Current network status 25 1 INTRODUCTION Background and goals The background of the X.EARN-project goes back to the EARN BoD meeting in Nice in May 1987. The concern for having to pay for the EARN leased lines in 1988 started a discussion between the Nordic Directors what to do regarding EARN in the Nordic countries. The situation was (and still is) that the international lines are not used more than 10-20% of the capacity. The interest to use them for other services apart from EARN- traffic is evident. At that point in time the interest from the EUnet organizations in the Nordic countries and access to the RUNIT Cray Supercomputer from Finland was of major interest. The X.EARN project was formally started in August at a meeting hosted by NORDUNET. At the meeting two contracts were agreed between the EARN Directors in the Nordic countries. Iceland was not represented as they had not planned to stay on EARN after 1987. The contracts covered two topics, the first an agreement on a cost- sharing principle based on equality between Denmark, Finland Norway and Sweden for all international cost during 1988. The second agreement was to start he X.EARN project. The goals for the X.EARN project is as follows: Project-goals The X.EARN project goal is to deliver a plan for decision in the reference group according to the agreement made in August. The goal for the project is to see how we technically can put on new services on existing EARN-leased-lines, i e to provide a general transport network. NORDUNET:s intention The goals as they are described above gives a oppurtunity to have a Decision on the creation of a common general transport network. NORDUNET:s primary intention is to establish a infrastructure for most user communities. In this case the first step is to create the proposed transport network, which will be used several separate networks running simultaneously e g for Super- computer users, DECNETs, EUnet and EARN. The reasons are both cost considera- tions and interoperability. The second reason is to ensure a possibility for migration to OSI. NORDUNET took the position to propose a tool which can introduce OSI services in Parallel with interim or manufacture dependent services. All network organizations who will use X.EARN have OSI as a common goal. Working together in this proposed project will greatly improve the conditions for a coordinated OSI in the Nordic countries. NORDUNET considers the proposed project as a vehicle to promote more coordinated management of existing networks services, especially between the Nordic branches of EUnet, EARN and services based on TCP/IP and DECnet. NORDUNET furthermore proposes three other projects, harmonization of Internet-IP, DECnet and electronic mail. The latter with top priority. 2 DEFINITION OF DESIRED SERVICES The following matrix describes the countries priorities for introducing services on a common internordic network. The "services" are sometimes a full architecture e g DECnet and the ARPA Internet Protocol suite, below noted as TCP/IP. In other cases the service is just a protocol i e X.25 or Blue-book file-transfer. They should both be considered as user-services in this context. The priorities are 1, the highest, to 3 which is the lowest. Services FI NO DK SE IS Interim: - EARN/RSCS 1 1 1 1 - DECnet * SPAN/HEPNET 2 3 2 2 * Cray-station 1 1 2 2 - EUnet, IP 1 2 2 1 (NETnews, E-MAIL) - TCP/ IP 1 1 1 1 - Blue-book 3 2 3 3 Standard: - X.25 3 1 2 2 - XXX-PAD 3 1 2 2 - X.400 2 1 2 1 - FTAM 2 1 2 2 _____________ US-Connection to NSFnet 2 2 2 1.5 INTEREST in SNA NO NO YES NO Comment EARN is a prerequisite service. There are certain differences in the list and priorities of the desired services. The existing services in the Nordic countries vary. This can also be seen in the appendix, Current network status. One can see at least three categories of interests, the first being interconnection of existing services like DECNET:s, TCP/IP and X.25 based services. The most desired service being TCP/IP. Also cooperation with EUnet has a strong interest. The second part is for new or pilot-oriented standard services, X.400 MHS and experiments with FTAM. The third category of interest is to bring on new user-communities. In this case interest from the Nordic Supercomputer users have been expressed. Discussions with the Nordic Meteorologists has also started. They are planning to use a Nordic Supercomputer-site for computations and need a network service. Apart from bring on new services on teh EARN lines an interest for better US-connections was expressed within the Nordic countries. The proposal therefore contains a connection to the US. 3 PROPOSED SOLUTION, summary Details of the items mentioned below are described in section 4, Technical aspects. 3.1 Functional description The transport network is proposed to be one logical inter-nordic Ethernet. The network provides access/connection points for EARN/RSCS, X.25, Internet IP and if decided by the national organizations also DECnet. The Nordic back-bone network propose to provide access points to the national networks for the following services: - EARN/RSCS - X.25 - Internet-IP (- DECnet) Inter-nordic network, European connection, step 1 The first step would be to set up the connections between Denmark, Finland, Norway and Sweden. Possibly also a connection to Iceland. A new connection in central Europe will be connected in stead of the existing one between Stockholm and Geneva. Once this step is carried out step 2 may follow. US- connection, step 2 The second step is planned to be a connection to the US. A formal application to join the NSFnet will be sent. The solution of the physical connection is still for consideration. 3.2 Technical description The project-group proposes that the implementation of the NORDUnet is based on four distributed segments of the international Ethernet interconnected by 64 Kb/s leased lines and MAC-level bridges. To this Ethernet the national networks connects via routers and gateways, special servers, X.25 switches or similar, see figure 1, appendix. National networks may only connect to the NORDUnet via the "level 3 routers" not via the MAC-bridges. The lines are proposed to be leased from the from the Nordic PTT:s jointly owned SCANTEL Corporation. 3.3 Technical management and routing As mentioned above the national networks will be connected to the Nordic back-bone through the routers and servers. This is considered essential to create an easily managed well protected environment isolated from national traffic. This "wall of isolation" between the internordic back-bone and the national networks eliminates the need for complicated Ethernet filters. The Nordic Ethernet, the back-bone consist of a few well-controlled Ethernet connections plus a number of routers. This makes it be very reliable and easy to maintain. There is no need to configure or stop bridges when adding new interfaces e g for a temporary analyzer or new gateways. For further details on management and operations issues see section 6. 3.4 Connecting different networks to the inter-nordic Ethernet We suggest the use of dedicated DECnet and IP-routers, not to be combined with the MAC -bridges. The separation is necessary to avoid a later problem with migration to ISO-IP, to DECnet Phase V or just changes in versions of related software which might interfere with the whole network service. Basic LAN/WAN We propose Vitalink:s TransLAN equipment for the MAC-level. The reason is good management functions (also integrated with proposed BSC server for EARN/RSCS and X.25) and possibility of looped networks trough "spanning-tree" routing load balancing and priorities on protocol types. The equipment is well proven standard product. EARN Current EARN RSCS based on BSC-lines could be connected to the Ethernet via synchronous servers. We propose Vitalink:s TransLINK. TCP/IP and DECnet A dedicated protocol router is the best choise for connecting IP-based services to the international Ethernet. We propose the CISCO router. DECnet is best handled by a dedicated DIGITAL system with two Ethernet interfaces. For backup the use of a preferably dedicated host with two Ethernet interfaces which could also function as an experimental ISO gateway in parallel with the dedicated routers. Since the inter-nordic Ethernet would be a multi-node network where all routers are logically connected directly to each other there should be a separate C-class IP-number for the inter- nordic TCP/IP network. DECnet areas should be harmonized with the HEPNET/SPAN initiative style gateway-ed with "Poor Man's Routing" to the national DECNETs if a common addressing scheme can not be harmonized. X.25 and ISO It is possible to provide a private X.25 network over the LAN-structure. Both for inter-nordic X.400 or FTAM use or for direct connectivity to the possible future EARN X.25 network. Before implementing a X.25 solution several studies, both concerning addressing and configuration will have to be performed in practice. Other protocols Protocols that can not utilize either Ethernet or X.25 but only synchronous BSC, SDLC, HDLC, DDCMP etc lines can also be handled, if necessary, with the proposed synchronous servers as for the EARN-solution above. 3.5 Comparison of LAN/WAN to private X.25/WAN The project group started with two models for the WAN. A X.25 backbone or LAN-WAN as an alternative. After discussions with the PTT and SCANTEL it became obvious that a public X.25 service was not a solution, due to both cost reasons and bandwith problems. The options was then a private X.25 network or a LAN/WAN. The following table gives a overview of the reasons for proposing a LAN/WAN rather than a private X.25 backbone network. LAN-based solution: + Wide variety of protocols can be supported, even sync lines + Can fully utilize 2Mbit/s lines already, much faster than X.25 + Doesn't compete directly with public PTT services like X.25 + No problems with "virtual circosis" (too many VC's on interface) + No fragmentation problems + Live insertion and automatic configuration + Loop topology with load-sharing and redundancy is available + Priorities for different interfaces or protocols are possible +/- New challenging technology +/- No accounting, only statistics 3.6 Cost summary For a detailed cost analysis see section 7. Step1 Step2 Step 1+2 Present Type of cost, kSEK Initial Operation Initial Operation EARN - Further study X.EARN 75 - Equipment 1.470 150 300 180 - Lines 120 1.585 30 2.275**) 987 - Personnell 200 300 75 300 _________________________________ Total: 1.865 2.035 405 2.755 987*) Investment Total investment step 1 and 2: 1.865 405 _____ 2.270 kSEK ***) Contribution from NORDUNET ./. 700 _____ 1.570 kSEK To be financed by the National organizations : 393 kSEK, per country Operational Total operational costs step 1 and 2: 2.755 To be financed by the National organizations : 690 kSEK per country per year **). (Present cost for EARN international lines c a 247 kSEK per country, 1988) THE COST FOR 1988 MAY BE HIGHER DUE TO OVERLAP IN NETWORK SOLUTIONS __________ *) Only PTT costs are included **) Costs for connection from New York to NSFnet site not included. ***) Costs for EARN central funding i e US-connection not included. 4 TECHNICAL ASPECTS 4.1 LAN vs X.25 based backbone, RARE - COSINE paper by Peter Linington Peter Linington, RARE has proposed a policy-document to RARE/COA. The paper is called "Statement of tehe RARE positioning on the provision of Network Services". Both the COSINE policy-group and the RARE COA has taken a decision to adopt it as a policy. The paper describes how and who should organize and provide network services. In this case network services refers to the ISO term network service. One of the requirements of the paper is to provide an end-to-end addressing. This should be solved regardless if the network consists of subnetwork (ISO 8648) with reference to the users needs. The criteria is that every end-system in a subnetwork should have a ISO-NSAP address. How does the proposed LAN-WAN solution fit in? It is our opinion that by providing national X.25 connections to the LAN we fully meet the requirements put up by the paper. For further details see also the addressing scheme of the private X.25 network below. The special case of a LAN as a WAN is not a problem in this respect. NSAP:s will be provided in LAN:s to. 4.2 DECnet The situation on existing DECnet networks in the Nordic countries as described in section 10, makes it hard to establish a Nordic-wide network without a lot of re- numbering of area-codes. We therefore propose that the national DECNETs in the Nordic countries harmonize the addressing according to the SPAN/HEPnet scheme described below. Apart from the more "open" DECNETs there also exists a Nordic (SE, NO, DK) "VLSI- network"which uses the area-codes 2, 3 and 43 today. They are normally connected to the "national" DECNETs. The HEPNET/SPAN initiative HEPNET is a network for the collaboration of high-energy physics and is centrally managed from CERN. SPAN is the ESO network. Both of them utilize a mixture of leased-lines and X.25 connections. In order to be able to interconnect a larger set of DECNET:s a addressing scheme has been adopted. The DECnet area numbers 1-63 is divided into two parts, on for an international "top-level" DECnet by of reserving the DECnet areas 1-46. Each country gets an area number between 1-46 and normally dedicates one nod/machine for the connection on to the top-level international DECnet. The DECnet parameter MAXIMUM AREA is set to 46. The "split" might be put higher due to the increasing number of member networks. The national DECnet nodes must use the area-numbers 47-63. In order to communicate to the international or other national DECNET:s the national node-machine /backbone-machine has to run "Poor-Mans-Routing", PMR. This allows a user to do MAIL and FILE-COPY. Terminal connections by use of CTERM (SET HOST...) requires that the user has a valid user-id on both of the backbone-machines. Status Both Norway and Denmark will use this scheme for interconnection to HEPNET- /SPAN. Sweden and Finland have to apply for a international DECnet area-number and renumber the existing DECNETs in order to be able to interconnect over the inter-nordic transport network. Proposed solution If a full address-harmonization can not be made, then each of the countries have to provide a dedicated VAX/VMS system to create the necessary separation of the backbone to the national DECnet. All existing international links has to be taken down or those machines must choose which network to be connected to. A coordinator for the DECnet in the nordic countries has to be nominated or else a management function for distributing area-codes over 46 must be set up in each country. If full connectivity is to be achieved node-tables and name harmonization has to be a procedure and responsible organization has to be appointed and set on contract. 4.3 Addressing scheme for the Internet protocol The best IP addressing scheme for our network would be one network number with one subnet level for countries and another subnet level for universities and a last subnet level for subnets to the university backbone. However, this can not be done at the moment because some equipment don't support more than one level of subnetting (eg a Sun as a gateway). It may also be hard to get a class A network number, which is needed because a class B number is too small for the whole Nordic IP-environment. IP-address administration Sweden The administration of IP-addresses differs from country to country. In Sweden ENEA Data AB acts as back-bone node for EUnet. They also administrate the INTERNET-mail domain .SE. For "normal" smaller organizations they provide IP-number at C-class-level. Today two class B networks exist, Chalmers in Gothenburg and ENEA. If anyone else need B-class networks they have to apply directly to SRI-NIC. Norway UNINETT is doing the administration of the IP-addresses for the R&D environment. Finland FUNET is doing the administration for IP-addresses in the R&D environment. Denmark UNI-C is doing the administration for IP-addresses in the R&D environment. Proposed solution Unrelated C-class IP-numbering plan The solution is to assign a lot of unrelated network numbers to different part of the total nordic network. This means that an outside gateway has to be aware of 15 - 30 different network numbers to be able to reach people on our universities (there will be many more numbers if we don't do subnetting at the university level). Below is a figure of how you can assign numbers to the different parts of a net. The degree of detail in the figure is varied to be able to show typical cases at each level. It is assumed that Finland keeps one B-class address common to all regions, but that Sweden will have different numbers for each university. This is because Finland uses national bridges and Sweden will use national routers for the IP traffic. Subnetting and subnetting mask, national issue Also assumed is that half of the computers are directly connected (possibly via bridges) to the university backbone and the other half via routers. However, this is just an example and can be assigned as needed. For simplicity, the subnet mask is assumed to be 8 bits, but 11 bits is probably the best for subnets with workstations. Administration of IP-addresses The top-level Ethernet has to have separate C-class addresses and a responsible function has to be appointed to administrate it. 4.4 EARN RSCS services Summary There are many different ways to share a line with EARN NJE traffic with which even recursive "Taarta paa taarta" systems that work well can be devised. The BSC- datalink level solutions work with every system without modification and are especially interesting for large area Ethernets and high speed lines with TDM. For the IBM SNA systems the X.25 over leased lines or Ethernet is the obvious way to go but for those VM/SP systems with TCP/IP instead of SNA as well as for the BITNET connection the VMNET TCP/IP transport server is ideal. Unix systems connect naturally with UDP/IP and VMS systems with DECNET over whatever backbone there is. JNET system nearby IBM, CDC etc. is also a good alternative for other solutions. The NJE over X.25 and OSI implementations are not yet available and therefore not suitable as an interim solution while waiting for OSI protocols. Proposal for internordic EARN connections Best solution would be the Princeton code developed for the BITNET transition to RSCS over TCP/IP. It should be soon available at least for many VM/SP TCP/IP implementations. Because many Nordic VM/SP systems are going to have TCP/IP soon the logical VM/SP backbone can be preserved. If this can not be achieved the situation running BSC over Ethernet or X.25 should be considered. Considerations Data link and network level solutions These simply let other protocols share the line with the BSC protocol without any changes to existing software on the hosts. These let the old network run as it is when new protocols are tested and introduced on the same lines. In most cases the maxi- mum available speed for NJE traffic is 64Kbit/s but now even the current 9.6Kbit/s lines aren't used enough and it's expected that most of the volume will be from other protocols than NJE in the future. Multiplexed and bandsplit lines The simpliest and oldest way of sharing one line with different synchronous protocols is to divide the physical line to fixed lower speed channels. On low speed analog lines some modems support bandsplitting e.g. a single 9.6Kbit/s line to four 2.4Kbit/s channels. With higher speed digital lines from 56Kbit/s up one can use Time Division multiplexers to easily split up e.g. a 2 Mbit/s line to different size channels at will. Advantage of these methods is simplicity and relatively low cost but the allocation of the bandwidth is newer optimal between the protocols and can't change dynamically. E.g. one 9.6 Kbit/s channel from a 64Kbit/s line can be allocated for EARN traffic and if the speed isn't optimal it can easily be changed to a new one. Modern TDM's are sophisticated microprocessor controlled systems featuring online configuration, statistics generation, automatic alternate routing, modular design etc. Time division Multiplexing would ensure that the EARN filetransfer and traffic bursts on the other channels wouldn't interfere with each other. Once the network is in operation the management apart from bandwidth allocation is simple and the different protocols shouldn't interfere with each other. There's a great variety of TDM's available today and one higher end example of the digital TDM's is the MEGAMUX II from General DataComm for 2Mbit/s line with maximum of 512 synchronous, asynchronous or isochronous data and CVSD, PCM, ADPCM or ASP voice channels, even videoconferencing is possible. BSC in a X.25 network BSC as well as many other protocols can be broken up and re-packed to packets used by nearly any other packet based network like X.25 or Ethernet which in effect gives a dynamic statistical multiplexing. More efficient solution is available by using some multiprotocol packet switches which support BSC and other protocols in addition to X.25. E.G. DCA communication switches can act as private X.25 switches, terminal exchanges and BSC or SDLC lines at the same time carrying the interswitch traffic in packets either over leased lines or wide area Ethernet. Solution is nice and supports both the X.25 for other protocols and EARN BSC without any software changes giving dynamic load balancing. Problem with this solution is that it's dependent on some specific vendor's packet switch and can be expensive. Another interesting solution is provided by Protocol Processors that can carry BSC or SDLC traffic over any X.25 network. For example GTE Telenet, which also manufactures and operates X.25 networks, offer two models: TP3/II-3006 has 4 or 8 9.6Kbit/s ports and one 19.2Kbit/s X.25 netline and TP3/II-3325 has a maximum of 52 19.2 Kbit/s ports and two 64Kbit/s X.25 netlines. Traffic priorities can be set for different circuits like in many X.25 switches to avoid congestion by batch file traffic. This solution relies also on proven technology like TDM's and gives also dynamic load balancing with the danger of congestion. The maximum supported line speeds are currently in the range of 19.2Kbit/s to 64Kbit/s which are much lower than those of TDM's. Management is comparable to an ordinary X.25 network and should be easy after the initial setup. Synchronous traffic over Wide Area Ethernet Finland like many other countries is building a single large Ethernet that connects all the local Ethernets in the different universities around the country which easily supports line speeds between 64Kbit/s and 10Mbit/s. As wide area Ethernets formed with MAC-level protocol independent bridges and high speed lines gain popularity, traditional X.25 networks running synchronous traffic over Ethernet become important for the applications that need them. Many new products have emerged in addition to the X.25 switches that can utilize Ethernet as a carrier. These systems act as synchronous statistical multiplexers and support many different protocols over predefined virtual circuits between two synchronous ports. Examples: The simplest solution is to use Bridge CS/200 terminal server which has 4 or 10 ports that can be configured to support BSC 19.2 Kbit/s virtual circuits as well as asynchronous traffic. More versatile system is Ungermann Bass Network Interface Unit-140 with two 19.2 Kbit/s ports which supports character oriented BSC (IBM,Unisys,Honeywell...), bit oriented HDLC or SDLC and length oriented (DDCMP) protocols. Fastest and most expensive unit is VitaLINK's TransLINK with 4 or 8 ports and aggregate throughput of 800Kbit/s. TransLINK can also be used with a single leased line instead of Ethernet connection. Setting priorities for different types of traffic is now available on wide area Ethernet. Using Ethernet as carrier for synchronous protocols is similar to using X.25 but the maximum supported speeds are in the 800Kbit/s range. Ethernet bridges can also viewed as high speed packet switches or statistical multiplexors and the different Ethernet backbones can be separated with routers and these synchronous multiplexors when needed. Transport level solutions Transport level solutions rely on proprietary or open transport protocols and non-standard application to application protocols between the NJE systems. Because of that they normally work well between similar implementations on operating systems using the same main transport protocols. Between dissimilar implementations normally a leased BSC-line preferably between nearby machines is needed at least somewhere to maintain connectivity between the different subnetworks. When using the transport protocols all their bandwith is available for NJE and the management is mainly the problem of the transport network used. RSCS and SNA SNA is the IBM's strategic communications architecture which of course supports very well it's own NJE protocols with either RSCS V2 on a VM/SP system or JESx on a MVS system. The connections between the systems are either through SDLC or X.25. IBM can support X.25 either running SNA over X.25 PVC's or SVC:s or over SNA SDLC lines (XI). The advantage of this solution is that it's IBM supported off-the-shelf product line with extensive network management utilities. The disadvantages why we want to consider other alternatives even for IBM systems is complexity, hard offline configuration and tuning, no support for Ethernet, high price even with discounts and the need for an expensive 372x communication controller. There's also no SNA/NJE implementations with X.25 support for other than IBM operating systems so other vendor's systems need different solutions in any case. With the price and manpower needed for an non-SNA site to convert to SNA one can easily buy and manage several minicomputers and servers to do the job. Because SNA is IBM's strategic product also needed for OSI products it might eventually be needed in a large VM/SP environment. Not all sites or even countries are interested in supporting large IBM systems and they at least need other solutions. SNA over X.25 supports the normal maximum X.25 line speed 64Kbit/s and SNA over SDLC lines over 1 Mbit/s line speeds. The needed program products are at least: RSCS V2, GCS, VTAM, NCP, NPSI and PEP although SNAPAD, NETVIEW, XI, OTSS, OSNS, GTMOSI, X.400 and others might be interesting as well. RSCS and TCP/IP In the U.S. there's already a large and rapidly growing TCP/IP internet which consists of many high speed networks like ARPA, NSFNET, and CSNET. Because TCP/IP is the only real interactive internetworking protocol with economical implementations available for nearly every operating system it is quite popular on BITNET sites and also in Europe. E.g. Israel and Norway are building large TCP/IP networks and many other countries like Finland are recommending it on the protocol independent Ethernets and X.25 networks. Large smooth migration from TCP/IP to OSI IP and TP4 is expected in the future as many US networking agencies like NSF and DoD are planning it. NSF has funded the development of a VM/SP software to transfer the RSCS traffic over TCP/IP especially for the BITNET migration to TCP/IP. The server called VMNET has been developed at Princeton and is soon available to other than beta test sites also in Europe. This software is also very interesting in the Nordunet community between the VM/SP systems using TCP/IP as well as for a BITNET connection through a TCP/IP satellite link. TCP/IP can use as it's transport layer X.25, leased lines, Ethernet, Hyperchannel and others. The same RSCS/TCP/IP protocol might also be supported by JNET and Urep in the future. No modifications to the existing software or additional management load, just a 'black box' virtual machine between RSCS and TCP/IP. NJE over X.25 Experimental software to carry NJE directly over X.25 has been developed in Germany but on IBM systems the SNA is needed anyway to control the expensive communications controller. If production versions of this software were in-expensively available for VM/SP,MVS,VMS and Unix systems without long development time it might be an interesting solution for X.25 based networks. JNET and DECnet JNET is a popular RSCS emulator for VMS systems which can use DECnet in addition to BSC lines. DECnet in turn can use leased lines, Ethernet and X.25. JNETs connected together with DECnet are successfully being used as transit nodes between VM/SP systems without any noticed pro- blems. Because most of the current EARN nodes are already JNET nodes one can often be found near other NJE systems for a BSC interconnection. This solution doesn't need anything special to the current JNET part of EARN although some problems might arise when trying to use more advanced NJE features between MVS or RSCS V2 systems or applying some modifications planned for international transit nodes but because half of the EARN nodes are JNET systems we have to try to solve them anyway. Urep and UDP/IP Urep is a popular RSCS emulator for unix systems which supports in addition to BSC lines UDP/IP which means that all Unix systems on a TCP/IP Internet can easily be connected together with NJE. It's not yet supporting the TCP/IP protocol used by VMNET and not currently recommended as transit network between real RSCS systems because it isn't yet as transparent as JNET. It's however recommended for linking unix systems economically to EARN because of the relatively low cost of a site license with sources. NJE over OSI NJE over OSI is an idea of transferring NJE over ISO protocol stack but as it is not yet being developed it's better to wait for for OSI RJE, FTAM, MHS and VT applications and in the meanwhile use the solutions that are available today. 4.5 X.25 Private network, addressing The X.25 addressing is specified in CCITT recommendation X.121. The address consist of a Data Network Identification Code (DNIC-with four digits) which only is used for International Routing, and a Network Terminal Number (NTN-with maximum ten digits) for national routing. The DNIC consist of a Data Country Code (DCC) and a Network Digit as shown below: _________ DNIC: I_I_I_I_I I I___ Network Digit. Finland Norway: Denmark: | 1 Datex 1 Datex 1 Datex | 2 Datapak 2 Datapak 2 Datapak | 3 Digipak 3 unused 3 Paxnet | I I_________DCC Denmark : 238 Sweden : 240 Norway : 242 Finland : 244 Iceland : 274 Each National Administration can use the Network Number to select between the different Public or Private Networks. The Network Terminal Number consist of maximum 14 digits. Each administration usually reserve the last 2-4 digits for local addressing. Each local Packet switch should be connected to the Public Network and the Private Network. It should be easy to automatic re-route the traffic from the private Network via the Public Network in case of fault conditions. It is possible to use the same network terminal Number in the private Network as in the Public. If some of the private X.25 switches do not have a direct connection to the Public Network, it could be part of a switch which has such a connection. Comparison to EARN proposal This proposal is different from the EARN proposal at the following points: - It is based upon The National Numbering plan and not upon a separate EARN-numbering plan; - It is open for further extensions and changes in the network; - It is easy to use the PTT-network as a back-up network under heavy load conditions and for traffic to Institutions which not have a separate leased line to the Academic network. Proposal Each Academic network should apply for a Network digit, with their national administration. 5 THE PTT-situation 5.1 The status of PTT:s in the Nordic countries The situation in the Nordic countries varies as far as both monopoly and technical infrastructure are concerned. The Swedish, Norwegian and Icelandic PTT:s are in a monopoly-situation. Denmark and Finland have several telephone companies that provide services. On the service-side Public X.25 networks in the Nordic countries lack international high-speed bandwith. The normal international links use 9.600 BPS with X.75 protocols. Upgrade to 64 kBPS has been installed between Norway and Sweden, Norway to Denmark and Denmark to Sweden just recently Due to the fact that different vendors has provided the X.25 equipment in the Nordic countries the possibility of closer cooperation in management/inter-operability is very hard to implement technically. The internal national X.25-networks normally use 64-kBIT-lines as the highest speed available today. X.25 version 1984 is not introduced yet in any of the nordic countries. The normal tariffs makes volume traffic connect-time dependent due to lack of bandwith. This is especially a problem on international connections. 5.2 SCANTEL In 1987 a company was formed by the Swedish PPT owned "holding company" TeleINVEST called SCANTEL. SCANTEL is as of 1988 owned by all the Nordic countries, Sweden will till own 48%, Finland, Denmark and Norway, 16% each and Iceland the remaining 4% of the shares. SCANTEL is intended to be the Nordic PTT:s to provide international communications within the Nordic countries and to the rest of the world. The services are voice, data and image. Also some "value-added services" like MHS is mentioned. SCANTEL has the ambition to provide "one-stop-shopping" by sub-contracting other communication providers abroad. SCANTEL can provide connections to the US trough INTELSAT. They have the possibility of 64 kBPS today. In Europe their counterpart is the Dutch PTT. 6 MANAGEMENT AND OPERATIONAL REQUIREMENTS 6.1 Operational requirements The operation and backup of the internordic network consists of many different parts and levels and varies depending on the solutions supported. A working network shouldn't need much more operation than the current national networks because of the advanced automatic network management and routing systems available today. But always something unexpected might happen and a wizard is needed. Line backup The PTTs should provide quite reliable leased lines but in case they fail for longer periods the emerging pre-ISDN switched 64Kbit/s lines with automatic circuit setup could be a very usefull as a national backup. Public X.25 network might be used as a backup for private X.25 switches or TCP/IP, DECnet and OSI routers with an X.25 connection. Pre-ISDN and full-ISDN networks will probably be the easier, faster and cheaper alternative especially in the future. Switching to backup lines can be automatic but a manual operation is cheaper and probably sufficient. Bridges Ethernet bridges in an inter-nordic network with only a few well controlled systems connected to it should be easy and automatic to operate. Error and traffic statistics should be checked regularly to detect malfunctions. A removable Ethernet analyzer is a very good tool to test and analyze the behaviour of the network and debug problems with the upper layer protocols. Most bridges can be configured online from remote consoles and set up to filter unwanted packets. X.25 switches X.25 switch management varies greatly between different vendors products but consists at least of DTE-address and routing table assignments, parameter set-up, traffic monitoring and accounting. Their management might require more expertise and work than the bridges but can also be handled remotely from a knowledgeable site when needed. X.25 communications analyzer might be very usefull when debugging problems with connections and different X.25 implemen- tations. As a backup they can use public X.25, ISDN and redundant lines. TCP/IP routers Dedicated routers should be quite reliable after they have been properly configured but also their operation needs some supervision. Routing and fragmentation might cause problems especially when the network grows and gets connected to internets outside Nordic countries. You can also get statistics from the routers and may configure them remotely. In case of real problems in the network a TCP/IP expert with protocol analyzer might be needed. A good backup is to have a BSD Unix host with two Ethernet interfaces in parallel with the dedicated router and set up the cost for using it so high that it is used only when the dedicated router is out of operation. This host can be used at the same time for many OSI protocol experiments, gatewaying, file- and information services, network monitoring and management etc. In case of a line, bridge or X.25-switch failure a multiprotocol router like CISCO could use directly pre-ISDN or public X.25 networks to carry the important TCP/IP and DECnet traffic. DECnet routers DECnet needs the normal operational procedures probably already available and the situation situation with backup is much the same as with TCP/IP routers. Normally a router consisting of a VAX/VMS system with two Ethernet cards should be used. If Poor Man's Routing is used it might pose special problems to look for. EARN EARN can be carried with many ways over two transport networks and normally one has to worry about the normal RSCS problems like spool fill-up, large files, extensive messages, queue sorting etc. regardless of the connection type used. The new network allows for many logical parallel connections between computers which greatly reduces the problems when some transit node fails, you just go around it. It might be usefull to have a complex point to point connectivity even with parallel JNET and TCP/IP networks although routing table generation might become quite complicated. Alternatively, new logical connections could be set up only as backup when then main transit nodes fail. OSI Management of PILOT OSI networks is very dependant of the implementations as no general OSI network management standards exist yet. The management is an important part of a large network and should be studied as part of the pilot experi- ments. Different implementations might use as a network layer and sublayers X.25, ISO IP over X.25, X.25 over ISO 8802/3 (Ethernet), ISO IP over 8802/3, ISO IP over TCP/IP etc. In general we should have a growing number of OSI expertise in each country to manage the migration. 6.2 Management and responsibilities We introduce a new level of networking with the introduction of this inter-nordic LAN-WAN. It is obvious that some level of coordination above the national level is needed. In any case there should be one responsible "functional organization" appointed to the following tasks at the international level: - Overall responsibility for the basic LAN-lines, configuration of bridges to ensure that the network stays up and external contacts to SCANTEL/PTT; - administration of DECnet-node-table updates and external contacts; - administration of IP-addresses and Routers set-up in each country and contacts with ARPA Internet; - administration of a X.25 private network, routing-tables updating and every-day operation. 7 COSTS 7.1 Investment, equipment Step1, Basic configuration 4 TransLAN+ 8 line modules 500 4 CISCO-routers with 2 Ethernet cards 500 4 TransLINK synchronous servers 210 _______ Total for basic configuration: 1.000 kSEK 4 X.25 switches (varies on configuration and model) 260 kSEK Total investment cost: 1.470 kSEK Step 2, US connection Due to NSFnet uncertainty of equipment choise we can only estimate the costs. 2 Routers or 1 router + 1 bridge 300 kSEK Total investment cost: 300 kSEK 7.2 Tele-communications costs Prices are approximative and quoted from SCANTEL. They refer to the list-prices from the PTT:s. 7.2.1 Existing analog leased line 9.600 BPS network Prices are approximated to kSEK, M1020 quality costs not included. The PTT:s have different policys for modems, in some countries (NO, FI and DK) modems are possible to buy. The Swedish monopoly will end in April -88. Modem costs are approximated to 10 kSEK/year per end-point. It is not possible to use higher speed modems on existing analog lines. Line Swe part Counter-part Tot/year SE - NO 76 82 158 SE - FI 76 107 183 SE - DK 76 40 116 _______ Sub tot: 457 kSEK SE - CH 185 285 475 kSEK (Alternate route: DK - NL, 9.600 B/S 250 kSEK) US-costs 1988 c a 200 kSEK (according to EARN financing model) Estimated cost per year for existing network for comparison is 987 kSEK (Change to DK-NL included) 7.2.2 New 64 kBPS digital leased-line network from PTT:s, quoted by SCANTEL SCANTEL can not give a formal offer to NORDUNET until approximately June -88. They can however be used for ordering lines, "one-stop-shopping" at this point in time. The swedish PTT:s may adjust the prices on the international lines in april -88 when they drop the monopoly on modems and other services. 64 kBPS lines are normally available with a delivery-time of c a 12 weeks. Modems are included. Line Tot/year Initial costs remark Step1 SE - NO 330 30 SE - FI 475 30 cost for local connection SE - DK 280 30 within Helsinki not quotable without order DK - NL 500 30 64 kb/s _______________ Sub total: 1.585 kSEK 120 kSEK Step2 (US-connection 370 kSEK 30 kSEK) Connections from Stockholm (9.6 kb/s) to international INTELSAT- GATEWAY in New-York, "local" cost to NSFnet-site not included. US-connection 690 kSEK 30 kSEK (64 kb/s) Estimated cost per year for new network for comparison 2.275 kSEK (Step 1 and 2, US 64 kb/s) Initial costs c a 150 kSEK. 7.3 Cost for set-up of the network Initial costs Step 1, Inter-nordic An estimate of the amount of work is c a 1 person-month each for setting up and configure (total in four places), 50 kSEK per month x 3 = 150 kSEK + travel kSEK 50. - LAN-bridges including EARN-BSC; IP-routers and X.25 switches. Sub total: 200 kSEK Step 2, US connection Estimated to 1 person month at 50 kSEK + travel Sub total: 75 kSEK 7.4 Coordination and maintenance cost Coordination of IP, X.25 and DECnet addressing as well as a responsible site for the whole network should be placed as contracts. C a 1/5 person per task at 50 kSEK/task per year = 200 kSEK These tasks are to be carried out nationally. There is also a need for coordination meetings, max 10 persons 4 times per year 3 kSEK per trip x 8 x 4 = 100 kSEK Maintenance of the equipment is estimated to 135 kSEK (10 % of invested capital) for step 1, for step 2 an extra 30 kSEK is estimated. Note that Personnell cost for the long term running is not included. This will probably not increase the amount of work apart from the other tasks. 7.5 Further study X.EARN Further specification of implementation, mainly travel costs, 6 persons 4 meetings at 3kSEK per trip = 45 kSEK. Coordination with EARN DIGITAL and IBM initiative, 5 trips at 6 kSEK, 30 kSEK. Total for further study of X.EARN, 75 kSEK 8 TIME-SCALE AND IMPLEMENTATION PLAN ESTIMATED TIMESCALE The whole time-scale is dependent on when decisions can be taken. The following time-scale is based on the assumptions that a positive decision about going forward with the implementation in NORDUNET can be taken in January -88. The national organizations should take their decisions no later than April -88. Implementation plan Action Apr May June July Aug Sept Oct Remark A1 Decision Nordunet START D2 Decision national org --------> Step 1 A3 Order lines X A4 Planning for installation -----------------> A5 National contracts -----> D6 Decide on equipment X D7 Delivery, lines X R8 Delivery, equipment X A9 Test of Equipment and lines --HHH--> A10 Education --> A11 Put into operation IP X---> D12 EARN on new net how? X----> D16 Decision to take down existing network X Dependent decisions D17 US- and Europe connections, earliest decision time Y - depends on IBM, EARN and others. Step 2 Depends on D18 US-connection D19 Decision on equipment, US D17 D20 Order equipment, US D17 D21 Order line to US D17 D22 Decide on equipment, Europe D17 D23 Order equipment, Europe D17 D24 Order line, Europe?, latest D17 Parallel activities -MAIL-HARMONIZATION SEPARATE PROJECTS -X.400 -DECnet Harmonization