Method and apparatus for diagnosing problems in data communication networks

Description Submit all comments and votes

FIELD OF THE INVENTION

This invention relates to data communication network management apparatus and methods that provide a processing system for isolation, diagnosis and control of communication problems or faults in the communication link sources.

PRIOR ART

Numerous prior network link management problem diagnosis methods and devices exist in the field. These generally are designed in a manner specific to the particular physical devices that make up the data communication links. In telephone systems in general, loop back signals may be transmitted from a controlling node to the various elements making up the communciation link to a target node, and signals may be propagated down the communication link to be looped back by devices in the line which are operating correctly and which can respond to the loop back commands to the control node. Such processes are, however, totally inappropriate when the data communication network devices operate under differing protocols, are supplied by different vendors and have differing diagnostic or data providing capabilities.

More sophisticated techniques are also in existence where the data communication network contains devices supplied by the vendors of the host data node or control node systems. For example, the IBM Corporation markets components for a data communication system including host system mainframe computers, operator control consoles and communication network control program applications that can communicate with and diagnose problems occurring in a data communication network that includes IBM supplied modems, multiplexers, switches and the like. However, these systems share a common system architecture and communication protocol and are thus amenable to a single diagnostic application program and protocol. They avoid the difficulty encountered as mentioned above, with numerous protocols and numerous physical devices supplied by diverse vendors. Such uniform systems are, however, not often achieved and in many networks constructed by users and purchasers of various components, such uniformity cannot be brought about without major reinvestment.

It is therefore desirable that some method and system apparatus be provided that is capable of accommodating the more usually encountered data communication networks which are constructed of multiple layers of various vendors' physical devices having diverse capabilities and communication protocols.

OBJECTS OF THE INVENTION

It is an object of this invention to provide an improved method and apparatus for isolating and diagnosing problems in data communication networks. It is furthr an object to provide an improved diagnostic system in which the controlling node may issue generic problem determination requests to an intermediate translation facility having access to data concerning the physical configuration and characteristics of the network components which comprise a link to an identified target node experiencing a problem, and which intermediate facility can translate the generic and non-device-specific requests for diagnoses into device-specific commands addressed to particular devices in the link and which can receive from such devices specific responses which may be retranslated back into generic problem determination responses to the requesting host operator or control program.

BRIEF SUMMARY

The foregoing and still other objects not specifically enumerated are provided by the present invention in an architecturally designed system utilizing a novel communications technique. The system comprise a host or operator that is responsible for generating generic control or problem determination diagnostic requests. These requests are issued in their generic form in a non-device-specific format. The data communications system contains an intermediate control and translation facility that intercepts the generic problem determination requests from the operator or user system. The translation facility has access to physical configuration data files that constitute a network map and contain information for each link under the translation control's responsibility. This identifies, for each physical device constituting each communication link within its purview, the salient characteristics thereof including the, communication protocol requirements, capabilities and physical location or addresses for each such device. The translation control facility accesses these data files for an identified target node and link in response to a generic request from the host operator or user system. It then issues one or more device-specific addressed problem isolation, determination or control commands onto the communication link. It receives device-specific responses from devices which it is capable of accessing utilizing the information from the physical configuration data base. This intermediate translation and control facility then may issue still further commands to specific physical devices until the problem situation has been isolated and identified (and perhaps resolved by implementation of an avoidance technique such as switching to another communication link) and it retranslates the results into generic non-device-specific problem determination results which are responsive to the original generic request from the host operator or application. It transmits these non-device-specific generic responses back to the requester. The responses identify the source of the problem and indicate to the system operator or control program which measures have been taken or need to be taken to recover from the problem situation.

BRIEF DESCRIPTION OF DRAWINGS

The invention will be described with respect to a preferred embodiment thereof which is further illustrated and described in the drawings in which:

FIG. 1 illustrates a schematic data communication system or network constructed in accordance with the present invention as a preferred embodiment thereof.

FIG. 2 illustrates the conceptual definition of physical link connections and physical link connection segments as components linking a using node to a target node or station.

FIG. 3 illustrates schematically the logical conception of a communications link together with the physical reality of a specific communications link in its conceptual form.

FIG. 4 is a schematic layout showing how FIGS. 4A through 4C are to be assembled to create a single drawing.

FIGS. 4A-4C are a problem determination example flow chart assembled as shown in FIG. 4 showing how the intermediate translation facility organizes the diagnostic processes and communications with the various link components with on LCSM and static connections.

FIG. 5 is a schematic layout showing how FIGS. 5A-5C are to be assembled together into a single drawing.

FIGS. 5A-5C illustrate a portion of another diagnostic flow chart example with on LCSM and dynamic and static connections.

FIG 6 is a schematic layout showing how FIGS. 6A-6C are to be assembled together into a single drawing.

FIGS. 6A-6C illustrate yet another diagnostic flow chart example with two LCSMs and dynamic and static connections.

FIG. 7 illustrates an example of nested or layered multiple intermediate control and diagnostic facilities in a layered network.

FIG. 8 illustrates multiple diagnostic and control facilities interconnected in a peer network configuration.

FIG. 9 illustrates schematically a generic request or response message format.

DETAILED SPECIFICATION

The present invention provides a method and apparatus for allowing a data communication system or network operator or even an automated applications program running in the host or control system to provide problem determination and management in the physical computer data communcations links and connections. The method devised does not require that the system operator "understand" the physical components that make up the communication link connections in the system. By "understand", it is meant that neither the system physical component types or identities that make up a given communications link nor the specific commands, formats or responses that the components are capable of receiving or providing need be known to the operator or to the diagnostic applications program.

The invention is conceptually and schematically illustrated in FIG. 1.

By way of introduction to some unique terminology and to provide an understanding of the basic concepts of the invention as applied to this system, FIG. 1 illustrates a user system 1. The user system 1 is the communication system operator or application program which is the source of generic problem determination and control requests. The generic requests are issued as non-device-specific inquiries or requests over a communication path 2 that could be a tightly coupled on-site cable link between the control console or an internal link between the control program and an intermediate service system 3 or it could be a communications link to a remote service system. The interconnecting link is shown generally as 2 and carries generic, non-device-specific inquiries or requests and resulting responses from the service system 3.

Service system 3 provides an intermediate control and translation facility and will generally be in the form of a program which is executed to provide specific diagnostic processes as will be described in greater detail later. The service system is associated with a physical network configuration data file or manager that contains, in effect, a network configuration map. This is shown as block 4. Block 4 contains the associated particular device data indicating the physical connections making up various links under the purview of the serice system 3, the specific physical device identities, capabilities for diagnoses, communication protocols and formats and the like. This information is used by the service system 3 to generate device-specific requests and inquiries into the communication network shown as various logical link 5 in FIG. 1. These are generally addressed, device-specific commands that are generated and sent to diagnose the condition of a given physical communication link by diagnosing its component parts in serial fashion from the end nearest the service system 3. A particular using node A is identified as numeral 6 within the overall communications link 8 which links the using node 6 with a target station 7. Overall, the node 6, the station 7 and the interconnecting communication link may be comprised of many components and constitute a "target system" for which problem diagnosis and control is desired in the context of the present invention.

Specific names have been given to the user system, service system and target system in the context in this invention. The architectural design of the preferred embodiment of the invention as shown in FIG. 1 has components that will now be identified in greater detail. The service system is constituted by a Link Connection Subsystem Manager hereinafter LCSM. The LCSM 3 in FIG. 1 has access to configuration data obtained and managed by another program or facility in files of information identified as the Link Connection Configuration Manager (hereinafter LCCM). The physical link connection components linking a using node 6 to a target node 7 and which make up the communications link 8 between the two are known as Link Connection Components (hereinafter LCCs).

FIG. 1 illustrates the basic scheme, architectural design and logical flow of the preferred embodiment of the invention. In general, the user system, i.e., the host system control operator or control program needs to be able to send diagnostic requests to and receive responses from the communications facility to get information about the logical link connections 8 without having to "understand" what the specific physical link connection components may be, what their inter-connection paths may be, or what their various requirements, capabilities and protocols may be.

In the invention, the service system, the LCSM 3, receives generic problem determination or control requests from the user system 1. In response, it accesses the configuraiton data base to determine the present physical configuration of the specific link to the target system node or station for which problem determination has been requested. The service system, the LCSM 3, does this by a generic request to the LCCM 4. The service system then is armed with a device-specific data and the physical network configuration and interconnection identifications that show the physical components making up a given communications link. LCSM 3 is then enabled to issue device-specific commands in series to the LCCs making up the given link for which problem determination is required. The LCSM 3 generates appropriate device-specific diagnostic and control commands to be sent to the physical target system devices serially to analyze their condition and to analyze the data responses returned from the LCCs. In response to any device-specific replies, the LCSM 3 generates either additional inquiries and/or, finally, generates the response to the user system 1 in the form of a generic non-device-specific problem determination message.

As alluded to earlier, target system link connections may be made up of multiple layers, herein called link subsystems, comprising various types of physical devices, device capabilities, and communication protocols all of which are usually provided by diverse vendors. As information and data communication networks of the type shown in FIG. 1 are constructed by users, they generally grow to support multiple protocols including IBM system standard SNA and non-SNA protocols. These systems usually contain multiple logical networks and may incorporate one or more physical networks. The data communications networks so constructed not only provide for the transportation of data in the normal systems today, but they may also include analog or voice information which has been suitably digitized for communications and control purposes. These factors all compound the problem of diagnosis for any specific problem isolation in the network, and particularly for isolating faulty components in a given link.

The invention describes an architectural structure and system method of operation that allows support of both SNA and non-SNA hierarchically nested or peer connected networks. The architectural structure design allows functions such as the service system function, the user system function or the target system function to be interconnected, distributed throughout the network in various components and/or nested in layered interconnections. The specific choice of placement for a given function within the structure is dependent upon the level of support, i.e., problem detection analysis or determination, that is to be implemented. The invention provides a consistent view of the link connection subsystems that allows effective problem determination and link fault recovery processes to be performed by the operator or control program for individual link components without the control program or operator being required to know what the specific link components or their characteristics actually are.

As noted above, the major problem with user constructed systems is that of providing effective problem determination in multi-layer, multi-vendor, multi-protocol communication networks. The end user usually is the first person to notice that there is a problem somewhere in the network, but the user usually waits for a period of time before calling the network operator for assistance. The reaction times of the end user and of the system operator account for a large part of lost system availability. Once it has been determined that a problem does exist, then some form of problem determination procedure must be performed in order to determine which physical device is at fault and what physical device recovery procedure should be employed to provide the fastest restoration of service to the end user. In the simplest form, this may be merely a matter of discovering which device is faulty so that it may be replaced or so that its particular vendor may be called for service. In the present day environment, these procedures are manually performed and may be disruptive to the communications link not only to the end user but to any intermediate system components.

The problem grows even more complex as communication network users migrate from separate physical network for voice and data into integrated physical networks for handling both voice and data. The problem grows significantly more complex as users also add higher functional components such as Time Division Multiplexers, Statistical Multiplexers, Protocol Converters, Front End Line Switches and the like. These diverse physical components create their own complex sources of problems and compound the difficulty of isolating a fault within the communications link in which they are used. They also create additional layers of complexity in the network. Such physical devices and the resulting complex communications link may provide many misleading conclusions if the specific idiosyncracies of the various devices present in a given physical link are not taken into consideration during analysis of the falling conditions. In the architectural system shown in FIG. 1, the LCSM 3 implements a diagnostic process that allows support of SNA and non-SNA hierarchical and peer connected networks. It allows functions to be distributed and/or nested within the network itself and permits programs or system operators to access link subsystem physical data for performing problem determination and/or to effect operational changes. Each subsystem has its own LCSM 3 responsible for the subsystem's unique problem determination and probable cause analyses for the physical devices constituting the subsystem. The knowledge of what the physical link configuration comprises gives to the LCSM-3 the ability to send diagnostic or control requests to other subsystem managers and also provides the operators access to all of the components in the link connection.

Management of the link connection requires its own hierarchical structure for commands and data flow. This structure is shown conceptually in FIG. 2. The physical link connection components 10 are the LCCs, LCC-1 through LCC-4, shown in FIG. 2. Together, LCCs form physical link segments 9 between each LCC and the next LCC, node or station. The segments 9 provide the overall physical link 8 connection between a using node 6 and a target station 7. The logical SNA view of the link 8 does not always reflect the fact that physical and hierarchical structural changes may occur or that various physical devices actually exist to make up the physical link segments 9.

The logical structure utilized in the invention is shown in FIG. 2. The actual physical link 8 is the connection of components that a user has assembled forming the logical link between two stations 6 and 7. In FIG. 2, the using node A and station B could be SNA or non-SNA nodes. Both node A and station B contain a station that wishes to communicate to the other through the link connection 8. The link connection 8 is composed of some arbitrary number of physical connection components. Each of the physical components 10 is referred to as a Link Connection Component LCC. Each LCC receives signals on its physical interconnection to the link and then passes them to another LCC or eventually to a node. The LCC is the smallest addressable element in the link connection 8. It can sometimes be addressed through a data link protocol of general usage or may require a specialized format. The addressability allows the subsystem manager LCSM 3 in FIG. 1 to address each LCC 10 using the correct protocol and physical capabilities that it has learned from the data stored in the LCCM 4. The LCSM may then send requests for data to specific LCCs 10 in a format or protocol understandable to them. It can then receive the responses from the LCCs 10 and interpret them.

The communication path segment connecting two LCCs 10 is identified as a link segment 9 in FIG. 2. Each link segment 9 is a portion of a communication path that may include copper wire, coaxial cable, optical fiber, microwave links or other satellite or radio communication components. In addition, a link segment 9 may contain even other LCCs 10 and other link segments 9. The definition thus given is generic. For example, in FIG. 2 there is a link segment between LCC-1 and LCC-3 that contains two smaller segments interconnecting LCC-1 to LCC-2 and LCC-2 to LCC-3. Each LCC reports to an assigned link connection subsystem manager, LCSM 3. An LCSM 3 is thus responsible for one or more specific LCCs and therefore is in control of the link segments therebetween. An LCSM 3 may address its assigned collection of link connection components 10 and is responsible for the management of the components themselves. The collection of components addressed by an LCSM 3 is referred to as the link subsystem for logical analysis.

A detailed description of a preferred embodiment together with the steps utilized in the method of operation of preferred embodiment will now be given together with detailed descriptions of the various processes employed and an identification of which devices within the physical network they are employed. The functions performed by each process in the link connection that services the operation of the link and which aid in link problem determination and eventual recovery will be described now.

The specific components that are described include the nodes A and B which use the link, each of the LCCs 10 that make up the link interconnections, the LCSM 3 and the LCCM 4.

A typical using node 6 as shown in FIG. 1 may be a communications controller or a communications system having an integrated communications adapter. Either type of device incorporates program controlled self-diagnostic capabilities for determining whether the node itself is the cause of a problem or whether the problem is in the communications link attached to it. A node 6 is assigned the responsibility for detecting link connection problems. This is usually accomplished by inference from the node 6's inability to send or receive or by the detection of an extensive number of retransmissions being required on that link. The using node 6 has two functions to perform in the event a problem is detected. First, node 6 must perform an elementary probable cause analysis of each problem to determine whether the problem is due to a failure in the node itself or whether it lies in the link connection. When a failure is discovered within the node itself, then the node runs its own internal diagnostic routines to isolate the problem for reporting. An improperly functioning communications adapter, i.e., a line driver, internal modem or the like, might be found in such a test. When the problem is not within the node 6 itself, it is assumed to lie somewhere within the link connection components attached to the node. The node then reports this link connection failure to the link connection subsystem manager, LCSM 3. Systems and devices of this type that comprise a using node 6 as just discussed are in common usage today. An IBM 3725 communications controller is a typical example of a system that is capable of diagnosing faults in itself and/or of identifying the fact that the fault is not within iteself but lies within the communication link connection. These devices have the capability of reporting an error condition to an LCSM 3 together with any associated data that is normally maintained such as traffic counts, error counts and adapter interface status conditions that may be reported.

It is the responsibility of the LCSM when notified of a problem by a node 6, to learn what the communications link connection configuration is for a given communications link between node 6 and node 7 such as in FIG. 1. This information will be obtained from the LCCM 4 as will be described later.

The LCSM 3 is responsible for managing its assigned link subsystems for a given link connection or set of link connections. LCSM 3 receives notification of potential problems from using nodes such as node 6 in FIG. 1. It receives any unique data from the link LCCs 10 that may be forwarded to it by the node 6. The LCSM 3 is the component in the system that must send commands eventually to the LCCs 10 and which receives their responses. The LCSM obtains from the LCCM 4 the present connection configuration identifying the elements in the given communication link together with the addresses of the individual LCCs 10 with which it will communicate. The LCSM does not contain the configuration map of the entire link connection.

The LCSM receives commands or inquiries from and responds to requests for tests to be performed from the user system or operator 1 in the form of generic requests 2 as shown in FIG. 1. The requests from the operator 1 will be directed to a given LCSM in response to indication of a problem being reported from a given node 6 which will be relayed to the operator and displayed on a screen. The operator will determine which LCSM 3 has been assigned the management function for determining problems within the identified links connected to the node 6. The operator will issue a generic problem determination request to the LCSM 3 that is assigned to managing a given communications link and will identify the target node 7 for problem determination.

The LCSM 3, in response to these generic requests, will query the LCCM 4 tp determine the communications link configurations and addresses of devices constituting the link. It will also determine what the appropriate protocol or communication method is for each identified specific LCC 10. The LCSM 3 will then generate a sequential series of inquiries to implement testing of the communications link between nodes 6 and 7 by serially issuing diagnostic commands to the individual LCCs 10 in turn. It will eventually report either that a failure has been detected and isolated to a specific LCC 10 or that a failure has been detected or has not been isolated to a specific component or that no trouble has indeed been found.

The LCSM 3 will return a response to the operator or using system 1 in the form of a generic response that has been translated from the device specific responses received from the LCCs 10. It may indicate that a particular problem has been isolated by a performed probable cause analysis routine which isolates the error condition to a specific LCC 10 or to a connection to a specific component within its sphere of knowledge. The report to the operator or system management program may be employed for further analysis or possible rerouting of traffic to bypass a failed element. The information may be used directly by the operator or may possibly be routed to a higher network management application program for further analysis. Because of its limited capabilities, the LCSM 3 is not expected to determine the probable causes of error for the entire link connection that may exist but only for its own assigned LCCS 10. Other LCSMs may be involved in determining probable cause error conditions for still other LCCs in a given communications link between two nodes and the user system or host operator 1 must be able to send requests for tests to multiple LCSMs 3 in such a system configuration in order to determine fully what problem is occurring and which element is responsible.

The LCCs 10 typically may be protocol converters, computerized branch exchanges, time division multiplexers, modems, statistical multiplexers, front end line switches, local area network controllers and the like. Each link connection component 10 will perform specific functions that it is capable of carrying out at the physical link layer that it represents. These functions, which in turn give rise to the customary names of the LCCs themselves, include: digital to analog signal conversion, typically performed by modems; line multiplexing, normally performed by multiplexors or some switching systems; and other functions that effect the physical data transmission layer. Each LCC 10 monitors its own operational condition for its own link segment. At the occurrence of failures, the LCC 10 affected may initiate various tests to determine the causes of failure or it may merely record them for later analysis by another entity. A given LCC 10 may, if it is so enabled by its construction, attempt a recovery action when a problem is detected by initiating internal self-tests and/or by notifying its neighbors of a problem. It may participate with its neighbors in problem determination procedures which may include performing wrap tests or line analysis tests such as those carried out typically by some "intelligent" modems. Each LCC 10 must be able to execute and respond to diagnostic commands received from its assigned managing LCSM 3. The commands may cause functions to be performed such as self-testing, status checking at interfaces, and collection of various operating parameter settings for the individual devices. The specific commands that may be received from the LCSM 3 will, of course, necessarily be in the proper format and/or protocol required by the LCC 10. Since various LCCs have differing capabilities and may implement different command functions and responses, the physical configuration of the individual links between nodes served by a given LCSM 3 are maintained in the LCCM 4.

An effective physical "map" of a given communications subsystem has a set of links and link segments, together with identification of each of the LCCs making up the link, the unique characteristics and requirements of each of the LCCs, their addresses, and their diagnostic capabilities. All this data may be entered manually into files of data maintained by the LCCM 4 for later retrieval and response to inquiries.

An example of how the LCCM 4 can gather dynamic configuration data is the IBM 3174 controller using the Network Asset Management function. The IBM 3174 Network Asset Management works as follows. When a device attached to the 3174 powers-on, it automatically passes machine type, model and serial number to the 3174. Thi