Title: Distributed user management information in telecommunications networks
Abstract: The present invention provides a method and apparatus for implementing distributed user management information in telecommunications networks. At least a portion of a user's management information is stored in a team session file that is accessible by a network management system (NMS) client. For example, the team session file may be saved in memory that is local to the NMS client or, if a user logs in through a remote system using a web browser, the team session file may be saved as a cookie in memory local to the remote system. The NMS client may then utilize the user management information in the team session file while the user is logged into the NMS client. In one embodiment, the user management information stored within the team session file includes NMS server connection information. Thus, when a user logs into an NMS client, the NMS client uses the NMS server connection information to connect to an NMS server. The user management information stored within the team session file may be retrieved from user profile information corresponding to the user and stored in a central data repository, and since the user profile data is stored in a central repository, changes may be easily made to the user profile data and consequently pushed out to the team session files accessible by one or more NMS clients. Consequently, a user's management data may widely distributed for access by NMS clients located anywhere in the network.
Patent Number: 7,020,696 Issued on 03/28/2006 to Perry, et al.
| Inventors:
|
Perry; James R. (Merrimack, NH);
Snow; Kevin D. (Amherst, NH);
Black; Darryl (Hollis, NH)
|
| Assignee:
|
Ciena Corp. (Linthicum, MD)
|
| Appl. No.:
|
703531 |
| Filed:
|
November 1, 2000 |
| Current U.S. Class: |
709/223; 5/225; 5/227; 5/217 |
| Current Intern'l Class: |
G06F 15/17.3 (20060101) |
| Field of Search: |
709/223-229,205-207,217,219,203
|
References Cited [Referenced By]
U.S. Patent Documents
| 4750136 | Jun., 1988 | Arpin et al.
| |
| 4942540 | Jul., 1990 | Black et al.
| |
| 5515403 | May., 1996 | Sloan et al.
| |
| 5638410 | Jun., 1997 | Kuddes.
| |
| 5726607 | Mar., 1998 | Brede et al.
| |
| 5850399 | Dec., 1998 | Ganmukhi et al.
| |
| 5903564 | May., 1999 | Ganmukhi et al.
| |
| 5905730 | May., 1999 | Yang et al.
| |
| 5926463 | Jul., 1999 | Ahearn et al.
| |
| 5953314 | Sep., 1999 | Ganmukhi et al.
| |
| 5991163 | Nov., 1999 | Marconi et al.
| |
| 5991297 | Nov., 1999 | Palnati et al.
| |
| 5995511 | Nov., 1999 | Zhou et al.
| |
| 6008805 | Dec., 1999 | Land et al.
| |
| 6008995 | Dec., 1999 | Pusateri et al.
| |
| 6021263 | Feb., 2000 | Kujoory et al.
| |
| 6033259 | Mar., 2000 | Daoud.
| |
| 6041307 | Mar., 2000 | Ahuja et al.
| |
| 6044540 | Apr., 2000 | Fontana.
| |
| 6055575 | Apr., 2000 | Paulsen et al.
| |
| 6078595 | Jun., 2000 | Jones et al.
| |
| 6079020 | Jun., 2000 | Liu.
| |
| 6233618 | May., 2001 | Shannon.
| |
| 6434619 | Aug., 2002 | Lim et al.
| |
| 6732181 | May., 2004 | Lim et al.
| |
| Foreign Patent Documents |
| 9826611 | Jun., 1998 | WO.
| |
| 9905826 | Feb., 1999 | WO.
| |
| 9911095 | Mar., 1999 | WO.
| |
| 9914876 | Mar., 1999 | WO.
| |
| 9927688 | Jun., 1999 | WO.
| |
| 9930530 | Jun., 1999 | WO.
| |
| 9935577 | Jul., 1999 | WO.
| |
Other References
"The Abatis Network Services Contractor," Abatis Systems Corporation product
literature, 1999.
AtiMe-3E Data Sheet, 1-17 (Mar. 8, 2000).
Black, D., "Building Switched Networks," pp. 85-267.
Black, D., "Managing Switched Local Area Networks A Practical Guide" pp. 324-329.
"Configuration," Cisco Systems Inc. webpage, pp. 1-32 (Sep. 20, 1999).
Leroux, P., "The New Business Imperative: Achieving Shorter Development Cycles
while Improving Product Quality," QNX Software Systems Ltd. webpage, (1999).
NavisXtend Accounting Server, Ascend Communications, Inc. product information (1997).
NavisXtend Fault Server, Ascend Communications, Inc. product information (1997).
NavisXtend Provisioning Server, Ascend Communications, Inc. product information (1997).
Network Health LAN/WAN Report Guide, pp. 1-23.
"Optimizing Routing Software for Reliable Internet Growth," JUNOS product literature (1998).
PMC-Sierra, Inc. website (Mar. 24, 2000).
Raddalgoda, M., "Failure-proof Telecommunications Products: Changing Expectations
About Networking Reliability with Microkernel RTOS Technology," QNX Software Systems
Ltd. webpage, (1999).
"Real-time Embedded Database Fault Tolerance on Two Single-board Computers,"
Polyhedra, Inc. product literature.
"Start Here: Basics and Installation of Microsoft Windows NT Workstation," product
literature (1998).
Syndesis Limited product literature, 1999.
"Using Polyhedra for a Wireless Roaming Call Management System," Polyhedra, Inc.,
(prior to May 20, 2000).
Veritas Software Corporation webpage, 2000.
|
Primary Examiner: Maung; Zarni
Assistant Examiner: Nguyen; Phuoc H.
Attorney, Agent or Firm: Engellenner; Thomas J., Mollaaghababa; Reza, Nutter McClennen & Fish LLP
Parent Case Text
RELATED APPLICATIONS
This application is a continuation-in-part of application number
Ser. No. 09/687,191 filed Oct. 12, 2000 which is a C-I-P of
Ser. No. 09/669,364 filed Sep. 26, 2000 which is a C-I-P of
Ser. No. 09/663,947 filed Sep. 18, 2000 which is a C-I-P of
Ser. No. 09/656,123 filed Sep. 6, 2000 which is a C-I-P of
Ser. No. 09/653,700 filed Aug. 31, 2000 which is a C-I-P of
Ser. No. 09/637,800 filed Aug. 11, 2000 which is a C-I-P of
Ser. No. 09/633,675 filed Aug. 7, 2000 which is a C-I-P of
Ser. No. 09/625,101 filed Jul. 24, 2000 which is a C-I-P of
Ser. No. 09/616,477 filed Jul. 14, 2000 which is a C-I-P of
Ser. No. 09/613,940 filed Jul. 11, 2000 which is a C-I-P of
Ser. No. 09/596,055 filed Jun. 16, 2000 which is a C-I-P of
Ser. No. 09/593,034 filed Jun. 13, 2000 which is a C-I-P of
Ser. No. 09/574,440 filed Jun. 20, 2000 and
Ser. No. 09/591,193 filed Jun. 9, 2000 which is a C-I-P of
Ser. No. 09/588,398 filed Jun. 6, 2000 which is a C-I-P of
Ser. No. 09/574,341 filed May 20, 2000; and
Ser. No. 09/574,343 filed May 20, 2000.
Claims
What is claimed is:
1. A method, for managing a telecommunications network, comprising:
detecting a log-on request from a user at a network management system (NMS) client,
wherein the log-on request includes a user identification;
accessing a team session file corresponding to the user identification and including
current NMS server connection information;
connecting the NMS client to an NMS server using the current NMS server connection
information included in the team session file;
wherein prior to detecting a log-on request from a user at an NMS client, the
method comprises:
detecting an initial log-on request from the user at the NMS client:
receiving initial NMS server connection information from the user at the NMS
client connecting to an NMS server using the initial NMS server connection information;
retrieving user profile data corresponding to the user identification from the
NMS server;
wherein the user profile data includes the current NMS server connection information;
saving the current NMS server connection information and the user identification
in the team session file;
wherein the log-on request is a first log-on request and the NMS server is a
first NMS server, and wherein the method further comprises:
changing the current NMS server connection information in the user profile data;
sending the changed user profile data, including the changed current NMS server
connection information, to the NMS client;
detecting a second log-on request from the user at the NMS client, wherein the
second log-on request includes the user identification;
accessing the team session file corresponding to the user identification and
including the changed current NMS server connection information; and
connecting the NMS client to a second NMS server using the changed current NMS
server connection information included in the team session file.
2. The method of claim 1, wherein receiving initial NMS server connection information
from the user at the NMS client, comprises:
displaying a connection dialog box to the user; and
receiving the initial NMS server connection information from the user through
the connection dialog box.
3. The method of claim 1, wherein the team session file is stored locally to
the NMS client.
4. The method of claim 1, wherein the log-on request is from a remote system
through a web browser and the team session file is stored as a cookie in memory
local to the remote system.
5. The method of claim 1, wherein the current NMS server connection information
comprises primary NMS server connection information and secondary NMS server connection
information and wherein connecting the NMS client to an NMS server using the current
NMS server connection information included in the team session file, comprises:
sending a first connection request from the NMS client to a first NMS server
using the primary NMS server connection information; and
sending a second connection request from the NMS client to a second NMS server
using the secondary NMS server connection information if the first connection request
fails.
6. The method of claim 1, wherein the user identification comprises a username.
7. The method of claim 1, wherein the current NMS server connection information
comprises an NMS server port number.
8. The method of claim 1, wherein the current NMS server connection information
comprises a domain name server (DNS) name.
9. A method for managing a telecommunications network, comprising:
detecting a log-on request from a user at a network management system (NMS) client,
wherein the log-on request includes a user identification;
accessing a team session file corresponding to the user identification and including
current NMS server connection information;
connecting the NMS client to an NMS server using the current NMS server connection
information included in the team session file
wherein prior to detecting a log-on request from a user at an NMS client, the
method comprises:
detecting an initial log-on request from the user at the NMS client;
receiving initial NMS server connection information from the user at the NMS
client;
connecting to an NMS server using the initial NMS server connection information;
retrieving user profile data corresponding to the user identification from the
NMS server;
wherein the user profile data includes the current NMS server connection information;
saving the current NMS server connection information and the user identification
in the team session file;
wherein retrieving user profile data corresponding to the user identification
from the NMS server, comprises:
retrieving user profile data at the NMS server from a central data repository,
wherein the user profile data includes the current NMS server connection information;
generating a user profile logical managed object (LMO) at the NMS server, including
the current NMS server connection information; and
sending the user profile LMO to the NMS client; and
wherein saving the current NMS server connection information and the user identification
in the team session file, comprises:
saving the current NMS server connection information and the user identification
from the user profile LMO in the team session file.
10. A method for managing a telecommunications network, comprising:
detecting a log-on request from a user at a network management system (NMS) client,
wherein the log-on request includes a user identification;
accessing a team session file corresponding to the user identification and including
current NMS server connection information;
connecting the NMS client to an NMS server using the current NMS server connection
information included in the team session file
wherein prior to detecting a log-on request from a user at an NMS client, the
method comprises:
detecting an initial log-on request from the user at the NMS client;
receiving initial NMS server connection information from the user at the NMS
client;
connecting to an NMS server using the initial NMS server connection information;
retrieving user profile data corresponding to the user identification from the
NMS server;
wherein the user profile data includes the current NMS server connection information;
saving the current NMS server connection information and the user identification
in the team session file;
wherein retrieving user profile data corresponding to the user identification
from the NMS server, comprises:
retrieving user profile data at the NMS server from a central data repository,
wherein the user profile data includes the current NMS server connection information;
generating a user profile logical managed object (LMO) at the NMS server, including
the current NMS server connection information;
generating a client user profile LMO at the NMS server, including at least the
current NMS server connection information from the user profile LMO and in a format
expected by the NMS client; and
sending the client user profile LMO to the NMS client; and
wherein saving the current NMS server connection information and the user identification
in the team session file, comprises:
saving the current NMS server connection information and the user identification
from the client user profile LMO in the team session file.
11. A method, for managing a telecommunications network, comprising:
detecting a log-on request from a user at a network management system (NMS) client,
wherein the log-on request includes a user identification;
accessing a team session file corresponding to the user identification and including
current NMS server connection information;
connecting the NMS client to an NMS server using the current NMS server connection
information included in the team session file;
wherein prior to detecting a log-on request from a user at an NMS client, the
method comprises:
detecting an initial log-on request from the user at the NMS client;
connecting to an NMS server using default NMS server connection information;
retrieving user profile data corresponding to the user identification from the
NMS server,
wherein the user profile data includes the current NMS server connection information;
and
saving the current NMS server connection information in the team session file;
wherein the log-on request is a first log-on request and the NMS server is a
first NMS server, and wherein the method further comprises:
changing the current NMS server connection information in the user profile data;
sending the changed user profile data, including the changed current NMS server
connection information, to the NMS client;
detecting a second log-on request from the user at the NMS client, wherein the
second log-on request includes the user identification;
accessing the team session file corresponding to the user identification and
including the changed current NMS server connection information; and
connecting the NMS client to a second NMS server using the changed current NMS
server connection information included in the team session file.
12. A method for managing a telecommunications network, comprising:
detecting a logon request from a user at a network management system (NMS) client,
wherein the log-on request includes a user identification;
accessing a team session file corresponding to the user identification and including
current NMS server connection information;
connecting the NMS client to an NMS server using the current NMS server connection
information included in the team session file;
wherein prior to detecting a log-on request from a user at an NMS client, the
method comprises:
detecting an initial log-on request from the user at the NMS client;
connecting to an NMS server using default NMS server connection information;
retrieving user profile data corresponding to the user identification from the
NMS server,
wherein the user profile data includes the current NMS server connection information;
and
saving the current NMS server connection information in the team session file;
wherein retrieving user profile data corresponding to the user identification
from the NMS server, comprises:
retrieving user profile data at the NMS server from a central data repository,
wherein the user profile data includes the current NMS server connection information;
generating a user profile logical managed object (LMO) at the NMS server, including
the current NMS server connection information; and
sending the user profile LMO to the NMS client; and
wherein saving the current NMS server connection information and the user identification
in the team session file, comprises:
saving the current NMS server connection information and the user identification
from the user profile LMO in the team session file.
13. The method of claim 12, wherein retrieving user profile data corresponding
to the user identification from the NMS server, comprises:
retrieving user profile data at the NMS server from a central data repository,
wherein the user profile data includes the current NMS server connection information;
generating a user profile logical managed object (LMO) at the NMS server, including
the current NMS server connection information;
generating a client user profile LMO at the NMS server, including at least the
current NMS server connection information from the user profile LMO and in a format
expected by the NMS client; and
sending the client user profile LMO to the NMS client; and
wherein saving the current NMS server connection information and the user identification
in the team session file, comprises:
saving the current NMS server connection information and the user identification
from the client user profile LMO in the team session file.
Description
BACKGROUND
To configure or manage a network device in a telecommunications network, a user
typically connects directly to the network device through a network management
system. Most network management software is based on the Simple Network Management
Protocol (SNMP), and a user connects to a network device by issuing an SNMP command,
for example, read/write or read only, followed by a password in the form of a community
string. Often, only one community string is used to access the network device,
and thus, all users allowed to access the network device must "share" the community
string. Sharing the community string and directly connecting a user to the network
device reduces the security of the network device.
More advanced systems allow multiple SNMP community strings to be used to gain
access to a network device. Generally, these community strings are stored in a
table within the network device. Where a large number of users may be connected
to the device, however, community strings may still need to be shared or the table
in the network device must be very large.
Although one or more community strings may be shared by multiple users and
used to access the same network device, community strings are normally different
for each network device. Thus, to connect to multiple network devices, a user must
separately connect (i.e., issue an SNMP command and community string) to each network
device. This may take considerable time and requires the user to remember multiple
community strings.
In addition, if the one or more community strings needed to access a network
device
must be changed—for example, in response to a security problem—every
user allowed to access the device must be notified of the community string change.
If the community string is changed quickly, then some users may be denied access
until they receive the notification including the new password. If the community
string is not changed until after an amount of time necessary to notify all users,
then until the change is implemented, the security problem will continue.
SUMMARY
The present invention provides a method and apparatus for implementing distributed
user management information in telecommunications networks. At least a portion
of a user's management information is stored in a team session file that is accessible
by a network management system (NMS) client. For example, the team session file
may be saved in memory that is local to the NMS client or, if a user logs in through
a remote system using a web browser, the team session file may be saved as a cookie
in memory local to the remote system. The NMS client may then utilize the user
management information in the team session file while the user is logged into the
NMS client. In one embodiment, the user management information stored within the
team session file includes NMS server connection information. Thus, when a user
logs into an NMS client, the NMS client uses the NMS server connection information
to connect to an NMS server. The user management information stored within the
team session file may be retrieved from user profile information corresponding
to the user and stored in a central data repository, and since the user profile
data is stored in a central repository, changes may be easily made to the user
profile data and consequently pushed out to the team session files accessible by
one or more NMS clients. Consequently, a user's management data may widely distributed
for access by NMS clients located anywhere in the network.
In one aspect, the present invention provides a method for managing a telecommunications
network including detecting a log-on request from a user at a network management
system (NMS) client, where the log-on request includes a user identification, accessing
a team session file corresponding to the user identification and including current
NMS server connection information and connecting the NMS client to an NMS server
using the current NMS server connection information included in the team session
file. The team session file may be stored locally to the NMS client or, where the
log-on request is from a remote system through a web browser, the team session
file may be stored as a cookie in memory local to the remote system. The current
NMS server connection information may include primary NMS server connection information
and secondary NMS server connection information and connecting the NMS client to
an NMS server using the current NMS server connection information included in the
team session file may include sending a first connection request from the NMS client
to a first NMS server using the primary NMS server connection information and sending
a second connection request from the NMS client to a second NMS server using the
secondary NMS server connection information if the first connection request fails.
The user identification may comprise a username. The current NMS server connection
information may include an NMS server IP address or a domain name server (DNS)
name and may also include an NMS server port number. Prior to detecting a log-on
request from a user at an NMS client, the method may include detecting an initial
log-on request from the user at the NMS client, receiving initial NMS server connection
information from the user at the NMS client, connecting to an NMS server using
the initial NMS server connection information, retrieving user profile data corresponding
to the user identification from the NMS server, wherein the user profile data includes
the current NMS server connection information and saving the current NMS server
connection information and the user identification in the team session file.
The log-on request may be a first log-on request and the NMS server may be a
first NMS server, and the method may further include changing the current NMS server
connection information in the user profile data, sending the changed user profile
data, including the changed current NMS server connection information, to the NMS
client, detecting a second log-on request from the user at the NMS client, where
the second log-on request includes the user identification, accessing the team
session file corresponding to the user identification and including the changed
current NMS server connection information and connecting the NMS client to a second
NMS server using the changed current NMS server connection information included
in the team session file. Receiving initial NMS server connection information from
the user at the NMS client may include displaying a connection dialog box to the
user and receiving the initial NMS server connection information from the user
through the connection dialog box. Retrieving user profile data corresponding to
the user identification from the NMS server may include retrieving user profile
data at the NMS server from a central data repository, where the user profile data
includes the current NMS server connection information, generating a user profile
logical managed object (LMO) at the NMS server, including the current NMS server
connection information, and sending the user profile LMO to the NMS client, and
saving the current NMS server connection information and the user identification
in the team session file may include saving the current NMS server connection information
and the user identification from the user profile LMO in the team session file.
Instead, retrieving user profile data corresponding to the user identification
from the NMS server may include retrieving user profile data at the NMS server
from a central data repository, where the user profile data includes the current
NMS server connection information, generating a user profile logical managed object
(LMO) at the NMS server, including the current NMS server connection information,
generating a client user profile LMO at the NMS server, including at least the
current NMS server connection information from the user profile LMO and in a format
expected by the NMS client, and sending the client user profile LMO to the NMS
client, and saving the current NMS server connection information and the user identification
in the team session file may include saving the current NMS server connection information
and the user identification from the client user profile LMO in the team session file.
Prior to detecting a log-on request from a user at an NMS client, the method
may include detecting an initial log-on request from the user at the NMS client,
connecting to an NMS server using default NMS server connection information, retrieving
user profile data corresponding to the user identification from the NMS server,
where the user profile data includes the current NMS server connection information,
and saving the current NMS server connection information in the team session file.
The log-on request may be a first log-on request and the NMS server may be a first
NMS server, and the method may further include changing the current NMS server
connection information in the user profile data, sending the changed user profile
data, including the changed current NMS server connection information, to the NMS
client, detecting a second log-on request from the user at the NMS client, where
the second log-on request includes the user identification, accessing the team
session file corresponding to the user identification and including the changed
current NMS server connection information and connecting the NMS client to a second
NMS server using the changed current NMS server connection information included
in the team session file. Retrieving user profile data corresponding to the user
identification from the NMS server may include retrieving user profile data at
the NMS server from a central data repository, where the user profile data includes
the current NMS server connection information, generating a user profile logical
managed object (LMO) at the NMS server, including the current NMS server connection
information, and sending the user profile LMO to the NMS client, and saving the
current NMS server connection information and the user identification in the team
session file may include saving the current NMS server connection information and
the user identification from the user profile LMO in the team session file. Instead,
retrieving user profile data corresponding to the user identification from the
NMS server may include retrieving user profile data at the NMS server from a central
data repository, where the user profile data includes the current NMS server connection
information, generating a user profile logical managed object (LMO) at the NMS
server, including the current NMS server connection information, generating a client
user profile LMO at the NMS server, including at least the current NMS server connection
information from the user profile LMO and in a format expected by the NMS client,
and sending the client user profile LMO to the NMS client, and saving the current
NMS server connection information and the user identification in the team session
file may include saving the current NMS server connection information and the user
identification from the client user profile LMO in the team session file.
In another aspect, the present invention provides a method for managing a telecommunications
network including detecting a log-on request from a user at an NMS client, where
the log-on request includes a user identification, connecting the NMS client to
an NMS server, retrieving user profile data corresponding to the user identification
from the NMS server and saving at least a portion of the user profile data and
the user identification in a team session file. The team session file may be stored
locally to the NMS client or, where the log-on request is from a remote system
through a web browser, the team session file may be stored as a cookie in memory
local to the remote system. The user profile data saved in the team session file
may comprise current NMS server connection information, and connecting the NMS
client an NMS server may include accessing the team session file using the user
identification, retrieving NMS server connection information from the team session
file and connecting the NMS client to an NMS server using the NMS server connection
information included in the team session file.
BRIEF DESCRIPTION OF THE DRAWINGS
FIG. 1 is a block diagram of a computer system with a distributed processing system;
FIGS. 2
a-2
b are block and flow diagrams of a distributed
network management system;
FIG. 3
a is a block diagram of a logical system model;
FIGS. 3
b and 3
d-3
f are flow diagrams depicting
a software build process using a logical system model;
FIG. 3
c is a flow diagram illustrating a method for allowing applications
to view data within a database;
FIG. 3
g is a flow diagram depicting a configuration process;
FIGS. 3
h and 3
j are flow diagrams depicting template driven
network services provisioning processes;
FIGS. 3
i and 3
k-3
m are screen displays of
an OSS client and various templates;
FIGS. 4
a-4
z, 5
a-5
z, 6
a-6
p,
7
a-7
y, 8
a-8
e, 9
a-9
n,
10
a-10
i, 11
a-11
k, 11
n-11
o,
11
s and 11
x are screen displays of graphical user interfaces;
FIGS. 11L-11
m are tables representing data in a configuration database;
FIGS. 11
p-11
r and 11
t-11
u are
tables representing data in a network management system (NMS) database;
FIG. 11
v is a block and flow diagram representing the creation of a user
profile logical managed object including one or more groups;
FIG. 11
w is a block and flow diagram of a network management system implementing
user profiles and groups across multiple databases;
FIGS. 12
a and 13
a are block and flow diagrams of a computer
system incorporating a modular system architecture and illustrating a method for
accomplishing hardware inventory and setup;
FIGS. 12
b-12
c and 14
a-14
f are
tables representing data in a configuration database;
FIG. 13
b 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;
FIGS. 13
c and 13
d are block and flow diagrams of an accounting
subsystem for pushing network device statistics to network management system software;
FIG. 15 is a block and flow diagram of a line card and a method for executing
multiple instances of processes;
FIGS. 16
a-16
b are flow diagrams illustrating a method
for assigning logical names for inter-process communications;
FIG. 16
c 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;
FIG. 16
d is a chart representing a message format;
FIGS. 17-19 are block and flow diagrams of a computer system incorporating
a modular system architecture and illustrating methods for making configuration changes;
FIG. 20 is a block and flow diagram of a computer system incorporating a modular
system architecture and illustrating a method for distributing logical model changes
to users;
FIG. 21 is a block and flow diagram of a computer system incorporating a modular
system architecture and illustrating a method for making a process upgrade;
FIG. 22 is a block diagram representing a revision numbering scheme;
FIG. 23 is a block and flow diagram of a computer system incorporating a modular
system architecture and illustrating a method for making a device driver upgrade;
FIG. 24 is a block diagram representing processes within separate protected
memory blocks;
FIG. 25 is a block and flow diagram of a line card and a method for accomplishing
vertical fault isolation;
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.
FIG. 27 is a block diagram of an application having multiple sub-processes;
FIG. 28 is a block diagram of a hierarchical fault descriptor,
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;
FIG. 30 is a table representing data in a configuration database;
FIGS. 31
a-31
c, 32
a-32
c, 33
a-33
d
and 34
a-34
b 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;
FIG. 35 is a block diagram of a network device;
FIG. 36 is a block diagram of a portion of a data plane of a network device;
FIG. 37 is a block and flow diagram of a network device incorporating a policy
provisioning manager;
FIGS. 38 and 39 are tables representing data in a configuration database;
FIG. 40 is an isometric view of a network device;
FIGS. 41
a-41
c are front, back and side block diagrams,
respectively, of components and modules within the network device of FIG. 40;
FIG. 42 is a block diagram of dual mid-planes;
FIG. 43 is a block diagram of two distributed switch fabrics and a central switch fabric;
FIG. 44 is a block diagram of the interconnections between switch fabric central
timing subsystems and switch fabric local timing subsystems;
FIG. 45 is a block diagram of a switch fabric central timing subsystem;
FIG. 46 is a state diagram of master/slave selection for switch fabric central
timing subsystems;
FIG. 47 is a block diagram of a switch fabric local timing subsystem;
FIG. 48 is a state diagram of reference signal selection for switch fabric local
timing subsystems;
FIG. 49 is a block diagram of the interconnections between external central
timing subsystems and external local timing subsystems;
FIG. 50 is a block diagram of an external central timing subsystem;
FIG. 51 is a timing diagram of a first timing reference signal with an embedded
second timing signal;
FIG. 52 is a block diagram of an embeddor circuit;
FIG. 53 is a block diagram of an extractor circuit;
FIG. 54 is a block diagram of an external local timing subsystem;
FIG. 55 is a block diagram of an external central timing subsystem;
FIG. 56 is a block diagram of a network device connected to test equipment through
programmable physical layer test ports;
FIG. 57 is a block and flow diagram of a network device incorporating programmable
physical layer test ports;
FIG. 58 is a block diagram of a test path table;
FIG. 59 is a block and flow diagram of a network management system incorporating
proxies to improve NMS server scalability;
FIGS. 60
a-60
n are tables representing data in a configuration database;
FIG. 61
a is a block diagram representing a physical managed object;
FIG. 61
b is a block diagram representing a proxy; and
FIG. 62 is a screen display of a dialog box.
DETAILED DESCRIPTION
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.
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.
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.
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. 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.
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.
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.
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.
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.
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
2C) bus.
Alternatively, the control and data may be passed over one common
path (in-band).
Network/Element Management System (NMS):
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.
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. 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.
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.
Referring to FIG. 2
a, 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 administrator. In addition, the NMS server provides the NMS
client with network device management information, which the client then makes
available to the administrator. "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
task. 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.
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.
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. 13
b).
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.
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.
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.
Referring again to FIG. 2
a, 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.
Instead of having a single central processor card (e.g.,
12, FIG.
1;
543, FIG.
35), the external control functions and the internal
control functions 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. 41
a 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, a
