Method, apparatus, and program for configuring networks with consistent route and bandwidth settings

An apparatus and method for verifying route and bandwidth settings of multiple services provided over networks. The apparatus has an extractor and a verifier. Based on input data describing services each having primary and secondary routes between specific locations, an available bandwidth of each network, and a guaranteed bandwidth of each service, the extractor selects a first network to be verified and extracts first services that use the first network as their respective primary routes. The extractor then selects at least one second network from among the networks that the first services specify as their respective secondary routes. The extractor extracts second services that use the second network as their primary routes and specify the first network as their secondary routes. The verifier sums up guaranteed bandwidths that the first and second services should provide, and determines whether the sum is smaller than an available bandwidth of the first network.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is based upon, and claims the benefits of priority from, the prior Japanese Patent Application No. 2006-035527, filed Feb. 13, 2006, the entire contents of which are incorporated herein by reference.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates to a method, apparatus, and computer program for configuring networks. More particularly, the present invention relates to a network configuration method, apparatus, and program stored in a computer-readable medium for configuring networks to maintain the quality of services executed between an access source location and an access destination location.

2. Description of the Related Art

Many businesses have used reliable, bandwidth-guaranteed network services to interconnect their business locations over wide area networks (WAN) based on public switched telephone networks (PSTN), public data communications networks, or leased lines. The communications technologies used in this type of WANs include the Point-to-Point Protocol (PPP), High Level Data Link Control (HDLC), Integrated Services Digital Network (ISDN), Frame Relay, and Asynchronous Transfer Mode (ATM). The recent trend, however, is toward virtual private networks using Internet Protocol (IP-VPN) or wide area Ethernet™ services. While IP-based services generally offer no guarantee of bandwidth and are relatively less reliable, the enterprise network users can enjoy a greatly increased bandwidth of, for example, more than 1 Gbps, in contrast to some 100 Mbps of conventional networks.

Also, recent years have seen a widespread use of IP phones based on the Voice over IP (VoIP) technologies, as well as a proliferation of video conference systems using streaming techniques. Network systems tend to carry those new service traffic in addition to business applications. IP phones and video conference systems are more sensitive to network delays than other ordinary data communication services. A delay due to an excessive burst of traffic would degrade the quality of a delivered sound or video stream.

Some legacy applications (i.e., non-web-based applications) providing mission-critical services 24 hours, 365 days a year are designed on the assumption that they can use network connections with a guaranteed bandwidth. Those applications cannot migrate to a new web-based environment unless the network system offers guaranteed bandwidth services. To meet such demands, IP-based wide-area networks are required to provide bandwidth-guaranteed, secure and reliable communication channels equivalent to conventional leased line connections.

Under the above-described circumstances, more and more functions are integrated into a network device (e.g., router and switch) deployed at business locations and at the edge of a WAN. For example, recent network devices have the functions of controlling bandwidth, priority, security, and routing with multihoming support. Those features are also available as dedicated appliances that can work seamlessly in combination with a router or a switch.

To realize a highly reliable IP-based WAN by using such edge devices, some verification mechanism has to be implemented to quickly check the configuration of many edge devices distributed across the network. This may typically be realized by using Telnet login and command line interface (CLI) of each edge device (e.g., routers, switches, traffic controller, security controllers) located at offices or on WAN edges. It is, however, not easy to check the order and consistency of device settings, while keeping in mind the difference between vender-specific CLI specifications, as well as considering the overall network topology. This difficulty leads to an increased cost of network system operations.

One known method to reduce the workload of operations and management is to distribute a configuration file from an operation management site to each edge device on the network. This method, however, merely automates the task of applying the settings that are previously prepared. One drawback of the method is its dependency on the interface specifications of each individual device and the consequent lack of versatility. Another drawback is that the method does nothing about guaranteeing bandwidth for multiple services. Yet another drawback is that the operator needs to know well about quality of service (QoS) control mechanisms.

To address the problems described above, Japanese Patent No. 3137583 proposes a static setting method for routing parameters of network devices. However, the proposed method still lacks consideration of bandwidth guarantee for multiple services.

SUMMARY OF THE INVENTION

In view of the foregoing, it is an object of the present invention to provide a method, an apparatus, and a program stored in a computer-readable medium for verifying whether the routes and bandwidths of service traffic are configured correctly.

To accomplish the above object, the present invention provides a method of configuring networks to maintain quality of services executed between an access source location and an access destination location. This network configuration method comprises the following steps: (a) receiving input data describing a plurality of services each having a primary route and a secondary route between the access source location and the access destination location, an available bandwidth of each network carrying traffic of the services, and a guaranteed bandwidth of each of the services; (b) selecting, from among the plurality of networks, a first network to be verified, based on the received input data; (c) extracting first services that use the first network as primary routes thereof; (d) selecting at least one second network from among the networks that the first services specify as secondary routes thereof; (e) extracting second services that use the second network as primary routes thereof and specify the first network as secondary routes thereof; (f) calculating a sum of the guaranteed bandwidths that are supposed to be available to the first services and the second services; and (g) determining whether the sum is smaller than an available bandwidth of the first network.

Also, to accomplish the above object, the present invention provides an apparatus for configuring networks to maintain quality of services executed between an access source location and an access destination location. This apparatus has an extractor and a verifier. The extractor receives input data describing a plurality of services each having a primary route and a secondary route between the access source location and the access destination location, an available bandwidth of each network carrying traffic of the services, and a guaranteed bandwidth of each of the services. Based on this received input data, the extractor selects a first network to be verified, from among the plurality of networks. The extractor extracts first services that use the selected first network as their primary routes. The extractor selects at least one second network from among the networks that the first services specify as their secondary routes. The extractor then extracts second services that use the second network as primary routes and specify the first network as secondary routes. The verifier calculates a sum of guaranteed bandwidths that are supposed to be available to the first services and the second services, and determines whether the sum is smaller than an available bandwidth of the first network.

DESCRIPTION OF THE PREFERRED EMBODIMENTS

Preferred embodiments of the present invention will now be described in detail below with reference to the accompanying drawings, wherein like reference numerals refer to like elements throughout. The following description begins with an overview of the present invention and then proceeds to a more specific embodiment of the invention.

FIG. 1is a conceptual view of the present invention. The illustrated network configuration device1is used primarily to manage the route and bandwidth of each application service in a wide-area network environment employing multi-vendor edge devices to carry data traffic across two or more different business locations. Each service has a primary route and at least one secondary route interconnecting two locations. According to the present embodiment, the network configuration device1has an extractor3and a verifier4and linked to a network cluster5to which the managed networks belong.

The extractor3receives two sets of input data, first input data2aand second input data2b. The first input data2adescribes primary and secondary routes of each service, as well as a guaranteed bandwidth that is supposed to be available to each service. The second input data2bgives an available bandwidth of each intermediate network, i.e., how much bandwidth each network can offer to carry the service traffic.

Based on the given first input data2aand/or second input data2b, the extractor3selects a specific network as an object to be verified in the subsequent process. The selected network is referred to herein as a first network. The extractor3then consults the first input data2ato extract first services that use the selected first network as their primary routes. The extractor3further identifies a second network that the extracted first services specify as their secondary routes. The extractor3also extracts second services that use the identified second network as their primary route.

The verifier4calculates a sum of guaranteed bandwidths of the second services, which use the second network as their primary routes and specify the first network as their secondary routes. The verifier4further adds the guaranteed bandwidth of the first service to that sum. The verifier4then verifies whether the resulting sum of guaranteed bandwidths is smaller than the available bandwidth of the first network. The information about available bandwidth of each network can be obtained by using Simple Network Management Protocol (SNMP) or the like.

In the example ofFIG. 1, Services A, B, C, and so on are executed across different business locations (not shown). Each service has a predefined primary route and secondary route interconnecting locations as shown in the first input data2a. More specifically, Service A uses Network #1as its primary route and specifies Network #2as its secondary route, while Services B and C use Network #2as their primary routes and Network #1as their secondary routes. Available bandwidths of Networks #1to #3are given in the second input data2b.

The network configuration device1operates in the context ofFIG. 1as follows. The extractor3first focuses on a specific entry of the second input data2b, thus selecting Network #1as a target network to be verified. The extractor3then extracts a service that uses the selected Network #1under verification as its primary route. What is selected in this case is Service A. The extractor3then seeks a network that the extracted service A specifies as its secondary route, thus finding Network #2. The extractor3then identifies which services are using Network #2as their primary routes. The first input data2aindicates that they are Service B and Service C.

Consulting the second input data2b, the verifier4calculates a sum of guaranteed bandwidths of Services B and C, which use Network #2as their primary routes and Network #1as their secondary routes. The verifier4further adds the guaranteed bandwidth of Service A, thus obtaining the sum of guaranteed bandwidths of all services A, B, and C relevant to Network #1, the network under verification. The verifier4now verifies whether the obtained sum is smaller than the available bandwidth of Network #1under verification.

The network configuration device1verifies the consistency of a plurality of service routes and their bandwidth allocations in the above-described way. The network operators use this device when, for example, their network system needs to be modified. The proposed network configuration device1helps them configure the network routes and bandwidth allocations correctly, thus making their systems more reliable. More specific embodiments of the present invention will now be described in the following sections.

Network System

FIG. 2shows the configuration of a network system according to an embodiment of the present invention. The illustrated network system300serves as part of a public infrastructure or a mission-critical system that supports a company's business operations such as manufacturing control. Specifically, the network system300involves a management server100and its managed object group200. Various applications, including accounting services, run on the network system300.

The management server100functions as a network provisioning system that allocates bandwidth quotas and other resources for services to be provided. The management server100is linked to a managed object group200through an enterprise's management network10, which may also be referred to as an enterprise network. The managed object group200includes a data center21, WANs22and23, exchange points24to26, WANs27to29, and sales branches30to32.

The data center21offers Internet access service, as well as operations and maintenance service, upon demand from exchange points24to26. The data center21acts as, for example, a web server by running web server applications.

The WANs22and23are relatively large networks operated by, for example, a nationwide service provider. The WANs22and23carry communication data traffic between the data center21and exchange points24to26. The exchange points24to26are intermediate facilities that collect communications data from sales branches30to32and forward them to the data center21, or vice versa.

The WANs27to29are, on the other hand, relatively small networks operated by, for example, regional network service providers. The WANs27to29carry communication data traffic between the sales branches30to32and exchange points24to26.

The sales branches30to32are part of an enterprise's sales network over the country. Service applications run between those sales branches30to32and the data center21, as well as among the sales branches30to32. The present embodiment assumes that an accounting service is provided between the sales branch30and data center21. Edge devices are deployed at the data center21, WANs22and23, exchange points24to26, WANs27to29, and sales branches30to32. Edge devices offer dual-redundant functions for routing, switching, packet controlling, and others.

Hardware Configuration of Management Server

FIG. 3shows an example hardware configuration of the management server100. The illustrated management server100has the following functional elements: a central processing unit (CPU)101, a random access memory (RAM)102, a hard disk drive (HDD)103, a graphics processor104, an input device interface105, and a communication interface106. The CPU101controls the entire system of the management server100, interacting with other elements via a bus107.

The RAM102serves as temporary storage for the whole or part of operating system (OS) programs and application programs that the CPU101executes, in addition to other various data objects manipulated at runtime. The HDD103stores program and data files of the operating system and various applications.

The graphics processor104produces video images in accordance with drawing commands from the CPU101and displays them on the screen of an external monitor11coupled thereto. The input device interface105is used to receive signals from external input devices, such as a keyboard12and a mouse13. Those input signals are supplied to the CPU101via the bus107. The communication interface106is connected to the management network10, allowing the CPU101to exchange data with other computers (not shown) on that network10. The computer system described above serves as a hardware platform for realizing the processing functions of the present embodiment.

Management Server Functions

With the hardware configuration described in the preceding section, the management server100employs various functional elements for network provisioning purposes.FIG. 4is a block diagram of the management server100. As seen, the management server100has a configurer110, a configuration database120, a service policy builder130, a service policy database140, a service policy verifier150, a command generator160, and a service policy enforcer170.

The configurer110is responsive to automatic node detection of a network management product, such as Systemwalker™ Centric Manager and Systemwalker™ Network Manager, or to instructions from a management server administrator. When requested, the configurer110creates and edits an edge device data table41ain a configuration database120. The edge device data table41acontains information about edge devices in the WANs22,23,27to29, exchange points24to26, and sales branches30to32.

The configurer110provides a GUI-based WAN configuration window for the operator to build an edge device data table41aby using a keyboard12and mouse13. According to user input, the configurer110builds a WAN configuration table51ain the configuration database120to describe properties of each edge device interconnecting WANs22,23, and27to29and sales branches. Using this WAN configuration table51ain the configuration database120, the service policy builder130creates a service policy table61ain the service policy database140to describe how to operate and manage the services. Specifically, the service policy table61acontains route parameters and bandwidth parameters for operating an accounting service. Route parameters define primary and secondary routes, each including a forward route and a return route, that carry the accounting service traffic. Bandwidth parameters define how much bandwidth each primary or secondary route is supposed to guarantee.

The service policy builder130interacts with the operator through a GUI-based service policy setting window, allowing him/her to build a service policy table61aby using the keyboard12and mouse13.

It is assumed in the present embodiment that the primary forward route of accounting service traffic goes from the sales branch30to the data center21, passing through the WAN27, exchange point24, and WAN22in that order. It is also assumed that the primary return route of the accounting service traffic goes from the data center21to the sales branch30, passing through the WAN22, exchange point24, and WAN27in that order. It is further assumed that the secondary forward route of accounting service traffic goes from the sales branch30to the data center21, passing through the WAN28, exchange point25, and WAN23in that order. Yet another assumption is that the secondary return route of accounting service traffic goes from the data center21to the sales branch30, passing through the WAN23, exchange point25, and WAN28in that order. The present embodiment also assumes the use of an edge device data table41a, WAN configuration table51a, and service policy table61ashown inFIGS. 5,6, and7, respectively. These tables will be described in detail later.

The service policy verifier150verifies consistency of the entire network system by making sure that there are no contradictions in the service policy parameters defined in the service policy table61a. The details of this consistency verification will be described in a later section.

The command generator160generates commands for reconfiguring edge devices according to their respective properties by consulting the service policy data after it is verified by the service policy verifier150. The service policy enforcer170sends those commands to their destination devices to enforce the policy.

Suppose, for example, that a new network configuration has to be added to the network system300ofFIG. 2. The management server100then performs an administrative session according to the flowchart ofFIG. 5. First, the configurer110defines the entire system configuration by creating an edge device data table41aand a WAN configuration table51a(step S1). Then the service policy builder130builds a service policy in a service policy table61aby consulting the edge device data table41aand WAN configuration table51astored in the configuration database120(step S2). The service policy verifier150verifies consistency of this service policy table61astored in the service policy database140(step S3). If the service policy table61acontains some inconsistency (i.e., if “NO” at step S3), the service policy verifier150returns to step S2to allow the operator to modify the service policy table61a. If the service policy table61ais found consistent (i.e., if “YES” at step S3), then the command generator160produces vendor-specific commands to implement the content of the service policy table61aon each edge device (step S4). Finally the service policy enforcer170enforces the device reconfiguration as a transaction of each service (step S5), thus completing the administrative session. The subsequent sections will describe each step S1to S5in detail.

Edge Device Data Table

FIG. 6shows the edge device data table41a. The illustrated edge device data table41ahas the following data fields: “Edge Device Name,” “Managed IP,” “OS,” “Password,” and “Enable Password. Each row of this edge device data table41aforms an associated set of parameters describing the profile of a particular edge device.

More specifically, the edge device name field shows the name of a specific edge device deployed in the network system300. The example ofFIG. 6gives the following edge device names: “EDGE-Center-1A,” “EDGE-Center-1B,” “EDGE-M1-1A,” “EDGE-M1-1B,” “EDGE-M2-1A,” and “EDGE-M2-1B.” The managed IP field shows the IP address of a corresponding edge device, which is used for administrative purposes. The example ofFIG. 6gives a managed IP address “AA.BB.CC.DD” for the corresponding device “EDGE-Center-1A.”

The OS field indicates the operating system used in the corresponding edge device. The example ofFIG. 6gives the name of a specific OS “EDGE OS12.2” running on the device “EDGE-Center-1A.” The password field contains a special password required for management of the corresponding edge device. The example ofFIG. 6gives a password “*********” of the device “EDGE-Center-1A.” The enable password field contains an enable password with no particular restrictions. The example ofFIG. 6gives a password “*********” of the device “EDGE-Center-1A.”

The above data fields are filled out for every edge device belonging to the network system300. In the present embodiment, the edge device data table41ahas edge device entries corresponding to the data center21, exchange points24to26, and sales branches30to32.

WAN Configuration Table

FIG. 7shows a WAN configuration window50. This WAN configuration window50provides a table field51, ADD WAN button52, DELETE WAN button53, ADD LOCATION button54, DELETE LOCATION button55, OK button56, and CANCEL button57. The table field51contains a WAN configuration table51a, which has the following data fields, from left to right: “WAN Name,” “Location Name,” “Bandwidth Controller Name,” “Type A,” “Router Name,” and “Type B. Each row of this WAN configuration table51aforms an associated set of parameters describing a particular WAN.

The WAN Name field indicates the name of a WAN. In the example ofFIG. 7, the name “WAN-A” represents the WAN22shown inFIG. 2. Adding a WAN name to the WAN configuration table51aenables the operator to define locations. The location name field accommodates symbols of locations connected to the WAN22. Specifically, the WAN configuration table51aofFIG. 7has the following location name field entries: “Data Center” representing the data center21, “Exchange Point #1” representing an exchange point24, and “Exchange Point #2” representing another exchange point25.

The WAN configuration table51aallows the operator to define four edge devices for each location, which include a bandwidth controller and a router used in the primary route, as well as those used in the secondary route. The bandwidth controller name field specifies an edge device for controlling bandwidth at a location. The WAN configuration table51amay provide a pull-down menu for selection of a bandwidth controller name and a router name, the menu containing the names of candidate edge devices previously registered in the edge device data table41a.

The type A field next to each bandwidth controller name is set to either “MAIN” or “SUB” indicating that the corresponding bandwidth controller is a working edge device or a protection edge device. In the case where the bandwidth controller is protected with a dual-redundant design, both “MAIN” and “SUB” devices are defined. Otherwise, the operator only fills out a “MAIN” edge device field while leaving the corresponding “SUB” field blank. In the example ofFIG. 7, two bandwidth controllers “EDGE-Center-1A” and “EDGE-Center-1B” are registered respectively as “MAIN” and “SUB” bandwidth controllers located at the data center21. Also registered are a “MAIN” bandwidth controller named “EDGE-M1-1A” and a “SUB” bandwidth controller named “EDGE-M1-1B,” both located at the exchange point24. Further registered are a “MAIN” bandwidth controller named “EDGE-M2-1A” and a “SUB” bandwidth controller named “EDGE-M2-1B,” both located at the exchange point25.

The router name field specifies an edge device for routing network traffic, and the corresponding type B field takes a value of “MAIN” or “SUB” to indicate whether that edge device serves as a working device or a protection device in the case where the routing function is protected with a dual-redundant design. In the example ofFIG. 7, the bandwidth controller name field and router name field contain the same names since the present embodiment assumes that both the bandwidth controller function and router function are integrated in a single edge device. The present invention, however, should not be limited to this assumption since it is of course possible to use separate edge devices for bandwidth control and routing.

The operator defines the above parameters for all WANs22,23, and27to29, althoughFIG. 7only shows those of WAN22. A new WAN entry can be added to the WAN configuration table51aby pressing the NEW WAN button52. The operator is then allowed to enter a new WAN name to a newly opened WAN name field. The operator subsequently presses a NEW LOCATION button54, which permits him/her to define locations connected to the WAN.

The operator may delete an existing entry of the WAN configuration table51a. To delete a specific WAN entry, he/she selects it and presses a DELETE WAN button53. This action deletes all service parameters associated with the selected WAN, including the values of location name field, bandwidth controller name field, type A field, router name field, and type B field. To delete a particular location registered in the WAN configuration table51a, he/she selects it and presses a DELETE LOCATION button55. This action removes the selected location from the existing WAN entry.

The WAN configuration window50further provides an OK button56to make the edited WAN configuration table51atake effect. Pressing the OK button56finalizes the WAN configuration table51a, thus causing its contents to be transferred to the configuration database120.

The operator can cancel the current editing session of the WAN configuration table51aby pressing a CANCEL button57. Pressing this CANCEL button57allows the operator to exit from the editing session without reflecting the changes that he/she have made to the WAN configuration table51a.

Service Policy Table

FIG. 8shows a service policy setting window60for building a service policy. This service policy setting window60has the following objects: a table field61, a NEW SERVICE button62, a DELETE SERVICE button63, an INSERT POINT button64, a SEND button65, and a CANCEL button66.

The table field61contains a service policy table61a, which has the following data fields, from left to right: “Service Name,” “Type,” “Max,” “Min,” “Priority,” “Source IP,” “Dest IP,” “Protocol,” “Port,” “Start Location,” “WAN1,” “Exchange Point,” “WAN2,” and “End Location.” Each row of this service policy table61aforms an associated set of parameters describing a policy of a specific service.

Each entry of the service policy table61atakes up four lines. The first line defines a primary forward route, the second line a primary return route, the third line a secondary forward route, and the fourth line a secondary return route.

The service name field shows the name of a specific service. Specifically, the example ofFIG. 8gives a value of “Accounting System1” in this field, which is the name of the accounting service that the present embodiment assumes. The type field and subsequent data fields describe a primary forward route, a primary return route, a secondary forward route, and a secondary return route on which the service traffic of “Accounting System1” will be conveyed. Primary routes are indicated by the type field value of “MAIN” while secondary routes are indicated by the type field value of “SUB.”

The min field defines a minimum guaranteed bandwidth in units of Mbps for the corresponding service. This parameter gives the amount of bandwidth that the service traffic can occupy, no matter how much traffic other services may produce.FIG. 8shows that every route provides a capacity of at least 5 Mbps.

The operator specifies both or either of those max and min parameters as necessary. He/she may leave them blank in the case no specific guarantee or limitation is required. When he/she specifies both, the max parameter has to be greater than the min parameter.

The priority field provides a drop-down list for the operator to select a value of either “Priority” or “Even” (the latter being default). When “Priority” is selected, the service is assigned to a priority queue that a corresponding edge device supports, so that it will be processed in preference to other services in a normal queue. Streaming services such as VoIP applications may be given a “Priority” property since a traffic delay would be fatal to the quality of those services. Note that the operator is only allowed to prioritize one route per service. An attempt to set two or more priority routes for the same service would cause an error. In the example ofFIG. 8, the priority field is set to “even” for all entries.

The source IP field indicates the IP address of a service source of the accounting service in the present context. The IP address may be either a host IP address or a subnet IP address. According to the example ofFIG. 8, a source IP address value of “10.0/16” is set to the primary forward route, and “10.3/16” to the primary return route, where lower 16 bits are omitted because they are subnet IP addresses. The secondary route entries are automatically filled out with the same IP address values as their corresponding primary route entries.

The destination IP (DEST IP) field contains the IP address of a service destination of the accounting service in the present context. The IP address may be either a host IP address or a subnet IP address. According to the example ofFIG. 8, an IP address value of “10.3/16” is set to the primary forward route, and “10.0/16” to the primary return route, where lower 16 bits are omitted because they are subnet IP addresses. The secondary route entries are automatically filled out with the same IP address values as their corresponding primary route entries.

The protocol field specifies a protocol, which is, in the present embodiment, selected from among those listed in a drop-down list. The list may include the following protocols: Transmission Control Protocol (TCP), User Datagram Protocol (UDP), Internet Control Message Protocol (ICMP), File Transfer Protocol (FTP), H.323, Real-Time Streaming Protocol/Real-time Transport Protocol (RTSP/RTP), and Session Initiation Protocol/Session Description Protocol/RTP (SIP/SDP/RTP). TCP is selected for every table entry in the example ofFIG. 8.

The port field depends on the protocol field. Specifically, when the corresponding protocol field has a value of “FTP,” “H.323,” “RTSP/RTP,” or “SIP/SDP/RTP,” the port field is set to “dynamic.” In the case of “ICMP,” the port field becomes unavailable. In the case of “TCP” or “UDP,” the port field accommodates a specific port number. InFIG. 8, every protocol field is set to “TCP,” and thus the corresponding port field contains a value of “12345” as an example port number.

The start location field indicates where the corresponding route starts. In the example ofFIG. 8, the start location fields of the primary and secondary forward routes are set to “Sales Branch #1” representing the sales branch30, and those of the primary and secondary return routes are set to “Data Center.”

The exchange point field specifies an exchange point, i.e., an intermediate location between the start location and the end location. According toFIG. 8, the exchange point field contains an exchange point name “Exchange Point #1” representing the exchange point24on the primary forward and return routes, as well as “Exchange Point #2” representing the exchange point25on the secondary forward and return routes.

The end location field indicates where the corresponding route reaches. In the example ofFIG. 8, the end location fields of the primary and secondary forward routes are set to “Data Center” representing the data center21, and those of the primary and secondary return routes are both set to “Sales Branch #1” representing the sales branch30.

Note that every primary route and its corresponding secondary route should be routed in such a way that they will pass through different WANs. In other words, the primary and secondary routes must not meet each other before reaching their common destination. This avoids the possibility of the two routes failing simultaneously.

The WAN1 field indicates a WAN that interconnects the start location and exchange point. According toFIG. 8, the WAN1 field of the primary forward route contains a value of “WAN-C,” the name of WAN27interconnecting the sales branch30and exchange point24. Also the WAN1 field of the primary return route contains a value of “WAN-A,” the name of WAN22interconnecting the data center21and exchange point24. Further, the WAN1 field of the secondary forward route contains a value of “WAN-D,” the name of WAN28interconnecting the sales branch30and exchange point24. Also the WAN1 field of the secondary return route contains a value of “WAN-B,” the name of WAN23interconnecting the data center21and exchange point24.

The WAN2 field indicates a WAN that interconnects the corresponding exchange point and end location in a similar way to the WAN1 field. Referring toFIG. 8, the WAN2 field of the primary forward route contains a value of “WAN-A,” the name of WAN22interconnecting the exchange point24and data center21. Also the WAN2 field of the primary return route contains a value of “WAN-C,” the name of WAN27interconnecting the exchange point24and sales branch30. Further, the WAN2 field of the secondary forward route contains a value of “WAN-B,” the name of WAN23interconnecting the exchange point25and data center21. Also the WAN2 field of the secondary return route contains a value of “WAN-D,” the name of WAN28interconnecting the exchange point25and sales branch30.

The operator presses a NEW SERVICE button62when he/she needs to add a new service entry to the service policy table61a. The operator is then allowed to enter the name of a new service to a newly opened service name field.

The service policy setting window60also offers a DELETE SERVICE button63for the operator to remove an existing service entry from the service policy table61a. Pressing this DELETE SERVICE button63causes the selected service to be deleted from the service name field and other related data fields.

The operator can add a new exchange point entry to the service policy table61aby pressing an INSERT POINT button64. The INSERT POINT button64, when pressed, adds a new exchange point field between the start location and end location, together with a corresponding WAN field.

The parameters set in the service policy table61ado not take effect until an APPLY button65is pressed. This APPLY button65causes the edited service policy table61ato be saved into the service policy database140.

The operator can cancel the current editing session of the service policy table61aby pressing a CANCEL button66. Pressing this CANCEL button66allows the operator to exit from the editing session without reflecting any changes that he/she have made to the service policy table61a.

The operator repeatedly uses those buttons to add new services or remove obsolete services until the service policy table61acontains as many entries as the number of actual services. A service policy database schema is designed and implemented, based on this service policy table61a.FIG. 9is a class diagram showing a service policy database schema according to the present embodiment.

Enterprise network class81has one instance per enterprise. One enterprise network class instance has references to a plurality of enterprise WANs. For enterprise WAN class82, as many instances as the number of enterprise WANs are created. Specifically, the present embodiment involves five enterprise WAN class instances, WANs22,23,27,28, and29.

Enterprise WAN class82has references to a plurality of instances of location class83, which are created as many as the number of locations. Specifically, the present embodiment involves sales branches30to32, exchange points24to26, and a data center21as location class instances. Exchange point class84and data center class85, corresponding to the exchange points24to26and data center21, are created as subclasses inheriting properties from the location class83.

Location class83has references to a plurality of instances of enterprise WAN class82. For example, the sales branch30in the present embodiment has references to two WANs27and28. Location class83also has references to a plurality of instances of interlocation route class86. The term “interlocation route” refers to a route between locations connected to a single WAN. Think of, for example, four locations on a WAN edge. In this case there are twelve (=4×3) ways to connect two locations (when forward and return routes are counted as different routes). That is, twelve instances of the interlocation route class86are created.

Interlocation route class86has references to two instances of location class83; one is a start location and the other is an end location.

Enterprise network class81has references to as many instances of service class87as the number of services. Specifically, one service class instance is created in the present embodiment.

Service class87has references to a plurality of instances of interlocation service class88, meaning that one service can be represented as a set of interlocation services.

Interlocation service class88has the following four route properties: primary forward route, primary return route, secondary forward route, and secondary return route. Those properties are represented as an array of references to interlocation route class instances. Interlocation service class88also has the following four bandwidth properties: primary forward route bandwidth, primary return route bandwidth, secondary forward route bandwidth, and secondary return route bandwidth. Each of those properties is represented as a reference to an instance of service bandwidth policy class89. It has to be noted here that a primary route service bandwidth policy class90representing a service bandwidth policy of a primary route is defined as an inheritance from service bandwidth policy class, as is a secondary route service bandwidth policy class91representing a service bandwidth policy of secondary routes.

Primary forward route bandwidth and primary return route bandwidth are references to instances of primary route service bandwidth policy class90. Likewise, secondary forward route bandwidth and secondary return route bandwidth are references to instances of secondary route service bandwidth policy class91.

Each instance of interlocation route class86gives a specific route and has a specific available bandwidth as its property. It also has references to a plurality of service bandwidth policy class instances. Those instances form a set of service bandwidth parameters for a plurality of services.

Service policy class92is defined as a superclass of service bandwidth policy class89, with the properties of “Protocol,” “Source IP Address,” “Destination IP Address,” and “Port.”

Edge device class93has the properties of “edge device,” “Managed IP,” “Password” and “Enable Password,” each represented as a reference to command class97. Switch class94, router class95, and packet control equipment class96are subclasses inheriting properties from the edge device class93. Edge device class93has references to command class97.

Command class97provides commands for controlling routes and bandwidths, the subclasses of which include: model-1 command class98, model-2 command class99, and model-3 command class72. Those subclasses represent vendor-specific commands used in the individual edge devices.

Consistency Verification

This section describes how the service policy verifier150verifies consistency of service policy parameters stored in the service policy table61a.FIGS. 10 and 11show a flowchart of a process that verifies consistency of service policy parameters. Briefly, the first half (steps S11to S19) of this flowchart verifies each specified route, and the second half (steps S20to26) verifies bandwidth setting of each route.

The verification process begins with selecting a service from among those listed in the service policy database structure ofFIG. 9(step S11). The service policy verifier150then selects one interlocation service from the currently focused service (step S12). The selected interlocation service has a primary forward route, a primary return route, a secondary forward route, and a secondary return route. The service policy verifier150traces the reference links of data elements constituting each route, from the start location to the end location, in an attempt to find whether the end location can be reached through the specified interlocation routes (steps S13to S16). If one or more routes fail to reach the destination (i.e., if either of steps S13to S16results in “NO”), the service policy verifier150enters a route setting error record to an error log (step S17) and proceeds to steps S18. If all routes are found reachable (i.e., if all steps S13to S16result in “YES”), then the service policy verifier150determines whether all interlocation services have been checked (step S18). If not (i.e., if “NO” at step S18), the process returns to step S12to select another interlocation service for verification. If all interlocation services have been checked (i.e., if “YES” at step S18), then the service policy verifier150determines whether all services have been checked (step S19). If not (“NO” at step S19), the process returns to step S11to select another service for verification.

If all services have been checked (“YES” at step S19), the service policy verifier150then extracts one set of interlocation routes with a data structure shown inFIG. 9(step S20). The extracted set of interlocation routes include a primary route and a secondary route. The service policy verifier150then checks whether the maximum bandwidth limit and minimum guaranteed bandwidth of each primary route are specified correctly, as well as whether the same of each secondary route are specified correctly. Specifically, the service policy verifier150executes the following tests:

The service policy verifier150first examines the minimum guaranteed bandwidth of primary routes. More specifically, it sums up the minimum guaranteed bandwidths of all services that use the WAN under verification as their primary route. The result is referred to as a first sum. The service policy verifier150determines whether this first sum is lower than the available bandwidth of the WAN under verification multiplied by a guaranteed bandwidth allocation ratio (step S21). This test conditions is referred to as a “first condition.” The guaranteed bandwidth allocation ratio is a ratio of bandwidth that can be assigned to bandwidth-guaranteed service traffic. While it has a default value of 0.5, the operator is allowed to specify the ratio as part of environment settings, in the range from zero (exclusive) to one (inclusive).

If the first condition is not satisfied (i.e., if “NO” at step S21), the service policy verifier150determines that some minimum guaranteed bandwidths of primary routes are set incorrectly, thus proceeding to step S22. At step S22, the service policy verifier150enters a bandwidth setting error record to an error log before it goes to step S26, so as to indicate that there is an error in the current setup of minimum guaranteed bandwidths of services that use the WAN under verification as their primary routes.

If, on the other hand, the first condition is satisfied (i.e., if “YES” at step S21), the service policy verifier150advances to the next step in an attempt to determine whether the maximum bandwidth limits are set correctly for primary routes. Specifically, the service policy verifier150finds a service that has the largest amount of maximum bandwidth limit among the services using the WAN under verification as their primary routes. Subsequently the service policy verifier150subtracts the minimum guaranteed bandwidth of the found service from the maximum bandwidth limit of the same and then adds the result to the first sum, thereby yielding a second sum. The service policy verifier150determines whether the second sum is smaller than the available bandwidth of the WAN under verification (step S23). This test condition is referred to as a second condition.

If the second condition is not satisfied (i.e., if “NO” at step S23), the service policy verifier150determines that some maximum bandwidth limits of primary routes are set incorrectly, thus proceeding to step S22. At step S22, the service policy verifier150enters a bandwidth setting error record to an error log before it goes to step S26, so as to indicate that there is an error in the current setup of maximum bandwidth limit of services that use the WAN under verification as their primary routes.

If, on the other hand, the second condition is satisfied (i.e., if “YES” at step S23), the service policy verifier150advances to the next step in an attempt to determine whether the minimum bandwidth limits are set correctly for secondary routes. Specifically, the service policy verifier150sums up the minimum guaranteed bandwidths of as many services as specified by a secondary route activation parameter, among those that specify the WAN under verification as their secondary routes. The service policy verifier150then adds the result to the second sum, thereby yielding a third sum. The service policy verifier150determines whether this third sum is smaller than the available bandwidth of the WAN under verification (step S24). This test condition is referred to as a third condition.

The secondary route activation parameter refers to the number of services that would use the WAN under verification in the event of as many concurrent failures in interlocation routes as specified by a simultaneous route failure parameter, among a plurality of services that specify the WAN under verification as their secondary routes while using some other WANs as their respective primary routes. The simultaneous route failure parameter represents the number of failures that could occur, in the worst case, to WANs other than the one under verification. While its default value is set to one, the operator may give a specific value of the simultaneous route failure parameter as part of the environment settings. If this is the case, the service policy verifier150automatically recalculates the secondary route activation parameter from the given value.

If the third condition is not satisfied (i.e., if “NO” at step S24), the service policy verifier150determines that some minimum guaranteed bandwidths of secondary routes are set incorrectly, thus proceeding to step S22. At step S22, the service policy verifier150enters a bandwidth setting error record to an error log before it goes to step S26, so as to indicate that there is an error in the current setup of minimum guaranteed bandwidth of services that use the WAN under verification as their aux routes.

If, on the other hand, the third condition is satisfied (i.e., if “YES” at step S24), the service policy verifier150advances to the next step in an attempt to determine whether the maximum bandwidth limits are set correctly for secondary routes. Specifically, the service policy verifier150finds a service that has the largest amount of maximum bandwidth limit, among the services that specify the WAN under verification as their secondary routes. Subsequently the service policy verifier150subtracts the minimum guaranteed bandwidth of the found service from the maximum bandwidth limit of the same and then adds the result to the third sum, thereby yielding a fourth sum. The service policy verifier150determines whether the fourth sum is smaller than the available bandwidth of the WAN under verification (step S25). This test condition is referred to as a fourth condition.

If the fourth condition is not satisfied (i.e., if “NO” at step S25), the service policy verifier150determines that some maximum bandwidth limits of secondary routes are set incorrectly, thus proceeding to step S22. At step S22, the service policy verifier150enters a bandwidth setting error record to an error log before it goes to step S26, so as to indicate that there is an error in the current setup of maximum bandwidth limit of services that use the WAN under verification as their aux routes.

If, on the other hand, the fourth condition is satisfied (i.e., if “YES” at step S25), the service policy verifier150advances to the next step to determine whether all interlocation routes have been checked. That is, it determines whether all WAN routes are checked (step S26). If there are unchecked interlocation routes (i.e., if “NO” at step S26), then the service policy verifier150returns to step S20to select a new interlocation route for verification. If all interlocation routes have been checked (i.e., if “YES” at step S26), the service policy verifier150then determines whether there is any inconsistent route setting or bandwidth setting (step S27). More specifically, it determines whether the error log contains a route setting error record or bandwidth setting error record. If either record is found in the error log (i.e., if “NO” at step S27), the service policy verifier150produces a consistency verification window to indicate the inconsistency (step S28) before concluding the present verification session. If the error log has no such records (i.e., if “YES” at step S27), the service policy verifier150successfully finishes the verification session.

Consistency Verification Result Window

FIG. 12shows a window that contains a table representing a consistency verification result. This consistency verification result window70has a table field71to show a consistency verification result table71acreated to indicate verification results of the service policy table61a. The consistency verification result table71ahas the following data fields, from left to right: “Service Name,” “Type,” “Reachability,” “Start Location,” “Bandwidth Consistency1,” “Exchange Point,” “Bandwidth Consistency2,” and “End Location.” Each row of the consistency verification result table71aforms an associated set of parameters describing a consistency verification result. Some data fields are common to the service policy table61adescribed in an earlier section. The following will focus on the data fields that are not present in the service policy table61a.

The reachability fields contains a value of “GOOD” or “NOT GOOD” to indicate the results of consistency verification steps S11to S19for each verified primary forward route, primary return route, secondary forward route, and secondary return route. The example ofFIG. 12suggests that there is an error in the current setup of a secondary return route.

The bandwidth consistency1field indicates the result of bandwidth verification steps S20to S26for each verified WAN (i.e., each verified primary forward route, primary return route, secondary forward route, and secondary return route) between a start location and an exchange point. The field contains a value of “GOOD” for bandwidth parameters with no error. In the case of an error, the field indicates the name of the erroneous bandwidth parameter. The example ofFIG. 12shows an error indication suggesting that the primary return route on the WAN22between the data center21and exchange point24has a problem with the minimum bandwidth settings of some related secondary routes. The example ofFIG. 12also shows another error indication suggesting that the secondary forward route on the WAN28between the sales branch30and exchange point25has a problem with minimum bandwidth settings of some related primary routes.

The bandwidth consistency2field indicates the result of bandwidth verification steps S20to S26for each verified WAN (i.e., each verified primary forward route, primary return route, secondary forward route, and secondary return route) between an exchange point and an end point. The field contains a value of “GOOD” for bandwidth parameters with no error. When an error exists, the field indicates the name of the erroneous bandwidth parameter. The example ofFIG. 12shows an error indication suggesting that the primary return route on the WAN28between the exchange point24and sales branch30has a problem with maximum bandwidth limit settings of some related secondary routes.FIG. 12also shows another error indication pointing out that the secondary forward route on the WAN23between the exchange point25and data center21has a problem with maximum bandwidth limit settings of some related primary routes. Such error indications in the consistency verification result table71awill help the operator to correct erroneous parameters in the service policy table61aofFIG. 8.

Command Generation

FIG. 13gives a command reference table showing how the setting commands for edge devices vary depending on vendors. The command generator160uses this table to produce commands suitable for each target edge device. Specifically, a model-1command class98, model-2command class99, and model-3command class72are produced from the interlocation service class88and service bandwidth policy class89. Appropriate commands can be produced in this way for each of the primary forward route, primary return route, secondary forward route, and secondary return route of an interlocation service.

FIG. 14is a flowchart showing how the command generator160produces a command. Specifically, the command generator160first refers to a list of services of the service class87(step S31) according to its data structure shown inFIG. 9. The command generator160then extracts an interlocation service included in one of the services (step S32). The command generator160generates a command for each of the primary forward route, primary return route, secondary forward route, and secondary return route of the extracted interlocation service (step S33to S36).

The command generator160then determines whether it has produced commands for all interlocation services (step S37). If not (i.e., if “NO” at step S37), the command generator160returns to step S32to extract another interlocation service for further command generation. If commands have been produced for all interlocation services (if “YES” at step S37), the command generator160determines whether it has produced commands for all services (step S38). If not (i.e., if “NO” at step S38), the command generator160returns to step S31to focus on another service for further command generation. If commands have been produced for all services (i.e., if “YES” at step S38), the command generator160transfers the produced commands to the command classes referenced by an edge device class according to the data structure ofFIG. 9(step S39), thus concluding the present command generation process.

Reconfiguration of Edge Devices

FIG. 15is a flowchart showing how the service policy enforcer170reconfigures edge devices. Specifically, the service policy enforcer170first refers to a list of services of the service class87(step S41) according to its data structure shown inFIG. 9. The service policy enforcer170then extracts an interlocation service included in one of the services (step S42). The extracted interlocation service involves a primary forward route, primary return route, secondary forward route, and secondary return route. The service policy enforcer170configures edge devices with those routes as a single transaction. If it fails to setup any of those routes, the service policy enforcer170cancels the settings about all the routes including those that have been successfully configured. The following will describe the process in greater detail.

The service policy enforcer170begins with determining whether the edge devices have successfully been configured for the primary forward route (step S43). If not successful (i.e., if “NO” at step S43), the service policy enforcer170moves to step S50. If successful (i.e., if “YES” at step S43), the service policy enforcer170then determines whether the edge devices have successfully been configured for the primary return route (step S44). If not successful (i.e., if “NO” at step S44), the service policy enforcer170cancel the changes made to edge devices on the primary forward route (step S45) and proceeds to step S50. If successful (i.e., if “YES” at step S44), the service policy enforcer170then determines whether the edge devices have successfully been configured for the secondary forward route (step S46). If not successful (i.e., if “NO” at step S46), the service policy enforcer170cancel the changes made to edge devices on the primary forward route and primary return route (steps S45and S47) and proceeds to step S50. If successful (i.e., if “YES” at step S46), the service policy enforcer170then determines whether the edge devices have successfully been configured for the secondary return route (step S48). If not successful (i.e., if “NO” at step S48), the service policy enforcer170cancel the changes made to edge devices on the primary forward route, primary return route, and secondary forward route (steps S45, S47, and S49) and proceeds to step S50. If successful (i.e., if “YES” at step S48), the service policy enforcer170then determines whether all interlocation services have been applied (step S50).

If there are unapplied interlocation services (i.e., if “NO” at step S50), the service policy enforcer170returns to step S42to select a new interlocation service for further policy enforcement. If all interlocation services have been applied (i.e., if “YES” at step S50), the service policy enforcer170determines whether all services have been applied (step S51). If not (i.e., if “NO” at step S51), the service policy enforcer170returns to step S41to select a new service for further policy enforcement. The process completes when all services are applied (i.e., if “YES” at step S51).

Advantages

The above sections have described a network system300according to the present embodiment. As can be seen, the service policy verifier150verifies settings of primary and secondary routes on a specific WAN by finding services that use that WAN as their primary routes or secondary routes and determining whether the sum of their guaranteed bandwidths is smaller than the WAN's available bandwidth, based on an edge device data table41a, WAN configuration table51a, and service policy table61a. The service policy verifier150verifies every WAN in this way, thus helping the network operator to determine whether each service is configured correctly in terms not only of bandwidth settings, but also of route settings.

The service policy verifier150is also designed to calculate first to fourth sums in a stepwise manner to verify the minimum guaranteed bandwidth and maximum bandwidth limit of primary routes and secondary routes individually. The results of this calculation are summarized in a consistency verification result table71afor the purpose of browsing by the operator. This feature helps him/her to identify and locate an error in the route setup and/or bandwidth setup, as well as to reconfigure the system with correct route and bandwidth parameters.

The present embodiment allows the operator to set a simultaneous route failure parameter, which enables him/her to determine whether each service can deliver an expected level of quality even if two or more interlocation routes are failed at the same time.

The present embodiment provides an edge device data table41ato collect information about edge devices, which enables the management server100to configure a wide variety of edge devices without much knowledge about their quality of service (QoS). Also the command generator160is designed to produce device-specific commands automatically, without requiring the operator to prepare a configuration file. The produced commands are applied to each edge device by the service policy enforcer170, thus eliminating the need for the operator to log in to an edge device using Telnet or other facilities.

While the above-described embodiment has a two layers of networks, the present invention is not limited to this specific type of network system. The system may have more layers. Or alternatively, the system may be configured in a star topology, which is a form of a singly-layer network.

Also, while the above-described embodiment includes only one management WAN, the present invention is not limited to that configuration. It is possible to employ two or more management servers100. It is also possible to place the management server100in the data center21.

Computer Programs

The functions of the above-described management server100are implemented as a computer application. That is, the present invention can be realized by running computer programs designed for the purpose. The programs includes a series of instructions describing what the management server100is supposed to do. A computer system executes such programs to provide the intended functions of the present invention. For the purpose of storage and distribution, the programs may be stored in a computer-readable storage medium. Suitable computer-readable storage media include magnetic storage media, optical discs, magneto-optical storage media, and solid state memory devices. Magnetic storage media include hard disk drives (HDD), flexible disks (FD), and magnetic tapes. Optical discs include digital versatile discs (DVD), DVD-RAM, compact disc read-only memory (CD-ROM), CD-Recordable (CD-R), and CD-Rewritable (CD-RW). Magneto-optical storage media include magneto-optical discs (MO).

Portable storage media, such as DVD and CD-ROM, are suitable for distribution of program products. Network-based distribution of software programs is also possible, in which case several master program files are made available on a server computer for downloading to other computers via a network. A user computer stores necessary software components in its local storage unit, which have previously been installed from a portable storage media or downloaded from a server computer. The computer executes the programs read out of the local storage unit, thereby performing the programmed functions. As an alternative way of program execution, the computer may execute programs, reading out program codes directly from a portable storage medium. Another alternative method is that the user computer dynamically downloads programs from a server computer when they are demanded and executes them upon delivery.

CONCLUSION