Error detection/correction and fault detection/recovery – Pulse or data error handling – Transmission facility testing
Reexamination Certificate
1999-01-08
2001-08-28
Decady, Albert (Department: 2133)
Error detection/correction and fault detection/recovery
Pulse or data error handling
Transmission facility testing
C714S031000
Reexamination Certificate
active
06282678
ABSTRACT:
BACKGROUND OF THE INVENTION
In order to accommodate the increasing amount of data traveling over networks, communication speed improvements for network communication devices are constantly sought. Speed improvements mandate new transmission protocols. The new transmission protocols may be evolutionary or revolutionary. In both cases, however, comprehensive testing is mandatory.
An example of a data or network communication device that requires testing and is used to transmit data over networks, such as the internet, is a router. Routers select the best path to send a message, based on the destination and source addresses. Routers perform a number of tasks. High level routing tasks are partitioned into smaller subtasks, forming layering and service models. The idea behind layering is that each layer is responsible for providing some service to the layer above and does this by using the services of the layer below. There are certain interfaces required to communicate between layers, and there are protocols for communicating between the same level layers located on different routers. Router and other network device manufacturers must test communication links and protocols between each layer combination exhaustively as part of device and network validation.
Besides layer communication protocols, there are intra- and inter-domain routing protocols. Examples of intra-domain routing protocols are RIP, IS-IS, OSPF, and integrated routing. Some examples of inter-domain routing protocols are static routing, EGP, BGP, IDRP. These protocols are also continually evolving, and the network communications devices implementing the protocols must be tested before new features are released to market.
Like routing protocols, switching modes in routers are also evolving. Some examples of switching modes are CEF (Cisco Express Forwarding, which is a non-cache-based switching mode for IP packets), IP switching (which is cache-based), and Tag Switching (where “tags” are added to each IP packet). Improvements and extensions are being made continually to these and other switching modes. Consequently, extensive testing of new features is critical.
Hardware interfaces are also increasing in variation, sophistication, and bandwidth (among other features). Example interfaces include Ethernet, Fast Ethernet, Token Ring, FDDI (fiber distributed data interface), and HSSI (high speed serial interface). Some routers support multiple interfaces of the same type or different types. Like the routing protocols and the switching modes, hardware interfaces are also evolving. And, like routing protocols and switching modes, hardware interfaces also require comprehensive testing on a network topology level.
Still further, in order to communicate between a source and a destination, data packets may have to travel over networks using different routing protocols, different switching modes, and hardware interfaces as they travel from link to link on their data paths. To do this, the data packets are typically encapsulated, in Ethernet frames for example. These encapsulation modes are also modified periodically in order to keep up with the changing interfaces, switching modes, and routing protocols.
Developments in new routing protocols, switching modes, encapsulation modes, and hardware interfaces require new sets of tests; but, backward compatibility is usually a requirement in order to maintain an existing client base so that new computers and new data communication devices can be added to their existing networks with minimal cost and impact to an existing, running network. This means that each time a small improvement is made, new testing must be performed on the data communication devices, as well as testing to ensure backward compatibility.
In general, most testing code is the same for performing standard network testing tasks, such as establishing network communication and network configuration, and collecting data, while specific functionality tests are often unique, being written to test a single functionality of a specific network communication device in a specific test environment.
SUMMARY OF THE INVENTION
The problem with the typical strategy to implement device testing is that every test engineer must design a test program for every protocol, switching mode, hardware interface, and encapsulation mode. Although commonality exists among the code used to perform this testing, typically the test scripts are written in a non-general format with no way of taking advantage of the common and reusable code sections in future test programs.
The current invention provides increased expandability, versatility and reusability of test code by identifying and grouping similar code into test environment support libraries, specific test libraries, and topology files. A general main driver routine solves the expandability, versatility, and reusability issues since the corresponding components are kept external or distinct from the static, single purpose, generic main driver routine. And, once code is developed for new routing protocols, switching modes, encapsulation modes, and hardware interfaces, the code is accessible and can be exercised by other external routines, thereby reducing test development, debug, and integration times.
In general, according to one aspect, the invention features a test system for network communication devices comprising a topology input file. This file describes connections between the network communication devices. A test environment support routines library contains device-independent test information for data management. A case specific routines library contains device-specific tests and device-specific configuration control information for the network communication devices. And, a main driver routine then references the topology input routines, the test environment support routines, and the case specific test routines.
A test control computer is connected to the network communication devices to receive configuration and control information. The main driver routine, usually running on the control computer, receives a test command, and, in response, accesses the corresponding topology input file to build test vector command buffers for each of the network communication devices to establish configuration for testing. The main driver routine uses test environment support routines to manage data on the control computer and executes the specific test case routines according to the topology input file. In a preferred embodiment, the test control computer communicates with the network communication devices by using an automated test system.
REFERENCES:
patent: 5271000 (1993-12-01), Engbersen et al.
patent: 5421004 (1995-05-01), Carpenter et al.
patent: 5557740 (1996-09-01), Johnson et al.
patent: 5854889 (1998-12-01), Liese et al.
patent: 5864660 (1999-01-01), Hamameh et al.
patent: 5987625 (1999-11-01), Wolff
patent: 6134690 (2000-10-01), Ivaturi et al.
Snay David K.
Syed Faiz
Cisco Technology Inc.
De'cady Albert
Hamilton Brook Smith & Reynolds P.C.
Ton David
LandOfFree
Generic test execution method and apparatus does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Generic test execution method and apparatus, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Generic test execution method and apparatus will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2477706