The Stanford University Network (SUNet) consists of local networks within buildings, and a backbone network that connects the local networks to each other and to networks off campus. The backbone is designed and operated by Networking Systems, a division of Distributed Computing and Communication Systems (DCCS), part of Information Technology Systems and Services (ITSS). Network services within a building are the responsibility of the department(s) that occupy that building. There are approximately 280 active local networks on campus. According to our most recent estimates, more than 18,000 users access SUNet every day. Ten Networking Sytems engineers design, build, and operate the SUNet backbone network and related services.
In the case of academic and administrative buildings, Networking Systems provides and supports the data communication infrastructure up to, but not beyond, the facility entrance. Networking Systems provides training and services that enable departments to manage the local network within the buildings. Four Networking Systems staff support approximately 400 local network administrators (LNAs), representing every School and administrative unit of the University.
For student residences, Networking Systems supports the data communication infrastructure to the telecommunications service outlet in student rooms. The Residential Computing group within Housing and Dining Services supports student use of network services in student housing facilities and interfaces with Networking Systems when necessary. Two Networking Systems staff members support network service to the student residences.
There are over 24,000 computers that actively use SUNet, and we are still experiencing a 25% growth per year in the number of SUNet connections. We estimate that the total number of networked computers on campus will peak at about 40,000, based on the size of the campus community and the increasingly important role network-based communications plays in the University's academic and administrative affairs.
The SUNet backbone is based on Fiber Distributed Data Interface (FDDI) technology, with an Ethernet backup network. Over the last two years, the original FDDI backbone and server rings have been divided to increase the capability to handle traffic. SUNet is currently comprised of six active FDDI rings: three rings form the true backbone that interconnect routers; two are server networks for the Distributed Computing Group (DCG), the DCCS division which provides academic computing resources; and one is used as the network carrying traffic on and off campus to our BBN Planet (formerly Bay Area Regional Research Network, BARRNet) connection. See Figure 1 for a graphical representation of today's topology.
The most recent change to SUNet was the addition of a Cisco 7513 router as the main traffic exchange point. All six FDDI rings are connected to this router. The internal bandwidth of this router, approximately 2 gigabits per second, now represents our capability to handle backbone traffic.
This router has been named Core-Gateway to reflect its function. The connectivity provided by Core-Gateway is backed up by leaving the original Cisco routers (AGS+ and 7000) in place to provide continued routing between the FDDI rings should there be any problem with Core-Gateway. Core-Gateway also contains two fast Ethernet interfaces, which will be used to connect additional server nets, one for the administrative systems in Forsythe Hall and one for the academic servers in Sweet Hall.
There are 12 primary gateways that comprise the balance of the backbone. Four of these gateways are Cisco 7000s, and eight are Cisco AGS+ routers. The legacy Cisco AGS routers are still being used as well, though mostly as second level routers called departmental routers. These routers are used to divide congested building networks into multiple subnets. Each Ethernet network is connected to two backbone routers for redundancy.
Another evolution in the SUNet backbone has been the switch to using the Open Shortest Path First (OSPF) protocol for exchanging routes among the routers. This protocol, developed by the Internet Engineering Task Force (IETF), provides very quick selection of alternate routes in the event of network problems. It has already proven itself several times, transparently routing around interface failures.
The standard protocol on the backbone is TCP/IP. There are no other protocols routed on the backbone at this time. Windows NT already uses the IP protocol, and NetWare users can migrate their servers to IP. AppleTalk is the only other protocol that is currently under discussion for support. This is due to Stanford's large installed base of AppleTalk computers and peripherals, more than 8,000 at last count.
Today, the campus Appletalk internet is composed of approximately 300 Shiva Fastpath gateways that provide connections between Appletalk zones by encapsulating Appletalk inside IP packets. The zone list is centrally managed and distributed. Over the years, this arrangement has proven remarkably reliable given the large number of gateways that must be coordinated. However, the Fastpath technology is no longer actively supported by Shiva Corp. and our aging set of Fastpaths will become incresingly problematic. Apple's Open Transport technology promises to be support IP as a transport mechanism, but release is unlikely before 1998.
In the short term, we plan to further divide the FDDI infrastructure into "community-based" rings. A community would consist of groups of users that tend to exchange a large amount of their traffic among themselves. The next two community rings being created will be a dormitory ring for the student residences and an administrative ring focused on buildings where staff mostly communicate with the administrative systems in Forsythe Hall.
While we continue to use FDDI as the production network, we are experimenting with Asynchronous Transfer Mode (ATM), the technology that many feel represents the next generation of network service. ATM promises to bring higher capacity than FDDI, plus quality-of-service guarantees with bandwidth reservation, features necessary for new multimedia and digital video applications. Most networking suppliers are focusing on ATM as the next generation technology.
Thanks to the foresight of the Computer Science faculty and a generous donation from Cisco Systems, the new Gates Computer Science building has the infrastructure necessary to benefit from ATM, and Networking Systems staff are assisting in the activation of this equipment. New routers deployed for the dorm backbone will have ATM capability, allowing us to compare FDDI with ATM.
Another promising technology for the server networks is "Fast Ethernet," an enhanced CSMA/CD technology running at 100 megabits per second. Both the academic server networks in Sweet Hall and the administrative server networks in Forsythe Hall plan to deploy a Cisco Catalyst-5000 switching hub to provide a switched Fast Ethernet connection to the backbone network.
The Cisco Catalyst-5000 hubs deployed in the Gates building, have shown solid performance using virtual LAN (VLAN) technology. When combined with ATM connectivity, these hubs will provide Stanford with additional flexibility in delivering SUNet to campus workgroups. With routers using ATM LAN Emulation (LANE) standards, VLANs running over ATM will deliver increased bandwidth at lower cost becuase they require fewer fiber optic connections than today's SUNet delivery methods.
There has been a significant effort over the last eight months to move from best- effort support to a production-level environment. Toward that end, additional staff have been hired, an on-call program has been implemented, and a service-level committment has been introduced.
One of the staff additions is an off-hours engineer who provides extended weekday coverage. Networking Systems now provides 5-day, 16-hour coverage, Monday through Friday (7am-11pm). Additional coverage is provided through a combination of on-call engineers and a negotiated agreement with the Forsythe Hall computer operations staff, members of the ITSS Operations, Systems and Services group.
The Forsythe systems operators pick up SUNet hot-line calls on weekday nights and all day Saturday and Sunday. They have been trained to answer first-level questions and given instructions on how and when to refer calls. Networking Systems engineers are on call during these hours to provide extended support. A cellular phone, pager, and laptop computer with modem facilitate complete communication for the on-call engineer.
The second staff addition is a software programmer to support SUNet Operations. This person provides a consistent resource for initial troubleshooting on the software products that Networking Systems maintains. This position also gives us dedicated resources to support special programming requirements of the SUNet Operations group.
The SUNet Service Level Commitment was implemented in February, 1996. The Commitment identifies key backbone services that will be supported with highest priority, and other services that will be treated with high, but not critical support. The goal is 99.8% availability of key services. The Service Level document outlines the various support hours and response times that SUNet customers can expect. The response times are based on the nature of the network or product in question, and how important the item is to campus network operation.
The reporting portion of the Service Level Committment is still under development. Developing consistent, accurate methods of measuring up-time and producing reports of the measurement have been difficult to accomplish.
Network management and monitoring has been as difficult at Stanford, as in all large network environments. Currently, we are running at least six different commercial products and compiling the various results using scripts.
The greatest difficulties in consolidating products are: the variety of equipment that is being monitored, the lack of a single product on the market that will meet our needs, the lack of sufficient customization options in the products, the lack (so far) of a modular approach in providing management products from the management platform vendor, and the proprietary nature of information retrieval and display of each platform.
Some of this will be rectified when more third party providers begin building for the major platforms, and the platform providers make their products more general as they mature. Standards for management features, data interchange and performance will emerge. For the time being, we'll continue to use a wide range of products.
For more information about the Stanford University Network, call the Networking Systems office (415-723-3909) or send email to HelpSU.
| Back to Top | | Networking Systems |
Last Modified: 5/17/96