RESOURCE RESERVATION AND INTEGRATED SERVICES
on a Gigabit Internetwork using ATM Point-to-Point Protocol

Sponsored through Intel

Background

The Internet protocol suite provides the foundation for much of the current data communications intrastructure. The explosive growth of the Internet, coupled with the increasing bandwidth demands of multimedia and WWW applications has strained the capabilities of existing IP routers, which cannot scale up the the new bandwidth requirements. On the other hand, the last few years has seen the emergence of Asynchronous Transfer Mode (ATM) technology, which offers unprecedented scalability and cost/performance, as well as the ability to reserve network resources for real-time oriented traffic and support multipoint communications. These complementary strengths and limitations make it natural to combine IP with ATM to obtain the best that each has to offer.

This project describes an architecture and a network framework, that enables the synergistic combination of IP and ATM technologies.

Approach to the research

We propose the design of a highly scalable IP router based on an ATM core and a set of tightly coupled start of the art Intel processors (These can be either Pentiums or P6 processors --- we will refer to them as Pentiums from now on). This High Performance Integrated Services IP Router (ISIR), provides flexibility in congestion control, routing, resource management, and packet scheduling.

Each router is designed using an ATM switch and host interface components. These components form a substrate that links a set of IP Processing Elements (IPPE). IPPEs control packet processing, and directly control the ATM substrate. The IPPEs are Pentium processors implementing flexible routing and queueing strategies that are central to high-performance IP networks.

Each router has IPPEs connected to each port. IP datagrams are carried across ATM Virtual Circuits (VCs) between routers, and between routers and hosts. At each router, IP packets are received on the input IPPE, which does a routing lookup to determine the outgoing link for that packet. After passing through ATM substrate, the packets are queued at the output IPPEs, which implement the queueing and scheduling policies for the router. Long term IP flows are mapped to dedicated VCs using an extension to the RSVP resource reservation protocol, thereby bypassing software processing altogether. The use of an ATM substrate, coupled with an IPPE for each link, ensures that the architecture can scale to arbitrary sizes.

Milestones for the project

1st Milestone

Acquire the necessary infrastructure to start building the IP router. The starting requirements are 4 Pentium workstations, 6 ATM interface cards, and 1 8 port ATM switch. The switch and the ATM interfaces operate at 155 Mbps.

Setup the IPPEs for IP forwarding along preestablished PVCs (Permanent Virtual Circuits). Recall that each IPPE consists of a Pentium workstation with 2 ATM interfaces.

Do the necessary testing, measurement, and optimizing of the ATM device driver and the IP processing for this environment.

At this point, a basic IP router will be ready.

2nd Milestone

Implement the RSVP resource reservation protocol on the IPPEs and on the end hosts.

Enable both audio applications (eg. vat) and video applications (eg. nv) to use RSVP.

Develop the RSVP extensions necessary to assign ATM VCs to individual IP packet flows.

At this point, applications will be able to request resource reservations from the IP router.

3rd Milestone

Design and implement IP scheduling within IPPEs. The initial implemenetation will focus on creating two classes of service- a best effort class, and a real time class. The packet scheduler will be designed to accept and process RSVP reservation requests.

Assemble the final testbed, by adding 2 more IPPEs and 2 more end systems to the testbed.

At this point, end to end resource reservations will be in place across the testbed.

4th Milestone

Once the High Performance Integrated Services Router is complete, detailed performance evaluations will be carried out, instrumenting any system bottlenecks. Testing will be carried out using a mixture of benchmarks and real applications.

Last Modified: July 24, 1996

<hari@dworkin.wustl.edu>
Return to the ARL Home Page