Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!rutgers!njin!psuvax1!psuvm!PUCC!LVARIAN From: LVARIAN@PUCC.BITNET (Lee C. Varian) Newsgroups: bit.listserv.nodmgt-l Subject: BITNET Restructuring Proposal Message-ID: Date: 6 Feb 90 15:59:46 GMT Sender: Node Management Discussion Reply-To: Node Management Discussion Lines: 359 Approved: NETNEWS@PSUVM Gateway Dear BITNET/CREN colleague, The enclosed proposal for a restructuring of the BITNET network was presented to the CREN Technical Committee in early December, 1989. At the most recent CREN Board meeting, the Committee recommended that the proposal be more widely circulated within the BITNET/CREN community. This mailing is an attempt to comply with that recommendation which was accepted by the Board. As you probably already know, several of us at Princeton have been working on the VMNET programs which allow RSCS NJE traffic to use IP networks. One of the motivations for this work was to have BITNET connections over IP networks. Once the technical aspects of RSCS NJE over IP were resolved, the questions of how to best use, deploy, and manage this new type of BITNET connection were raised. In an attempt to address some of these questions, we are submitting for discussion a proposal which would reorganize the structure of the BITNET network. A number of core sites are proposed which would play key roles in the restructured BITNET network. It is important to point out that this recommendation does not itself propose the creation of new IP network connectivity, but rather suggests how BITNET NJE traffic might be organized to utilize existing IP connectivity. The proposal is compatible with and could utilize any further growth of the NSFNET and regional IP networks, as well as any CREN IP network. We hope you will carefully consider the proposal and provide your input on its possible implementation. A file of the discussions which have taken place thus far on this proposal may be gotten from the LISTSERV at PUCC. To get a copy of the file: TELL LISTSERV AT PUCC GET BIT2PLAN COMMENTS Or, send mail to LISTSERV@PUCC on Bitnet with the body / text of the mail containing the command: GET BIT2PLAN COMMENTS Lee Varian (LVARIAN@PUCC) Peter Olenick (Q0239@PUCC) Michael Gettes (GETTES@PUCC) * * * * * * Proposal to Restructure the Network Supporting BITNET Historically the physical and logical networks supporting BITNET have been structured on leased communications lines connecting member sites. New sites connect to the network based upon an existing BITNET member's willingness and ability to support the request for connection. The cost of the leased communications line, which is paid for by the new BITNET site, is also a consideration in choosing which existing BITNET sites are possible connection points. The cost of the communications line may be different based on factors of distance and tariff considerations. This method of connecting new sites has worked quite well, but the lack of a formal structure for the network is creating limitations which impair the efficiency and growth of BITNET. The lack of a structure increases the complexity of routing table generation and hampers efforts to implement network management tools. The ability to create BITNET links by using the national and regional IP networks increases the confusion over where BITNET connections should be made. The idea of reorganizing BITNET into a more formal structure has been discussed for a number of years, but the costs of the additional leased lines needed to implement such a plan made the project economically infeasible. Now, BITNET has the ability to use the national and regional IP networks; a plan to restructure BITNET by using the IP networks appears to be cost effective and implementable. This plan could also be implemented using private communications facilities and IP routers instead of using the national and regional networks. The costs of an implementation using a private IP network would need to be carefully considered. Restructuring Proposal The restructuring is based on the concept of 'regionalization', the separation of the network into geographic areas or regions. Each region would have two 'core' sites. Each core site would have RSCS-over-IP connections to every other core site. The core sites would form a 'backbone'. The national and regional IP networks are the physical facilities that would be used by the core sites to form the BITNET backbone. By generating appropriate BITNET routing tables, the number of nodes and the amount of traffic handled by the core sites for a given region can be statically balanced. Within a region, the core sites could connect to a number of 'mid-level' sites, again by use of RSCS-over-IP. This type of structure has the ability to provide an alternate path into a region if a core site were out of service. The member sites or 'end' sites within a region could connect to the mid-level sites. Traditional leased line connections may exist at any level within the structure but these types of connections will continue to have limitations. That is, if a host with traditional leased lines is down, no other path may exist to the sites supported by that leased line. The following diagram attempts to present graphically the structure of the regional model. Diagram for Regional Model (Example of a single Region) +--------+ | end | | site | +---||---+ RSCS/IP RSCS/IP +---------+ +---||---+ ========== core | +---------+ BSC | end | | site | | mid- ----------- site | RSCS/IP | | RSCS/IP | level | +--------+ ========== =========== site | | | | | RSCS/IP +--------+ RSCS/IP | | | =========== end | ========== | +---||----+ | site | +---||----+ || +--------+ || || RSCS/IP RSCS/IP || || RSCS/IP +---||----+ || +--------+ ========== core | +---||----+ BSC | end | | site | | mid- ----------- site | RSCS/IP | | RSCS/IP | level | +--------+ ========== =========== site | | | | | RSCS/IP +--------+ RSCS/IP | | | =========== end | ========== | +---||----+ | site | +----|----+ RSCS/IP +--------+ | || | +---||---+ +--------+ | | end | BSC | end | | | site ------------ site | | +--------+ +--------+ | | +--------+ | BSC | end | |----------------------------------- site | +--------+ In the diagram, the end site shown as a single node can be a collection of nodes connected by a mixture of leased lines and IP. Benefits of the restructuring The purpose of the regionalization is to impose a structure on the logical network supporting BITNET. This structure will reduce the burden on the current hub sites by decreasing the number of files which must transit these sites. Overall network service will be improved because the number of 'hops' a file must take to reach its destination will be reduced or be no greater than in the current BITNET topology. The impact on BITNET when a key BITNET node or Internet connectivity fails will be reduced because of the increased number of connections between core sites. As the intra-regional mid-level structure develops, the ability of the core sites to dynamically reroute traffic around a disabled core node will provide improved network access. The three level (core, mid-level, end site) structure of the region can be expanded to include additional levels and paths as needed within the region, thereby providing for dynamic rerouting within a region as well. Implementation Plan The current BITNET network would be divided into seven regions. Each region would have the required two core sites. No attempt has been made to define the mid-level sites within the regions. The mid-level structure will develop at different rates within the different regions. The rate will depend on many factors including the level of IP connectivity, amount of BITNET traffic generated, and amount of network expertise available. The regions and core sites can be implemented without having the mid-level structure defined. The proposed region and associated core sites are as follows: Region 1 - NorthEast BUACCA: Boston University YALEVM: Yale University Region 2 - MidEast CORNELLC: Cornell University CUNYVMV2: City University of New York Region 3 - MidAtlantic PUCC: Princeton University PSUVM: Penn State University Region 4 - SouthEast UMDD: University of Maryland VTVM2: Virginia Polytechnic Institute and University Region 5 - MidWest UICVM: University of Illinois at Chicago UKCCB: University of Kentucky Region 6 - MidSouth RICEVM1: Rice University UIUCVMD: University of Illinois at Urbana-Champaign Region 7 - West UCBCMSA: University of California at Berkeley USCVM: University of Southern California Core Site Guidelines For a machine to be considered for use as a core site it should meet the following requirements: 1. The machine must run VM with FAL, VMNET, and RSCS Version 2. 2. The system must have the capacity to support the number of RSCS-over-IP connections needed for connectivity to other core sites. This capacity should take into account IP connectivity capacity, processor capacity, spool capacity and manpower requirements. 3. Core sites may need to add additional software facilities and modifications to improve throughput and overall network management. An example of these might be installation of the BITNET II transmission algorithm to improve throughput of RSCS over IP. 4. One if not both core sites in a region should run a LISTSERV which is part of the LISTSERV backbone. Because LISTSERV files are a large component of BITNET traffic, having the core sites on the LISTSERV backbone will enhance the operation of this pervasive application. 5. Core sites are encouraged to consider running NETSERV and acting as INTERBIT sites. Running these facilities will reduce network load and provide greater service to the region. 6. With BITNET making use of the national and regional IP networks, the core sites will need to establish procedures for dealing with their IP service and its supplier. These procedures should include out-of-hours procedures, local operating procedures, and problem determination procedures. These same general guidelines can be scaled appropriately and applied to the mid-level sites. All the suggested core sites meet the guidelines with minor exceptions. All of the core sites chosen are VM machines in the 308x class or larger. All core sites chosen run FAL or WISCNET, with all but one of the WISCNET sites planning conversion to FAL in the near future. All of the core sites expect to run RSCS Version 2 as soon as feasible. All core sites chosen are accessible via the regional and national IP networks. Clearly the BITNET core sites will assume a leadership role in their regions. Expertise in RSCS, FAL, and TCP/IP, as well as operating systems will be of value to the core site in problem solving. This expertise will also be useful in guiding the development of networking within the core site's BITNET region. One of the goals of this plan is to minimize the disruption to the functioning of BITNET. Current leased line connections would not be required to be altered. All current BITNET sites would be assigned to one of the regions. This is true for the international connections as well. The international links would be associated with the region of the host system. New RSCS-over-IP connections would be made only within a region; inter-regional traffic flow would be via the BITNET backbone. Some of the current leased line connections would no longer be used. For example, George Washington University (GWUVM) has leased line connections to Penn State (PSUVM) and University of Maryland (UMDD). Under this regionalization plan, GWUVM is part of Region 4 and its outbound traffic would flow toward the core site at UMDD. GWUVM's connection to PSUVM would be unused. Another example of a change in the current BITNET topology would be the RSCS-over-IP link between Princeton (PUNFSV2) and Columbia University (CUVMB). This link would be discontinued because it would be inter- regional. CUVMB would be part of Region 2 and PUNFSV2 would be part of Region 3. Connection of Cooperating Networks Cooperating networks, such as EARN and NetNorth, may be connected to BITNET in different ways under this proposal. A cooperating network might be connected to BITNET using a traditional point-to-point connection to one BITNET site and appearing as an extension of the region that the cooperating network physically connects to. An example of this type of connection would be the cooperating network EARN appearing as an extension of Region 2 because of FRMOP22's physical connection to CUNYVMV2. Alternatively, a cooperating network might connect by having multiple RSCS-over-IP connections to BITNET core sites. This could be accomplished in three ways: A designated cooperating network site could have multiple connections to different core sites. An example of this might be UTORVM of NetNorth being the designated NetNorth site and having connections to CORNELLC in Region 1, RICEVM1 in Region 6, and UCBCMSA in Region 7. The second way of accomplishing the connection of a cooperating network is to have multiple sites in the cooperating network connected to multiple core sites. An example of this method of connection might be to have UTORVM of NetNorth connected to CORNELLC in Region 2, MCGILLB of NetNorth connected to RICEVM1 in Region 6, and UALTAVM of NetNorth connected to UCBCMSA in Region 7. This second method of connection should provide greater bandwidth and multiple access between BITNET and the cooperating network. RSCS-over-IP connections between cooperating network sites and non-core site BITNET members would not be permitted. The third way a cooperating network might connect to BITNET would be as a new region or regions. An example of this might be that NetNorth would designate UTORVM and UALTAVM as BITNET core sites. NetNorth would form Region 8 and all BITNET connections from NetNorth would be via these core sites. The connection of a cooperating network to BITNET should be handled on a network-by-network basis because each cooperating network has different requirements and resources. Which implementation is chosen will depend on the structure, traffic flow, and policies of the cooperating network. Conclusion If this proposal is adopted and the implementation plan accepted, the restructing of BITNET's network can be complete in a short period of time, estimated at three months. Every attempt would be made to keep the disruption of BITNET services to an absolute minimum during the restructuring. The restructed BITNET would provide better service to all BITNET members and allow for orderly growth.