EXECUTIVE SUMMARY

With the complexity of networks increasing, management of these complex networks is becoming more and more of a challenge. The facilities desired and found in complex networks consists of the use of multiple platforms with different interfaces as well as hybrid overlays to handle various types of traffic such as, voice , data, and multimedia. In order for ISPs (Internet Service Provider) to maintain or achieve a competetive edge, these facilities should be provided effectively with low cost.

The solution to simplifying networks and encompassing voice,data, and mulitmedia while enabling rapid service deployment lies in the Access Concentrator network device. The system supports the desired facilities by concentrating multiple DSL access lines into high-speed switching network interfaces, essentially reducing the amount of equipment and cabling required for broadband services. The Access Concentrator device also provides a single management platform through which all voice, videow, and data traffic are integrated. By integrating the various types of traffic the network utilizes bandwidth more efficiently, leading to lower costs.

With the importance of these network devices clearly evident, an extensive interrogation of the operational range should be determined. Our goal throughout the upcoming few months is to deveolop a test methodology, which is a combination of test tools, test cases, reference standards, and processes to determine the operational range of the Access Concentrator device.

[Back to TOC]

---

INTRODUCTION

Ever since the Internet was born in 1969, it has been growing at an exponential rate. Internet began with four hosts and it now has over 160 million hosts. This huge number paints the picture that more and more people are subscribing to the Internet through their Internet Service Providers (ISPs). With more subscribers, ISPs now are faced with a more difficult task of managing a large number of connections while keeping the QoS as high as possible. One of the devices that helps them accomplish this job is the Access Concentrator (AC).

An AC is a networking device that sits between a gateway router and the Digital Subscriber Line Access Multiplexer (DSLAM). The DSLAM multiplexes a large number of subscribers to the backbone. This backbone is then connected to the Access Concentrator which has access to the Internet (outside world). So the AC basically handles all the traffics to and from the users.

With such a demand, our team is assigned the task of developing a methodology for testing an AC device. We are going to work with some different AC devices such as Cisco 7200 and 10000, Redback 800 and 10000, and net.com SCREAM. More specifically, we are going to write test cases to test the frame loss, throughput, latency, and jitter on each of the available devices. Due to the availability of the equipments, we may have to do this remotely or in persons.

[Back to TOC]

---

PROBLEM DESCRIPTION

Our overarching goal is to develop a test methodology to extensively interrogate the operational range of Access Concentrator (AC) devices. To do this we need a combination of test tools, test cases, reference standards and processes. First of all, we need to understand the existing terminology and methodologies. We need to know common performance measurement techniques, common terms, and understand PPP technology. Next we need to understand the devices that we are using. Currently, we are waiting for a Cisco 10K AC device, but there are others that we may use including but not limited to : Cisco 6400, Redback SMS 1800, 10K, and Nortel Shasta 5000. We need to understand features implemented by the devices under testing - PPP termination and aggregation, edge/metro routing, data encryption, etc. We then need to analyze identify performance factors of DUTs, typical performance issues of DUTs, throughput, latency, session setup characteristics, session flapping performance, variations due to interface/port options, and negotiated factors of AC devices with the mentor/instructor. We finally need to produce a detailed test methodology, documented results with a comparison to the standard DUT, and a recommendation for future improvements to the test methods.

[Back to TOC]

---

APPROACH TO SOLUTION

We have decided that in order to solve this problem, we will divide the task up based on the different aspects of an access concentrator. In order to do this, our first task is to read all of the documentation that we can. We need to figure out the differences between an access concentrator and a router or switch. There is no real definition/benchmark for what an access concentrator has to do. It is really up to the companies that manufacture them, as to what features they allow.

Once we have these definitions down, we will head on over to the lab and start looking at how to configure and use the tools that we will be given. the lab will look something like this:

Logically, however, it will look like this:

The aspects of an access concentrator that we know need to be tested can be divided into three catagories:

• The initialization of PPP connections
• The upstream traffic (to the IP cloud)
• The downstream traffic (from the IP cloud

Once we have come up with the specific things that an access concentrator needs to do in these situations, we will develop a methodology and testcases to see how well the actual devices handle this. Once the testcases are written, we will switch with other members in our group and let them go over the testcases we have created. After this verification phase, we will get in the labs and actually test the equipment. Of course, we will have been in the labs developing these testcases, seeing how things work, but the actual testing will not be until the testcases have been verified by our group members.

Currently we have a few 7200s and SmartBits in RTP. In California we have a Nortel Shasta (working ATM interface, but the GigE interfaces are not working yet), RedBack 800, and a Cosine IPSX (can not configure for large scale). These are devices that we may have remote access to later on in the semester. A few other devices that Spirent is trying to aquire are a Cisco 10K, RedBack 10K, and a Net.com Scream. With the equipment that we have in RTP at the current moment, the testing phase of this project may be rather limited.

After the testing, we will write up our finding, and the testcases for Spirent.

Everyone has to read the documentation. In order to do anything on this project, everyone must learn the new material. We do not have to be experts on the entire deivce, but we have to be knowledgable. Once everyone on has read the material, we have decided that breaking up the different parts of an access concentrator would be the best approach. That way, we can all become experts on individual pieces of the pie rather then the entire device. Since we are all human, group members will also have to help verify the testcase so no person spends too much time looking at a problem. The reason for reviewing with one other person, is because it takes up less time that way. However, any real issues that neither person can fix, will be brought to the group for help.

[Back to TOC]

---

PROPOSED VERIFICATION and VALIDATION PROCESS and DELIVERABLES

We plan to write software that will test our access concentrator operational range. The test will consist of developing scripts using SmarBits equipment. These test cases will be written to find where the access concentrator breaks. The interfaces for these tests are Ethernet and ATM. We will compare this information to the concentrator's specifications and draw conclusions about how successful our tests are.

We will test session capacity, which is the maximum number of PPPoE, PPPoA and PPPoEoA sessions that the DUT can establish and maintain. We will validate this by sending low-level traffic (Echo Requests) across each session. This is also used for session establishment rate, which will be measured too. It is the maximum rate at which PPP session establishment requests can be sent to the DUT resulting in successful sessions.

We will test throughput, which is measured packet loss, throughput, and latency of packets sent across PPP sessions. The final two tests are session stability, which is stability of DUT and data forwarding stability, which is forwarding stability, in the presence of repeated session establishments and teardowns. The session stability test is like a stress test on the DUT and data forwarding stability will be done to characterize the data forwarding performance under this stress test

[Back to TOC]

---

SCHEDULE

Current Schedule

[Back to TOC]

---

REFERENCES

Kentrox. Simplifying Hybrid Networks. 11 October 2002. <http://www.kentrox.com/solutions/shn/index.asp>.

Zacon, Robert. Hobbes' Internet Timeline v5.6. 1 April 2002. 11 October 2002. <http://www.zakon.org/robert/internet/timeline/>.

 

 

[Back to TOC]

---

APPENDICES

Relevant RFCs	Access Concentrator Devices
RFC 1242 RFC 2544 RFC 2285 RFC 2889 ERF 1661 (PPP) RFC 2364 (PPPoA) RFC 2516 (PPPoE)	Redback SMS 1800 and SMS 10000 Nortel Shasta 5000 net.com SCREAM 50, 100, 200 Cisco 10K and 6400 Cosine IPSX Juniper

This page was last updated on:
Thursday, November 7, 2002 22:00
Copyright © 2002 by Team 3, All Rights Reserved.
WebSite contact: K. Fritz Lehr, E-mail: kflehr@unity.ncsu.edu, Tel: (919) 593-0162