Home
Patent Search
IMT Blog
REGISTER
|
SIGN IN
United States Patent Application
20020165961
Kind Code
A1
Everdell, Peter B. ; et al.
November 7, 2002
Network device including dedicated resources control plane
Abstract
The present invention provides a method and apparatus for improving transmission of control information within a network device and between multiple connected network devices. Specifically, a control path is included within a network device that is independent of the data path and dedicates control path resources to each distributed processor within the network device. Dedicating resources insures that each processor has sufficient bandwidth on the control plane to transmit control information at high frequencies. This may prevent starvation of data transmissions during periods of high control information transfers and may also reduce the likelihood or further spreading of control information storms when one or more network devices in a network experiences a failure.
Inventors:
Everdell; Peter B.
(Littleton, MA)
, Noel; Chris R.
(Acton, MA
)
, Branscomb; Brian
(Hopkinton, MA
)
, Langrind; Nicholas A.
(Carlisle, MA
)
Correspondence Name and Address:
WORLD TRADE CENTER WEST 155 SEAPORT BOULEVARD
NUTTER MCCLENNEN & FISH LLP
BOSTON
MA
02210-2604
US
Series Code:
838320
Filed:
April 19, 2001
U.S. Current Class:
709/225;
370/469
U.S. Class at Publication:
709/225;
370/469
Intern'l Class:
G06F 015/173;
H04J 003/16; H04J 003/22
Claims
1. A telecommunications network device, comprising: a plurality of distributed processors; a data path coupled to the plurality of distributed processors; and a switched control path coupled to the plurality of distributed processors.
2. The telecommunications network device of claim 1, wherein the switched control path is a first switched control path and further comprising: a second switched control path coupled to the plurality of distributed processors.
3. The telecommunications network device of claim 2, wherein the first and second switched control paths comprise redundant switched control paths.
4. The telecommunications network device of claim 1, wherein the switched control path comprises an Ethernet switch.
5. The telecommunications network device of claim 4, wherein the Ethernet switch comprises: an Ethernet switch subsystem; and a plurality of physical Ethernet port chips coupled to the Ethernet switch subsystem, wherein each of the plurality of distributed processors is coupled with at least one of the plurality of physical Ethernet port chips.
6. The telecommunications network device of claim 5, wherein the plurality of physical Ethernet port chips is a first plurality of physical Ethernet port chips and the Ethernet switch subsystem comprises: an Ethernet switch chip; and a second plurality of physical Ethernet port chips coupled with the Ethernet switch chip, wherein the second plurality of Ethernet port chips are further coupled with the first plurality of physical Ethernet port chips.
7. The telecommunications network device of claim 1, wherein the switched control path comprises a proprietary bus.
8. The telecommunications network device of claim 1, wherein the switched control path comprises an Asynchronous Transfer Mode network.
9. The telecommunications network device of claim 1, wherein the switched control path comprises a Multi-Protocol Label Switching network.
10. The telecommunications network device of claim 1, fuirther comprising: a plurality of cards, wherein at least one of the plurality of processors is mounted on each of the plurality of cards.
11. The telecommunications network device of claim 1, wherein at least a portion of the plurality of distributed processors are coupled to the switched control path through multiple independent ports.
12. The telecommunications network device of claim 1, further comprising: an external port coupled with the switched control plane.
13. A telecommunications network device, comprising: a plurality of distributed processors; a data path coupled to the plurality of distributed processors; and a control path, including a plurality of control links, wherein at least one of the plurality of control links is coupled with each of the plurality of distributed processors.
14. The telecommunications network device of claim 13, wherein the control links comprise: Ethernet ports.
15. A telecommunications network device, comprising: a plurality of distributed processors; a data path coupled to the plurality of distributed processors; and a control path coupled to the plurality of distributed processors, wherein separate control path resources are dedicated to each of the plurality of distributed processors.
16. The telecommunications network device of claim 16, wherein the separate control path resources comprise: an Ethernet port.
17. A telecommunications network, comprising: a plurality of network devices, wherein at least a portion of the plurality of network devices each comprise: a plurality of distributed processors; a data path coupled to the plurality of distributed processors; and a switched control path coupled to the plurality of distributed processors.
18. The telecommunications network of claim 17, wherein the switched control path within each of the portion of the plurality of network devices is connected together as a multi-chassis switched control path.
19. A telecommunications network, comprising: a plurality of network devices, wherein at least a portion of the plurality of network devices each comprise: a plurality of distributed processors; a data path coupled to the plurality of distributed processors; and a control path, including a plurality of control links, wherein at least one of the plurality of c ontrol links is coupled with each of the plurality of d istributed p rocessors.
20. The telecommunications network of claim 19, wherein the control path within each of the portion of the plurality of network devices is connected together as a multi-chassis control path.
21. A telecommunications network, comprising: a plurality of network devices, wherein at least a portion of the plurality of network devices each comprise: a plurality of distributed processors; a data path coupled to the plurality of distributed processors; and a control path coupled to the plurality of distributed processors, wherein separate control path resources are dedicated to each of the plurality of distributed processors.
22. The telecommunications network of claim 21, wherein the control path within each of the portion of the plurality of network devices is connected together as a multi-chassis control path.
23. A method of managing a telecommunications network device including a plurality of distributed processors, comprising: transmitting network data through a data path within the network device; and transmitting control information between the plurality of distributed processors through a switched control path.
24. The method of claim 23, wherein the switched control path is an Ethernet switch.
25. The method of claim 23, wherein the switched control path is an A synchronous Transfer Mode network.
26. The method of claim 23, wherein the switched control path is a Multi-Protocol Label Switching (MPLS) network.
27. The method of claim 23, wherein the switched control path is a proprietary bus.
28. A method of managing a telecommunications network device including a plurality of distributed processors, comprising: transmitting network data through a data path within the network device; and transmitting control information between the plurality of distributed processors through a plurality of control links in a control path, wherein at least one of the plurality of control links is dedicated to each of the plurality of distributed processors.
29. A method of managing a telecommunications network device including a plurality of distributed processors, comprising: transmitting network data through a data path within the network device; and transmitting control information between the plurality of distributed processors through a control path, wherein separate control path resources are dedicated to each of the plurality of distributed processors.
30. A method of managing a telecommunications network including a plurality of network devices, wherein at least a portion of the plurality of network devices each includes a plurality of distributed processors and a control path coupling the plurality of distributed processors, comprising: connecting each of the control paths in the portion of the plurality of network devices; and transmitting control information between the plurality of network devices through the connected control paths.
31. The method of claim 30, wherein each control path comprises a switched control path.
32. The method of claim 30, wherein the switched control paths comprise Ethernet switches.
33. The method of claim 30, wherein each control path dedicates control path resources to each of the plurality of processors within the network device.
34. The method of claim 30, wherein each control path dedicates a control link to each of the plurality of processor within the network device.
Description
[0001] This application is a continuation-in-part of U.S. Ser. No. ______, filed Apr. 10, 2001, entitled "Common Command Interface" still pending, which is a continuation-inpart of U.S. Ser. No. 09/803,783, filed Mar. 12, 2001, entitled "VPI/VCI Availability Index" still pending, which is a continuation-in-part of U.S. Ser. No. 09/789,665 filed Feb. 21, 2001, entitled "Out-Of-Band Network Management Channels" still pending, which is a continuation-in-part of U.S. Ser. No. 09/777,468, filed Feb. 5, 2001, entitled "Signatures for Facilitating Hot Upgrades of Modular Software Components", still pending, which is a continuation-in-part of U.S. Ser. No. 09/756,936, filed Jan. 9, 2001, entitled "Network Device Power Distribution Scheme", which is a continuation-in-part of U.S. Ser. No. 09/718,224, filed Nov. 21, 2000, entitled "Internal Network Device Dynamic Health Monitoring, which is a continuation-in-part of U.S. Ser. No. 09/711,054, filed Nov. 9, 2000, entitled "Network Device Identity Authentication", which is a continuation-in-part of U.S. Ser. No. 09/703,856, filed Nov. 1, 2000, entitled "Accessing Network Device Data Through User Profiles", which is a continuation-in-part of U.S. Ser. No. 09/687,191, filed Oct. 12, 2000 entitled "Utilizing Managed Object Proxies in Network Management Systems", which is a continuation-in-part of U.S. Ser. No. 09/669,364, filed Sep. 26, 2000 entitled "Distributed Statistical Data Retrieval in a Network Device", which is a continuation-in-part of U.S. Ser. No. 09/663,947, filed Sep. 18, 2000, entitled "Network Management System Including Custom Object Collections, which is a continuation-in-part of U.S. Ser. No. 09/656,123, filed Sep. 6, 2000, entitled "Network Management System Including Dynamic Bulletin Boards", which is a continuation-in-part of U.S. Ser. No. 09/653,700, filed Aug. 31, 2000, entitled "Network Management System Including SONET Path Configuration Wizard", which is a continuation-in-part of U.S. Ser. No. 09/637,800, filed Aug. 11, 2000, entitled "Processing Network Management Data In Accordance with Metadata Files", which is a continuation-in-part of U.S. Ser. No. 09/633,675, filed Aug. 7, 2000, entitled "Integrating Operations Support Services with Network Management Systems", which is a continuation-in-part of U.S. Ser. No. 09/625,101, filed Jul. 24, 2000, entitled "Model Driven Synchronization of Telecommunications Processes", which is a continuation-in-part of U.S. Ser. No. 09/616,477, filed Jul. 14, 2000, entitled "Upper Layer Network Device Including a Physical Layer Test Port", which is a continuation-in-part of U.S. Ser. No. 09/613,940, filed Jul. 11, 2000, entitled "Network Device Including Central and Distributed Switch Fabric Sub-Systems", which is a continuation-in-part of U.S. Ser. No. 09/596,055, filed Jun. 16, 2000, entitled "A Multi Layer Device in One Telco Rack", which is a continuation-in-part of U.S. Ser. No. 09/593,034, filed Jun. 13, 2000, entitled "A Network Device for Supporting Multiple Upper Layer Protocols Over a Single Network Connection", which is a continuation and part of U.S. Ser. No. 09/574,440, filed May 20, 2000, entitled Vertical Fault Isolation in a Computer System" and U.S. Ser. No. 09/591,193, filed Jun. 9, 2000 entitled "A Network Device for Supporting Multiple Redundancy Schemes", which is a continuation-in-part of U.S. Ser. No. 09/588,398, filed Jun. 6, 2000, entitled "Time Synchronization Within a Distributed Processing System", which is a continuation-in-part of U.S. Ser. No. 09/574,341, filed May 20, 2000, entitled "Policy Based Provisioning of Network Device Resources" and U.S. Ser. No. 09/574,343, filed May 20, 2000, entitled "Functional Separation of Internal and External Controls in Network Devices".
BACKGROUND
[0002] Within a telecommunications network both data and control information (i.e., external control information) is passed between network devices in the network. The external control information supports a variety of administrative tasks, for example, learning and calculating network topology for routing purposes, setting up connections between two or more devices and sending and responding to error messages. External control information may also include control information from a network/element management system (NMS) to a network device, for example, for provisioning services and retrieving billing and statistical data. Within a network device including distributed processors, in addition to external control information, a considerable amount of internal control information is transferred between the distributed processors such that the network device with the distributed architecture appears to other network devices as one entity.
[0003] Transmitting the internal and external control information over the data path is referred to as in-band management. Typically, the control information is pulled off the data path by a processing function on a line card and sent over a switch fabric within the network device to a processor card within the network device. Thus, a portion of the network device's data path bandwidth is consumed in the transfer of control information.
[0004] In addition to bandwidth consumption, during high traffic periods, congestion control mechanisms may cause data and/or control information to be dropped. Dropping control information may cause one or more network devices to fail and may bring down the entire network. For example, if "keepalive" control information for a network device is dropped, then a timeout may occur and the other network devices may assume that that network device is down. This will cause the other network devices to reroute traffic around the "failed" network device. Rerouting traffic generates a considerable amount of router updates and status messages in an already congested/collapsing network. In addition, the rerouted traffic may overload one or more other network devices causing them to go down or drop other keepalive messages again causing a flurry of routing updates and status messages. Moreover, the network device that was assumed to have gone down may generate "I'm back" messages causing more routing updates and status messages. Thus, the chaos spreads in widening circles outward through the network causing the network to quickly destabilize and collapse.
[0005] Increasing the priority of control information may prevent the control information from being dropped. During storms of control information, however, data traffic may be starved.
[0006] To address the issues of in-band management, a network device having a distributed architecture may include an internal out-of-band control plane. Each of the distributed processors is connected to the out-of-band control plane, and the processors use the out-of-band control plane to transmit control information. For example, the out-of-band control plane may be an internal I.sup.2C bus, PCI bus, Ethernet hub or proprietary bus. Since these control planes include a shared media, the processors connected to them must share the available bandwidth. For example, an Ethernet hub may provide a maximum bandwidth of 100 Mb/sec, which is shared by each of the connected processors. Thus, the larger the number of distributed processors in a network device the less bandwidth per processor is available. As a result, the scalability of these control planes is limited.
[0007] In addition, adding an internal control plane decreases the network device's reliability and availability. Reliability is decreased when the new components for the control plane are added--that is, the more components a network device has, the higher the likelihood of a failure of one or more components. If the network device fails due to the lower reliability, then the network device availability is reduced.
SUMMARY
[0008] The present invention provides a method and apparatus for improving transmission of control information within a network device and between multiple connected network devices. Specifically, a control path is included within a network device that is independent of the data path and dedicates control path resources to each distributed processor within the network device. Dedicating resources insures that each processor has sufficient bandwidth on the control plane to transmit control information at high frequencies. This may prevent starvation of data transmissions during periods of high control information transfers and may also reduce the likelihood or further spreading of control information storms when one or more network devices in a network experiences a failure.
[0009] In one aspect, the present invention provides a telecommunications network device, including a plurality of distributed processors, a data path coupled to the plurality of distributed processors and a switched control path coupled to the plurality of distributed processors.
[0010] In another aspect, the present invention provides a telecommunications network device including a plurality of distributed processors, a data path coupled to the plurality of distributed processors and a control path, including a plurality of control links, wherein at least one of the plurality of control links is coupled with each of the plurality of distributed processors.
[0011] In yet another aspect, the present invention provides a telecommunications network device including a plurality of distributed processors, a data path coupled to the plurality of distributed processors and a control path coupled to the plurality of distributed processors, wherein separate control path resources are dedicated to each of the plurality of distributed processors.
[0012] In still another aspect, the present invention provides a telecommunications network, including a plurality of network devices, wherein at least a portion of the plurality of network devices each comprises a plurality of distributed processors, a data path coupled to the plurality of distributed processors and a switched control path coupled to the plurality of distributed processors.
[0013] In another aspect, the present invention provides a telecommunications network, including a plurality of network devices, wherein at least a portion of the plurality of network devices each comprise a plurality of distributed processors, a data path coupled to the plurality of distributed processors and a control path, including a plurality of control links, wherein at least one of the plurality of control links is coupled with each of the plurality of distributed processors.
[0014] In yet another aspect, the present invention provides a telecommunications network, including a plurality of network devices, wherein at least a portion of the plurality of network devices each comprise a plurality of distributed processors, a data path coupled to the plurality of distributed processors and a control path coupled to the plurality of distributed processors, wherein separate control path resources are dedicated to each of the plurality of distributed processors.
[0015] In still another aspect, the present invention provides a method of managing a telecommunications network device including a plurality of distributed processors, including transmitting network data through a data path within the network device and transmitting control information between the plurality of distributed processors through a switched control path.
[0016] In another aspect, the present invention provides a method of managing a telecommunications network device including a plurality of distributed processors, including transmitting network data through a data path within the network device and transmitting control information between the plurality of distributed processors through a plurality of control links in a control path, wherein at least one of the plurality of control links is dedicated to each of the plurality of distributed processors.
[0017] In yet another aspect, the present invention provides a method of managing a telecommunications network device including a plurality of distributed processors, including transmitting network data through a data path within the network device and transmitting control information between the plurality of distributed processors through a control path, wherein separate control path resources are dedicated to each of the plurality of distributed processors.
[0018] In still another aspect, the present invention provides a method of managing a telecommunications network including a plurality of network devices, wherein at least a portion of the plurality of network devices each includes a plurality of distributed processors and a control path coupling the plurality of distributed processors, including connecting each of the control paths in the portion of the plurality of network devices and transmitting control information between the plurality of network devices through the connected control paths.
BRIEF DESCRIPTION OF THE DRAWINGS
[0019] FIG. 1 is a block diagram of a computer system with a distributed processing system;
[0020] FIGS. 2a-2b are block and flow diagrams of a distributed network management system;
[0021] FIGS. 2c-2j are block and flow diagrams of distributed network management system clients and servers;
[0022] FIG. 3a is a block diagram of a logical system model;
[0023] FIGS. 3b and 3d-3f are flow diagrams depicting a software build process using a logical system model;
[0024] FIG. 3c is a flow diagram illustrating a method for allowing applications to view data within a database;
[0025] FIG. 3g is a flow diagram depicting a configuration process;
[0026] FIGS. 3h and 3j are flow diagrams depicting template driven network services provisioning processes;
[0027] FIGS. 3i and 3k-3m are screen displays of an OSS client and various templates;
[0028] FIGS. 4a-4z, 5a-5z, 6a-6p, 7a-7y, 8a-8e, 9a-9n, 10a-10i, 11a-11k, 11n-11o, 11s and 11x are screen displays of graphical user interfaces;
[0029] FIGS. 11L-11m are tables representing data in a configuration database;
[0030] FIGS. 11p-11r and 11t-11u are tables representing data in a network management system (NMS) database;
[0031] FIG. 11v is a block and flow diagram representing the creation of a user profile logical managed object including one or more groups;
[0032] FIG. 11w is a block and flow diagram of a network management system implementing user profiles and groups across multiple databases;
[0033] FIGS. 12a and 13a are block and flow diagrams of a computer system incorporating a modular system architecture and illustrating a method for accomplishing hardware inventory and setup;
[0034] FIGS. 12b-12c and 14a-14f are tables representing data in a configuration database;
[0035] FIG. 13b is a block and flow diagram of a computer system incorporating a modular system architecture and illustrating a method for configuring the computer system using a network management system;
[0036] FIGS. 13c and 13d are block and flow diagrams of an accounting subsystem for pushing network device statistics to network management system software;
[0037] FIG. 15 is a block and flow diagram of a line card and a method for executing multiple instances of processes;
[0038] FIGS. 16a-16b are flow diagrams illustrating a method for assigning logical names for inter-process communications;
[0039] FIG. 16c is a block and flow diagram of a computer system incorporating a modular system architecture and illustrating a method for using logical names for inter-process communications;
[0040] FIG. 16d is a chart representing a message format;
[0041] FIGS. 17-19 are block and flow diagrams of a computer system incorporating a modular system architecture and illustrating methods for making configuration changes;
[0042] FIG. 20a is a block diagram of a packaging list;
[0043] FIG. 20b is a flow diagram of a software component signature generating process;
[0044] FIGS. 20c and 20e are screen displays of graphical user interfaces;
[0045] FIG. 20d is a block and flow diagram of a network device incorporating a modular system architecture and illustrating a method for installing a new software release;
[0046] FIG. 21 a is a block and flow diagram of a network device incorporating a modular system architecture and illustrating a method for upgrading software components;
[0047] FIGS. 21b and 21g are tables representing data in a configuration database;
[0048] FIGS. 21c-21f are screen displays of graphical user interfaces;
[0049] FIG. 22 is a block and flow diagram of a network device incorporating a modular system architecture and illustrating a method for upgrading a configuration database within the network device;
[0050] FIG. 23 is a block and flow diagram of a network device incorporating a modular system architecture and illustrating a method for upgrading software components;
[0051] FIG. 24 is a block diagram representing processes within separate protected memory blocks;
[0052] FIG. 25 is a block and flow diagram of a line card and a method for accomplishing vertical fault isolation;
[0053] FIG. 26 is a block and flow diagram of a computer system incorporating a hierarchical and configurable fault management system and illustrating a method for accomplishing fault escalation.
[0054] FIG. 27 is a block diagram of an application having multiple sub-processes;
[0055] FIG. 28 is a block diagram of a hierarchical fault descriptor;
[0056] FIG. 29 is a block and flow diagram of a computer system incorporating a distributed redundancy architecture and illustrating a method for accomplishing distributed software redundancy;
[0057] FIG. 30 is a table representing data in a configuration database;
[0058] FIGS. 31a-31c, 32a-32c, 33a-33d and 34a-34b are block and flow diagrams of a computer system incorporating a distributed redundancy architecture and illustrating methods for accomplishing distributed redundancy and recovery after a failure;
[0059] FIG. 35 is a block diagram of a network device;
[0060] FIG. 36 is a block diagram of a portion of a data plane of a network device;
[0061] FIG. 37 is a block and flow diagram of a network device incorporating a policy provisioning manager;
[0062] FIGS. 38 and 39 are tables representing data in a configuration database;
[0063] FIG. 40 is an isometric view of a network device;
[0064] FIGS. 41a-41c are front, back and side block diagrams, respectively, of components and modules within the network device of FIG. 40;
[0065] FIG. 42 is a block diagram of dual mid-planes;
[0066] FIG. 43 is a block diagram of two distributed switch fabrics and a central switch fabric;
[0067] FIG. 44 is a block diagram of the interconnections between switch fabric central timing subsystems and switch fabric local timing subsystems;
[0068] FIG. 45 is a block diagram of a switch fabric central timing subsystem;
[0069] FIG. 46 is a state diagram of master/slave selection for switch fabric central timing subsystems;
[0070] FIG. 47 is a block diagram of a switch fabric local timing subsystem;
[0071] FIG. 48 is a state diagram of reference signal selection for switch fabric local timing subsystems;
[0072] FIG. 49 is a block diagram of the interconnections between external central timing subsystems and external local timing subsystems;
[0073] FIG. 50 is a block diagram of an external central timing subsystem;
[0074] FIG. 51 is a timing diagram of a first timing reference signal with an embedded second timing signal;
[0075] FIG. 52 is a block diagram of an embeddor circuit;
[0076] FIG. 53 is a block diagram of an extractor circuit;
[0077] FIG. 54 is a block diagram of an external local timing subsystem;
[0078] FIG. 55 is a block diagram of an external central timing subsystem;
[0079] FIG. 56 is a block diagram of a network device connected to test equipment through programmable physical layer test ports;
[0080] FIG. 57 is a block and flow diagram of a network device incorporating programmable physical layer test ports;
[0081] FIG. 58 is a block diagram of a test path table;
[0082] FIG. 59 is a block and flow diagram of a network management system incorporating proxies to improve NMS server scalability;
[0083] FIGS. 60a-60n are tables representing data in a configuration database;
[0084] FIG. 61a is a block diagram representing a physical managed object;
[0085] FIG. 61b is a block diagram representing a proxy;
[0086] FIG. 62 is a screen display of a dialog box;
[0087] FIG. 63 is a block diagram of a network device connected to an NMS;
[0088] FIG. 64 is a table representing data in an NMS database;
[0089] FIG. 65 is a block and flow diagram of a threshold management system;
[0090] FIGS. 66a-66e are screen displays of a graphical user interface;
[0091] FIG. 67 is a screen display of a threshold dialog box;
[0092] FIGS. 68, 69a-69b, 70a-70b and 71 are tables representing data in a configuration database;
[0093] FIG. 72a is a front, isometric view of a power distribution unit;
[0094] FIG. 72b is a rear, isometric view of the power distribution unit of FIG. 72a without a cover;
[0095] FIG. 73a is a rear, isometric view of a network device chassis including dual rnidplanes;
[0096] FIGS. 73b-73c are enlarged views of portions of FIG. 73a;
[0097] FIG. 74 is a block and schematic diagram of a portion of a module including a power supply circuit;
[0098] FIGS. 75, 76 and 79 are screen displays of a Virtual Connection Wizard;
[0099] FIG. 77 is a screen display of a VPI dialog box;
[0100] FIG. 78 is a screen display of a VPI/VCI dialog box;
[0101] FIGS. 80 and 81 are block and flow diagrams of a common command interface;
[0102] FIG. 82 is a block and flow diagram of an application including a command API and a display API;
[0103] FIG. 83 is a block and flow diagram of an extended common command interface;
[0104] FIG. 84 is a block and flow diagram of a switch control plane within a network device including a distributed architecture;
[0105] FIG. 85 is a block and flow diagram of a switch subsystem;
[0106] FIG. 86 is a block and flow diagram of a redundant switch control planes within a network device including a distributed architecture; and
[0107] FIG. 87 is a block and flow diagram demonstrating distributed processors including multiple ports to each redundant switch control plane within a network device.
DETAILED DESCRIPTION
[0108] Modular Software:
[0109] A modular software architecture solves some of the more common scenarios seen in existing architectures when software is upgraded or new features are deployed. Software modularity involves functionally dividing a software system into individual modules or processes, which are then designed and implemented independently. Inter-process communication (IPC) between the processes is carried out through message passing in accordance with well-defined application programming interfaces (APIs) generated from the same logical system model using the same code generation system. A database process is used to maintain a primary data repository within the computer system/network device, and APIs for the database process are also generated from the same logical system model and using the same code generation system ensuring that all the processes access the same data in the same way. Another database process is used to maintain a secondary data repository external to the computer system/network device; this database receives all of its data by exact database replication from the primary database.
[0110] A protected memory feature also helps enforce the separation of modules. Modules are compiled and linked as separate programs, and each program runs in its own protected memory space. In addition, each program is addressed with an abstract communication handle, or logical name. The logical name is location-independent; it can live on any card in the system. The logical name is resolved to a physical card/process during communication. If, for example, a backup process takes over for a failed primary process, it assumes ownership of the logical name and registers its name to allow other processes to re-resolve the logical name to the new physical card/process. Once complete, the processes continue to communicate with the same logical name, unaware of the fact that a switchover just occurred.
[0111] Like certain existing architectures, the modular software architecture dynamically loads applications as needed. Beyond prior architectures, however, the modular software architecture removes significant application dependent data from the kernel and minimizes the link between software and hardware. Instead, under the modular software architecture, the applications themselves gather necessary information (i.e., metadata and instance data) from a variety of sources, for example, text files, JAVA class files and database views, which may be provided at run time or through the logical system model.
[0112] Metadata facilitates customization of the execution behavior of software processes without modifying the operating system software image. A modular software architecture makes writing applications--especially distributed applications--more difficult, but metadata provides seamless extensibility allowing new software processes to be added and existing software processes to be upgraded or downgraded while the operating system is running (hot upgrades and downgrades). In one embodiment, the kernel includes operating system software, standard system services software and modular system services software. Even portions of the kernel may be hot upgraded under certain circumstances. Examples of metadata include, customization text files used by software device drivers; JAVA class files that are dynamically instantiated using reflection; registration and deregistration protocols that enable the addition and deletion of software services without system disruption; and database view definitions that provide many varied views of the logical system model. Each of these and other examples are described below.
[0113] The embodiment described below includes a network computer system with a loosely coupled distributed processing system. It should be understood, however, that the computer system could also be a central processing system or a combination of distributed and central processing and either loosely or tightly coupled. In addition, the computer system described below is a network switch for use in, for example, the Internet, wide area networks (WAN) or local area networks (LAN). It should be understood, however, that the modular software architecture can be implemented on any network device (including routers) or other types of computer systems and is not restricted to a network switch.
[0114] A distributed processing system is a collection of independent computers that appear to the user of the system as a single computer. Referring to FIG. 1, computer system 10 includes a centralized processor 12 with a control processor subsystem 14 that executes an instance of the kernel 20 including master control programs and server programs to actively control system operation by performing a major portion of the control functions (e.g., booting and system management) for the system. In addition, computer system 10 includes multiple line cards 16a-16n. Each line card includes a control processor subsystem 18a-18n, which runs an instance of the kernel 22a-22n including slave and client programs as well as line card specific software applications. Each control processor subsystem 14, 18a-18n operates in an autonomous fashion but the software presents computer system 10 to the user as a single computer.
[0115] Each control processor subsystem includes a processor integrated circuit (chip) 24, 26a-26n, for example, a Motorola 8260 or an Intel Pentium processor. The control processor subsystem also includes a memory subsystem 28, 30a-30n including a combination of non-volatile or persistent (e.g., PROM and flash memory) and volatile (e.g., SRAM and DRAM) memory components. Computer system 10 also includes an internal communication bus 32 connected to each processor 24, 26a-26n. In one embodiment, the communication bus is a switched Fast Ethernet providing 100 Mb of dedicated bandwidth to each processor allowing the distributed processors to exchange control information at high frequencies. A backup or redundant Ethernet switch may also be connected to each board such that if the primary Ethernet switch fails, the boards can fail-over to the backup Ethernet switch.
[0116] In this example, Ethernet 32 provides an out-of-band control path, meaning that control information passes over Ethernet 32 but the network data being switched by computer system 10 passes to and from external network connections 31a-31xx over a separate data path 34. External network control data is passed from the line cards to the central processor over Ethernet 32. This external network control data is also assigned a high priority when passed over the Ethernet to ensure that it is not dropped during periods of heavy traffic on the Ethernet.
[0117] In addition, another bus 33 is provided for low level system service operations, including, for example, the detection of newly installed (or removed) hardware, reset and interrupt control and real time clock (RTC) synchronization across the system. In one embodiment, this is an Inter-IC communications (I.sup.2C) bus.
[0118] Alternatively, the control and data may be passed over one common path (in-band).
[0119] Network/Element Management System (NMS):
[0120] Exponential network growth combined with continuously changing network requirements dictates a need for well thought out network management solutions that can grow and adapt quickly. The present invention provides a massively scalable, highly reliable comprehensive network management system, intended to scale up (and down) to meet varied customer needs.
[0121] Within a telecommunications network, element management systems (EMSs) are designed to configure and manage a particular type of network device (e.g., switch, router, hybrid switch-router), and network management systems (NMSs) are used to configure and manage multiple heterogeneous and/or homogeneous network devices. Hereinafter, the term "NMS" will be used for both element and network management systems unless otherwise noted. To configure a network device, the network administrator uses the NMS to provision services. For example, the administrator may connect a cable to a port of a network device and then use the NMS to enable the port. If the network device supports multiple protocols and services, then the administrator uses the NMS to provision these as well. To manage a network device, the NMS interprets data gathered by programs running on each network device relevant to network configuration, security, accounting, statistics, and fault logging and presents the interpretation of this data to the network administrator. The network administrator may use this data to, for example, determine when to add new hardware and/or services to the network device, to determine when new network devices should be added to the network, and to determine the cause of errors.
[0122] Preferably, NMS programs and programs executing on network devices perform in expected ways (i.e., synchronously) and use the same data in the same way. To avoid having to manually synchronize all integration interfaces between the various programs, a logical system model and associated code generation system are used to generate application programming interfaces (APIs)--that is integration interfaces/integration points--for programs running on the network device and programs running within the NMS. In addition, the APIs for the programs managing the data repositories (e.g., database programs) used by the network device and NMS programs are also generated from the same logical system model and associated code generation system to ensure that the programs use the data in the same way. Further, to ensure that the NMS and network device programs for managing and operating the network device use the same data, the programs, including the NMS programs, access a single data repository for configuration information, for example, a configuration database within the network device.
[0123] Referring to FIG. 2a, in the present invention, the NMS 60 includes one or more NMS client programs 850a-850n and one or more NMS server programs 851a-851n. The NMS client programs provide interfaces for network administrators. Through the NMS clients, the administrator may configure multiple network devices (e.g., computer system 10, FIG. 1; network device 540, FIG. 35). The NMS clients communicate with the NMS servers to provide the NMS servers with configuration requirements from the administrators. In addition, the NMS servers provide the NMS clients with network device management information, which the clients then make available to the administrators. "Pushing" data from a server to multiple clients synchronizes the clients with minimal polling. Reduced polling means less management traffic on the network and more device CPU cycles available for other management tasks. Communication between the NMS client and server is done via Remote Method Invocation (RMI) over Transmission Control Protocol (TCP), a reliable protocol that ensures no data loss.
[0124] The NMS client and server relationship prevents the network administrator from directly accessing the network device. Since several network administrators may be managing the network, this mitigates errors that may result if two administrators attempt to configure the same network device at the same time.
[0125] The present invention also includes a configuration relational database 42 within each network device and an NMS relational database 61
external to the network device. The configuration database program may be executed by a centralized processor card or a processor on another card (e.g., 12, FIG. 1; 542, FIG. 35) within the network device, and the NMS database program may be executed by a processor within a separate computer system (e.g., 62, FIG. 13b). The NMS server stores data directly in the configuration database via JAVA Database Connectivity (JDBC) over TCP, and using JDBC over TCP, the configuration database, through active queries, automatically replicates any changes to NMS database 61. By using JDBC and a relational database, the NMS server is able to leverage database transactions, database views, database journaling and database backup technologies that help provide unprecedented system availability. Relational database technology also scales well as it has matured over many years. An active query is a mechanism that enables a client to post a blocked SQL query for asynchronous notification by the database when data changes are made after the blocked SQL query was made.
[0126] Similarly, any configuration changes made by the network administrator directly through console interface 852 are made to the configuration database and, through active queries, automatically replicated to the NMS database. Maintaining a primary or master repository of data within each network device ensures that the NMS and network device are always synchronized with respect to the state of the configuration. Replicating changes made to the primary database within the network device to any secondary data repositories, for example, NMS database 61, ensures that all secondary data sources are quickly updated and remain in lockstep synchronization.
[0127] Instead of automatically replicating changes to the NMS database through active queries, only certain data, as configured by the network administrator, may be replicated. Similarly, instead of immediate replication, the network administrator may configure periodic replication. For example, data from the master embedded database (i.e., the configuration database) can be uploaded daily or hourly. In addition to the periodic, scheduled uploads, backup may be done anytime at the request of the network administrator.
[0128] Referring again to FIG. 2a, for increased availability, the network device may include a backup configuration database 42' maintained by a separate, backup centralized processor card (e.g., 12, FIG. 1; 543, FIG. 35). Any changes to configuration database 42 are replicated to backup configuration database 42'. If the primary centralized processor card experiences a failure or error, the backup centralized processor card may be switched over to become the primary processor and configuration database 42' may be used to keep the network device operational. In addition, any changes to configuration database 42 may be written immediately to flash persistent memory 853 which may also be located on the primary centralized processor card or on another card, and similarly, any changes to backup configuration database 42' may be written immediately to flash persistent memory 853' which may also be located on the backup centralized processor card or another card. These flash-based configuration files protect against loss of data during power failures. In the unlikely event that all copies of the database within the network device are unusable, the data stored in the NMS database may be downloaded to the network device.
[0129] Instead of having a single central processor card (e.g., 12, FIG. 1; 543, FIG. 35), the external control functions and the internal control finctions may be separated onto different cards as described in U.S. patent application Ser. No. 09/574,343, filed May 20, 2000 and entitled "Functional Separation of Internal and External Controls in Network Devices", which is hereby incorporated herein by reference. As shown in FIGS. 41a and 41b, the chassis may support internal control (IC) processor cards 542a and 543a and external control (EC) processor cards 542b and 543b. In this embodiment, configuration database 42 may be maintained by a processor on internal control processor card 542a and configuration database 42' may be maintained by a processor on internal control processor card 543a, and persistent memory 853 may be located on external control processor card 542b and persistent memory 853' may be located on external control processor card 543b. This increases inter-card communication but also provides increased fault tolerance.
[0130] The file transfer protocol (FTP) may provide an efficient, reliable transport out of the network device for data intensive operations. Bulk data applications include accounting, historical statistics and logging. An FTP push (to reduce polling) may be used to send accounting, historical statistics and logging data to a data collector server 857, which may be a UNIX server. The data collector server may then generate network device and/or network status reports 858a-858n in, for example, American Standard Code for Information Interchange (ASCII) format and store the data into a database or generate Automatic Message Accounting Format (AMA/BAF) outputs.
[0131] Selected data stored within NMS database 61 may also be replicated to one or more remote/central NMS databases 854a-854n, as described below. NMS servers may also access network device statistics and status information stored within the network device using SNMP (multiple versions) traps and standard Management Information Bases (MIBs and MIB-2). The NMS server augments SNMP traps by providing them over the conventional User Datagram Protocol (UDP) as well as over Transmission Control Protocol (TCP), which provides reliable traps. Each event is generated with a sequence number and logged by the data collector server in a system log database for in place context with system log data. These measures significantly improve the likelihood of responding to all events in a timely manner reducing the chance of service disruption.
[0132] The various NMS programs--clients, servers, NMS databases, data collector servers and remote NMS databases--are distributed programs and may be executed on the same computer or different computers. The computers may be within the same LAN or WAN or accessible through the Internet. Distribution and hierarchy are fundamental to making any software system scale to meet larger needs over time. Distribution reduces resource locality constraints and facilitates flexible deployment. Since day-to-day management is done in a distributed fashion, it makes sense that the management software should be ;distributed. Hierarchy provides natural boundaries of management responsibility and minimizes the number of entities that a management tool must be aware of. Both distribution and hierarchy are fundamental to any long-term management solution. The client server model allows for increased scalability as servers and clients may be added as the number of network managers increase and as the network grows.
[0133] The various NMS programs may be written in the JAVA programming language to enable the programs to run on both Windows/NT and UNIX platforms, such as Sun Solaris. In fact the code for both platforms may be the same allowing consistent graphical interfaces to be displayed to the network administrator. In addition to being native to JAVA, RMI is attractive as the RMI architecture includes (RMI) over Internet Inter-Orb Protocol (IIOP) which delivers Common Object Request Broker Architecture (CORBA) compliant distributed computing capabilities to JAVA. Like CORBA, RMI over IIOP uses IIOP as its communication protocol. IIOP eases legacy application and platform integration by allowing application components written in C++, SmallTalk, and other CORBA supported languages to communicate with components running on the JAVA platform. For "manage anywhere" purposes and web technology integration, the various NMS programs may also run within a web browser. In addition, the NMS programs may integrate with Hewlett Packard's (HP's) Network Node Manager (NNM.TM.) to provide the convenience of a network map, event aggregation/filtering, and integration with other vendor's networking. From HP NNM a context-sensitive launch into an NMS server may be executed.
[0134] The NMS server also keeps track of important statistics including average client/server response times and response times to each network device. By looking at these statistics over time, it is possible for network administrators to determine when it is time to grow the management system by adding another server. In addition, each NMS server gathers the name, IP address and status of other NMS servers in the telecommunication network, determines the number of NMS clients and network devices to which it is connected, tracks its own operation time, the number of transactions it has handled since initialization, determines the "top talkers" (i.e., network devices associated with high numbers of transactions with the server), and the number of communications errors it has experienced. These statistics help the network administrator tune the NMS to provide better overall management service.
[0135] NMS database 61 may be remote or local with respect to the network device(s) that it is managing. For example, the NMS database may be maintained on a computer system outside the domain of the network device (i.e., remote) and communications between the network device and the computer system may occur over a wide area network (WAN) or the Internet. Preferably, the NMS database is maintained on a computer system within the same domain as the network device (i.e., local) and communications between the network device and the computer system may occur over a local area network (LAN). This reduces network management traffic over a WAN or the Internet.
[0136] Many telecommunications networks include domains in various geographical locations, and network managers often need to see data combined from these different domains to determine how the overall network is performing. To assist with the management of wide spread networks and still minimize the network management traffic sent over WANs and the Internet, each domain may include an NMS database 61 and particular/selected data from each NMS database may be replicated (or "rolled up") to remote NMS databases 854a-854n that are in particular centralized locations. Referring to FIG. 2b, for example, a telecommunications network may include at least three LAN domains 855a-855c where each domain includes multiple network devices 540 and an NMS database 61. Domain 855a may be located in the Boston, Mass. area, domain 855b may be located in the Chicago, Ill. area and domain 855c may be located in the San Francisco, Calif. area. NMS servers 851a-851f may be located within each domain or in a separate domain. Similarly, one or more NMS clients may be coupled to each aNMS server and located in the same domain as the NMS server or in different domains. In addition, one NMS client may be coupled with multiple NMS servers. For example, NMS servers 851a-851c and NMS clients 850a-850k may be located in domain 856a (e.g., Dallas, Tex.) while NMS servers 851d-851f and NMS clients 850m-850u may be located in domain 856b (e.g., New York, N.Y.). Each NMS server may be used to manage each domain 855a-855c or, preferably, one NMS server in each server domain 856a-856b is used to manage all of the network devices within one network device domain 855a-855c. A single domain may include network devices and NMS clients and servers.
[0137] Network administrators use the NMS clients to configure network devices in each of the domains through the NMS servers. The network devices replicate changes made to their internal configuration databases (42, FIG. 2a) to a local NMS database 61. In addition, the data collector server copies all logging data into NMS database 61 or a separate logging database (not shown). Each local NMS database may also replicate selected data to central NMS database(s) 854a-854n in accordance with instructions from the network administrator. Other programs may then access the central database to retrieve and combine data from multiple network devices in multiple domains and then present this data to the network administrator. Importantly, network management traffic over WANs and the Internet are minimized since all data is not copied to the central NMS database. For example, local logging data may only be stored in the local NMS databases 61 (or local logging database) and not replicated to one of the central NMS database.
[0138] NMS Out-Of-Band Management Channels:
[0139] Typically communication between an NMS client and server starts with the client connecting to the server through an application programming interface (API). For security purposes, the client generally provides a password and other user credentials, and the server provides the client with a handle. The client uses the handle in all subsequent asynchronous API calls to the server, and in each call, the client provides the server with a call back address. The server uses the call back address to respond to the client after executing the client request included in the call. Synchronous interfaces may also be provided by the server for operations that require the client to wait for a server response before proceeding. In addition, clients may register for traps with a server such that network devices connected to that server may asynchronously notify the server and, hence, clients of problems.
[0140] For each client connected to a server, the server allocates certain resources such as the handle assigned to each client and memory space. In addition, the server maintains a queue of client requests. Server threads are used to execute the queued client requests, and the server may allocate one thread per device or the server may maintain a pool of worker threads across all clients or for each client.
[0141] Since client requests are executed in the order in which they are queued, one disadvantage is that a client request to respond to a high priority situation will have to sit in the queue until all previous requests are executed. Moreover synchronous calls into the server often suspend the client until the server responds. During this period of time, the situation to be addressed by the client request may cause network errors or a complete network failure. As an example, if the control room containing the network device is on fire, the administrator would send a client request to cause the server to shut down the network device. If the request must wait in a queue, the network device may send out erroneous messages and/or cause the network to fail as it suffers damage in the fire before the server executes the client request to shut down the device.
[0142] Similarly, if an NMS client receives multiple notifications from one or more NMS servers, the NMS client may respond to the notifications in the order in which they were received. If a high priority notification is sent from a server to a client, for example, a notification that a network device has gone down, and the client is busy, network errors or a complete network failure may occur before the client can respond to the notification.
[0143] In addition, when an NMS client sends a request to an NMS server, the client typically waits for a timer to expire before acknowledging that the NMS server is experiencing difficulty and cannot respond. Moreover, once the timer expires, the NMS client has no information as to what problems the NMS server was experiencing. For example, the server may have been overloaded, the server may have crashed or the client may have lost connectivity. If an NMS server has gone down or the client has lost connectivity, during the time that the client is waiting for its timer to expire, the client will not be receiving server notifications and, thus, cannot monitor the five functional areas of network management as defined by the International Organization for Standardization (ISO), specifically, Fault, Configuration, Accounting, Performance and Security (FCAPS). As a result, the network administrator through the NMS client will not be monitoring their network.
[0144] Ultimately, delays in responding to high priority client requests and server notifications and disconnects between NMS clients and NMS servers affect management availability and possibly network availability.
[0145] To avoid these problems, one or more out-of-band management channels are provided between each NMS client and each NMS server. High priority client requests and server notifications may be sent over the out-of-band management channels to ensure fast response times. In addition, periodic roll calls between NMS clients and NMS servers may be executed over the out-of-band management channels to allow for quick discovery of any disconnects and reclaiming associated client resources. Further, periodic roll calls may be conducted between the NMS servers and the network devices to which they are connected, and if a server discovers that a network device has gone down, it may send a high priority notification to appropriate NMS clients over the out-of-band management channels to insure a fast response by the clients.
[0146] Referring to FIG. 2c, as in typical NMS client/server connections, when an NMS client, for example, NMS client 850a, connects through an API 1261 with an NMS server, for example, NMS server 851a, the NMS client provides a password 1260 and other user credentials 1262, and if accepted, the NMS server sends the NMS client a handle 1264 to use for all future calls to the NMS server. For additional security, the password may be encrypted. In accordance with the invention, in addition to providing a password and standard user credentials during the initial connection, the NMS client further registers a high priority API 1265
with the NMS server by providing a high priority call back address 1266. The server may then use the high priority call back address to establish a separate connection 1268 through the high priority API (i.e., client out-of-band management channel) and send a high priority server notification to the NMS client. For example, the NMS server may send an emergency notification indicating that a network device has crashed. The connection may be established through RMI or another connection-oriented protocol such as RPC or CORBA. The client out-of-band management channel, therefore, provides an immediate communication channel between the server and client for high priority server notifications.
[0147] Referring to FIG. 2d, each NMS client (e.g., 850a) may register a high priority channel via API 1274 with each NMS server (e.g., 851a, 851b, 851e) with which it connects. Referring to FIG. 2e, instead, each NMS client (e.g., 850a) may register a different high priority channel via APIs 1276a-1276c with each NMS server (e.g., 851a, 851b, 851e) with which it connects or, referring to FIG. 2f, if a limited number of high priority APIs 1278a-1278b are available to the NMS client (e.g., 850a), the client may share them among the NMS servers (e.g., 851a, 851b, 851e) with which it connects. Moreover, each client may register multiple channels via multiple APIs with each server and each channel may have a different level of priority.
[0148] Referring to FIG. 2g, in addition to sending high priority server notifications over the client out-of-band management channels established between a server and one or more clients, the servers may periodically send roll call messages 1280a-1280e to each of the clients to which they are connected over the client out-of-band management channels to determine if the connections between each server and the clients are still valid. If a client does not respond 1282a-1282e, then a server knows the connection has been lost, and the server may take back all the resources it allocated to that client. Optionally the server may also notify one or more other clients of the lost connection.
[0149] Each server may also send periodic roll call messages to the network devices to which they are connected. Again, if a network device does not respond, the server knows the connection has been lost or the network device has gone down. In either case, the server sends a high priority message to the clients that are managing that device over one or more client out-of-band management channels.
[0150] Referring again to FIG. 2c, in addition to having the client register a high priority API, the server may also register a high priority API by sending the client a high priority call back address 1270
when the server sends the client the handle. The client may then use the high priority call back address 1270 to establish a separate connection 1272 through the high priority API (i.e., server out-of-band management channel) and send high priority (e.g., emergency) client requests to the NMS server. For example, if a control room is on fire or a network device is causing network errors, the NMS client may send an emergency client request to shut down a particular network device over RMI connection 1272
using high priority call back address 1270.
[0151] Different administrators may assign high priority to different situations. For example, an important customer may demand immediate resources to handle an important video conference. If given a high priority, the NMS client could then send the client request to set up the resources needed to handle the video conference through the server out-of-band management channel.
[0152] Referring to FIG. 2h, each NMS server (e.g., 851a) may register the same high priority API 1284 with each NMS client (e.g., 850a, 850d, 850g) with which it connects. Referring to FIG. 2i, instead, each NMS server (e.g., 851a) may register a different high priority API 1286a-1286c with each NMS client (e.g., 850a, 850d, 850g) with which it connects or, referring to FIG. 2j, if a limited number of high priority APIs 1288a-1288b are available to the NMS server (e.g., 851a), the server may share them among the NMS clients (e.g., 850a, 850d, 850g) with which it connects.
[0153] In addition to sending high priority server notifications over the server out-of-band management channels established between each server and one or more clients, the clients may periodically send roll call messages to each of the servers to which they are connected over the server out-of-band management channels to determine if the connections between each client and the servers are still valid. If a server does not respond, then a client knows the connection has been lost, and the client can immediately notify the system administrator. The administrator may then cause the client to connect with another server that can also connect with the same network devices with which the previous server had been connected. During this reconnection to a new server, the NMS client may continue to run.
[0154] Sending high priority messages over out-of-band management channels (client and/or server) maximizes client I server management availability and, hence, network availability. Periodic roll calls between distributed points of communication--clients to servers, servers to clients and servers to devices--ensure fast discovery of lost connections, and sending notifications of lost connections over the out-of-band management channels ensures fast responses to lost connections--all of which maximizes overall management availability.
[0155] Logical System Model:
[0156] As previously mentioned, to avoid having to manually synchronize all integration interfaces between the various programs, the APIs for both NMS and network device programs are generated using a code generation system from the same logical system model. In addition, the APIs for the data repository software used by the programs are also generated from the same logical system model to ensure that the programs use the data in the same way. Each model within the logical system model contains metadata defining an object/entity, attributes for the object and the object's relationships with other objects. Upgrading/modifying an object is, therefore, much simpler than in current systems, since the relationship between objects, including both hardware and software, and attributes required for each object are clearly defined in one location. When changes are made, the logical system model clearly shows what other programs are affected and, therefore, may also need to be changed. Modeling the hardware and software provides a clean separation of function and form and enables sophisticated dynamic software modularity.
[0157] A code generation system uses the attributes and metadata within each model to generate the APIs for each program and ensure lockstep synchronization. The logical model and code generation system may also be used to create test code to test the network device programs and NMS programs. Use of the logical model and code generation system saves development, test and integration time and ensures that all relationships between programs are in lockstep synchronization. In addition, use of the logical model and code generation system facilitates hardware portability, seamless extensibility and unprecedented availability and modularity.
[0158] Referring to FIG. 3a, a logical system model 280 is created using the object modeling notation and a model generation tool, for example, Rational Rose 2000 Modeler Edition available from Rational Software Corporation in Lexington, Massachusetts. A managed device 282 represents the top level system connected to models representing both hardware 284
and data objects used by software applications 286. Hardware model 284
includes models representing specific pieces of hardware, for example, chassis 288, shelf 290, slot 292 and printed circuit board 294. The logical model is capable of showing containment, that is, typically, there are many shelves per chassis (1:N), many slots per shelf (1:N) and one board per slot (1:1). Shelf 290 is a parent class generalizing multiple shelf models, including various functional shelves 296a-296n as well as one or more system shelves, for example, for fans 298 and power 300. Board 294 is also a parent class having multiple board models, including various functional boards without external physical ports 302a-302n (e.g., central processor 12, FIG. 1; 542-543, FIG. 35; and switch fabric cards, FIG. 35) and various functional boards 304a-304n (e.g., cross connection cards 562a-562b and forwarding cards 546a-546e, FIG. 35) that connect to boards 306 with external physical ports (e.g., universal port cards 554a-554h, FIG. 35). Hardware model 284 also includes an external physical port model 308. Port model 308 is coupled to one or more specific port models, for example, synchronous optical network (SONET) protocol port 310, and a physical service endpoint model 312.
[0159] Hardware model 284 includes models for all hardware that may be available on computer system 10 (FIG. 1)/network device 540 (FIG. 35) whether a particular computer system/network device uses all the available hardware or not. The model defines the metadata for the system whereas the presence of hardware in an actual network device is represented in instance data. All shelves and slots may not be populated. In addition, there may be multiple chassis. It should be understood that SONET port 310 is an example of one type of port that may be supported by computer system 10. A model is created for each type of port available on computer system 10, including, for example, Ethernet, Dense Wavelength Division Multiplexing (DWDM) or Digital Signal, Level 3 (DS3). The NMS (described below) uses the hardware model and instance data to display a graphical picture of computer system 10/network device 540 to a user.
[0160] Service endpoint model 314 spans the software and hardware models within logical model 280. It is a parent class including a physical service endpoint model 312 and a logical service endpoint model 316. Since the links between the software model and hardware model are minimal, either may be changed (e.g., upgraded or modified) and easily integrated with the other. In addition, multiple models (e.g., 280) may be created for many different types of managed devices (e.g., 282). The software model may be the same or similar for each different type of managed device even if the hardware--and hardware models--corresponding to the different managed devices are very different. Similarly, the hardware model may be the same or similar for different managed devices but the software models may be different for each. The different software models may reflect different customer needs.
[0161] Software model 286 includes models of data objects used by each of the software processes (e.g., applications, device drivers, system services) available on computer system 10/network device 540. All applications and device drivers may not be used in each computer system/network device. As one example, ATM model 318 is shown. It should be understood that software model 286 may also include models for other applications, for example, Internet Protocol (IP) applications, Frame Relay and MultiProtocol Label Switching (MPLS) applications. Models of other processes (e.g., device drivers and system services) are not shown for convenience.
[0162] For each process, models of configurable objects managed by those processes are also created. For example, models of ATM configurable objects are coupled to ATM model 318, including models for a soft permanent virtual path (SPVP) 320, a soft permanent virtual circuit (SPVC) 321, a switch address 322, a cross-connection 323, a permanent virtual path (PVP) cross-connection 324, a permanent virtual circuit (PVC) cross-connection 325, a virtual ATM interface 326, a virtual path link 327, a virtual circuit link 328, logging 329, an ILMI reference 330, PNNI 331, a traffic descriptor 332, an ATM interface 333 and logical service endpoint 316. As described above, logical service endpoint model 316 is coupled to service endpoint model 314. It is also coupled to ATM interface model 333.
[0163] The logical model is layered on the physical computer system to add a layer of abstraction between the physical system and the software applications. Adding or removing known (i.e., not new) hardware from the computer system will not require changes to the logical model or the software applications. However, changes to the physical system, for example, adding a new type of board, will require changes to the logical model. In addition, the logical model is modified when new or upgraded processes are created. Changes to an object model within the logical model may require changes to other object models within the logical model. It is possible for the logical model to simultaneously support multiple versions of the same software processes (e.g., upgraded and older). In essence, the logical model insulates software applications from changes to the hardware models and vice-versa.
[0164] To further decouple software processes from the logical model--as well as the physical system--another layer of abstraction is added in the form of version-stamped views. A view is a logical slice of the logical model and defines a particular set of data within the logical model to which an associated process has access. Version stamped views allow multiple versions of the same process to be supported by the same logical model since each version-stamped view limits the data that a corresponding process "views" or has access to, to the data relevant to the version of that process. Similarly, views allow multiple different processes to use the same logical model.
[0165] Code Generation System:
[0166] Referring to FIG. 3b, logical model 280 is used as input to a code generation system 336. The code generation system creates a view identification (id) and an application programming interface (API) 338
for each process that requires configuration data. For example, a view id and an API may be created for each ATM application 339a-339n, each SONET application 340a-340n, each MPLS application 342a-342n and each IP application 341a-341n. In addition, a view id and API is also created for each device driver process, for example, device drivers 343a-343n, and for modular system services (MSS) 345a-345n (described below), for example, a Master Control Driver (MCD), a System Resiliency Manager (SRM), and a Software Management System (SMS). The code generation system provides data consistency across processes, centralized tuning and an abstraction of embedded configuration and NMS databases (described below) ensuring that changes to their database schema (i.e., configuration tables and relationships) do not affect existing processes.
[0167] The code generation system also creates a data definition language (DDL) file 344 including structured query language (SQL) commands used to construct the database schema, that is, the various tables and views within a configuration database 346, and a DDL file 348 including SQL commands used to construct various tables and SQL views within a network management (NMS) database 350 (described below). This is also referred to as converting the logical model into a database schema and various SQL views look at particular portions of that schema within the database. If the same database software is used for both the configuration and NMS databases, then one DDL file may be used for both.
[0168] The databases do not have to be generated from a logical model for views to work. Instead, database files can be supplied directly without having to generate them using the code generation system. Similarly, instead of using a logical model as an input to the code generation system, a MIB "model" may be used. For example, relationships between various MIBs and MIB objects may be written (i.e., coded) and then this "model" may be used as input to the code generation system.
[0169] Referring to FIG. 3c, applications 352a-352n (e.g., SONET driver 863, SONET application 860, MSS 866, etc.) each have an associated view 354a-354n of configuration database 42. The views may be similar allowing each application to view similar data within configuration database 42. For example, each application may be ATM version 1.0 and each view may be ATM view version 1.3. Instead, the applications and views may be different versions. For example, application 352a may be ATM version 1.0
and view 354a may be ATM view version 1.3 while application 352b is ATM version 1.7 and view 354b is ATM view version 1.5. A later version, for example, ATM version 1.7, of the same application may represent an upgrade of that application and its corresponding view allows the upgraded application access only to data relevant to the upgraded version and not data relevant to the older version. If the upgraded version of the application uses the same configuration data as an older version, then the view version may be the same for both applications. In addition, application 352n may represent a completely different type of application, for example, MPLS, and view 354n allows it to have access to data relevant to MPLS and not ATM or any other application. Consequently, through the use of database views, different versions of the same software applications and different types of software applications may be executed on computer system 10 simultaneously.
[0170] Views also allow the logical model and physical system to be changed, evolved and grown to support new applications and hardware without having to change existing applications. In addition, software applications may be upgraded and downgraded independent of each other and without having to re-boot computer system 10/network device 540. For example, after computer system 10 is shipped to a customer, changes may be made to hardware or software. For instance, a new version of an application, for example, ATM version 2.0, may be created or new hardware may be released requiring a new or upgraded device driver process. To make this a new process and/or hardware available to the user of computer system 10, first the software image including the new process must be re-built.
[0171] Referring again to FIG. 3b, logical model 280 may be changed (280') to include models representing the new software and/or hardware. Code generation system 336 then uses new logical model 280' to re-generate view ids and APIs 338' for each application, including, for example, ATM version two 360 and device driver 362, and DDL files 344' and 348'. The new application(s) and/or device driver(s) processes then bind to the new view ids and APIs. A copy of the new application(s) and/or device driver process as well as the new DDL files and any new hardware are sent to the user of computer system 10. The user can then download the new software and plug the new hardware into computer system 10. The upgrade process is described in more detail below. Similarly, if models are upgraded/modified to reflect upgrades/modifications to software or hardware, then the new logical model is provided to the code generation system which re-generates view ids and APIs for each process/program/application. Again, the new applications are linked with the new view ids and APIs and the new applications and/or hardware are provided to the user.
[0172] Again referring to FIG. 3b, the code generation system also creates NMS JAVA interfaces 347 and persistent layer metadata 349. The JAVA interfaces are JAVA class files including get and put methods corresponding to attributes within the logical model, and as described below, the NMS servers use the NMS JAVA interfaces to construct models of each particular network device to which they are connected. Also described below, the NMS servers use the persistent layer metadata as well as run time configuration data to generate SQL configuration commands for use by the configuration database.
[0173] Prior to shipping computer system 10 to customers, a software build process is initiated to establish the software architecture and processes. The code generation system is the first part of this process. Following the execution of the code generation system, each process when pulled into the build process links the associated view id and API into its image. For example, referring to FIG. 3d, to build a SONET application, source files, for example, a main application file 859a, a performance monitoring file 859b and an alarm monitoring file 859c, written in, for example, the C programming language (.c) are compiled into object code files (.o) 859a', 859b' and 859c'. Alternatively, the source files may be written in other programming languages, for example, JAVA (java) or C++ (.cpp). The object files are then linked along with view ids and APIs from the code generation system corresponding to the SONET application, for example, SONET API 340a. The SONET API may be a library (.a) of many object files. Linking these files generates the SONET Application executable file (.exe) 860.
[0174] Referring to FIG. 3e, each of the executable files for use by the network device/computer system are then provided to a kit builder 861. For example, several SONET executable files (e.g., 860, 863), ATM executable files (e.g., 864a-864n), MPLS executable files (e.g., 865a-865n), MSS executable files 866a-866n, MKI executable 873a-873n files for each board and a DDL configuration database executable file 867
may be provided to kit builder 861. The OSE operating system expects executable load modules to be in a format referred to as Executable & Linkable Format (.elf). Alternatively, the DDL configuration database executable file may be executed and some data placed in the database prior to supplying the DDL file to the kit builder. The kit builder creates a computer system/network device installation kit 862 that is shipped to the customer with the computer system/network device or, later, alone after modifications and upgrades are made. To save space, the kit builder may compress each of the files included in the Installation Kit (i.e., .exe.gz, .elf.gz), and when the files are later loaded in the network device, they are de-compressed.
[0175] Referring to FIG. 3f, similarly, each of the executable files for the NMS is provided separately to the kit builder. For example, a DDL NMS database executable file 868, an NMS JAVA interfaces executable file 869, a persistent layer metadata executable file 870, an NMS server 885 and an NMS client 886 may be provided to kit builder 861. The kit builder creates an NMS installation kit 871 that is shipped to the customer for installation on a separate computer 62 (FIG. 13b). In addition, new versions of the NMS installation kit may be sent to customers later after upgrades/modifications are made. When installing the NMS, the customer I network administrator may choose to distribute the various NMS processes as described above. Alternatively, one or more of the NMS programs, for example, the NMS JAVA interfaces and Persistent layer metadata executable files may be part of the network device installation kit and later passed from the network device to the NMS server, or part of both the network device installation kit and the NMS installation kit.
[0176] When the computer system is powered-up for the first time, as described below, configuration database software uses DDL file 867 to create a configuration database 42 with the necessary configuration tables and active queries. The NMS database software uses DDL file 868 to create NMS database 61 with corresponding configuration tables. Memory and storage space within network devices is typically very limited. The configuration database software is robust and takes a considerable amount of these limited resources but provides many advantages as described below.
[0177] As described above, logical model 280 (FIG. 3b) may be provided as an input to code generation system 336 in order to generate database views and APIs for NMS programs and network device programs to synchronize the integration interfaces between those programs. Where a telecommunications network includes multiple similar network devices, the same installation kit may be used to install software on each network device to provide synchronization across the network. Typically, however, networks include multiple different network devices as well as multiple similar network devices. A logical model may be created for each different type of network device and a different installation kit may be implemented on each different type of network device.
[0178] Instead, of providing a logical model (e.g., 280, FIG. 3b) that represents a single network device, a logical model may be provided that represents multiple different managed devices--that is, multiple network devices and the relationship between the network devices. Alternatively, multiple logical models 280 and 887a-887n--representing multiple network devices--may be provided, including relationships with other logical models. In either case, providing multiple logical models or one logical model iz representing multiple network devices and their relationships as an input(s) to the code generation system allows for synchronization of NMS programs and network device programs (e.g., 901a-901n) across an entire network. The code generation system in combination with one or more logical models provides a powerful tool for synchronizing distributed telecommunication network applications.
[0179] The logical model or models may also be used for simulation of a network device and/or a network of many network devices, which may be useful for scalability testing.
[0180] In addition to providing view ids and APIs, the code generation system may also provide code used to push data directly into a third party code API. For example, where an API of a third party program expects particular data, the code generation system may provide this data by retrieving the data from the central repository and calling the third-party programs API. In this situation, the code generation system is performing as a "data pump".
[0181] Configuration:
[0182] Once the network device programs have been installed on network device 540 (FIG. 35), and the NMS programs have been installed on one or more computers (e.g., 62), the network administrator may configure the network device/provision services within the network device. Hereinafter, the term "configure" includes "provisioning services". Referring to FIG. 4a, the NMS client displays a graphical user interface (GUI) 895 to the administrator including a navigation tree/menu 898. Selecting a branch of the navigation tree causes the NMS client to display information corresponding to that branch. For example, selecting Devices branch 898a within the tree causes the NMS client to display a list 898b of IP addresses and/or domain name server (DNS) names corresponding to network devices that may be managed by the administrator. The list corresponds to a profile associated with the administrator's user name and password. Profiles are described in detail below.
[0183] If the administrator's profile includes the appropriate authority, then the administrator may add new devices to list 898b. To add a new device, the administrator selects Devices branch 898a and clicks the right mouse button to cause a pop-up menu 898c (FIG. 4b) to appear. The administrator then selects the Add Devices option to cause a dialog box 898d (FIG. 4c) to appear. The administrator may then type in an IP address (e.g., 192.168.9.203) or a DNS name into field 898e and select an Add button 898f to add the device to Device list window 898g (FIG. 4d). The administrator may then add one or more other devices in a similar manner. The administrator may also delete a device from the Device list window by selecting the device and then selecting a Delete button 898h, or the administrator may cancel out of the dialog box without adding any new devices by selecting Cancel button 898i. When finished, the administrator may select an OK button 898j to add any new devices in Device list 898g to navigation tree 898a (FIG. 4e).
[0184] To configure a network device, the administrator begins by selecting (step 874, FIG. 3g) a particular network device to configure, for example, the network device corresponding to IP address 192.168.9.202
(FIG. 4f). The NMS client then informs (step 875, FIG. 3g) an NMS server of the particular network device to be configured. Since many NMS clients may connect to the same NMS server, the NMS server first checks its local cache to determine if it is already managing the network device for another NMS client. If so, the NMS server sends data from the cache to the NMS client. If not, the NMS server using JDBC connects to the network device and reads the data/object structure for the physical aspects of the device from the configuration database within the network device into its local cache and uses that information with the JAVA interfaces to construct (step 876) a model of the network device. The server provides (step 877) this information to the client, which displays (step 878) a graphical representation 896a (FIG. 4f) of the network device to the administrator indicating the hardware and services available in the selected network device and the current configuration and currently provisioned services. Configuration changes received by an NMS server--from either an NMS client or directly from the network device's configuration database when changes are made through the network device's CLI interface--are sent by the NMS server to any other NMS clients connected to that server and managing the same network device. This provides scalability, since the device is not burdened with multiple clients subscribing for traps, and ensures each NMS client provides an accurate view of the network device.
[0185] Referring to FIGS. 4f-41, graphical representation 896a (i.e., device view, device mimic) in graphic window 896b may include many views of the network device. For example, device mimic 896a is shown in FIG. 4f displaying a front view of the components in the upper portion of network device 540 (FIG. 35). The administrator may use scroll bar 926a to scroll down and view lower portions of the front of the network device as shown in FIG. 4g. The administrator may also use image scale button 926b to change the size of graphic 896a. For example, the administrator may shrink the network device image to allow more of the device image to be visible in graphic window 896b, as shown in FIG. 4h. This view corresponds to the block diagram of network device 540 shown in FIG. 41a. For instance, upper fan tray 634 and middle fan trays 630 and 632 are shown. In addition, forwarding cards (e.g., 546a and 548e), cross-connection cards (e.g., 562a, 562b, 564b, 566a, 568b), and external processor control cards (e.g., 542b and 543b) are shown.
[0186] GUI 895 also includes several splitter bars 895a-895c (FIG. 4f) to allow the administrator to change the size of the various panels (e.g., 896b, 897 and 898). In addition, GUI 895 includes a status bar 895d. The status bar may include various fields such as a server field 895e, a Mode field 895f, a Profile field 895g and an active field 895h. The server filed may provide the IP address or DNS name of the NMS server, and the profile field may provide the username that the administrator logged in under. The active field will provide updated status, for example, ready, or ask the administrator to take particular steps. The mode field will indicate an on-line mode (i.e., typical operation) or an off-line mode (described in detail below).
[0187] Device mimic 896a may also provide one or more visual indications as to whether a card is present in each slot or whether a slot is empty. For example, in one embodiment, the forwarding cards (e.g., 546a and 548e) in the upper portion of the network device are displayed in a dark color to indicate the cards are present while the lower slots (e.g., 928a and 929e) are shown in a lighter color to indicate that the slots are empty. Other visual indications may also be used. For example, a graphical representation of the actual card faceplate may be added to device mimic 896a when a card is present and a blank faceplate may be added when the slot is empty. Moreover, this may be done for any of the cards that may or may not be present in a working network device. For example, the upper cross-connection cards may be displayed in a dark color to indicate they are present while the lower cross-connection card slots may be displayed in a lighter color to indicate the slots are empty.
[0188] In addition, a back view and other views of the network device may also be shown. For example, the administrator may use a mouse to move a cursor into an empty portion of graphic window 896b and click the right mouse button to cause a pop-up menu to appear listing the various views available for the network device. In one embodiment, the only other view is a back view and pop-up menu 927 is displayed. Alternatively, short cuts may be set up. For example, double clicking the left mouse button may automatically cause graphic 896a to display the back view of the network device, and another double click may cause graphic 896a to again display the front view. As another alternative, a pull down menu may be provided to allow an administrator to select between various views.
[0189] Device mimic 896a is shown in FIG. 4i displaying a back view of the components in the upper portion of network device 540 (FIG. 35). Again the administrator may use scroll bar 926a and/or image scale button 926b to view lower portions (FIGS. 4j and 4k) of the back of the network device or more of the network device by shrinking the graphic (FIG. 41). These views correspond to the block diagram of network device 540 shown in FIG. 41b. For example, upper fan tray 628 (FIG. 4i), management interface (MI) card 621 (FIG. 4i) and lower fan tray 626 (FIG. 4k) are shown. In addition, universal port cards (e.g., 556h, 554a and 560h, FIG. 41), switch fabric cards (e.g., 570a and 570b) and internal processor control cards (e.g., 542a and 543a) are also shown. Again, graphic 896a may use a visual indicator to clearly show whether a card is present in a slot or whether the slot is empty. In this example, the visual indicator for universal port cards is the display of the ports available on each card. For example, universal port card 554a is present as indicated by the graphical representation of ports (e.g., 930, FIG. 41) available on that card, while universal port card 558a (FIG. 41b) is not present as indicated by a blank slot 931.
[0190] Since the GUI has limited screen real estate and the network device may be large and loaded with many different types of components (e.g., modules, ports, fan trays, power connections), in addition to the device mimic views described above, GUI 895 may also provide a system view menu option 954 (FIG. 4m). If an administrator selects this option, a separate pull away window 955 (FIG. 4n) is displayed for the administrator including both a front view 955a and a back view 955b of the network device corresponding to the front and back views displayed by the device mimic. The administrator may keep this separate pull away window up and visible while provisioning services through the GUI. Moreover, the GUI remains linked with the pull away window such that if the administrator selects a component in the pull away window, the device mimic displays that portion of the device and highlights that component. Similarly, if the administrator selects a component within the device mimic, the pull away window also highlights the selected component. Thus, the pull away window may further help the administrator navigate in the device mimic.
[0191] Device mimic 896a may also indicate the status of components. For example, ports and/or cards may be green for normal operation, red if there are errors and yellow if there are warnings. In one embodiment, a port may be colored, for example, light green or gray if it is available but not yet configured and colored dark green after being configured. Other colors or graphical textures may also be used show visible status. To further ease a network administrator's tasks, the GUI may present pop-up windows or tool tips containing information about each card and/or port when the administrator moves the cursor over the card or port. For example, when the administrator moves the cursor over universal port card 556f (FIG. 4o), pop-up window 932a may be displayed to tell the administrator that the card is a 16 Port OC3 Universal Port Module in Shelf 11/Slot 3. Similarly, if the administrator moves the cursor over universal port card 556e (FIG. 4p), pop-up window 932b appears indicating that the card is a 16 Port OC12 Universal Port Module in Shelf 11/Slot 4, and if the cursor is moved over universal port cards 556d (FIG. 4q) or 556c (FIG. 4r), then pop-up windows 932c and 932d appear indicating the cards are 4 Port OC48Universal Port Module in Shelf 11/Slot 5 and 8 Port OC12Universal Port Module in Shelf 11/Slot 6, respectively. If the administrator moves the cursor over a port, for example, port 933 (FIG. 4s), then pop-up window 932e appears indicating the port is an OC12in Shelf 11/Slot 4/Port 1.
[0192] The views are used to provide management context. The GUI may also include a configuration/service status window 897 for displaying current configuration and service provisioning details. Again, these details are provided to the NMS client by the NMS server, which reads the data from the network device's configuration database. The status window may include many tabs/folders for displaying various data about the network device configuration. In one embodiment, the status window includes a System tab 934 (FIG. 4s), which is displayed when the server first accesses the network device. This tab provides system level data such as the system name 934a, System Description 934b, System Contact 934c, System Location 934d, System IP Address 934e (or DNS name), System Up Time 934f, System identification (ID) 934g and System Services 934h. Modifications to data displayed in 934a-934e may be made by the administrator and committed by selecting the Apply button 935. The NMS client then passes this information to the NMS server, which then writes a copy of the data in the network device's configuration database and broadcasts the changes to any other NMS clients managing the same network device. The administrator may also reset the network device by selecting the Reset System button 935b and then refresh the System tab data by selecting the Refresh button 935c.
[0193] The status window may also include a Modules tab 936 (FIG. 4t), which includes an inventory of the available modules in the network device and various details about those modules such as where they are located (e.g., shelf and slot, back or front). The inventory may also include a description of the type of module, version number, manufacturing date, part number, etc. In addition, the inventory may include run time data such as the operational status and temperature. The NMS server may continuously supply the NMS client(s) with the run time data by reading the network device configuration database or NMS database. Device mimic 896a is linked with status window 897, such that selecting a module in device mimic 896a causes the Module tab to highlight a line in the inventory corresponding to that card. For example, if an administrator selects universal port card 556d, device mimic 896a highlights that module and the Module tab highlights a line 937 in the inventory corresponding to the card in Shelf 11/Slot 5. Similarly, if the administrator selects a line in the Module tab inventory, device mimic 896a highlights the corresponding module. Double clicking the left mouse button on a selected module may cause a dialog box to appear and the administrator may modify particular parameters such as an enable/disable parameter.
[0194] The status window may also include a Ports tab 938 (FIG. 4u), which displays an inventory of the available ports in the network device and various details about each port such as where they are located (shelf, slot and port; back or front). The inventory may also include a description of the port name, type and speed as well as run time data such as administrative status, operational status and link status. Again, device mimic 896a is linked with status window 897 such that selecting a port within device mimic 896a causes the Port tab to highlight a line in the inventory corresponding to that port. For example, if the administrator selects port 939a (port 1, slot 4) on card 556e, then the Port tab highlights a line 939b within the inventory corresponding to that port. Similarly, if the administrator selects a line from the inventory in the Port tab, device mimic 896a highlights the corresponding port. Again double clicking the left mouse button on a selected port may cause a dialog box to appear and the administrator may modify particular parameters such as an enable/disable parameter.
[0195] Another tab in the status window may be a SONET Interface tab 940
(FIG. 4v), which includes an inventory of SONET ports in the network device and various details about each port such as where they are located (shelf and slot; back or front). Medium type (e.g., SONET, Synchronous Digital Hierarchy (SDH)) may also be displayed as well as circuit ID, Line Type, Line Coding, Loopback, Laser Status, Path Count and other details. Again, device mimic 896a is lined with status window 897 such that selecting a port within device mimic 896a causes the SONET Interface tab to highlight a line in the inventory corresponding to that SONET port. For example, if the administrator selects port 941a (port 2, slot 5) on card 556d, then the SONET Interface tab highlights line 941b corresponding to that port. Similarly, if the administrator selects a line from the inventory in the SONET Interface tab, device mimic 896a highlights the corresponding port. Again, double clicking the left mouse button on a selected SONET interface may cause a dialog box to appear and the administrator may modify particular parameters such as an enable/disable parameter.
[0196] The System tab data as well as the Modules tab, Ports tab and SONET Interface tab data all represent physical aspects of the network device. The remaining tabs, including SONET Paths tab 942 (FIG. 4w), ATM Interfaces tab 946, Virtual ATM Interfaces tab 947 and Virtual Connections tab 948, display configuration details and, thus, display no data until the device is configured. In addition, these configuration tabs 942, 946-948 are dialog chained together with wizard-like properties to guide an administrator through configuration details. Through these tabs within the GUI (i.e., graphical context), therefore, the administrator then makes (step 879, FIG. 3g) configuration selections. For example, to configure a SONET path, the administrator may begin by selecting a port (e.g., 939a on card 556e, FIG. 5a) within device mimic 896a and clicking the right mouse button (i.e., context sensitive) to cause a pop-up menu 943 to be displayed listing available port configuration options. The administrator may then select the "Configure SONET Paths" option, which causes the GUI to display a SONET Path configuration wizard 944 (FIG. 5b).
[0197] The SONET Path configuration wizard guides the administrator through the task of setting up a SONET Path by presenting the administrator with valid configuration options and inserting default parameter values. As a result, the process of configuring SONET paths is simplified, and required administrator expertise is reduced since the administrator does not need to know or remember to provide each parameter value. In addition, the SONET Path wizard allows the administrator to configure multiple SONET Paths simultaneously, thereby eliminating the repetition of similar configuration process steps required by current network management systems and reducing the time required to configure many SONET Paths. Moreover, the wizard validates configuration requests from the administrator to minimize the potential for mis-configuration.
[0198] In one embodiment, the SONET Path wizard displays SONET line data 944a (e.g., slot 4, port 1, OC12) and three configuration choices 944b, 944c and 944d. The first two configuration choices provide "short cuts" to typical configurations. If the administrator selects the first configuration option 944b (FIG. 5c), the SONET Path wizard creates a single concatenated path. In the current example, the selected port is an OC12, and the single concatenated path is an STS-12c. The wizard assigns and graphically displays the position 944e and width 944f of the STS-12c path and also displays a SONET Path table 944g including an inventory having an entry for the SONET STS-12c path and each of the default parameters assigned to that SONET path. The position of each SONET path is chosen such that each path lines up on a valid boundary based on SONET protocol constraints.
[0199] If the administrator selects the second configuration option 944c (FIGS. 5d and 5e), the SONET Path wizard creates one or more valid SONET paths that fully utilize the port capacity. In the current example, where the selected port is an OC12port, in one embodiment, the second configuration option 944c allows the administrator to quickly create four STS-3c paths (FIG. 5d) or one concatenated STS-12c (FIG. 5e). The user may select the number of paths in window 944s or the type of path in window 944t. Windows 944s and 944t are linked and, thus, always present the user with consistent options. For example, if the administrator selects 4 paths in window 944s, window 944t displays STS-3c and if the administrator selects STS-12c in window 944t, window 944s displays 1
path. Again, the SONET path wizard graphically displays the position 944d and width 944f of the SONET paths created and also displays them in SONET Path table 944g along with the default parameters assigned to each SONET path.
[0200] The third configuration option allows the administrator to custom configure a port thereby providing the administrator with more flexibility. If the administrator selects the third configuration option 944d (FIG. 5f), the SONET Path wizard displays a function window 944h. The function window provides a list of available SONET Path types 944i and also displays an allocated SONET path window 944j. In this example, only the STS-3c path type is listed in the available SONET Path types window, and if the administrator wishes to configure a single STS-12c path, then they need to select the first or second configuration option 944b or 944c. To configure one or more SONET STS-3c paths, the administrator selects the STS-3c SONET path type and then selects ADD button 944k. The SONET Path wizard adds STS-3c path 944l to the allocated SONET paths window and then displays the position 944e and width 944f of the SONET path and updates Path table 944g with a listing of that SONET path including the assigned parameters. In this example, two STS-3c paths 944l and 944m are configured in this way on the selected port. The administrator may select an allocated path (e.g., 944m or 944n) in window 944j and then select the remove button 944n to delete a configured path, or the administrator may select the clear button 944o to delete each of the configured paths from window 944j. Moreover, the administrator may select an allocated path and use up arrow 944u and down arrow 944v to change the position 944e.
[0201] In any of the SONET Path windows (FIGS. 5c-5f), the administrator may select a path in the SONET path table and double click on the left mouse button or select a modify button 944p to cause the GUI to display a dialog box through which the administrator may modify the default parameters assigned to each path. The wizard validates each parameter change and prevents invalid values from being entered. The administrator may also select a cancel button 944q to exit the SONET path wizard without accepting any of the configured or modified paths. If, instead, the administrator wants to exit the SONET Path wizard and accept the configured SONET Paths, the administrator selects an OK button 944r.
[0202] Once the administrator selects the OK button, the NMS client validates the parameters as far as possible within the client's view of the device and passes (step 880, FIG. 3g) this run time/instance configuration data, including all configured SONET path parameters, to the NMS server. The NMS server validates (step 881) the data received based on its view of the world and if not correct, sends an error message to the NMS client, which notifies the administrator. Thus, the NMS server re-validates all data from the NMS clients to ensure that it is consistent with changes made by any other NMS client or by an