[IMR] IMR87-02.TXT Westine [Page 1]  ~ FEBRUARY 1987 INTERNET MONTHLY REPORTS ------------------------ The purpose of these reports is to communicate to the Internet Research Group the accomplishments, milestones reached, or problems discovered by the task forces and contractors in the Internet Research Program. This report is for research use only, and is not for public distribution. Each task force and contractor is expected to submit a 1/2 page report on the first business day of the month describing the previous month's activities. These reports should be submitted via Internet mail to Westine@ISI.EDU. Reports are requested from BBN, ISI, LL, MIT-LCS, NTA, SRI, UCL, and UDEL. Other groups are invited to report newsworthy events or issues. BBN LABORATORIES AND BBN COMMUNICATIONS CORPORATION --------------------------------------------------- WIDEBAND NETWORK BSAT software Release 2.2 was distributed to the Wideband Network sites this month. The new BSAT software runs under Chrysalis operating system Release 2.3.1, and is built using a new C compiler Westine [Page 1]  Internet Monthly Report February 1987 which generates more efficient code than the previously used compiler. The release also includes some minor operational enhancements. The Ft. Monmouth Wideband site were brought back up on the channel. The BSAT and Butterfly Gateway are now up and running. The initial implementation of the BSAT's stream scheduling synchronization software has been completed and debugged in a test network environment. Release of this software will occur early next month after final testing and integration is performed. VAX NETWORKING In the month of February, implementation into 4.3bsd Unix of the Inter-Agent protocol for passing group membership information between Multicast Agents was completed. Debugging and testing of the implementation are taking place on systems at BBN and at Stanford University. Multicast Agents are currently running on one machine at each of BBN and Stanford University. Non-Agent 4.3bsd multicast kernels are currently running on several Stanford systems, and on one BBN system. The wider and more diverse use of the 4.3bsd multicast implementation allows for testing and exercising of the more complex parts of the system. A second release of the 4.3bsd multicast implementation was made available to Eric Cooper at Carnegie-Mellon University. This release includes the inter-agent protocol and numerous bug fixes to the release of 18 December 1986. SATNET The SATNET has been very stable all month. There were no SIMP software crashes and no new SIMP hardware problems. Two sites, Tanum and Fucino, are still not using channel 1, but the adjustments made to channel 0 in January have kept the network healthy. We are awaiting the successful testing of the Linkabit modems to repair channel 1. We have switched our monitoring system over to a new C70 (HNOC). The SIMPs now report to two hosts. The ability to switch between the two hosts should give us more reliability as far as monitoring and control of the network. Periodically we have seen the links between the SIMPs and Gateways flapping. We are trying to isolate the problem. Westine [Page 2]  Internet Monthly Report February 1987 ARPANET STATUS The ARPANET experienced another period of extreme congestion beginning in late January and lasting roughly through mid-February. During this period service across gateways was particularly bad. Over the past six months, transmission capacity in the ARPANET has been critical, especially on the network's cross-country paths. The congestion experienced in January and February was due primarily to a modest increase in traffic that pushed the ARPANET "over the edge". Two significant short-term steps were taken to alleviate the congestion. First, parameters in the network's packet-switching nodes were adjusted to increase the stability of routing along the network's cross-country paths. Second, the software of core gateways running EGP was modified to reduce the rate at which gateways transmit messages such as Hello/IHeardYou, Network Reachability messages, traps, etc. The combined effect of these actions has been to reduce the mean round trip delay seen in the ARPANET by nearly half (620 ms on 23 February vs. 1170 ms on 5 February), and to increase the overall throughput of the network by about 25%. Interestingly, the average message size in the ARPANET has increased; this may be the result of the network "opening" itself more to multipacket messages. The number of 5-packet messages has doubled, and the number of 8-packet messages has increased by a factor of 2.3. While these improvements are real, it should be noted that the fixes made were "band-aid" fixes -- and the box of band-aids is very nearly empty! The long-term solution to ARPANET traffic problems is, of course, additional bandwidth. DCA has initiated actions to procure needed trunking capacity. In addition, several ARPANET nodes will soon be upgraded from C/30E's to C/300s, increasing switching capacity at several locations where that has also been a problem. These actions, together with the network expansion that will soon be taking place, should result, in the long term, in improved ARPANET performance. In the short term, however, we may continue to see congestion, especially if traffic continues to increase before additional trunking capacity is installed. GATEWAYS The Butterfly Gateways continue to be stable. The Wideband Butterfly Gateway at Ft. Monmouth was reinstalled. Except for when a squirrel got into one of the bases substation and vaporized itself which took down the power, the site has been stable. There are now 21 Butterfly Gateways installed. We are seeing some problems with the Ethernet interfaces on a few Westine [Page 3]  Internet Monthly Report February 1987 of the Wideband gateways which cause the interface to freeze. This is being investigated. We made several changes to the core LSI-11 gateways which run EGP to reduce the rate which they exchange updown and reachability messages and made them try harder to keep their EGP connections up. This has reduced traffic (which helps the ARPANET) and has make the overall system more stable. Bob Hinden ISI --- Internet Concepts Project Visitors to ISI were Col. Alex Lancaster (USMC) to discuss ISI operations, and Mary Stahl and Sue Romano from the NIC to discuss RFC formats and the change over of network number assignments to the NIC as of 1-Mar-87. Jon Postel attended the IAB Meeting at SRI, 3-4 Feb 87, and the Congressional FCCSET meeting in San Diego Feb 18. Paul Mockapetris attended the Internet Engineering Task Force meeting in San Jose, CA, Feb 4-6, and the DSAB Naming Task Force meeting at SRI Feb 26. Two RFCs were published: RFC 989: John Linn, IAB Privacy Task Force "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encipherment and Authentication Procedures". RFC 996: D.L. Mills, "Statistics Server". Multimedia Conferencing Project We are investigating the possibility of adapting a commercial video codec for use on the Wideband Net to expand the number of packet video sites. Since the commercial codecs are not very tolerant of lost packets, we need to understand the packet loss rate and distribution for video traffic on the Wideband Net. We have augmented the Packet Video Protocol implementation to allow the detection of missing packets (our experimental packet video system doesn't care about missing packets), so we can now run video for an extended period of time to collect loss information. Brian Hung has integrated the document scanning and multimedia software into one program. Brian is looking at ways of improving the program such as reducing the time it takes to reduce the scanned image and display it on the screen. Brian will also start working on adding the text capability to the existing program so Westine [Page 4]  Internet Monthly Report February 1987 that a message can include both bitmap and text media. Steve Casner and Brian Hung NSFNET Project February must have been National Meeting Month. Bob Braden attended the following meetings: the IAB at SRI; one day of the INENG Task Force at NASA Ames; the NSFNET Federation Assembly in San Diego; and the Computer Network Study Workshop of FCCSET, also in San Diego. Finally, Bob presented a discussion of the Internet architectural model and its corruptions at a one-day SURANET technical meeting at the University of Delaware. Annette DeSchon continued work on a background file transfer server. This server will allow a user to submit a request for a reliable file transfer to take place in the future. A message reporting the results will be returned to a specified mailbox when the transfer has been completed. In addition, she began collecting information on the current topology of the NSFNET. This information will be used to generate maps and host tables in cooperation with the NNSC. Work continued on updating the gateway specification RFC985. Opinions were gathered from the Internet technical community on several controversial points in the specifications. For example, a straw-man proposal that gateways not implement ICMP Source Quench led to a significant discussion, to which many contributed. The concensus was that Source Quench, for all its known deficiencies, is better than nothing. Another hotly debated topic concerned Host Redirects vs. Net Redirects. Finally, there was a concensus AGAINST adopting RFC975 (Autonomous Confederations); this leaves us with a great quandry about what the vendors should do about EGP. Supercomputer and Workstation Communication Project We have achieved a data rate of 1 Mb/s of user-host-generated datagram traffic across the Wideband Net. This was done with ICMP echo pings as part of a series of tests to better understand and isolate the various factors that might affect NETBLT protocol operation over the Wideband Net. The 1 Mb/s rate is close to the calculated total bandwidth currently available on the channel. The traffic was bidirectional: 500 Kb/s (packets of 1400 data bytes every 22ms) going from ISI to the BBN BSAT Echo Host and back to ISI. Two Suns were used, each generating half the traffic, to avoid packet loss in reception of the returned packets. Continued a survey of NSF supercomputer sites, focusing on San Diego's CTSS Cray and Pittsburgh's COS Cray systems. Since Pittsburgh's system is batch oriented (with a VAX VMS front end), and is one of the few sites with Internet FTP working (although its Westine [Page 5]  Internet Monthly Report February 1987 just a user FTP, no server), we should be able to do some interesting experiments, where all workstation/ supercomputer communication is via file transfer. Also, Pittsburgh's front end VAX appears to be on the same local network as a Wideband gateway, so we should be able to FTP via satellite. Continued experimentation with X-Windows. Alan Katz is setting up a standard window environment that will come up when you log in (sort of like suntools), but that can be run from any X-Windows client. Experimented with the various window managers. Alan Katz received a PhD in Physics from UCLA. Steve Casner and Alan Katz MIT-LCS ------- No report received. NTA & NDRE ---------- No report received. ROCKWELL INTERNATIONAL ---------------------- Tactical Internet Multicast Protocols As reported in December's Internet Monthly, David Young has been designing extensions to the multicast protocols presented in RFCs 966 and 988. His goal has been to increase the protocols' efficiency in limited-bandwidth, multi-hop networks and to support host management of multicast groups and their rapid forming/disbanding - functions envisioned as being required for tactical scenarios. During the past two months, David designed the detailed changes to the IP service interfaces and the corresponding changes to the procedures by which multicast groups are formed. He documented these changes in a draft RFC and submitted it to the End-to-End Services Task Force for review prior to official release. The key points are summarized as follows: 1) Add a group membership parameter to the IP service interface function calls. This allows a managing process to specify the members of the group as it is created and maintained. Westine [Page 6]  Internet Monthly Report February 1987 2) Expand the IP to subnetwork service interface to encompass the same functionality as the user to IP service interface. This reflects the parallel operations performed in the internet and the subnetworks during the formation of a multicast group. 3) Enhance the gateway multicast function to make it recognize the group membership list parameter of the IGMP Create Group Request. This implies also that, upon receipt of an IGMP create group request with a non-empty membership parameter, it would send unsolicited IGMP Create Group Replies to one group member in every subnetwork outside of the managing host's subnetwork. 4) Upon creation of a host group in the subnetwork, send an ICMP message via IP multicast to inform the IP modules of each host group member of their membership in the group. A corresponding multicast would occur at the transport layer to activate the process group. 5) Allow captive multicast addresses to be used for multicasting in a subnetwork when a multicast agent is not available to assign a host group address. A preferable alternative would be the following proposal. 6) Take the host group address assignment function out of the gateway and put it in the host. A host creating a host group can derive the group address from the socket address of the originating process. This can then be adapted to the IP header by using the options field to hold the upper part of the address that will not fit in the 32 bit destination address. John Jubin SRI --- No report received. UCL --- UCL have now put up Diamond Release 3.0 succesfully, and have been exchanging mail (including photos) locally and with the US (BBN and UMich). To do this also required the UCL Domain Nameserver to be mildly overhauled. TTL fields are still giving some trouble. The UCL Sequential Exchange Protocol has been ported to the MIT PC/IP environment and is undergoing preliminary tests. Westine [Page 7]  Internet Monthly Report February 1987 The ISODE/Pepy to build automatic presentation level code generators is nearly complete. This will eventually be part of the ISODE kit. Work has started on instrumenting and rate controlling the BSD TCP code so it can be used as a standard measurement tool. John Crowcroft UNIVERSITY OF DELAWARE ---------------------- 1. Development continues on the Dissimilar Gateway Protocol (DGP). The data-base design and transmission model are almost complete. The structure of the routing algorithm is taking shape, as well as the rules for data exchange between systems. A document describing this work has been distributed for preliminary review and will be distributed to the task forces shortly. Meanwhile, development continues on features to support DGP in the fuzzball and Unix 4.3bsd systems. A distributed-simulation package from Columbia is being evaluated as well. 2. Mike Minnich continues gearing up for a heavyweight assault on protocol design and performance issues, in particular TCP retransmission and gateway queueing strategies. Mike is familiar with the work of Van Jacobson, Lixia Zhang and John Nagle and has collected an awsome stash of statistics and simulation packages, as well as my own trove of Internet mesasurements. 3. The fuzzball software configurations at Linkabit, Ford and U Delaware have finally stabilized, as well as the USECOM Patch Barracks (Stuttgart) MILNET outpost. A new gateway DCN-GW connects the old DCNET swamp and serves as backup for the primary UDel gateway. Just for fun the UDel fuzzballs are multi-homed with DCNET and ARPANET (port expander) addresses to keep the routing algorithm warm. Transferring update files to Patch turned out to be astonishingly hard, due to poor network performance in general and also because of PSN interface bugs (also observed elsewhere). 4. The addition of Patch to the Network Time Protocol (NTP) peer group now extends the span of synchronized clocks to Europe. However, preliminary performance evaluation indicates the phase jitter on the European MILNET segment often exceeds the capability of the synchronizing algorithm to deliver continuous time, so that frequent clock resets occur. The Westine [Page 8]  Internet Monthly Report February 1987 algorithm is being studied with the intent of providing adaptive parameters responsive to observed path characteristics. Dave Mills Westine [Page 9]  Internet Monthly Report February 1987 NSF NETWORKING -------------- The NSFnet is an internet originally designed to provide access to NSF-funded supercomputers. Prospective supercomputer sites initially proposed their own consortium networks. These access networks were later augmented by a nationwide backbone which interconnects the supercomputer sites. Additional proposals were received and funded by the NSF to enrich the NSFnet infrastructure by building new regional networks and attaching them to the backbone, and by helping existing networks to attach. The NSFnet backbone sites are located at Cornell University, the University of Illinois (Urbana Campus), the John von Neumann Center in Princeton, the National Center for Atmospheric Research, the Pittsburgh Supercomputing Center and the San Diego Supercomputing Center. Regional/consortium networks currently existing or being implemented are the Bay Area Regional Research network (BARRnet), the consortium networks of the John von Neumann Center and the San Diego Supercomputer Center and the network of the Pittsburgh Supercomputer Academic Affiliates (PSCAAnet), WESTnet, NORTHWESTnet, NYSERnet in New York State, MIDnet in the Midwest, SESQUInet in the Houston area, SURAnet in the Southeast, and the University SAtellite Network pilot project (USAN). Pre-existing networks being connected include the Merit Computer Network in Michigan, CSNET, and the ARPANET - which is being augmented to include a number of NSF-specified sites. Active collaboration and coordination between DARPA and NSF is carried out under the terms of a Memorandum of Understanding signed by the Director of each agency. The NSFnet has already a richly connected infrastructure, building upon and partly using DARPA- developed protocols and systems; DARPA's pioneering network research has played an important role in the implementation of the NSFnet, and many participants in the DARPA-funded efforts are also active in helping the ambitious NSFnet program to succeed. Today the NSFnet is tightly coupled to and reachable by the Internet, of which it is a major component. The NSFnet backbone now contains two transcontinental links; although they currently run at 56 kb/s, there are plans to upgrade them to T1 by the end of the year. It is anticipated that there will be a permanent NSFnet Operations and Management Center later this year. Until then Ed Krol of the UIUC serves as the acting director of the NSFnet backbone and Cornell University runs the interim O&M center. BBN is running the NSFnet Network Service Center, which is an NSFnet equivalent to the Westine [Page 10]  Internet Monthly Report February 1987 Arpanet NIC at the SRI. Several other people are involved in keeping the NSFnet running. However, the following is a first list of people who are responsible for parts of the overall NSFnet: NSFnet Backbone sites: Alison Brown Cornell (607)255-8686 alison@tcgould.tn.cornell.edu Scott Brim Cornell (607)255-9392 swb@devvax.tn.cornell.edu Ed Krol Illinois(217)333-1637 krol@uxc.cso.uiuc.edu Charlie Catlett Illinois(217)333-1637 catlett@uxc.cso.uiuc.edu Brian Gould JVNC (609)520-2000 gould@jvnca.csc.org Sergio Heker JVNC (609)520-2000 heker@jvnca.csc.org Joe Choy NCAR (303)497-1222 choy@scdsw1.ucar.edu Don Morris NCAR (303)497-1282 morris@scdsw1.ucar.edu Mike Levine PSC (412)268-4960 levine@cpwpsca.bitnet Jim Ellis PSC (412)268-6362 ellis@morgul.psc.edu Fred McClain SDSC (619)534-5045 mcclain@sdsc-sds.arpa Paul Love SDSC (619)534-5043 loveep@sdsc-sds.arpa NSFnet backbone support: Scott Brim Cornell (607)255-9362 swb@devvax.tn.cornell.edu Craig Callinan Cornell (607)255-5060 craig@devvax.tn.cornell.edu Dave Mills UDEL (302)451-8247 mills@udel.edu Mike Petry UMD (301)454-2946 petry@trantor.umd.edu Hans-Werner Braun UMich (313)763-4897 hwb@mcr.umich.edu NSF supported networks: Bill Yundt BARRnet (415)723-3909 gd.why@forsythe.stanford.edu Tom Ferrin BARRnet tcf@cgl.ucsf.edu Dick Edmiston CSNET (617)497-2777 edmiston@sh.cs.net Dennis Perry DARPA (202)694-4002 perry@vax.darpa.mil Ed Krol Illinois(217)333-1637 krol@uxc.cso.uiuc.edu Charlie Catlett Illinois(217)333-1637 catlett@uxc.cso.uiuc.edu Brian Gould JVNC (609)520-2000 gould@jvnca.csc.org Sergio Heker JVNC (609)520-2000 heker@jvnca.csc.org Eric Aupperle MERIT (313)764-9423 eric_aupperle@um.cc.umich.edu Hans-Werner Braun MERIT (313)763-4897 hwb@mcr.umich.edu Hellmut Golde NORTHWESTnet(206)543-0070 golde@cs.washington.edu Westine [Page 11]  Internet Monthly Report February 1987 John Sobolewski NORTHWESTnet (206)543-5970 83486@UWACDC.BITNET Richard Mandelbaum NYSERnet (716)275-2916 rma@rochester.arpa Bill Schrader NYSERnet (607)255-8686 cu2@cornellc.bitnet Marty Schoffstall NYSERnet (518)271-2654 schoff@nic.nyser.net Mark Meyer MIDnet (402)472-5108 mark@unlcdc3.bitnet Doug Gale MIDnet (402)472-5108 doug@unlcdc3.bitnet Mike Levine PSCnet (412)268-4960 levine@cpwpsca.bitnet Jim Ellis PSCnet (412)268-6362 ellis@morgul.psc.edu Fred McClain SDSCnet (619)534-5045 mcclain@sdsc-sds.arpa Paul Love SDSCnet (619)534-5043 loveep@sdsc-sds.arpa Guy Almes SESQUInet(713)527-4834 almes@rice.edu Farrell Gerbode SESQUInet farrell@rice.edu Jack Hahn SURAnet (301)454-6030 @umd2.umd.edu:hahn@umdc.umd.edu Glenn Ricart SURAnet (301)454-4323 glenn@umd5.umd.edu Joe Choy USAN (303)497-1222 choy@scdsw1.ucar.edu Don Morris USAN (303)497-1282 morris@scdsw1.ucar.edu Pat Burns WESTnet (303)491-7709 pburns@csugreen.bitnet Dick Jonsen WICHE (303)497-0200 General NSFnet responsibilities: Bob Braden ISI (213)822-1511 braden@isi.edu Jon Postel ISI (213)822-1511 postel@isi.edu Bernie O'Lear NCAR (303)497-1205 olear@scdsw1.ucar.edu Steve Wolff NSF (202)357-9717 steve@note.nsf.gov Dan VanBelleghem NSF (202)357-9717 dvanbell@note.nsf.gov Stan Ruttenberg UCAR (303)497-8998 stan@sh.cs.net Dave Farber UDEL (302)451-1163 farber@udel.edu Dave Mills UDEL (302)451-8247 mills@udel.edu Ed Krol Illinois(217)333-1637 krol@uxc.cso.uiuc.edu Hans-Werner Braun UMich (313)763-4897 hwb@mcr.umich.edu The NSFnet community intends to provide status reports to keep the community informed about ongoing progress and projects that are being worked on. This is the first version of these reports. This being the first one resulted in some differences in the scope of the individual reports. It turned out that one of the reports, the JVNCnet report, included much more information than the other ones. This was leading us to the idea of featuring a particular network more extensively in upcoming monthly reports. For next month Paul Love of the San Diego Supercomputing Center has offered to feature SDSCnet. Westine [Page 12]  Internet Monthly Report February 1987 The following are the individual reports from individual sites. NNSC (NSFnet Network Services Center) ------------------------------------- The NSF Network Service Center (NNSC) provides general information regarding the current state of NSFNET, including the NSF-supported component networks and supercomputer centers. The NNSC, located at BBN Laboratories Inc., is an NSF-sponsored project of the University Corporation for Atmospheric Research. The NNSC has information and documents available on-line and in printed form. It will distribute current news through network mailing lists, bulletins, newsletters, and on-line reports. It maintains a database of contact points and sources of additional information about the NSFNET component networks and supercomputer centers. As a central information service, the NNSC is available as an initial contact point for questions about using NSFNET when prospective users do not know whom to call. The NNSC will answer general questions. For detailed information relating to specific components of NSFNET, the NNSC will help users find the appropriate source for further assistance. The NNSC will encourage development and identification of local campus network technical support to better serve NSFNET users in the future. In addition, the NNSC will help prospective remote users of the NSF Supercomputer Centers use NSFNET to access those centers. Users may reach the NNSC by calling the hotline at 617-497-3400 or by electronic mail at nnsc@nnsc.nsf.net. Karen Roubicek, NNSC User Liaison, roubicek@SH.CS.NET NSFnet backbone sites ===================== The interim NSFnet backbone consists of seven links, tying together six IP gateways. These gateways are all LSI 11/73 systems running Fuzzball software. These Fuzzball gateways will be phased out when the more permanent NSFnet T1 backbone is installed and declared to work reliably. The Fuzzball systems were originally chosen as they were readily available dedicated IP switches supporting a routing protocol which can handle complicated topologies. Westine [Page 13]  Internet Monthly Report February 1987 Cornell University, Theory Center --------------------------------- Besides running a national supercomputer center, the Cornell Theory Center is responsible for network operations for NSFNet and for backup operations for NYSERNet (the New York State regional network). Current activities: Software is in place so that personnel are notified whenever an NSFNet link fails. We currently report on all and error conditions traffic through the fuzzballs (reports are available by anonymous FTP to tcgould.tn.cornell.edu, in directory "nsfnet_traffic"). Starting in the beginning of March statistics will be available for the SURANet gateway. We have also begun software to analyze output from the gatedaemon, to look for excessive route flapping, patterns in round-trip delay variations, and so forth. Reports on NYSERNet are not yet available. See the appendix for a report on "gated". Scott Brim, swb@devvax.tn.cornell.edu University of Illinois, Urbana Campus -------------------------------------- (NCSA, National Center for Supercomputer Applications) ------------------------------------------------------ Charlie Catlett wrote and is still willing to distribute NETSPY to fuzzball sites to allow them to query the fuzzballs without a telnet session startup. He is also working on enhancing the MIT/CMU PCIP based pinger (MONITOR) to act more rationally on large nets, have a better operator interface, and send alarms on performance as well as reachability criterion. Documentation is available in FTP anonymous/cd NSF/readme from uiucuxc.cso.uiuc.edu. The TCP/IP project for Cray CTSS is nearing completion. The Hyperchannel drivers on both ends (CTSS and BSD 4.3) are talking so the implementation can finally be checked for compatability with other Telnet/FTP/TCP/IP implementations. Illinois Bell has notified us in writing that they will supply us with 56kb digital service in mid May. We are pressuring them to replace at least the CMU line with the new service in early March - and they are making an effort to do so! We have finally received our new loads for our campus network Proteon gateways so the conversion to our class B address should be coming within the next month. (We made the mistake of ordering our 7.2 loads with the Decnet option and the delivery was delayed until we said "We would take it without Decnet"). We have ordered a Vita-Link earthstation for Indiana University with a delivery in March. At that time we will drop off USAN and turn into a hub of our own. This was planned from the beginning of Westine [Page 14]  Internet Monthly Report February 1987 the project. Ed Krol, krol@uxc.cso.uiuc.edu John Von Neumann Supercomputing Center, Princeton -------------------------------------------------- General Description: JVNCnet is a high speed packet switched network that connects a central location, the John von Neumann Center (JVNC) at Princeton, NJ with a number of universities (see attached table). At this time all the links are up and the network is fully operational. The purpose of the network is twofold. First, to enable researchers at the universities to access the supercomputer at JVNC. Second, to be part of a larger national network, the NSFnet, which is formed by other Supercomputer centers sponsored by the National Science Fundation. Configuration: The JVNCnet network uses a "star" topology, i.e., all of the communications circuits converge at a single point, JVNC. Two campuses, Harvard and Brown, get access to JVNC through MIT; and Stevens and UMDNJ get access through NJIT. The network's special features are: - access to the JVNC supercomputer. - very high bandwidth mostly T1 (1.544 Mbps), and in a few cases 56kbps. Two satellite links, (see table). - access to large computer networks on the different campuses, plus the NSFnet, and the ARPANET. The LAN is formed by two ethernet cables connecting all our packet switching machines, our front ends, terminal servers, and graphic workstations. The Front-end systems are connected to the supercomputer via a 50Mbps "loosely coupled network". The two ethernet cables as well as all the of point to point links are subnets of the JVNC "class B" number (JVNC-NET, 128.121). The "communication" ethernet is "jvnc-ether" (also 128.121.50.* , where "*" means any number). The other ethernet, "jvnc-admin" is mostly used by terminal servers and two of the front ends, (network number is 128.121.51). The LAN has on line a few SUN workstations for use by high resolution graphics. The APPLETALK network, and the PC-NET network Westine [Page 15]  Internet Monthly Report February 1987 are also integrated into the JVNCnet network to provide computer access for the JVNC managers and staff. The links between JVNC and the remote campuses are point to point links. The interface on the VAX's is the DMR11. The T1 lines, use high speed AVANTI multiplexers with CSU/DSU's to interface to the DDS high speed link. AT&T is the major carrier, for both the T1 lines and 56k lines. The packet switching is performed by VAX750's and VAX8600's running ULTRIX. And ip routers on alpha test. At JVNC one VAX8600 ("JVNCA") handles the load of 5 high speed T1 circuits, and two ethernets. One VAX750 ("JVNCB") is connected to 1 high speed T1 circuit two 56kbps circuits and one ethernet. One VAX750 ("JVNCE") connected to 1 high speed T1 circuit and one ethernet. The satellite service connects JVNC with the University of Arizona, and the University of Colorado. This is accomplished by using VITALINK Bridges which "extend" the ethernet all the way to these remote locations. At MIT's gateway to JVNC ("COVENTRY"), the machine handles 3 T1 circuits, one to JVNC, one to HARVARD, and one to BROWN, and also the access to their campus via the ethernet. An ip router connects a 56kbps line from NJIT to our subnet 50. Similar routers at NJIT connect to Stevens Tech and UMDNJ. All the lines are 56kbps for these three New Jersey institutions. JVNC has also a MICRO-PDP-11 ("FUZZBALL") running specialized software that serves as the packet switched node to the NSFnet. Protocols: Like the ARPANET and NSFnet, JVNCnet also uses TCP/IP protocols. They are widely used by the Universities, and they are supported by the ULTRIX, and BSD operating systems, as well as on other OS's by many vendors. Other services include TELNET (virtual terminal connection), FTP (File Transfer Protocol) , SMTP (Simple Mail Transfer Protocol), FINGER, WHOIS, etc... Mail: - SMTP (ARPA mail) One of the machines, "jvnca" is our major mailer for "ARPA" mail. And it serves all the other UNIX based machines on our network. It also serves as the mail "distributor" at JVNC, for mail that is not delivered directly to the front ends. Westine [Page 16]  Internet Monthly Report February 1987 Our arpa mail address is "username@jvnc.csc.org". - BITNET One of the front ends, JVNCC has a direct access to BITNET. We get our BITNET access thru Princeton. In order to do that we use 9600 bps extra bandwidth out of our T1 line to Princeton, and we feed that directly into JVNCC. Our BITNET address is "username@jvnc". Currently the bitnet node is "jvncc" so the address at this point is "username@jvncc". Access to Other Networks: NSFnet: The JVNC is one of the six backbone components of the NSFnet. Thus our access to the NSFnet is a direct one, since the "fuzzball", is on our major "communications" ethernet. We have a 56kbps line to the Cornell Fuzzball and another 56kbps line to the CMU Fuzzball. At the present time JVNC is contributing to the NSFnet traffic with approximately 20 different networks being advertized to the NSFnet backbone from JVNC. ARPANET: We will be able to reach ARPANET via 11 out of the 13 member of the JVNC consortium. At this point we are being announced to the ARPANET core machines by three IMP's, one at the CMU Center, one at the University of Pennsylvania, and one at Columbia University. The last two are members of the JVNC Consortium (the line to U. of Pen is a T1 line and the line to Columbia is a 56kbps line). We are also expecting our own IMP to be in placed at the end of March. Routing: Routing at JVNC is performed by the GATED routing program developed at Cornell University. The routes at the main gateways of JVNC, JVNCA, JVNCB and JVNCE is performed by the use of GATED. This program uses RIP to exchange routing information between the JVNC hosts and gateways, as well as with the "remote gateways", the program is also capable of exchange EGP reachability information and it talks and listen to HELLO packets (the NSFnet routing protocol). Most of the "remote gateways" of the Consortium are already running "gated" and their access to JVNC, JVNCnet and the rest of the NSFnet is integrated with their campus networks. A few of them are Westine [Page 17]  Internet Monthly Report February 1987 in the process of integrating their campus networks. We are providing all the support that they need so they can have a smoth path to full access to the national networks. Due to this kind of routing mechanism, part of the ARPANET traffic that is currently going from some of our consortium members to other consortium members traverse JVNCnet lines instead of taking the ARPANET route. At the same time there are multiple ways to access JVNC via ARPANET, as well as the NSFnet. This provides a backup service for our "star" configured architecture, allowing maximum reachability from the Consortium sites to JVNC. Dial-In Access: JVNC offers dial-in access via 32 300/1200/2400 MNP error correcting modems. The modems are hard-wired to a terminal server that is connected to subnet 50 (jvnc-ether). From this terminal server, the users can access any of our front ends (JVNCC, JVNCD, and JVNCF). Also we provide access to/from the TYMNET network, for some users that cannot reach JVNC otherwise. Network Monitoring: Network monitoring is performed from JVNCA automatically by sending "echo packets" addressed to the different gateways and hosts of the JVNCnet network. This information is used to compute statistics based on the percentage of returned packets as well as the round- trip delay. The program performs the following functions: (1) collects the statistics of the network, (2) sets an alarm to the operator and to the com person when one of the gateways/hosts/super computer doesn't respond, (3) creates a daily, weekly, monthly report of the status of the network, including information of: a.- the number of times every node goes down, b.- the mean time to recover, c.- the mean time between failures, d.- the maximum time to recover, e.- the percentage of utilization ( or access ) to every gateway, hosts and to the supercomputer (4) records when a point to point link is not performing at its optimum level. (5) graphics color display of the network status in our main area at the JVNC. Westine [Page 18]  Internet Monthly Report February 1987 The scheduling of maintanence for the gateways and hosts that make the JVNCnet network, is done with the help of a database like program that the operators run. This information can be accessed by anyone that can get to the JVNCnet network, by using "finger" (the command is: finger schedule@jvnca.csc.org). The network monitoring and scheduling is done 24hs a day seven days a week. The computer operators are trained to attend the network. There are communication people on call 24hs a day seven days a week to maintain the system available. Special efforts are being underway to improve our monitoring system, based on the past experience and the inmediate needs. Special procedures have been written for the Operators so they can monitor the JVNCnet and the NSFnet, and also to initiate troubleshooting, and determination of the problems. Name Servers: JVNC provides the means to resolve the JVNC hosts names for the domain "CSC.ORG", for the entire internet community that utilizes "name servers" (NS). At the same time, JVNC has sponsored the few Consortium members that were not running NS's, to start doing so. At this time, with the exception of one campus, ALL the Consortium members are running NS's. Some of these campuses NS's are backups for other campuses NS's belonging to our Consortium. Due to our natural communication means, the JVNC provides the ideal path for that backup servers to update their data over the JVNCnet network. Currently, the JVNCnet network with its domain "CSC.ORG", is being served by a name server running on JVNCA.CSC.ORG, (also known as JVNCA). This is our primary name server and the authority for the domain CSC.ORG. The network also has backups, or secondary NS's, one in MIT, (BITSY.MIT.EDU), and the other in Penn State (PSUGATE). JVNCA is a backup for Princeton's University domain "PRINCETON.EDU". The Princeton domain is served by a primary name server running at PUSUPER, and with JVNCA as its backup. Note that PSUGATE, as well as PUSUPER are both vax750's that are 1 hop away from JVNC, and form part of the JVNCnet network. The links between them and JVNC is provided by high speed T1 lines (1.544Mbps). Reachability is provided to BITSY.MIT.EDU via JVNCnet, NSFnet and ARPANET, as are PSUGATE, PUSUPER and JVNCA. Westine [Page 19]  Internet Monthly Report February 1987 NSFnet Support: As an interested member of the NSFnet we are providing NSFnet external operations as a backup for Cornell and also after hours. This kind of support is part of the cooperation that exist between the NSFnet sites and it is the only way to keep the network operational. Westine [Page 20]  Internet Monthly Report February 1987 THE JVNCnet NETWORK =================== 128.121.51 128.121.50 ethernet ethernet || || T1 || || |--- RUTGERS || || | T1 || || |--- U.OF.PEN || || | T1 T1 || ||------ JVNCA------ MIT ------- HARVARD ||------------------------| | T1 || ||* |--- IAS || || | T1 || || |--- PRINCETON || || || || 56k || || |--- U.OF.ROCHESTER || || | 56k || ||------ JVNCB------ COLUMBIA || || | T1 || || |--- NYU || || || || T1 || ||------ JVNCE------ PENN.STATE || || || || 56k || ||------ BRIDGE----- SATELLITE------- U.OF.ARIZONA || || | 56k || || |---- U.OF.COLORADO || || || || 56k 56k || ||------ UB-ROUTER---- NJIT----- STEVENS INSTITUTE || || | 56k || || |------- UMDNJ || || || || 56k || ||------ FUZZBALL------- CORNELL || || (NSFnet) | 56k || || |----- CMU || || || ||------ dial-in terminal servers ( and TYMNET access ) || || || ||------ JVNCC----------- || || | |==== CYBER205.1 || |CI-bus | || | |loosely_coupled_network ||---------------------- JVNCD----------- || | || |==== CYBER205.2 || | Westine [Page 21]  Internet Monthly Report February 1987 ||---------------------- JVNCF----------- || ||---------------------- graphics machines || ||---------------------- staff terminal servers || note: (*) JVNCA is connected to both ethernets, and 5 T1 lines JVNCA: vax8600 running ULTRIX1.2 JVNCB: vax750 running ULTRIX1.2 JVNCE: vax750 running ULTRIX1.2 JVNCC: vax8600 running VMS JVNCD: vax8600 running VMS JVNCF: vax8600 running ULTRIX1.2 JVNC Consortium =============== node access to Arpanet Type of line ---- ----------------- ------------ U. of Pennsylvania yes T1 MIT yes T1 Harvard U. yes T1 Brown U. no T1 * IAS no T1 Princeton U. no T1 * Rutgers U. yes T1 Penn State no T1 * NYU yes T1 NJIT no 56kbps * Stevens no 56kbps * UMDNJ no 56kbps * Columbia U. yes 56kbps U. of Rochester yes 56kbps U. of Arizona no 56kpbs satellite U. of Colorado no 56kbps satellite where T1: 1.544 Mbps *: they get access via JVNC Sergio Heker, heker@jvnca.csc.org Westine [Page 22]  Internet Monthly Report February 1987 National Center for Atmospheric Research ----------------------------------------- (and University SAtellite Network project) ------------------------------------------ All USAN sites except Woods Hole are up and running. The cutover from 128.117 to 128.116 for the USAN sites is scheduled for the week of March 9, which means either Mon or Fri of that week because of the USAN meeting. The Proteon p4200 gateway between 128.116 and 117 is up and has been tested. There is also a CISCO gateway to the Univ. of Colorado. The essential configuration will be as shown: Satellite to JVNC | fuzzball USAN sites CISCO to U Colo TRANSLAN to 30th st | | | | ----------------------------------------------------------- 128.116 | PROTEON | ------------------------------------------------------------ 128.117 Various NCAR divisions connected by Bridges Severe snowstorm eve. of 18 Feb and morning 19 Feb in Boulder affected USAN performance, causing periods of total outage. Don Morris, morris@scdsw1.ucar.edu Pittburgh Supercomputer Consortium ---------------------------------- Despite line problems, the PSC Fuzzball has been running well. The machine will be rebooted with the latest version of software on February 20. We are scheduling retermination of the NSFnet leased lines to our local offices where we will have quicker and easier access to both the Fuzzball and PSC-Gateway. We are trying to schedule this for early March. Shortly after this we will transfer the PSC machines from the CMU network (128.2) to our own net (128.182). We have been testing Proteon P4200 Gateways with 56Kbps and T1 interfaces for use with our PSCnet. We hope to order the lines for PSCnet shortly. The psc-gw seems to be much better shape in recent weeks. BBN has adjusted the flow control parameters on our PSN and if they continue to work well here, then Darpa will request that this fix Westine [Page 23]  Internet Monthly Report February 1987 be applied at other X.25 sites. It appears that the design of the 5250 causes its performance to degrade faster than the 1822 interfaces in the face of heavy load at the PSN. ACC plans to have new ROMs to address this problem by early April. Jim Ellis, ellis@morgul.psc.edu San Diego Supercomputing Center ------------------------------- The San Diego Supercomputer Center (SDSC) is one of five such centers initiated by the National Science Foundation (NSF) in 1985. The primary research tool at the center is a CRAY X-MP/48 supercomputer. An SCS-40 minisupercomputer has just come online for research use; both run the interactive Cray Time Sharing System (CTSS) operating system developed at the Lawrence Livermore National Laboratory. In addition to these two systems, DEC and IBM equipment play a major role for communications and file systems. Researchers from more than 100 institutions scattered from Maryland to Hawaii are currently allocated time on one or more of the systems. The San Diego Center has attempted to provide as many types of communication links as its researchers find most suitable. To that end, it has joined several existing networks. A brief summary is set out below. A much more detailed picture will be in next month's report. SDSC is a backbone node of NSFnet. The center has NSFnet direct links to the supercomputer center at the University of Illinois and NSF's National Center for Atmospheric Research at Boulder; both at 56 kbits/s. A line will soon be in place to NASA's center at AMES providing a link between NSFnet and the NASA Science Internet. Connection via telnet to the SDSC Cray has been available for the past several months; FTP service will be inaugurated in late March 1987. During 1987, SDSC plans to extend IP services out from the center to the members of its consortium. Members of the SDSC consortium and some industrial users belong to SDSCnet, a network modeled on supercomputer network of the National Magnetic Fusion Energy Computer Center (MFEnet). SDSCnet nodes (VAX/VMS systems) access the supercomputers primarily via 56 kbit/s terrestrial or satellite links. The nodes themselves are often on university LANs and/or regional nets, with the usual benefits such provide. As SDSCnet and MFEnet are connected, SDSCnet users can access MFEnet sites, including the supercomputers at Livermore and at Florida State University. Conversely, MFEnet users can access the SDSC systems. Since several sites with allocations of time at SDSC use DECnet as their primary network, SDSC has implemented software to support their access to the center's systems. Additionally, the center has joined NASA's SPAN to enlarge the number of users with a connection Westine [Page 24]  Internet Monthly Report February 1987 to the center and to provide researchers at the center with access to SPAN's resources. Due to the interconnections of SPAN and DOE's HEP, users of that network can also connect to SDSC. Finally, SDSC is connected to BITnet and TYMnet. Dial-in telephone lines are also available. Paul Love, loveep@sdsc.arpa NSFnet regional, affiliated or consortia networks ================================================= Bay Area Regional Research network (BARRNET) -------------------------------------------- Two of five T-1 links for BARRNET backbone installed by telco (PacBell), third nearing completion, line four will be on UC owned microwave microwave from UCSF to UC Berkeley, which is available now. Fifth link will be third party supplied microwave from UC Berkeley to UC Davis, installation scheduled for March. Lawrence Livermore Labs and Stanford Linear Accelerator center have expressed interest in links into BARRNET. Univ of Nevada at Reno also expressed interest earlier. Proteon routers with Ethernet and full T-1 interfaces (SBE boards) have been bench tested at Stanford with Avanti Accupak 1.5 data formatters (DSX-1 interface w/o CSUs). Appears that with the CSU (Avanti's internal "ISU") the effective thruput will be limited to 1.344Mb/s by the Avanti because it uses straight bit-stuffing to meet the telco connect requirements. As a result, we have started testing Verilink units which use an algorithm for maintaining the telco T-1 bit density requirements that appears to avoid the loss of the 192kbps. Will also test Phoenix microsystems units which purport the same in their reformatter/CSUs and have a better physical configuration (8 packs, formatter or CSU to a 19" rack) and a built-in BERT in CSU. Have not attempted any thruput testing yet. First link to be activated will be NASA Ames to Stanford, second planned to be UCB to UCSF and UCB to Stanford. First one should be on air next week, second and third by first week of March. Bill Yundt, gd.why@forsythe.stanford.edu Illinois network ----------------- (refer to the UIUC backbone report) Westine [Page 25]  Internet Monthly Report February 1987 John von Neumann Supercomputing Center network (JVNCNET) --------------------------------------------------------- (refer to the JVNC backbone report) Merit Computer Network ----------------------- The Merit Computer Network began in the early seventies as an interuniversity network for the state of Michigan. Merit received NSF funding for its initial implementation, but is now funded by the affiliated Universities. However, Merit recently received some NSF funding to implement the TCP/IP protocol suite so that the Merit Universities can access the NSFnet. At the time of this writing Merit has 189 dedicated packet switching nodes, of which 26 are Primary Communications Processors (PCP) and the other 163 are Secondary Communications Processors (SCP) . Twentysix X.25 links are attached to the network, as well as 6168 asynchronous ports. Merit also connects to several mainframes via channel interfaces. One of Merit's SCPs is in Washington DC, connected via a dedicated link, and another as an experimental node at NCAR, connected via the USAN satellite network. Merit is connected via two links to the Telenet public data network and via a single link to ADP Autonet. As part of the NSF funded IP development effort Merit packet switching nodes, which are running a locally written data communications operating system, are now able to switch IP datagrams throughout the network. We anticipate this to work in conjunction with channel attached mainframes soon. At this point of time we can attached Ethernets to the Merit nodes as well as asynchronously attached PCs (running, e.g., the asynchronous version of the MIT PC/IP code). We anticipate a SLIP implementation for the asynchronous lines to be working soon. A detailed description of the Merit Computer Network can be obtained by sending a message to Merit_Computer_Network@UM.CC.UMICH.EDU which includes a USMail address. This electronic mail address can also be used to reach user consultants in case of any questions. An alternative way to contact the Merit Computer Network is by calling (313) 764-9423. Hans-Werner Braun, hwb@mcr.umich.edu Westine [Page 26]  Internet Monthly Report February 1987 NORTHWESTnet ------------ NorthWestNet is not active yet; negotiations with NSF are still in progress. Hellmut Golde, golde@cs.washington.edu NYSERnet -------- As of 20 Feb 1987, NYSERNet has the following topology with 56kbit links. T1's are also in place for the topology of below but have not been cutover to the switching gear. Rochester--------Cornell---------RPI | | | | | | Columbia NYU Internal routing is via RIP, the switching gear is Proteon4200's. NSFNet+Regional routing goes through Cornell's Fuzzball. Generalized INTERNET routing is site specific. Then NYSERNet Network Information Center opened on the 6th of February information can be obtained throught nic@nic.nyser.net or 518-266-NNIC. Marty Schoffstall, schoff@nic.nyser.net MIDnet ------ Gateway-routers have been selected and ordered (Proteon). Our biggest problem has been getting 56 kbs telephone lines into all locations. After innumerable meetings with telephone companies we are nearing resolution on that issue. In November MIDnet held its second regional meeting in Kansas City. In addition to business items there were several presentations and tutorials. A one day visit to NCSA by MIDnet users and user services staff is scheduled for March 30 and a third regional meeting for sometime in April. We hope to have some line segments operational in late April and the whole network up during the summer. Doug Gale, doug@unlcdc3.bitnet SDSCnet ------- (refer to SDSC backbone report) Westine [Page 27]  Internet Monthly Report February 1987 SESQUInet --------- We are currently funded by NSF and are shopping for phone lines and for gateways. In the gateway market, we are considering Proteon and Cisco. Initial sites will include: Baylor College of Medicine (Texas Medical Center, Houston) Houston Area Research Center (north of Houston) Rice University (Houston) Texas A&M University (College Station) Texas Southern University (Houston) University of Houston (Houston) Future growth will include the University of Texas, Baylor University, the NASA Johnson Spacecraft Center, and other campuses of the Texas Medical Center." Guy Almes, almes@rice.edu SURAnet ------- SURAnet Phase I is composed of 15 institutions in 12 states and the District of Columbia. Geographically, SURAnet ranges from Delaware, in the North, to Florida,in the South, and goes as far West as Louisiana. Topologically, SURAnet is composed of a major loop plus a number of stubs. The nodes in the loop are the University of Maryland, George Washington University (in the District of Columbia), Virginia Tech, the Triangle Universities (in North Carolina), Clemson University (in South Carolina), Georgia Tech, the University of Alabama at Birmingham, the University of Tennessee, and the University of Kentucky. The stubs are the University of Delaware,the National Science Foundation (in the District of Columbia), Florida State University, Louisiana State University, the University of West Virginia and the University of Georgia. LSU, FSU, the University of West Virginia, and the University of Georgia are the four sites which remain to be connected to the Network. All Suranet sites reachable by AT&T 56 kb lines were interconnected last Fall. Westine [Page 28]  Internet Monthly Report February 1987 Proteon routers for these sites were configured and tested at the University of Maryland. They were shipped to the sites by late December. They were talking to each other,for the most part, by the middle of January. The reliability of version 7.1 of the Proteon software was very poor. We decided that we had to move to version 7.2 with all possible speed. Prior to moving to 7.2 it was decided to hold a meeting of SURAnet site technical representatives, invited experts and guests. This was held at the University of Maryland on Feb. 13 and 14 and had over 70 participants. Version 7.2 is presently being installed. We anticipate that 7.2 will be more robust than 7.1. We will be in a position to report on this shortly. As I tried to convey above, all connected sites have been operational briefly, perhaps not all at the same time, under version 7.1 of the Proteon software. However, 7.1 had very poor reliability. We decided to move to 7.2. At this instant in time only Maryland and George Washington are running 7.2. It appears to be much more robust. We are trying to move to 7.2 at all connected sites very quickly. Ask me again next week. I am optimistic! Jack Hahn, hahn@umdc.bitnet WESTnet ------- (no report received as no email address was available at the time of contacting individual sites for this month's report) Westine [Page 29]  Internet Monthly Report February 1987 TASK FORCE REPORTS ------------------ Note on Task Force Mailing Lists For each Task Force there are two lists: taskforcename-TF@ISI.EDU is the task force itself, and taskforcename-INTEREST@ISI.EDU is other interested people. Anything that goes to the -INTEREST list is copied automatically to the -TF list (the -TF is a subset of the -INTEREST). The -TF list could be use to discuss TF business (meetings, minutes, schedules, plans, details). The -INTEREST list could be for free discussion of concepts and technical issues where you want ideas from anybody interested. Any additions or deletions to either list will be handled by Ann Westine (Westine@ISI.EDU). APPLICATIONS -- USER INTERFACE The task force is still in the midst of reorganization. Current members include Steve Casner (ISI), Terry Crowley (BBN), Jose Garcia Luna Aceves (SRI), Sunil Sarin (CCA), and Joseph Sventek (ANSA Project). Prospective members should contact me via e-mail (lantz@score.stanford.edu) as soon as possible; a meeting is being planned for early spring. Keith Lantz AUTONOMOUS NETWORKS A meeting is planned for 20-21 March in Palo Alto, California, and the task force mailing list is now in operation (AUTONETS-TF@C.ISI.EDU). Deborah Estrin Westine [Page 30]  Internet Monthly Report February 1987 END-TO-END SERVICES No progress to report this month. Bob Braden INTERNET ARCHITECTURE INARC related issues were discussed on several lists, including those related to the proposed Dissimilar Gateway Protocol (ineng-tf and nsfnet-routing) and host/gateway monitoring (gwmon). Dave Mills INTERNET ENGINEERING No report received. PRIVACY Following circulation of a final internal draft to the task force membership and processing of resulting comments, the Privacy Task Force RFC, "Privacy Enhancement for Internet Electronic Mail: Part I: Message Encipherment and Authentication Procedures", was submitted for distribution to the Internet community. It is now available from SRI-NIC as RFC989. The next task force meeting was scheduled for 31 March-1 April at RIACS. John Linn ROBUSTNESS AND SURVIVABILITY No report received. SCIENTIFIC COMPUTING No report received. Westine [Page 31]  Internet Monthly Report February 1987 SECURITY No report received. TACTICAL INTERNET No report received. TESTING AND EVALUATION No report received. Westine [Page 32]  Internet Monthly Report February 1987 APPENDIX ======== Network Routing Deamon for 4.3bsd (and like) Systems ---------------------------------------------------- Gated is a routing daemon that handles multiple routing protocols and is meant as a replacement for the Unix routed and egpup deamons, as well as any routing daemon that speaks the HELLO routing protocol. Gated currently handles the RIP, EGP, and HELLO routing protocols. The gated process can be configured to perform all 3 routing protocols or any combination of the three. The configuration for gated is by default stored in the file "/etc/gated.conf", but can be changed at compile time. Gated can be invoked with a number of debug flags and/or a log file. When debug flags are used, the process does not fork and detach itself from the controlling terminal. If there is no log file specified, all debug output is sent to the controlling terminal; otherwise, the debugging output is sent to the log file specified. The interaction of the three routing protocols are as follows: - Any route learned via an interior routing protocol (HELLO/RIP) takes precedence over the externally (EGP) learned route. More specifically, if a route is learned of via RIP and there is already an external route learned of via EGP, the EGP route is deleted and the RIP route is installed in its place. In effect, the exterior (EGP) route is used as a backup route should the interior (RIP/HELLO) route become unavailable. - Routing information learned via an interior routing protocol can be selectively passed on to the exterior routing protocol. Specifically, RIP and HELLO information can be passed on to EGP for further propagation. - Routing information learned from an exterior routing protocol is not passed on to the interior routing protocol. Specifically information learned via EGP is not passed on to RIP or HELLO for further progagation. With the emergence of the NSFnet and many regional networks like NYSERnet and SURAnet, the paths to different sites are not exclusively over the ARPAnet any more. There are many back doors and redundancies in the Internet. The gated process allows a site to take full advantage of the redundancy Westine [Page 33]  Internet Monthly Report February 1987 of the Internet dynamically. It allows sites to use a faster regional network link and still be able to rely on a slower ARPAnet link as a backup. Gated currently runs under 4.3BSD UNIX, DEC Ultrix V1.2, GOULD UTX/32 V1.2, V2.0. The code was and is still being developed at Cornell University and the University of Maryland. For more information on the protocol specifics, consult the following RFC's: RFC827 - EGP formal specifications. RFC891 - HELLO formal specifications. RFC911 - EGP under UNIX 4.2BSD routed(8) - BSD UNIX manual page describing the RIP process. For more information on gated contact: Mark Fedor Cornell Theory Center 265 Olin Hall, Cornell U. Ithaca, NY 14850 fedor@devvax.tn.cornell.edu Mark Fedor, fedor@devvax.tn.cornell.edu Westine [Page 34]