GB2271041A - Data network switch - Google Patents

Abstract

A data network switch for switching data between a plurality of data links comprises programmable control means (30, 31) for adapting the data switching in accordance with fulfilment of any one of a plurality of predetermined conditions, e.g. failure of, or error on, one of the data links, or a time of day. The switch uses an interpreted language (Switch Control Language, or SCL) in which each line is in the form of a task, the tasks being run simultaneously, permitting any of them to be triggered as soon as the relevant condition is fulfilled. <IMAGE>

Description

DATA NETWORK SWITCH Field of the Invention This invention relates to a data network switch, for example a network switch for use in a packet data network operating to the X.25 protocol.

Background to the Invention Network switches are generally arranged to switch packets of data from any one of the connected data links to any other according to the addresses associated with the packets. The data links may be to other network switches via, for example, leased lines or the public ISD network, to individual terminals/workstations, or to peripheral equipment such as printers. Connection to individual workstations or the like may be via a Packet Assembler/Disassembler (PAD), which typically will have up to sixteen asynchronous terminals plugged into it, and which assembles data from the terminals into packets for transmission through the network and receives packets from the network and disassembles them to route the data to the appropriate terminal. The PAD may be incorporated into a network switch to create a hybrid device, or it may be separate.References herein to "switch" shall include a PAD unless stated to the contrary.

A typical network switch will comprise several processors for different functions. For example, link processors are responsible for on-board packet switching and communicating with the main processor. Information on calls switched on-board is communicated to the main processor by the link processor. The switch can be configured for particular applications via an interface in the switch, either by a dedicated port on the switch to which a suitable device can be connected, or remotely across the X.25 network.

In either case, reconfiguration to deal with, for example, a failure in one of the data links, requires the intervention of the network manager.

Simple networks involving one or two switches, for example, generally do not justify the high cost of a network management system (NMS), with its own computer monitoring and controlling operation of the network, while large networks can give rise to such a high level of control messaging that the time taken by the NMS to process and react to these messages can significantly delay the response of the network to changing circumstances such as the failure of an individual link. As an example, a network with 200 switches might, with each switch generating one message per second, require the NMS to process 200 messages per second of all types.

Summary of the Invention The present invention provides a data network switch for switching data between a plurality of data links, the switch comprising programmable control means for adapting the data switching in accordance with fulfilment of any one of a plurality of predetermined conditions.

Preferably the programmable control means comprises a stored program defining the conditions and arranged to monitor continuously or repeatedly fulfilment of the conditions. Thus, the program is preferably of the expert system type in which, instead of each instruction in the program being operated on sequentially, the instructions operate as simultaneous tasks so that, as soon as a condition is fulfilled, associated operations are effected, subject only to any predetermined connection between those operations any others which might be running at the same time.

The programmable control means may also be arranged to transmit on one or more of the data links information relating to the operation of the switch and of the data links connected thereto, to data passing therethrough and/or to the switching of the data, and is preferably programmable to transmit the information in response to fulfilment of any one of the plurality of predetermined conditions. The information can alternatively or additionally be transmitted in response to receipt of a message, for example from a NMS.

The information may be stored for subsequent transmission.

The invention is particularly applicable to packet data networks, for example those operating under the X.25 protocol.

The switch of the invention may be used in a small network to provide flexibility of control without operator invention. For example, the effects of failure of a data link can be minimised by the switch being programmed to select an alternative link in the event of such a failure, and time-dependent switching can also be carried out, to ensure the most cost-efficient data transmission at any time of day. Information on usage of the data links, for example for accounting purposes, can be collected and transmitted to a monitoring computer. These benefits are also available in large networks, where the additional benefit is given of substantially reducing the load on the NMS, freeing it for monitoring and accounting tasks, for example.

Brief Description of the Drawinas In the drawings, which illustrate a preferred embodiment of the invention: Figure 1 is a diagram illustrating a typical network incorporating a number of switches in accordance with the invention; and Figure 2 is a block diagram of one of the switches.

Detailed Description of the Illustrated Embodiment Referring first to Figure 1, a simple X.25 network comprises three switches 10, 11 and 12, the first 10 (Switch 0) being connected to a host computer 13, and the other two 11 and 12 (Switch 1 and Switch 2) being connected via respective PADs 14 and 15 (PAD 1 and PAD 0) to endpoint devices. These may be individual terminals, computer peripherals, or LAN's. In the illustrated example, PAD 1 (14) connects in a terminal 16 and a printer 17, while PAD 0 (15) connects in two terminals 18 and 19. A larger network may be managed by a network management system (NMS) running on a computer linked into the network, but the illustrated network may not justify the additional cost.Each switch 10-12 or PAD 14 and 15 can provide the NMS, if present, with information on request relating to data transmission and the operation of the switch, for example on link type (DTE/DCE), link state (Up/Down/Off), packets received count, packet receive rate and maximum rate, bytes received count, bytes receive rate and maximum rate, packet transmitted count, packet transmit rate and maximum rate, bytes transmitted count, bytes transmit rate and maximum, active call count, and level two errors (relating to FCS, short frames, rejects received, rejects transmitted, and time outs). Various general status information can be provided, for example last reset time, empty buffer counts, calls active count, total calls since last reset, printer online, printer plugged in, and remote call active. Call status information, account messages and segment counts can also be provided by the switch.

This information is stored as necessary and transmitted to the NMS when the NMS requests it, but unsolicited information can be sent to the NMS by an individual switch concerning errors in the links, and changes of state of the links. The switches can be programmed, as hereinafter explained, to adapt the handling of data therethrough, and the collection and transmission of information, according to predetermined conditions being fulfilled. For example, different data links may be switched in and out at certain times of the day, according to data traffic density and/or link cost. Failure of a link can be handled by the attached switch, rather than the NMS having to re-route data traffic.

For example, the switch may be programmed to switch data to an alternative link if a first link fails.

Referring now to Figure 2, the switch is linked into the rest of the network via the X.25 link hardware 20, which is managed by the link management 21 and configuration management 22 modules within the device. Switching of data is controlled according to the individual packet addresses by the X.25 switching/call routing modules 23 and 24. Other features are the NMS interface 25 (if an external NMS is managing the switch) and remote management module 26 connected to the X.25 Level 3 module 27, to allow remote calls to the network management system, and the PAD management module 28 which permits connection of the PAD 29 as an internal add-on board.The switch includes, in accordance with the present invention, an additional programmable processing function comprising the Switch Control Language (SCL) configuration module 30 with the current SCL control task 31 being linked to the link management module 21, the X.25 Level 3 module 27, the NMS interface 25, and the PAD management module 28 as appropriate, according to the task being run. A Real Time Clock 32 is provided to control the operation of time-dependent tasks.

The switch contains an interpreted language by which it can be programmed by the user. - The language (Switch Control Language, or SCL) is not procedural like conventional programming languages. Instead, each line is in the form of a task, the task being run simultaneously, permitting any of them to be triggered as soon as the relevant condition, for example time or failure in a link, is fulfilled.

SCL provides a simple means to introduce bespoke features into a switch. The SCL procedures are stored in a similar way to the routing table entries in a conventional switch. However, they are not processed in the same way.

The routing table is processed sequentially - a call request is passed through the routing table directives starting at the top and working downwards (excluding jumps). Each SCL entry, by contrast, is a potentially separate task, independent of other tasks. Many can be running simultaneously, or there can be none running. The order of the entries in the table does not matter, as they are always run by name.

As well as the explicit tasks triggered within the SCL procedure table, there are also tasks that are automatically generated when particular SCL functions are executed, These are called "whens", and are "watchdog" tasks, which continually monitor something within the switch (for example the status of a particular link) and trigger another procedure when a particular condition is met.

SCL variables are integer variables that can be defined, set, incremented or decremented by SCL tasks. All variables are global; they can be read by any SCL task. SCL supports the following instructions: At, Begin, Call, Do, End call, For each, Link operation, arithMetic operation, NMS message, On error, Pause for, Transmit, Variable define, When. It will be appreciated that other instructions may be added, and that these definitions may be changed.

The At instruction will trigger the named procedure but in a quiescent state (shown as Sleeping on SCL status screens). When the specified time occurs, the procedure is woken up. This allows events to be scheduled to happen at particular times of the day. The procedure can re-schedule itself so that the same thing happens every day. At the specified time, the task will go from the sleeping state to a state PreAt, in which it waits for one minute to avoid being triggered immediately if the task re-schedules itself.

The #Begin instruction is required at the front of each procedure. It is used to name the task.

The Call instruction attempts to make an X.29 call to the specified DTE address. Call user data can be added following a dot. The call is passed through the routing table in the normal way. The call request will have no calling address; this can be added by the routing table if required. If the call is cleared, or there is no response for two minutes, the procedure is stopped. If there is an On error procedure specified, that procedure will be automatically triggered.

The Do instruction triggers another procedure into operation. If the named procedure does not exist, the procedure is stopped. If there is an On error procedure specified, that procedure will be automatically triggered.

The End instruction ends any existing call. It is not an error to attempt to end a non-existent call.

The For each instruction generates a "when" task which continually checks for event happening. When the event happens the named procedure is triggered. This type of "when" will not stop when the procedure is triggered, so the next time this event happens the task will be triggered again. There are four types of event that can be detected: A specified X.25 link going up or down; A specified DRP node number going up or down; A specified PAD port going up or down; and A specified variable reaching a particular value.

The Link operation instruction allows a specified link to be killed, stopped or restarted. The operation is a letter indicating the operation to be performed, one of K, S or R. The link number is that which is to be operated on. Thus, to kill link 05, for example, one can use LK05#.

The arithMetic operation allows SCL variables to be incremented, decremented or set.

The NMS message instruction sends an unsolicited alert message to an active NMS. The alert is sent with alert level 1. If the NMS does not have an active call to the switch, the alert message is discarded.

The On error instruction informs SCL which procedure should be triggered if the current procedure generates an error.

The Pause for instruction is used in conjunction with the Call instruction. When a call is established, the Pause for instruction pauses for time seconds for message to arrive. Case and parity of the received message are ignored.

One restriction is that the received message must be contained in one packet. If the message does not arrive within the specified time, or the call is cleared by the host, the procedure is stopped. If there is an On error procedure specified, that procedure will be automatically triggered.

The Transmit instruction is used in conjunction with the Call instruction. When a call is established, the Transmit instruction sends messaae to the host.

The Variable define instruction defines an SCL variable and assigns it a value.

The When instruction is very like the For each instruction, except that the event being looked for occurs, and the named procedure is triggered, the "when" task is automatically removed.

Thus it can be seen that there are two types of "when" task. One will continue to watch even when its particular is detected (this is called For each on the switch menu).

The other type automatically remove themselves from the task table once they have been triggered. The following examples illustrate the use of the SCL.

EXAMPLE 1 A switch has two links. One is via a 64k leased line (on link 0, say), and the other is plugged into a ISDN terminal server (on link 5). It is desired to initialise the ISDN line only if the leased line fails, since the ISDN cost is higher. Using SCL, the following three lines are defined: Bisdn,FLOODstart5- Bstart5-LR05 LK05 WLOOUstop5 Bstop5,LS05-LK05- In English, these three lines would translate to: Begin task "isdn", For each occurrence of link 00 going down, trigger procedure "start5".

Begin task "start5" Restart link 05 Kill link 05 When link 00 comes up, trigger procedure "stop5" Begin task "stop5" #Stop link 05 Kill link 05 To explain these in more detail, the first line start a "when" task operating to watch the state of link 00. When the state of link 00 goes from up to down, this "when" task will automatically trigger the procedure start5.

The second line is the procedure start5. This restarts link 5 and kills it; hopefully this should bring up the link. It also starts a new "when" which detects link 00 coming back up.. When that happens, the ISDN link is to be shut down, so the "when" triggers the procedure "stopS11.

The final procedure simply stops and kills link 5.

EXAMPLE 2 In this example, the Switch calls a particular host address to see if it is available, and if not, it then sends a message to the NMS. There are two levels at which the call can fail; the original call can clear, or the call can succeed, but the expected "Login:" prompt may not come back.

The procedure handles both eventualities using the On error directive.

Bckhost-Ofail C00001234567 Onlog-P10:Login E BfailLNCall to 00001234567 failed.

Bnlog-NCall to 00001234567 no login. E In English, these three lines translate to: #Begin task "ckhost" On error trigger task "fail" Call 00001234567 On error trigger task "nlog" Pause for 10 seconds for "Login" End the call Begin task "fail" send NMS message "Call to 00001234567 failed." Begin task "nlog" send NMS message "Call to 00001234567 no login." End the call EXAMPLE 3 This is an example of enabling links at a particular time of day. This situation might occur if extra capacity is required at particular times of the day. In this example, the extra capacity is switched in between 9 am and 5 pm.

Bisdn-A09:00start5- Bstart5;LR05LLK05LA17:00stop5r Bstop5ILS05LK0SI In English, these three lines translate as: Begin task "isdn" At 09:00 trigger task "start5" Begin task "start5" Restart link 05 Kill link 05 at 17:00 trigger procedure "stop5" Begin task "stop5" #Stop link 05 Kill link 05 It should be noted that this is also an example of disabling link 5 between 17:00 and 09:00.

Claims (10)

1. A data network switch for switching data between a plurality of data links, the switch comprising programmable control means for adapting the data switching in accordance with fulfilment of any one of a plurality of predetermined conditions.

2. A data network switch according to Claim 1, wherein the programmable control means comprises a stored program defining the conditions and arranged to monitor continuously or repeatedly fulfilment of the conditions.

3. A data network switch according to Claim 1 or 2, wherein the programmable control means is also arranged to transmit on one or more of the data links information relating to the operation of the switch and of the data links connected thereto, to data passing therethrough and/or to the switching of the data.

4. A data network switch according to Claim 3, wherein the programmable control means is programmable to transmit the information in response to fulfilment of any one of the plurality of predetermined conditions.

5. A data network switch according to Claim 3 or 4, wherein the programmable control means is arranged to transmit the information in response to a message received via one of the data links.

6. A data network switch according to Claim 3, 4 or 5, wherein the programmable control means is arranged to store the information for subsequent transmission.

7. A data network switch according to any preceding Claim, arranged to switch data in packet form.

8. A data network switch according to any preceding Claim, wherein at least one of the conditions is a time of day.

9. A data network switch according to any preceding Claim, wherein at least one of the conditions is a failure of or error on one of the data links.

10. A data network switch, substantially as described with reference to the drawings.