The University of Georgia has initiated the Virtual Electronic Network for University Services, hereinafter refereed to as VENUS, project through the University Computing and Networking Services (UCNS) department on the Athens campus. This project will create a fiber optic network infrastructure to interconnect approximately 200 buildings over an Asynchronous Transfer Mode (ATM) backbone. This backbone will provide connectivity for the legacy LANs already in use and allow for the development of new multimedia applications.

The project is phased to match the capabilities of UGA to acquire funds, allocate space, construct backbone telecommunication closets, install fiber optics, install network electronics, and configure the systems.

The purpose of this document is to present a detailed logical design of the campus fiber optic network infrastructure. The reader of this document is assumed to have basic knowledge of networking and approaches to physical connectivity infrastructures. Installation of the designed network will then enable implementation of ATM technology.

The logical design documentation provides UGA with the following information:

The logical design concepts will be used by the physical designer to establish:

This logical design concept will provide network backbone requirements and overall systems performance criteria which may be referenced to assess the success of the resulting networked environment.

Like many campuses, the University of Georgia has successfully deployed "first generation", shared media networking technologies extensively. Network connectivity appears to be pervasive with the level of workstation network attachment in most units typically exceeding 90 percent of available systems. This finding is consistent with other surveys which have been recently conducted to assess the extent of campus network utilization. The total number of network attached devices on the campus is estimated to be eight thousand and is expected to grow to approximately twelve thousand.

The existence of multiple servers within departments was found to be commonplace. The functions these systems predominately provide are file and print sharing (including limited application program sharing), World Wide Web (WWW) hosting, electronic mail service, and File Transport and Telnet support. Based on data provided by the UCNS, the estimated number of departmental servers supporting these specific functions are listed below. It is important to note that these are not necessarily individual server systems. Typically a number of the listed network functions are provided on the same host. The significant conclusion to draw from these numbers are that network support requirements to maintain operability of these systems is widely distributed and extensive.

The most common network file server operating systems appear to be Novel NetWare, UNIX NFS and AppleShare. The majority of the NetWare LAN systems are configured with NetWare version 3.12 with a small number, approximately 7 percent, running with NetWare version 4.1. There appears to be a general interest in migrating to the NetWare version 4 environment by several groups when a greater level of campus familiarity and competency with this network operating system has been achieved. A small, but growing number of Windows NT servers, approximately 30, were found to be deployed on the campus. The dominant UNIX network server host systems are Sun workstations followed by SGI, IBM RS6000 and LINUX servers.

Based on data provided by UCNS the current proximal distribution of file server platforms by network operating system environment is as follows:

Three network cabling technologies are commonly in use in the units surveyed. These are "10Base5", "10Base2" and "10baseT" wiring plants. This distribution of wiring technologies reflects the transitions in wiring systems which have occurred since networking services were first deployed on the campus which began approximately a decade ago. All cabling systems implemented in the past two years have utilized Category 5 specifications. Most groups interviewed expressed a desire to replace existing "10Base5" and "10Base2" wire distribution facilities with Category 5 wiring.

The dominant physical layer access method in use in the LAN environments is Ethernet although some limited use of token ring signaling is in use. Use of intelligent switching hubs to support 10 megabit Ethernet to the desktop is being deployed in some buildings. The current dominant vendor product used for this purpose is provided by Cabletron Systems, whose offerings are recommended and supported by the UCNS.

Physical connectivity is provided to all major buildings on campus via a broadband coaxial cable system for which the "head-end" is located in the Boyd Graduate Studies Building. This system consists of 7 separate legs or segments serving distinct geographic regions of the campus. Physical layer networking services are provided on the trunk segments using Manufacturing Application Protocol (MAP). Each campus broadband trunk segment supports three 10 megabits per second MAP channels. Bridged connection of the trunk MAP channels to building Ethernet segments is provided through Hughes LAN bridges. The multiple campus trunk channels are combined into a common networking addressing space using high performance CISCO routers located at the head-end. Logical host addressing and transport management services for inter-networking across the campus trunks are provided by the TCP/IP protocols. IP packet routing is provided centrally. Wide area connectivity is provided by Georgia's PeachNet system and the commercial Internet.

Remote access is provided by a centrally managed modem pool. Only asynchronous connectivity is supported through this service. Speeds up to 28.8 kilobits per second (kbps) are available. Point-to-Point Protocol (PPP) connectivity is provided through the campusCWIX service for which patrons subscribe directly with Cable & Wireless. A unique feature of the Cable & Wireless service is that local dial service is available state-wide.

Campus telephone services are provided through a Private Branch Exchange (PBX) system operated by the State of Georgia. Although the University of Georgia is the dominant user of this system, it is also provides voice services to other State offices located within the Athens, Georgia area.

A variety of specialized computing services, supporting focused research and instructional programs, exist on the campus. Many of these services are geographically distributed. In addition many departments have established instructional computing laboratories for which virtual networking access can be problematic. The University is also making a substantial investment in GSAMS distance learning studio facilities. Currently these teaching facilities must be served by dedicated fractional T1 circuits. Once Project VENUS is installed and functional, the capability of using these specialized facilities across the network will be enhanced.

To establish a mini-baseline for the existing network, Network General Sniffer traces were provided by the University of 5 leg segments: legs A0, A2, A4, D2 and F22. These traces provided a sampling of student laboratories, scientific, administrative, and general network traffic. The average utilization of the broadband network was less than 5 percent. The majority of the traffic was Transmission Control Protocol/Internet Protocol (TCP/IP) and Novell’s Internetwork Packet Exchange (IPX). There were also small amounts of NetBIOS, SNA, management overhead, XNS, ISO, and AppleTalk protocols. The Ethernet packet types were Ethernet II and 802.3. Further discussion with UGA staff indicated that the samples were low and that the typical utilization of the network is closer to 8 percent. The broadband capacity is 210 Mbps (7 legs times 3 channels per leg times 10 Mbps).

From the initial interviews with departments, affiliated colleges and user groups, we ascertained that UGA has a user demand for a network infrastructure that will support large amounts of data and video traffic. The current users have been restrained in how they can move data traffic between their LANs and the systems outside their buildings. Simple procedures such as file transfers and data backup increase backbone network traffic to a point that server congestion occurs. Because of the congestion, many of the users stated that they had resorted to copying data to diskettes and physically transporting the diskettes to the person to whom they desired to transfer the data. The users referred to this method of data transfer as "Sneaker Net." It is unrealistic for files that are larger than 1 or 2 megabytes to be transported via this method.

Most of the groups that we interviewed had common requests. Virtually all of the users interviewed want Internet access from home and office, and virtually all of them want to share data that they are building on their own servers with campus and Internet users. Many of them are accumulating gigabytes of data on their servers. Some individual data files exceeded 50 megabytes. Moving that amount of data across a 10 Mbps Ethernet network to 1.544 Mbps T1 digital service (digital data services at DS-1) can cause many network problems.

One common application that the users require is E-mail. Although they may be utilizing different e-mail systems, all have a need to exchange e-mail with their colleagues.

Several groups are developing their own Web servers. One example of a group that is developing its own Web server is the library. The groups want to allow direct campus access and also outside access via the Internet. These Web servers should be connected at one of the major nodes instead of to the buildings’ networks. This would allow for faster access and would reduce traffic across some of the slower connections.

A requirement from UCNS was that the backbone components provide very high redundant functions through the use of electronics and thus not rely totally on fiber cabling. This position allows the University to take advantage of any expected high speed backbone technologies the State of Georgia might implement for connectivity across the state, and provide WAN connections in at least two locations on campus.

Systematic and coordinated network management seemed minimal. Most groups maintained their own building network or have networked a small group of buildings, and felt that campus network management was needed for the backbone rather than their own environment.

Most student housing had a network connection, but it was not available in the individual rooms. UGA plans to bring the network "to the pillow" when the student housing buildings are renovated in the future.

Visual computing is another user demand for the network. Visual computing requires the ability for the network to transmit video data. Visual computing consists up to 1,400 cells of information per image, with each cell ranging in size from 1.5 to 2 megabytes. UGA’s GIS department is looking at ways of digitizing the signal and storing that information on disk. Users will then be able to access the information from across the network.

Video conferencing is also a user requirement. Video conferencing allows collaboration with colleagues who are on and off campus. Currently, UGA has nine video classrooms with an anticipated growth to twelve or more. Each video classroom needs a T1 connection. Individual T1 lines to each classroom is not cost-effective today because the rooms are not used enough to justify the cost. When Project VENUS is implemented, the new fiber and existing copper infrastructure would offer higher bandwidths and would allow the use of the current T1 lines to support all of the video classrooms without adding additional lines. This capability would also provide for mobile video classrooms where only a network connection to the backbone is required.

A variety of specialized computing facilities supporting focused research or instructional programs are operated by UCNS. Most of the computing facilities that are listed below currently keep their traffic within their facilities or buildings. Once Project VENUS is installed and functional, the capability of using the specialized computing facilities across the network will be available to everyone on the campus.

This is a partial list of the specialized computing facilities that we are aware of within the campus:

The Methodology for performing the Logical Design included site evaluation, requirements validation, strategy review, technology mapping, traffic modeling and design reviews with UCNS. The technology IBM recommended and UCNS concurred with was ATM. The design team validated the selection for ATM technology by mapping the following requirements criteria to ATM capabilities:

The selection of ATM technology provides UGA with a network architecture that will support their current and future network growth over the fiber backbone infrastructure.

The decision for the placement of the Switch Nodes was based primarily on the findings of the manhole system survey and a study the campus geography. The results from the end user interviews, the site tour, insights from UCNS, and IBM’s experience from working with other universities with similar requirements also influenced the selection of the Switch node site locations.

The logical topology established three layers of core switch nodes ("A", "B", and "C") called ATM switch nodes. These selected core buildings will be the center for the clustering of other buildings within close proximity or that can be easily connected through the campus duct bank system. Some compromises were made to the equal access rule because of the duct bank access and logical clustering. In some cases to provide redundancy and capacity for installation of fiber optics on campus, alternate duct banks were recommended (see "Redundant Duct Banks" in Physical Design Criteria section) .

Each building has been assigned a code that indicates its relative location on the logical topology. The first four positions of the code indicate the building number assigned by the University. The fifth, sixth and seventh positions identify the Switch Node to which the building is assigned. The eighth position indicates the logical position of the building within its cluster.

The following is an example of the building identification code and a description of its meaning:

The design team and UCNS staff reviewed different alternative backbone topologies in a strategy review workshop / meetings. The conceptual alternatives for the backbone topology were:

The matrix backbone topology with the starred connection for the cluster buildings was agreed to by UCNS without the single "B" layer cross connection. This topology provides some unique features. These features are:

The conceptual alternatives for the cluster buildings topology were:

The single star connecting into the core switch nodes of the matrix was selected because of its flexibility of implementation.

The logical design for UGA’s Project VENUS network is a multi-node ATM matrix topology with dual 155 Mbps connections between four central switch node locations. The design includes migration to 622 Mbps and growth to the remaining twelve switch node locations. Each switch node location has an average cluster of 12 buildings and is connected to the ATM backbone network.

The central switch node locations were chosen because they were the only buildings with space available for Backbone Telecommunication Closets. The clusters of buildings around the central switch node locations were chosen based mainly on geographical location and expected user groups.

A 16 switch node matrix topology was adapted to fit physical restraints and to provide growth capabilities for four or more additional switch nodes. The topology provides for a maximum of four switch hops between any two switch nodes on campus. The design does increase the latency by approximately 60 microseconds but provides for redundancy, load balancing, and scaleability.

The logical design was developed to enable creation of a robust, multi-vendor, network. The design was developed on the assumption that all applications use industry standard Application Program Interface’s (API’s).

To test the viability of the logical design, a simulation model was created. Using the maximum bandwidth that the current broadband network supports as background or noise, ATM traffic was added to simulate the Phase 1 (dual 155 Mbps) and Phase 3 (622 Mbps core and 155 Mbps secondary) traffic. This was done to determine the point that the network could become congested in the future (see SNAP / SHOT Modeling results in appendix C).

The SNAP / SHOT Modeling results indicated that the University would not require OC-48c speeds on the backbone in the near future. The fiber optics infrastructure is designed to support dual OC-12c full duplex ATM links and with the spares can be expanded. The current technology is excessively expensive and for a very low utilization rate this would make the use of OC-48c equipment unjustifiable. It is reasonable to mention that, as with most technology, ATM costs may drop in the future as cell switching technology matures.

The design allows network management functions to be distributed among the network manager, switch nodes, cluster hubs and floor hubs. The vendor selected by UGA for the primary electronics should provide the platform and applications to manage and support the operations of the network components. Depending on the vendor selected, the connection to the network manager may require a local connection to the legacy network and an out-of-band connection to one of the switch nodes. The selected electronics vendor should be responsible for providing the hardware and software necessary to provide connectivity for management of both the legacy and the ATM networks.

The Logical Design enables the use of legacy LAN technologies, (Ethernet Token Ring and FDDI) 25 Mbps, 155 and 622 Mbps ATM, and video using a video stream connection from a MPEG device to cell over the ATM backbone. Support for 100 Mbps ATM TAXI (Transparent Asynchronous Transmitter / Receiver Interface) was not emphasized in the design. The 100 Mbps ATM is not consistent with UCNS direction for standardization. The legacy AppleTalk traffic (ELAP) will be confined to the local collision domain to prevent unnecessary traffic on the backbone.

The Strategic Design Diagram (Figure 1) above depicts a matrix of 16 connected switch nodes. Some of the switches operate at 155 Mbps while others of them operate at 622 Mbps. Locations B02, B08, C05, and C08 are in the design but are currently omitted from the matrix. These switch nodes allow for future growth.

A cross matrix connection between B01 and B05 and a cross-matrix connection between C03 and C07 are not shown but are future options. Additional redundant cross matrix connections between B03, B07, C01 and C05 are also not shown.

The diagram ( Figure 2 ) shows the relationship between each of the switch nodes and their assigned cluster of buildings. Each node switch resides in the first building of its’ assigned cluster. The cluster buildings gain access to the backbone resources through their assigned node switch.

The above diagram ( Figure 3) shows an option for connectivity of clustered buildings (labeled as Cluster Buildings and "B - P" hubs) are to attached directly to an ATM switch node on the campus backbone allowing each cluster building to have equal access to the ATM switch. Note that the hubs in the A Building connects to the local switch. This equal access results in the requirement of the ATM switch nodes to have a larger chassis with higher port densities.

The diagram ( Figure 4 ) shows the future migration of the core backbone network to 622 Mbps and the 155 Mbps connections to the "B" and "C" level switch nodes.

The VENUS backbone is to evolve over several steps that include installation of fiber optics, ATM switched nodes, building distribution hubs, horizontal cabling in predetermined model buildings. Once the VENUS backbone is installed, it will enable WAN and application integration.

Project VENUS will require a major space acquisition in the node locations and cluster buildings to build Telecommunication Closets (TC). The allocation of the space and the construction must be done prior to the installation of fiber optic cabling and network electronics.

Building power systems need to be upgraded to protect the network electronics and computer equipment from harmonics. Installation and testing of grounds to minimize noise exposure from the UTP drop wiring is also recommended. The installation of UPS units for the switch nodes is recommended.

The network backbone will be implemented in a phased approach after the construction of backbone Telecommunication Closets is completed, racks and patch panels have been installed, and fiber optic cabling between switch node rooms has been installed and tested. A cable management system should be implemented to insure that all cables are labeled properly and that future adds, moves and changes are documented.

For the University to perform the implementation and integration of the network electronics, it must be able to perform the following tasks at a minimum:

• Determine the skill levels of the technical staff targeted for the project.
• Expedite the education of this technical staff on:
• ATM technology
• Network Management techniques using SNMP, MIBII, and RMON
• LAN Emulation
• ATM interfaces and integration across these interfaces
• Determine the additional skilled resources needed for the implementation and support of the ATM technology
• Select the following standards compliant products:
• ATM switches for the nodes
• Network management platform and software to manage the ATM equipment and building hubs
• Building ATM/Legacy hubs
• ATM to legacy bridges
• Schedule and setup a pilot implementation including:
• acquiring the pilot equipment to demonstrate and determine the configuration parameters
• installing the necessary infrastructure to support the pilot implementation and testing
• Arrange for hands-on training for the technical staff and support staff from the component providers on their selected products
• Configure pilot backbone using the demonstration model and test / adjust the component configurations including the network manager
• Certify technical staff on the installation and maintenance of the products at the end of the pilot
• Develop maintenance procedures that will enhance performance of the components
• Establish an implementation schedule that matches the migration assumptions for roll-out.

All the buildings to be networked are divided into sixteen (16) groups call clusters. Each building within a cluster is assigned a logical alphabetical sequence identifier. Then that cluster of buildings is assigned to a switched node. Switched nodes are then assigned a three (3) digit identifier (i.e. A01). All switched nodes reside in the "A" building of its’ supported cluster. Each building is assigned a unique building identifier, (i.e. 1621-A01A), that reflects the University building numbering scheme, the switch node associated with the building and the position of the building within its’ own cluster.

A detailed sequence plan will have to be developed by UGA to map the availability of infrastructure, telecommunication closets and operations support. Operations support must have the capabilities to provide for the roll out of the backbone and distribution connectivity including network management with server strategies. The availability of these items must be matched to the needs of the university and must be provided in a sequence that meets the priorities as established by the University. The sequence of installation is recommended as follows:

This implementation plan is based on the ability of UGA to acquire space in buildings and to obtain access to duct space for the fiber optics. With complete implementation of the infrastructure and networking, access to a high performance, high capacity digital communications system will enable communications capabilities anywhere on the UGA campus. The following overlapping steps are typical of a phased migration plan.

The following is a typical implementation sequence that can be used as a guide for the VENUS installation:

In any major networking project, creation of a physical infrastructure is often the most difficult task from both a planning standpoint. The fiber infrastructure phase is usually broken into steps that match the network electronics roll out so that each step can be linked and the steps can be overlapped.

The first step of the fiber infrastructure phase includes installing the required duct banks, providing for building access conduits, and construction of backbone telecommunication closets. Backbone telecommunication closets must be built for the placement of backbone equipment and for backbone fiber optics termination.

The second step of this phase is the building of telecommunication closets to provide for distribution of connectivity to the user community starting with "A" cluster buildings. The fiber infrastructure phase is complete when all the fiber optic segments between the attaching buildings are installed, terminated, and tested. At the conclusion of each step in this phase, the respective site(s) should be ready for the installation of switched node electronics.

With any project of this magnitude, implementation has to be divided into smaller projects that follow the fiber infrastructure phase. The electronics roll out will depend on the actual backbone fiber installation schedule. Following are smaller tasks that can be accomplished as part of the network electronics phase to complete the creation of the network.

The following topology diagram (Figure 5) is to used in conjunction with the demonstration diagram. It shows the backbone between the two ATM / Legacy hubs.

The core "A" switch nodes step of the network electronics phase focuses on the high profile areas such as the library, life sciences buildings, data center, and distance learning facilities. It also allows for the possible integration to the WAN. This step serves as a pilot project and test bed for the backbone. The diagram below (Figure 6) illustrates Step 2 of the project.

The distribution cabling phase is divided into steps that map to the associated fiber infrastructure and network electronics phase steps. This phase provides the horizontal and riser distribution cabling from user face plate to apparatus telecommunications closets. It also provides for installation of any riser cables from the apparatus telecommunications closets to the backbone telecommunication closets within the building. Note: The building-to-building cable should have been completed during the fiber infrastructure phase. This phase is also divided into steps, as follows.

Installation of horizontal and riser distribution cabling is accomplished in order of end user requirements. It begins in the "A" cluster buildings and progresses to additional buildings that are ready for connection to the backbone at that cluster site.

Horizontal and riser distribution cabling is also required in each of the remaining buildings. As horizontal cabling is completed, it should be attached to the campus backbone via the network electronics. Installation of this cabling must to be coordinated with the construction of telecommunication closets within each building. The telecommunication closets will be the location where the fiber and copper cables are terminated.

The sequence for installation in these buildings will be determined by its association with the core switch nodes, installation of infrastructure, and end users priority for connection to the backbone. The closets (ATC) will also house electronics that provide for the connection of the end user drops into the network.

Buildings should be migrated from the current data broadband network to the new fiber optic network as quickly as possible. Once the new network is functioning, UCNS should not support the old network in the buildings. Some migration period should be established to allow end users time to migrate to the new fiber network.

Removing the broadband cable would free up conduit space throughout the campus. The new fiber optic network will be using most of the remaining conduit pathways on the campus. The removal of the existing broadband cables would provide for future spare conduit. This would reduce the need for the University to install additional conduit capacity. Current, continuing video requirements could be met by using any available fiber or the requirements could be met by using ATM transport to carry the video information.

The design topology for Project Venus will enable users with Ethernet II or ATM adapters to connect to a multiprotocol hub and/or workgroup switch. Translation for the adapters would be provided by an ATM LAN bridge and LANE server. Either a multiprotocol (super) hub or cluster ATM switch would collect all the outbound and inbound traffic to the ATM switch nodes. Switch nodes would be connected to each other in a matrix (mesh-like) for cross-campus communications.

The "A" core switched nodes provide the major backbone layer fabric for the VENUS network. All components of the switch nodes are to be ATM Forum compliant.

The worst case port density is 24. The chassis should be able to support 24 or more ports. The chassis must be able to support hot pluggable cards and power supplies. The cards must be swappable, and have fault tolerant modules. The chassis should have:

The switch nodes are to support the phased migration and the logical design connectivity. A migration path is to be documented by the vendor selected for upgrades to the backplane / midplane, chassis, cards, and switch fabric for Step 7 and 8 to the OC-48c transmission rates and higher port densities of five OC-48c and sixteen OC-3c. For vendor’s that are required to provide additional chassis to meet the port densities, the switches are to function as a single chassis and not adversely affect the redundancy of the combined units.

The switch nodes provide transport for mixed data, MPEG2 video, and voice traffic. Legacy traffic is from client/server applications using IP, IPX and AppleTalk protocols in the buildings over 10Base-T Ethernet to local multiprotocol hubs. Bridges or switches must convert frames to cells for transport over the ATM backbone. When ATM native applications are developed, they will need to communicate directly over the ATM network with a Quality of Service (QoS), while the non-ATM applications will use the ATM Adaptation Layers 1, 2, and 5. The switch nodes must provide QoS for classes:

Note: See the ATM Quality of Service section, in Appendix C, for additional information.

The switch nodes at the "A" or core level will be the primary connection point between the campus network (private network) and the WAN (public network). The State of Georgia network is currently non-ATM T1 with the possibility of T3 and ATM over fiber in the future. The switch node is to provide the T1 interface with clock synchronization on the switch for loop timing, internal and external clocks configurable to four timing references, plus PLCP support. As an optional feature, the switch node chassis should support a high speed adapter with T3 interfaces.

To be consistent with future plans for the State of Georgia network, the ATM switch nodes will have to support NSAP and E.164 addressing and p-NNI-0, with p-NNI-1 in future upgrades. The local exchange carrier has indicated a requirement for B-ICI as the ATM Forum interface between public ATM network carriers.

There is a high probability that Frame Relay will be implemented by the local exchange carrier before ATM service is offered. The switch node should provide optional network connection support for Frame Relay for FRF.5, 7 and 8, plus FRF.6 with the Customer Network Management MIB proxy agent.

The switch nodes are to have at least 5 Gbps throughput with redundant switch fabric and enough available buffers for parallel dedicated cell buffering that provides a scaleable switch fabric to 10 Gbps of bandwidth. A migration path from the 5 Gbps per switched fabric to 10 Gbps and higher is to be documented by the selected vendor. Each switch node is to be sized to prevent lost packets. The switched nodes should also have the following basic features:

The I/O, processor, connector cards and panels are to support the switch architecture and provide the connectivity described below. The switching system is to include the following features and functions:

The intelligent multiprotocol hubs will provide flexible communications and connectivity between the legacy and ATM workstations. The workstations will be connected to the ATM backbone over the EIA/TIA 568A cable distribution system. The primary legacy connectivity is via 10Base-T using IP and IPX protocols. Video applications will be using the Moving Pictures Experts Group data compression for full motion video version 2 (MPEG2). The video is expected to be provided by video servers.

The following descriptions provide a set of expectations and the quality of the hub component for the network:

The selected vendor will be responsible for demonstrating:

Ethernet switches are an optional solution where the legacy segments are demonstrating high collisions / utilization that increase bandwidth prior to converting to ATM workgroup or ATM technology. In these situations, fast Ethernet is recommended. Fast Ethernet switches have the ability to support both 10BaseTx and 100BaseTx. The Ethernet switches, if used, are to include the following features and functions:

Bridging functions are to be provided for connectivity across all components of the network and to actively participate in the network management functions. The spanning tree and source route transparent bridge protocols are dependent on the addressing scheme and the intended use of the network. For router connections refer to the WAN Gateway and Firewall sections. As an alternative, routers could be substituted for the bridges at the interface of the legacy LANs and the ATM network (see the logical diagrams for possible locations). These routers would be configured to support the ATM cells to LAN conversions.

The lower speed workstations are mostly ISA bus machines. Newer workstations have a PCI bus. The PCI machines could connect natively to ATM hubs at 155 Mbps while the ISA machines could use a 25.6 Mbps adapter. Some vendors require an external switch/concentrator while others provide this function as part of their hubs. The following functional description is typical of external switches.

The workgroup switch is to be ATM Forum compliant and provide an ATM switching fabric with at least 4 Gbps full-duplex bandwidth with less than 32 microseconds of latency. The workgroup unit is to have the ability to expand without impact to the base unit. The unit is to have 12 workgroup ports and be expandable to at least 36 workgroup ports (typical lab size). The unit is to have the capability of two 155 Mbps I/O over multimode fiber optics and Cat. 5 UTP for a compatible connection to the ATM hubs. The switch fabric and I/O interfaces are to provide the following functions:

The following are the general features and functions that the 10/100 Mbps adapters should have:

The following are the general features and functions that the 10 Mbps adapters should have:

The following are the general features and functions that the 25 Mbps adapters should have:

The following are the general features and functions that the 155 Mbps adapters should have:

The operation of LAN-to-LAN bridge connectivity over an ATM network where multiple legacy protocols are needed is a requirement at the University. The migration to a single LAN protocol is not expected to happen in the early of steps of Project VENUS implementation. The use of emulated or virtual LAN to provide communication using LAN protocols across the backbone to physically separate LANs will be used for all the normal cross campus connectivity. The LAN Emulation Server (LES) / Configuration Server (LECS) will support this ELAN registration, functions between LESs and connection establishment.

The ATM Forum compliant LES is to be at version 2 or greater and consistent across the multiple hubs. Even though some vendors have the LES function external as well as internal to the multiprotocol hub, UGA prefers the use of internal implementation that is integrated.

The following are the expected minimum features and functions:

The following are the minimum features and functions of the Network Manager:

The electronics vendor selected by UGA should include in its pilot the complete network manager station and all necessary software for component management under NetView that provides the optimum operation, maintenance, and management of the pilot solution. This management station should be sized to support a network system with 10,000+ network connections. The network manager must be capable of supporting three locations: Network Operations Center, Data Center, and UGA Help Desk Level 2 support office. Access from a remote station for remote diagnostics is a requirement, either while in the TCs or from remote locations which are out of band.

Remote Network Monitoring will be required to supplement the SNMP MIB II for gathering information / data on the LAN networks. The network manager should use the RMON functions for statistics, alarms, and events. RMON should also provide graphing of bandwidth use, frames per second, frame distribution showing multicasts, unicasts and broadcasts, frame collisions and frames in error. The network manager is to use the RMON capabilities to enhance the proactive and predictive management through monitoring, troubleshooting, and capacity planning activities of the new network. In addition, the network manager should provide the ability to collect historical data.

The network components are to provide the necessary SNMP MIB II, RMON, and ATM UNI MIB to support and provide the information to the network manager. The university has NetView for AIX that can be used for network management. This system will have to be evaluated to determine that it has the minimum configurations as indicated below:

Traffic monitoring is to be provided by the RMON agents and network manager. Intrusive capture of traffic flows is not part of this design.

The "Firewall" device is intended to provide security protection between the UGA campus network and the Internet Service Provider (ISP). The firewall device is to be located logically between the campus LAN and the off campus WAN network. This was not included in estimates, see the section on optional activities.

The following are minimum features and functions to meet the intent of a "Firewall" to protect UGA from intrusions:

Wide Area Networks (WAN) are evolving, just as Local Area Networks (LAN) have over the past five years. SMDS, like token-ring, was designed to be a "better mouse trap" but seems to be in low demand by users, except in Europe. Frame relay (FR) can be compared to 10Base-T Ethernet in popularity, with high growth, aggressive pricing of tariffs, and large investments in the frame relay services being made by the carriers. ATM, being both a WAN and LAN technology, is the beginning of a convergence of technologies towards an Intranet / Internet world. Most universities with limited funds are implementing frame relay interfaces to take advantages of the tariff rates and are waiting for carriers to begin competitive pricing of ATM.

UGA desires to isolate the Project VENUS network from any off campus users. The gateway system should include an interface to the new network and to off-campus connections, such as WAN and/or MAN. The WAN gateways were excluded from the campus backbone estimates

IBM recommends that every telecommunication closet be equipped with an uninteruptible power system. This UPS will support key electronic equipment installed in the TCs such as switches, hubs, routers, bridges and gateways. Because LANs are susceptible to data loss due to power failure, UPS systems are a requirement to ensure an-interrupted operation of network equipment and to protect the equipment against many types of power problems, including brownouts and blackouts.

IBM recommends that the UPS be sized so that it would only be utilized at approximately 50% of its capacity when it is initially installed. This would allow for future growth without necessitating immediate replacement of the UPS.

UPS systems provide redundant power by supplying a source for backup power in the event that the primary power source fails. Depending on the level of fault tolerance that is required, network managers should install UPS’s on all public servers.

IBM’s recommendation is that all new UPS systems installed on the campus have the capability to provide status information using Simple Network Management Protocol (SNMP). Some UPS systems have more than 50 UPS MIB variables. The following is a list of the basic variables that should be included on any new UPS:

It is recommended that the UGA establish a pilot demonstration of all components prior to full deployment to successfully demonstrate the proposed solution for Phase 1 (Core "A" Switch Nodes). The pilot should closely emulate the expected conditions and uses on campus including legacy applications, video images, collaborative exchange of information, large GIS files, and the use of ATM. The pilot project should be used as a test bed for configuration and tuning, as a tool for application development, and for use as a training facility for UCNS support staff.

The pilot is to validate the integrated solution, not just for individual components or sections of the proposed solution but to provide the roll out configurations and parameters for the rest of the network electronics. The following system specifications are suggested as the minimum benchmark for the pilot project:

At the end of the demonstration, or just prior to the roll out, the necessary parameters to configure the various components of the solution based on the pilot measurements should be recorded in the network management documentation and in the manuals on the specific components.

The following ( Figure 7) is a representative sketch to indicate the expected demonstration setup:

The pilot is to be used to show how the solution handles the effect of multiple interruptions against the server while running MPEG2 video streams.

The following client/server functions are also to be demonstrated:

Forum compliant LAN Emulation version 2+ will be required of the network electronics to support multiple protocols over the ATM network. The proposed solution can have LAN Emulation that is migrated to Forum compliant LANE without major hardware or microcode replacements. LAN Emulation Servers, with hardware and software, are to be included in the support for up to 400 end users during the initial phase(s). The roll out beyond the pilot demonstration will require that the LANE server function be in the hubs and support users (two times the connectivity capacity of the hubs).

The network electronics should support the use of Classical IP implementation. The pilot facility should demonstrate support for both RFC 1577 and LAN Emulation. Cost estimates for Phase 1 are to be based on LAN Emulation with unit costing for future RFC 1577 support not included.

The pilot network electronics should support MPEG2 from a camera across the ATM network to storage device.

The pilot facility should be used to demonstrate support for distance learning (video, audio, and image) transmissions between a remote classroom and the university using ATM technology and how this solution will enable collaborative teleconferencing.

In addition to the costs for electronics as estimated in the tables above and the costs associated with the cabling infrastructure, there will be individual fit-up costs associated with each department. Depending on the funding model and level of service for ongoing support and maintenance, the monthly charges will vary.

The typical Ethernet initial startup costs per drop are $850 to $260 and typical ongoing costs are $60 per month based on support for a user base of 40 to 240 users (more users per hub results in a lower per drop cost). The cost typically includes physical connectivity, labor to install and cost per port on the electronic hubs. More technology intensive organizations will have support costs that can be as high as 3 times the $60 estimate with averages costs around $100 per month.

The ongoing monthly support cost for end users is based on the University of Georgia having 8,000 end users. The following assumptions used ratios for the different types of Network support functions per end user, for example: 1 support person for 285 end users (1:285).

The Forrester report gave examples for a 5000 user network in a commercial environment. The LAN Administration person is the first level (usually referred to as Level 0) of support and performs the basic checks and diagnostics of problems as well as being the interface between department and the help desks. The Help Desk staff function as the single point of contact across the university for problems and provides tracking, additional diagnostics and corrective action, and assignment of problems and requirement changes. This level is usually referred to as Level 1 support. The Physical LAN Support is responsible for the physical control of the infrastructure while the router support and remote access staff are the more technical staff (Level 2) and resolve problems not handled by the Level 0 or 1 staff. They are responsible to gain vendor support (Level 3) as required to complete the trouble tickets issued by the Help Desk.

The cost that follows the ratios is the adjusted cost of support for one year using the salaries provided in the Forrester report.

This estimated cost for end user support at UGA breaks down to $60.08 per month. This information was taken from a Forrester report and the design team modified the ratios to match UGA’s environment.

IBM researched the State of Georgia contracts for networking components via the PeachNet Web Page. The components were not assembled in a central repository, but were spread across multiple topic pages under multiple headings (workstations, networking, various vendors and business partners). To provide a budget for UGA, the team tried to find at least three vendors that might meet UGA’s requirements for each component, and used these costs as the price point. The three vendors consist of Cascade, Hewlett-Packard, and IBM. These specific vendors are also denoted in the following tables by being identified with a ¹superscript next to their respective names. The vendor provided materials and descriptions were assumed to be correct and representative of feature/functions. No attempt was made to validate product capabilities against specifications, UGA’s requirements, integration, or testing.

This information and a copy of working spreadsheets (see Exhibit and Appendix) are provided as a reference and are solely for information. IBM makes no warranty of any kind with regard to the ability of the components to meet UGA’s requirements. UGA and their chosen vendor has the responsibility to demonstrate comparable product solutions and performance to meet UGA’s requirements. The vendors included in the above pricing estimates included Bay Networks, Cabletron, Cascade, Cisco, ForeSystems, HP, IBM, UB Networks, , and 3-Com/ChipCOM. It is the responsibility of the UGA electronic personnel to provide thorough manufacturer’s technical specifications and a demonstration of the proposed system to show that the system meets UGA’s requirements and that pricing is appropriate for the solution.

The following is a summary of the budget research:

The ~ indicates that pricing was not found in the State of Georgia contract search for all necessary components.

The ¹superscript in these charts represent the specific vendor whose prices were used to develop the Cost Of Implementation - Budget View.>

An ATM cluster switch may be required where the vendor does not have ATM switching in their multiprotocol hub. This is provided for information on an alternative approach to the ATM switch node approach.

IBM shall not be liable for any direct, indirect, general, incidental, special or consequential damages in connection with the information provided above.

The pricing for LANE servers is not stated because comparisons were misleading and changed depending on systems platform and version levels selected.

In a client-server environment, many decisions must be made regarding performance issues across platforms. Decisions such as number, placement and capacity of clients and servers, the network topology, and the distribution of network traffic must be consistent in order to ensure that the service delivered meets desired expectations. The analysis of a client/server system involves many unique components, from the server platforms to the network connections.

System Network Analysis Program / Simulated Host Overview Technique, (SNAP/SHOT) is a capacity planning methodology that employs a discrete simulator. This methodology can be described as a tops-down process. Current environment data and future business requirements are used as input to describe the system’s workloads. Workloads are created from the existing configuration and/or trace data and extracted from a standard set of workload profiles. These workload profiles can be created from specific transaction data provided a client. These definitions of existing and future workloads are then used as input to the SNAP/SHOT simulator. The simulator uses workload definitions, along with the performance capabilities of available or new technology, to develop a viable capacity plan to meet the objectives of the client.

In general, the SNAP/SHOT methodology addresses the following:

Analyzing configurations containing any combination of LANs (Ethernet or Token Ring) and/or ATM connected over point-to-point WAN’s. It is used to evaluate the impact of various LAN/WAN topologies’ performance.

Evaluating the effects of different file/computer servers distribution options in the system, as well as the number and placement of servers and clients across the various LAN/WAN segments.

Determining the end-to-end response time of various system traffic and the network/server resources required to provide adequate response times.

Evaluating the capacity requirements of each component of the client/server system.

Each simulation produces a series of reports that describes the results of the simulation. Each unique component of the system (i.e., router, bridge, link, LAN) is detailed within a specific report. These reports are given to the client at the end of the session along with the supporting documentation.

The SNAP/SHOT methodology was delivered to UGA via a summary presentation on July 7,1996. The methodology was constructed to allow for future engagements using the base models for "what if" scenarios.

The objective of the SNAP/SHOT model run was to validate that the logical design will provide in excess of 1 Gbps of bandwidth for the 20% growth in end users.

The SNAP/SHOT model was built using information available from the client, interviews and experience with other universities, and generic switch node characteristics. The initial run of the model indicated very low utilization of the dual 155 Mbps ATM links for legacy traffic. As a result, the model was rerun with a single 622 Mbps link. These results can be compared across all link definition for per cent utilization runs.

The model was built using the campus as a WAN connected with fiber to simulate the high capacity switched fabric with equal tariff costs. Because real server profiles were not available, the model was run without emphasis on response time. Twelve (12) servers were needed to represent the 200 - 500 NetWare and Web servers in the model.

The user population was divided along industry projections for ATM workstations on a campus, using a 20% ratio. The 10,000 users were divided into 8,000 legacy and 2,000 ATM. To ensure growth capacity of 20%, a SNAP/SHOT run was made with a total of 12,000 workstations (8,000 + 2,000 + 2,000). Traffic was generated continuously to drive the network under worst possible conditions.

The following inputs were used for the SNAP/SHOT modeling exercise associated with the legacy network. The 4 switch node matrix was used. Each switch node represented a sub-network of 5 - 10 Mbps Ethernet segments (labeled 01A - 01E) with 400 workstations per segment for a total of 2,000 workstations per switch node (8,000 legacy workstations). Each Ethernet segment was considered as a 100 Mbps switched Ethernet with an average of 8% traffic to simulate the 40 Mbps per switch node location from the 5 segments (08 X 5 X 4 X 100 = 160 Mbps total). Each switch node consisted of three server segments with a server on each (labeled A1, A2, A3, B1, etc.). Traffic profile for workstations was divided as 75% IP, 20% IPX, and 5% SNMP/RMON. Specifications were made so that collisions on the legacy traffic would impact throughput, and so that percentages would include overhead. Messages completed (not total traffic generated) were used to measure data throughput. A single 622 Mbps ATM duplex link was used between switch nodes (labeled as AB, BC, CD, & DA). Traffic was distributed across the servers non-uniformly to simulate unique work loads and reflect trends resulting from interviews. The following lists network considerations:

The following inputs were used for the SNAP/SHOT modeling exercise associated with the legacy network:

The 4 switch node matrix was used without the follow-on steps that add additional switch nodes. The same legacy traffic was used with ATM imposed on top of it. ATM traffic loading was a mixture of multiple priorities (3 - 0) without blocking. (Congestion control or priorities blocking was not implemented in the model). 622 Mbps ATM full duplex was used between switch nodes (1,244 Mbps / link). Traffic loading on links was split between transmit and receive. Load balancing across the switches was not modeled .

ATM native traffic:

250 ATM workstations per switch node were added to the 8,000 legacy workstations up to 1,000 ATM workstations per switch node to get a total of 4,000 ATM workstations

Note: The generated legacy traffic in the model was 160.2 Mbps. The modeling assumption was to create a 160 Mbps of legacy load. This simulates the ultimate capacity of the existing broadband network.

Five SNAP/SHOT modeling runs were performed to evaluate the network design. These were done to determine the affect of adding the full capacity of the legacy network and the growth of ATM workstations in the 4 matrix design to a maximum of 12,000 workstation users. The modeling had the expected results on a single 622 Mbps ATM 4 Matrix Backbone with 4,000 ATM workstations performing file transfers, graphics, and video activities and 8000 Legacy workstations.

In the legacy-only model, the traffic reached 13.6% from A02 to A01 with the lowest being 1.2% from A02 to A03 on the single 622 Mbps links between switch nodes. This is equivalent to the current broadband network loaded to its capacity. The potential bottlenecks in this model would appear to be the server segments.

The run with the 500 ATM users per switch node (including the legacy) gave us a peak of 49.8% on the A03 to A02 link (with 7.3% on the reverse). The network traffic was intentionally left unbalanced to reflect realistic traffic profiles. At the 750 ATM users per switch node scenario, the A03 to A02 link was at 71.3% (with 10.5% on the reverse path). Normal network management procedures would change switch parameters to balance the switch matrix back to the 45% to 55% point for the 11,000 user network (at 1.01 Gbps). Also the phasing of the network growth would dictate the addition of "B" level switch nodes and thus alternate paths for traffic. The SNAP/SHOT model was run to indicate the best guess: 20% growth above the 10,000 users, follow-on steps not implemented ("B" and "C" switch nodes not installed), and switches permitted to auto-balance the load.

For the 20% growth run, 1000 ATM users per switch node resulted in a peak of 91.2% on the A03 to A02 link (with 12.9% on the reverse). Again load balancing across the matrix would be between 55% to 65% point for the 12,000 ((8000 + 2000)*(1.0 + 0.20)) user network (at 1.3 Gbps).

The model was saved for what-if scenario runs and as input into a specific switch design tool once the switch has been selected.

Asynchronous Transfer Mode (ATM) is a set of international standards for sending large amounts of voice, data, and video information simultaneously over a single network. Technically, ATM is a member of the cell switching family known as "cell relay". It combines the best of packet switching (which is designed for data), and circuit switching, which is designed to support delay-sensitive applications such as voice.

ATM provides a high-speed, connection-oriented switching and multiplexing technology that uses 53-byte cells (5-byte header, 48-byte payload) to transmit different types of traffic simultaneously without a common clock. (see Appendix C, ATM to Legacy Technology Overview, for additional information).

ATM will provide UGA with increased bandwidth (amount of information a network can carry), the ability to transmit mixed data, voice, text, image, and video delivery simultaneously over a single physical network.

Suggested reading for additional information on Asynchronous Transfer Mode (ATM) would include the following:

Upon completion of Project VENUS, the end user will have at least two connectivity options for access to the network. One is through a legacy connection and bridge that provides conversion to the ATM network. Another connectivity option is via an ATM adapter (ISA bus machines at 25 Mbps and PCI bus machines at 155 Mbps) using the ATM UNI 3.1 (private) interface. Because most of the applications will be using LAN interfaces IP and IPX, LAN emulation (LANE) functions will be required to provide LAN to LAN bridged connectivity across the ATM backbone.

The User Layer (ATM Services and Applications Layer) provides information that will be packaged into cells. This layer establishes the link between the ATM Adaptation Layer (AAL) and the application generating the traffic. ATM has 4 classes of service based on combinations of the following factors: how the bits are transmitted, type of connection, and bandwidth required. An AAL type for non-ATM applications is associated with each class of service. The link between the ATM equipment and the physical network is the User-to-Network Interfaces (UNI). The following is a table describing these relationships: