WIDE AREA NETWORK SIMULATION

USING ATM TECHNOLOGY

Computer Science and Engineering Department

University of Bridgeport

169 University Avenue, Dana Hall of Science

Bridgeport, CT 06601

elleithy@bridgepor.edu

Abstract

ATM technology has numerous high bandwidth applications. The need for multi megabits bandwidth of data, voice and video transfer over the wide area network is more than justified for Internet service providers and other larger organizations. ATM as a technology has a very short but successful history since early nineties. Today about almost all the connections to network service access points (NSAP) are based on ATM technology in the United States. ATM as a broadband technology has undergone a significant change in the recent years. Dramatic improvements in optimization, profound changes in the costs and vast increases in applications have made it possible for us to consider design of a WAN using ATM boxes.

In this paper, we introduce a cost-effective network that can be carried over long distances for the transfer of voice video and data. We use permanent virtual connections (PVC) as well as switched virtual connections (SVC) to talk to the ATM boxes placed at thousands of miles of distance. We can monitor as well as configure the boxes remotely. The whole configuration and monitoring can be done by logging to the web or using a craft and/or Telnet sessions.

1. Introduction

1.1 What is ATM?

Asynchronous Transfer Mode (ATM) is based on connections, not channels [MCD99]. The term “asynchronous” refers to the way in which ATM achieves its unchannelized bandwidth allocation. ATM only sends data associated with a connection when there is actual data to send. This is in contrast to channelized or Time Division Multiplexed (TDM) networks, where even if a channel is idle, a special bit pattern must be sent in every time slot representing a channel. Unlike X.25 or Frame Relay [BLCA98, SPOH97], ATM uses very short, fixed-length packets called cells. The ATM cell is 53 bytes long, consisting of a five-byte header containing an address, and a fixed 48-byte information field or payload. In contrast, Frame Relay uses a two-byte header and a variable-length information field, as shown in Figure 1.

ATM functionality corresponds to the Physical Layer and a portion of the Data Link Layer of the Open Systems Interconnection (OSI) reference model [JAIN93]. The ATM protocol functionality must be implemented in both user equipment such as hubs and routers, and network elements such as switches. The network does not know anything about the end-to-end application that is running over an ATM connection after the connection has been established.

1.2 How does ATM work?

ATM is application-transparent. The ATM cell size is a compromise between the long frames generated by data communications applications and the short, repetitive needs of voice traffic. As such, ATM allows a free mix of data, voice, and video within the same application. ATM supports four service classes to handle the various data types on a network. This ensures optimal network usage and guaranteed end-to-end delivery.

(a) Constant Bit Rate (CBR): Handles digital information, such as video and digitized voice that must be represented by a continuous stream of bits.

(b) Variable Bit Rate-Real Time (VBR-RT): Handles the packaging of special delay-sensitive applications, such as packet video, that requires low cell delay variation between endpoints.

(c) Variable Bit Rate Non-Real Time (VBR-NRT): Handles packaging for the transfer of long, bursty data streams over a pre-established ATM connection. This service is also used for short, bursty LAN traffic.

(d) Available Bit Rate/Unspecified Bit Rate (ABR/UBR): Handles LAN traffic.

See [CHEN96, SAIT96] for an in-depth discussion on ABR and comparison with CBR and VBR.

Four different types of ATM Adaptation Layers (AALs) [SUZ94] have been defined by the ATM Forum to handle the different types of ATM traffic. ATM takes information such as voice, video, and data from multiple sources and multiplexes it into a cell stream. Multiplexing defines the means by which several streams of data share a common physical transmission medium. Switching takes the instances of a physical transmission medium containing multiplexed information streams and rearranges the information streams between input and output. Therefore, information from one physical link in a specific multiplex position is switched to another output physical link. Conventional LANs, such as Ethernet and FDDI, use shared media where only one node can transmit at a time.

1.3 Bandwidth Efficiency

As an asynchronous cell relay technology, ATM differs from Time Division Multiplexing, or TDM. TDM is a synchronous mode of data communication that digital telephone networks have long used. TDM networks move information in fixed-length 8-bit “time slots.” Because TDM networks are designed to carry voice, 8,000 time slots per second (the rate of sampling used for the digitalization of voice) are allocated to each connection. This concept is what creates the basic 64-Kbps single digital channel. Moving information around in time slots works only if the time slots are synchronized. Information arriving on a node can expect to find its allocated time slot waiting to carry the information out. If input and output time slots are skewed from each other, the output slot might “depart” before it was filled. This form of transmission is sometimes called “synchronous transfer” because network clocks are synchronized to assure time slots match throughout the network. Figure 2(a) shows a sample TDM data stream. Time slot “User A” occurs right after the Frame Bit (F/B) and every third time slot thereafter. To locate User A data, start with the time slot after the Framing Bit, and count every third time slot thereafter. This is the synchronous nature of TDM. Unlike TDM, ATM attempts to allocate bandwidth more efficiently by giving users access to the entire communications channel on demand. If the channel is in use, a user may have to wait to gain access. However, because cells are small and fixed-length compared to frames, the delay is minimal and can be controlled. Using ATM multiplexing, for example, User A can transfer data using the entire bandwidth of the channel. User B inserts messages occasionally, as needed, and User C takes up almost no capacity. Figure 2(b) shows a sample ATM data stream. Users can access the channel on a somewhat random basis. Unlike TDM, a user’s traffic occurs asynchronously with respect to any framing information in the channel, hence the asynchronous nature of ATM.

2. ATM Standard

The ATM standard is defined as part of the Broadband Integrated Services Digital Network (B-ISDN) standard [STAL 99]. Architecturally, ATM comprises the bottom three layers of the B-ISDN protocol stack, as shown in Figure 3.

2.1 Layers

2.1.1 Physical Layer

The physical layer defines the electrical or physical interface, line speeds, and other physical characteristics. The Physical Media sub-layer provides the bit transmission capability, including bit alignment; line coding, and electrical/optical conversion. In addition to the generation and recovery of transmission frames, current ATM physical media includes the following:

Synchronous Optical Network (SONET) — A Bellcore specification that is currently being used in worldwide public data networks. It is a synchronous optical network-based User-Network Interface (UNI), either public or private, operating at speeds from 51 Mbps to 2 Gbps over single-mode optical fiber.

OC3c SONET — A SONET-based fiber-optic UNI, either public or private, operating at 155.52 Mbps over single-mode and multimode optical fiber.

Digital Signal Level 1 (DS1) — A public or private UNI operating at 1.544 Mbps over various cable types.

Digital Signal Level 3 (DS3) — A public or private UNI operating at 44.736 Mbps over coaxial cable.

The Transmission Convergence sub-layer is part of the Physical Layer and generates and recovers the transmission frame Performs cell framing and recovery performs bit timing Generates header error-control sequence

2.1.2 ATM Layer

Defines the cell format and is used for the transport of fixed-length cells between the endpoints of a virtual connection. The ATM Layer also provides multiplexing functions to establish multiple connections across a single UNI. The ATM Layer in the transmit direction, multiplexes ATM cells from individual virtual channels into one cell stream. At the receiving end, demultiplexes arriving cell streams into individual cell flows appropriate to the virtual channel.

2.1.3 ATM Adaptation Layer (AAL)

Defines the process of converting information from the upper layers into ATM cells. This layer deserves special attention because of the important role it plays in handling the different types of ATM traffic. The ATM Adaptation Layer (AAL) runs from the end system and is transparent to the ATM network. The AAL is organized into two logical sublayers:

Convergence sub-layer — Adapts the services provided by the ATM Layer to the requirements of the upper layers.

Segmentation and Reassembly sub-layer — Segments upper layer information into a size suitable for the payload of an ATM cell, and reassembles the contents of the ATM cell payload into upper layer information.

There are currently four different types of AALs to handle different types of ATM traffic.

Type 1: Constant Bit Rate (CBR) Services — Type 1 is an isochronous, constant bit-rate service for audio and video applications.

Type 2: Voice over ATM Services — Type 2 is intended for highly-efficient transmission of short packets for delay-sensitive applications such as audio and video. Type 2 supports both VBR and CBR traffic. AAL2 supports higher-layer requirements such as silence detection and suppression and voice compression. AAL2 is typically used in mobile telecommunications applications, due to its high bandwidth efficiency and low packetization

Type 3/4: Variable Bit Rate (VBR) Data Transfer Services — Type ¾ resulted from the merging of Type 3 (connection-oriented) and Type 4 (connectionless) VBR Data Transfer services. Type 3 handles packaging for the transfer of long, bursty data streams over a pre-established ATM connection. Type 4 manages the packaging of short, bursty data streams such as LAN traffic, but is encumbered by additional overhead.

Type 5: Simple and Efficient Adaptation Layer (SEAL) — Type 5 is an extension of the Type 3 AAL. It simplifies the Segmentation and Reassembly sub-layer portion of the Adaptation Layer to pack all 48 bytes of the ATM cell payload with data. AAL5 makes ATM look similar to high-speed Frame Relay. It also assumes that only one message is crossing the UNI at a time. That is, multiple end-users at one location cannot interleave messages on the same virtual circuit, but must queue them for sequential transmission. Type 5 is mainly used for data applications. The International Telecommunications Union-Telecommunications Sub-section (ITU-T) has defined certain service classifications based on how bits are transmitted, the required bandwidth, and the types of connections required. These include:

Class A (CBR) — Connection-oriented, constant bit rate data with a timing relationship between source and destination, for example 64 Kbps digital voice.

Class B (VBR-RT) — Connection-oriented, variable bit-rate video and audio with a timing relationship between source and destination.

Class C (VBR-NRT) — Connection-oriented, variable bit-rate with no timing relationship between source and destination, for example Frame Relay traffic.

Class D (UBR/ABR) — Connectionless, variable bit-rate data with no timing relationship between source and destination, for example SMDS traffic.

2.2 ATM Cell Structure

The ATM cell at a UNI consists of two parts: a 5-byte header and a 48-byte information field or payload as shown in Figure 5. For networking purposes, only the header is significant.

The ATM cell contains the following fields:

Generic Flow Control (GFC): Controls the flow of traffic across the UNI and into the network. Currently, this field is not used.

Virtual Path Identifier (VPI) and Virtual Circuit Identifier (VCI): Provides addressing identifiers used to route cell traffic. Because of their routing significance, the VPI and VCI addressing identifiers are described further in the next section.

Payload Type (PT): Indicates the type of information carried by the cell. This designation is used by the network or terminating equipment to provide various traffic handling mechanisms.

Cell Loss Priority (CLP): Indicates the cell Discard Eligible (DE) status, depending on current network congestion conditions.

Header Error Control (HEC): Provides protection against misdelivery of cells due to addressing errors.

Payload: Follows the HEC field and contains 48 bytes of user data.

An ATM cell viewed at a Network-Network Interface has slight differences; for example, the FC bits are included as part of a larger, 12-bit VPI field at the NNI.

2.3 ATM Connections: VPIs and VCIs

ATM cells are sent between two points over a shared facility composed of Virtual Channels (VCs). These connections can be established on-demand (as a switched service), or pre-provisioned (such as PVCs). A Virtual Channel is used to describe a connection between two communicating ATM entities associated by one identifier value called the Virtual Path Identifier (VPI) and one unique identifier value called the Virtual Channel Identifier (VCI). A Virtual Path (VP) is used to describe multiple, bi-directional transport of ATM cells belonging to virtual channels that are associated by a common VPI. A virtual channel can consist of the following:

1) A group of ATM links

2) User equipment to a central office switch link

3) Switch-to-switch link

4) Switch-to-user equipment link

All communications proceed along this same VC, which preserves cell sequence and provides a certain quality of service.

3. Implementation

3.1 Design issues

We are proposing two ways of controlling and configuring the ATM switches remotely:

1) Using Telnet sessions.

2) Using World Wide Web.

We can manage ATM access systems using friendly telnet sessions enabled by the specific IP addresses of the ATM boxes. This is particularly useful when the unit is remotely located and ongoing local management is not convenient. In our network design the vendor specific boxes that we are using are not equipped with Ethernet port, hence we created a default management group configured manually with management IP access enabled. When IP Management is enabled on a bridge group, a network interface to the ATM switches IP stack is created, thus enabling the switch to recognize IP data-gram addressed to it. Also, a tunnel is to be created so that incoming ATM PVC traffic could be connected to the management group.

Alternatively, we could talk to the boxes using user-friendly Web browsers. In our network, the management and networking of the switches can be done by minimizing costs and maximizing user productivity using WWW interface. Instead of having a dedicated service, which is much, more expensive, one could access our network very easily from anywhere and at anytime. The idea of using web also has the advantage of carrying out complex configurations just by menu –driven commands, which in our case is supported by the vendor device.

Since our network needs a high bandwidth interface, we decided to use DS-1 (1.44 Megs) Downstream traffic and OC-3 (155 Megs) upstream traffic. Software development for the interface is the part of this work.

Different important features such as negotiable quality of service, peak cell rate, sustainable cell rate, constant or variable cell rate have been implemented over our network.

3.2 Methodology

Our main focus is the transfer of data at a maximum speed of 155 Megabits over a wide distance. Our main objective was and is to make ATM switches friendlier to the user with minimum of faults in the network design, integrating data communication around the globe. Thus we decided to design a prototype of our own wide area network that can be controlled remotely.

3.3 Hardware and Software

Hardware requirements:

Packetstar PSAX 600 ATM Access Concentrator [LUC01a]

Packetstar PSAX 100 ATM Access unit [LUC01b]

Adtech ATM Test equipment [ADT01]

Radcom Signaling test equipment

Fiber optical and DS-1 Cables

Software Requirements:

Oasos ATM software

JAVA, C and C++

CDL

3.4 Implementation

The remote box is placed arbitrarily in Los Angeles and it is controlled by the box placed in New York, which is attached to the local management station. The management access boxes are placed in Chicago, which are two in quantity in our case. The routes are configured that if one of the management boxes goes down, the other box would work to keep the network up and running.

The exact pictorial representation of the simulated wide area network is shown in Figure 6.

The native ATM interfaces used in the simulation are DS1 and OC-3 running at 1.44 Megs and 155 Megs respectively. The protocol optional devices for the interfaces supported by our network were IPODs (interface protocol optional devices) and XPODs or expansion protocol optional devices. There is no difference in the capability of an XPOD or IPOD other than the number of interfaces supported, for the ATM interfaces. However XPOD is generally used to support an ATM uplink into a core network, and the IPOD are generally to provide user/drop side connectivity. In our configuration we used two DS-1 IPODs and three OC-3 XPODs. The connectivity issue at physical level was done through optical fiber cables for OC-3s and Rj-48 connector for DS-1. The OC-3 interface operating at 155.52 Mbps was of intermediate range with enhanced buffering, traffic policing and hardware OAM (operation and maintenance) capabilities. To setup the network each of the interfaces were doubled checked with port loop-back F4/F5 cells for the authenticity. For the DS-1 interface we used the PLCP (physical layer convergence protocol) framing standards at the data link layer. The interface at 1.544 Mbps was also with enhanced buffering capabilities as well as traffic policing and hardware OAM capabilities.

The lower end box Psax 100 supported a single power supply. AC: 90-132/180-264 VAC 47-63 HZ- Auto ranging 100-Watts power supply unit with one Ampere maximum draw. The DC end supported -36-76 VDC maximum draw. The higher end Psax 600 was with the dual power supply, which operated in load sharing manner, each having its own power feed. AC side supported 90-132/180-264 VAC 47-63 Hz, auto ranging with 300 watts maximum draw. The DC measures were –36 to –76 VDC with same as AC 300 watts maximum draw.

As for the clocking issue, all the boxes had internal reference oscillator recovered from user-specified interface. We could define the primary and secondary timing references. The primary reference is continually monitored and it switches over to the secondary in the event of primary failing. The system was configured so as to revert back to the primary source, once it has been stabilized for a definite period of time.

The ATM operating software used for the configuration on the boxes were carefully defined Application Programming Interface (API) based objected oriented system. The Oasos software was downloaded into the box using DB-9 serial cables through the craft interface. Initially the bare minimum operating code called Lzrom.bin was loaded after which the fuller version of OS was uploaded using FTP. The initial IP address assigning of the boxes were done through the craft interface so that FTP could be carried out. Each slot kept a complete copy of the operating system and applications software in flash storage. Upon powering up the boxes the operating system was loaded into each slots one at a time. A copy of system control application (SCA) was loaded into extra slot as a standby. Finally, the interface configuration on each slot went under examination and only the software modules needed were loaded into the memory. The application was tuned to available memory and could automatically scale itself to single or multi-processor configurations. The executable memory images were dynamically built.

Our native wide area network was capable of networking non-ATM services that could be adapted into ATM cells before being routed to the destination. The process of segmentation and re-assembly (SAR) was performed within the switch fabric in a location called protocol accelerator. Non-ATM traffic is either packet-based (Ethernet, frame) or circuit-based (time-division multiplexed traffic such as CES and compressed voice). In either case the boxes that we were using were capable of transferring both packets and compressed voice over our wide area network by adopting varied form of data into cells. Packet based traffic used AAL-5 and AAL-2 segmentation and re-assembly while circuit based ones used AAL-1 SAR.

The other functionality used in our wide area network was the adaptation soft permanent virtual circuit better referred as ASPVC. This functionality greatly simplifies the provisioning of adaptation services across our network by eliminating the need for hop-by-hop provisioning of establishment of circuits. The boxes are responsible for dynamically establishing an SVC (switched virtual circuit) across the entire backbone network. To give an example if we were to implement end-to-end circuit emulation service, PVCs would need to be established along each hop in the network that the circuit would traverse. This is simplified in our case by letting the core boxes support SPVCs. In this case, PVC would be needed on each termination link, and a single SPVC could be established across the entire backbone network. This is still a tedious provisioning process. Instead we use ASPVC by specifying service definition at each node. The rest would be taken care by the box itself by establishing SVC connection across the backbone network. The maximum numbers of ASPVC’s that could be configured on our network was limited to 1400. The SVC could be amounted to a total of 648 calls at a go. The boxes supported both E.164 as well as AESA (NSAP) addressing formats. The maximum numbers of VPs addressable was limited to 64 and that of VCs were limited to 4096.

Very interesting part of this project is in the traffic management. We were able to play with various service categories when traffic was passed through the Chicago gateway in our network. Buffer/queue management including congestion management, connection admission control (CAC), usage parameter control (UPC), traffic shaping etc were few areas that our network successfully operated upon

Quality of service was another interesting aspect in this work. Using buffer management techniques in conjunction with the connection admission control bandwidth allocation function, we could use various service categories like CBR (constant bit rate), VBR (variable bit rate) real time and non-real time, UBR (unspecified bit rate) and ABR (available bit rate) over our simulated network. Our network handled CBR and VBR traffic types as separate, independent service class, by separate queues, which were configurable in size. Minimum bandwidth guaranteed for unspecified bit rate as quoted by ATM forum was not to be seen in our network owing to the fact that vendor specific box did not have such capabilities.

In order to guarantee the requested quality of service for PVC or SVC of our network, we employed CAC functions when establishing a circuit. CAC function is the principle manager of system resources, including bandwidth. Each port has a fixed bandwidth and a variable bandwidth pool. The amount of fixed bandwidth is related to actual physical throughput limitations while the variable bandwidth is user configurable. The fixed bandwidth of each physical port is dependent upon the interface type, and configuration parameters. In our case the DS-1 interface had a fixed bandwidth of 1.54 Mbps while OC3 had the fixed bandwidth of 155.52 Mbps. With CAC we could control switch resources like cell buffers, bandwidth and VPI/VCI values. The detail of the configurations on the network is followed on the configuration detail part.

It is to be noted that bandwidth overbooking was achieved through the management of the variable pool. We could see that quality of service was violated when we overbooked VBR and UBR traffic in our network. The over subscribing of CBR traffic was not allowed in our network.

The parameters used for the CAC are:

PCR peak cell rate

SCR sustainable cell rate

MBS maximum burst size

VPI virtual path identifier

VCI virtual circuit identifier Buffers

We could choose the buffer size according to the type of service chosen. Two types of cell buffers are present; input buffers and output buffers. The total number of buffers depended on the type and number of interface PODs present.

The boxes supported transmissions of ATM operations, administration, and maintenance (OAM) cells on compatible interfaces. OAM cells were important diagnostic tools, for ensuring smooth network operations on our network. Both F4 and F5 cells were supported by the hardware. F4/F5 cells are very important tool in analyzing ATM network behavior and detecting service degradation. It also has a practical use in billing information purposes. In our network we used the OAM cells to check loop-back of the interface, continuity checks and complete OAM fault management. The F4/F5 cells are marked with a unique header, enabling the hardware to pick them out of an ATM cell stream. The OAM functions are associated with the ATM and physical layers only. F4 and F5 both operate at the ATM layer. F4 is associated with virtual paths and F5 are associated with virtual circuits.

The crux of the problem in our network design was the configuration of the CorIPs and then assimilating these CorIPs into AccesIPs. Considerable time was spent in getting the boxes rightly configured. Also, WanIPs required considerable time for configuration.

Configuring the boxes with Access IP provided a single unified IP address for management of the unit. It also created a native LAN service bridge group, which was tied to the Access IP management path. This enabled management traffic to be routed across the gateway Chicago unit to other downstream LA unit.

WanIP was enabled on each Chicago gateway boxes that created a native local area service bridge group, and created a tunnel associated with the bridge group. As for the dial types for the WanIP we used both ASPVC and PVCs.

The Chicago box was the unit configured with AccessIP as a gateway unit. The LA unit had the WanIP accordingly configured to talk to the gateway unit. The SA_WANIP command created a native local area network service bridge group on the LA box with IP access enabled and established a tunnel back to the access IP NLS group at the gateway Chicago unit. This tunnel back to the gateway unit’s Access IP bridge group provided the connectivity up the WAN to the local network management stations. A defualt IP route was defined on the local box using sa_route command. The default route designated a direction to the network when network management station tried to generate a response. The two corIPs functioned automatically in our network. The remote core IP provided during the configuration served as a default IP route whenever needed. The state machine in the boxes monitored the CorIPs. We could see by yanking cables that if CorIP1 failed that CorIP2 took over as a default route. This was a wonderful layback scheme in our network. In the event that our both CorIPs failed the default route was supposed to be undefined until one of the links came back up again.

The ASPVC dial type used in our network was of great functionality particularly for the WanIP scenario. When we shut down the LA box the management connectivity was restored automatically when the unit at LA came back up again with the SVC call.

An interesting part of this work also included the generation of cells from Adtech analyzers. We could pump in cells from the New York box and see the traffic passing through the LA box and back to the New York box. In doing so we had adjusted various traffic policing in the respective boxes to measure quality of service along the path. The count of the cells was precise in our circuit as intended in the service contract. The amount of traffic to be generated via test equipment was user configurable. The other advantage of this test equipment was the monitoring and diagnosis of our network. We could figure out the congestion in the port and cell highway through this particular test equipment by capturing either the port or the cells.

For our temporary circuits we used Radcom test equipment to analyze the setup and call proceedings in our network. We could verify the maximum number of calls on our network as well as other features like called party number, called peak cell rate, broadband bearer class used etc. Traffic descriptors in forward as well as backward directions could be justified with this Radcom device. This test equipment also was very handy in monitoring our ASPVC circuit. The dropped calls were easily identified through this device. Also, the congestion in the traffic path and other admission related details could be easily monitored.

4. Other Issues

4.1 Cost

The design of the network itself was an intellectual challenge. Although the total cost of the devices amounted to an astronomical cost from a layman’s point of view, we need to keep in mind that this work was intended for larger organizations such as Internet service providers and Telecom giants in the current market. The total cost of operation of the network that we operated is shown in Table 1.

As an extension of this work we could do a comparative studies of various ATM switches currently available in the market. Also, in that case we could have setup an interoperability scenario. Cost wise we would have run into higher sums of money if we had employed an interoperability research for this work.

4.2 Safety and Security Concerns

Our native wide area network required some safety measures. The boxes that we were using complied with the Bellcore GR-63-Core, TR-NWT-00078 and met the NEBS level 3 requirements. The devices we were using were laser safe. Harmonic current and Voltage fluctuation was built-in with safety regulated limits and we need not worry about human safety during operation of the device. The built-in safety measures in the vendor specific device provided the maximum level of human safety.

Adherence to standard protocols let our network operate our connection in the wide area network very robustly. Flexible security mechanisms furnished us with access control, authorization and encryption. All management traffic was protected against unauthorized access by constraining it to secure IP connections. End to end security for Java sessions was customized using Java class libraries.

The system incorporated two level of security protection. Firstly, users were granted application access privileges on a per user basis on Telnet and Java sessions. Additional security granularity was provided by granting users either full access (read/write) or limited access (read only operator for each application they have been authorized to use)

The process of software upgrade had a tighter version control. Each time the user wanted to change the software on the boxes, a user-level access is solicited. Because of the modular software architecture only those software components for which upgrade was desired could be transferred to the system. This minimized the effects of a software upgrade on existing services on our network. It also served as a key tool in time saving and management process of the upgrading software. In our work we used the standard operating system and did not worry much about upgrades of the software, although we did successfully demonstrated the software upgrading process.

5. Conclusions and Future Work

In this paper we introduced and implemented the idea of remotely controlling a far placed ATM box using network management station placed closer to the user for practical applications in our daily life. We have targeted our network design and actual implementation of WANIP and CORIP to make our native Wide Area Network functional. Also, we considered Negotiation of (QOS) quality of service in our network and the use of permanent (PVC) as well as (SVC) temporary connections for the transfer of data. Despite the fact that we could only use DS-1 and OC-3 interface for the transport of data, voice and video over our network; our network was scalable enough to add lots of features in the future.

We are considering adding other features to this network in the future such as frame Relay to ATM network internetworking, Inverse multiplexing over ATM (IMA) service, low bit rate voice capability, and Serial circuit emulation services

References

[ADT01 ] The Adtech AX/4000 Broadband Test System,

http://www.adtech-inc.com/products/ax4000.asp

[BLCC98] Black, U. Frame Relay Networks: Specifications and Implementations. McGraw-Hill, New York, 1998.

[CHEN96] Chen, T.; Liu, S.; and Samalam, V. “The Available Bit Rate Service for Data in ATM Networks,” IEEE Communications Magazine, May 1996.

[JAIN93] Jain, B. and Agrawala, A. Open Suystems Interconnections. McGraw-Hill, New York, 1993.

[LUC01a] PacketStar™ PSAX 600, http://www.lucent.com/ins/products/psax/psax600.html.

[LUC01b] PacketStar™ PSAX 100, http://www.lucent.com/ins/products/psax/psax600.html

[MCDY99] McDysan, D., and Spohn, D. ATM: Theory and Applications. Mc-Graw-Hill, New York, 1999.

[SOPH97] Spohn, D. Data Network Design. Mc-Graw Hill, New York, 1997.

[STAL99] Stallings, W. ISDN and Broadband ISDN, with Frame Relay and ATM. Prentice Hall, New Jersey, 1999.

[SAIT96] Saito, J., et al. “Performance Issues in Public ABR Service.” IEEE Communications Magazine, November 1996.

[SUZU94] Suzuki, T. “ATM Adaptation Layer Protocol,” IEEE Communications Magazine, April 1994.

Appendix A: Snapshots of different sessions

(These snapshots are for demo purposes; only few will be included in final version as space permits)