WO2007102145A1

WO2007102145A1 - Distributed networks and utilization of centralized redundancy

Info

Publication number: WO2007102145A1
Application number: PCT/IL2007/000280
Authority: WO
Inventors: Daniel Alon
Original assignee: Enure Networks Ltd.
Priority date: 2006-03-06
Filing date: 2007-03-06
Publication date: 2007-09-13

Abstract

In a network architecture comprising edge networks and centralized resources having redundancy, apparatus for location at an edge network comprising: a local monitoring unit for determining whether operation of the edge network is within a predetermined specification; an interruption unit for determining whether operation of the edge network is undergoing an interruption; and an invocation unit for i) inferring that if the edge network is operational with said predetermined specification and is simultaneously undergoing an interruption then a centralized resource is not sufficiently responsive, and ii) following such an inference, invoking redundancy of the resource. Thus for example a remote mail server may be exchanged for a redundant mail server by changing the server address in the mail client of the edge network.

Description

DISTRIBUTED NETWORKS AND UTILIZATION OF CENTRALIZED

REDUNDANCY

FIELD AND BACKGROUND OF THE INVENTION

The present invention relates to an architecture involving edge networks and a distribution of network resources including centralized resources with redundancy, and methods and an apparatus for invoking that centralized redundancy.

Central facilities of service provider networks, such as broadband, ISP or data networks, are subject to occasional failures due to many possible causes: DDoS (Distributed Denial of Service), technical failures, maintenance routines, natural disasters, sabotage etc. With large-scale networks, it is sometimes close to impossible to invoke the common robustness-engineering technique of redundancy, such as moving to an alternate server, as it might include the need to re-program parameters at each and every user (e.g., 100,000's of broadband users); or sometimes to massively refresh data at the user premises data such as a DNS address or the address of the SMTP server. Such an operation would be difficult at the best of times but would entail adding a huge load on the already stretched network specifically during a malfunction.

Modern technologies for automated operation of edge networks, such as home networks, as presented for example by Enure Networks, make it possible to ensure that the edge network (e.g., a home network) is technically sound. However such systems do not go beyond the edge network.

Furthermore, central facilities of service providers are required to have very high reliability and availability, in order to ensure service continuity. Disruption of service, such as disruption of broadband service, entails high financial costs, customer dissatisfaction and loss ("churn"), and reputation loss. Service providers go to great lengths to ensure service continuity. For example, service providers install redundant devices, which are engaged automatically into service when interruption is sensed in the currently active device. For example, a Domain Name Server (DNS), used for resolution of internet addresses, may go down prohibiting Internet browsing by home users. In such an event an alternate DNS server can be pressed into service, preserving service. Typically, home routers store two (2) DNS addresses to support such redundancy.

Other methods for service continuity assurance include elaborate Operation Support Systems (OSS) that automate problem handling and isolation in core networks. Such is distinct from edge networks, where OSS typically cannot reach.

Also centralized Network Management Systems (NMS) are provided by leading vendors such as IBM and HP. Specific tools for applications such as root cause analysis are available for use to find out why problems occur and ensure that the cause is dealt with, and finally there is the solution of putting large amounts of extra capacity in the core network to overcome load swings or partial failures, etc.

However, with all their sophistication and related investment requirments, such tools have limitations that can result in service interruptions. For example, even large overcapacity of a fully redundant network can be overwhelmed by a deliberate DDoS attack. Furthermore, natural disasters such as hurricane-related flooding may invoke loss of power or physical damage of facilities. All systems require maintenance and upgrading, and even the best teams may err, override redundancy and other fail-safe means and create failures while for example performing routine maintenance.

Typically, when such an interruption occurs, the end user (single home computer or home network) has no way of knowing whether the interruption that he experiences is caused by failure in the local network or computer, or is caused by a problem that resides within the ISP's network etc.

If the home network does not know where the problem is, then it cannot invoke any action on its own to deal with the problem, and the solution therefore remains with the central facilities. However, as noted, their ability to deal with the interruption has limitations.

There is thus a widely recognized need for, and it would be highly advantageous to have, a way of overcoming network interruptions which is devoid of the above limitations. SUMMARY OF THE INVENTION

According to one aspect of the present invention there is provided in a network architecture comprising edge networks and centralized resources having redundancy, apparatus for location at an edge network comprising: at least one local monitoring unit for determining whether operation of the edge network is within a predetermined specification; at least one interruption unit for determining whether operation of the edge network is undergoing an interruption; and and at least one invocation unit, associated with the interruption unit and the local monitoring unit for i) inferring that if the edge network is operational with said predetermined specification and is simultaneously undergoing an interruption then a centralized resource is not sufficiently responsive, and ii) following such inferring, invoking redundancy of said not sufficiently responsive resource.

According to a second aspect of the present invention there is provided, in a network architecture comprising edge networks and centralized resources having redundancy, a method comprising: determining whether operation of the edge network is within a predetermined specification; determining whether operation of the edge network is undergoing an interruption; inferring that if the edge network is operational with said predetermined specification and is simultaneously undergoing an interruption then a centralized resource is not sufficiently responsive, and following such inferring, invoking redundancy of said not sufficiently responsive resource.

According to a third aspect of the present invention there is provided, in a network architecture comprising edge networks and centralized resources having redundancy, apparatus for location at an edge network comprising: at least one local managing unit for managing said edge network; at least one support server monitoring unit, associated with said managing unit for monitoring a message space at a support server for messages indicating a redirection instruction to an alternative resource, wherein said local managing unit is configured with an invocation function for invoking said alternative resource according to said retrieved message.

According to a fourth aspect of the present invention there is provided, in a network architecture comprising edge networks and centralized resources having redundancy, apparatus for location at an edge network comprising: at least one local managing unit for managing said edge network; at least one message monitoring unit, associated with said managing unit for monitoring for messages indicating a redirection instruction to an alternative resource, wherein said local managing unit is configured with an invocation function for invoking said alternative resource according to said retrieved message.

Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention belongs. The materials, methods, and examples provided herein are illustrative only and not intended to be limiting.

Implementation of the method and system of the present invention involves performing or completing certain selected tasks or steps manually, automatically, or a combination thereof. Moreover, according to actual instrumentation and equipment of preferred embodiments of the method and system of the present invention, several selected steps could be implemented by hardware or by software on any operating system of any firmware or a combination thereof. For example, as hardware, selected steps of the invention could be implemented as a chip or a circuit. As software, selected steps of the invention could be implemented as a plurality of software instructions being executed by a computer using any suitable operating system. In any case, selected steps of the method and system of the invention could be described as being performed by a data processor, such as a computing platform for executing a plurality of instructions.

BRIEF DESCRIPTION OF THE DRAWINGS

The invention is herein described, by way of example only, with reference to the accompanying drawings. With specific reference now to the drawings in detail, it is stressed that the particulars shown are by way of example and for purposes of illustrative discussion of the preferred embodiments of the present invention only, and are presented in order to provide what is believed to be the most useful and readily understood description of the principles and conceptual aspects of the invention. In this regard, no attempt is made to show structural details of the invention in more detail than is necessary for a fundamental understanding of the invention, the description taken with the drawings making apparent to those skilled in the art how the several forms of the invention may be embodied in practice.

In the drawings:

Fig. 1 is a simplified diagram showing central resources with redundancy and an edge network with an automated home network operation system (AHNOS), having the ability to switch to the redundancy according to a first preferred embodiment of the present invention;

Fig. 2 is a simplified diagram illustrating the embodiment of Fig. 1 further comprising additional edge networks and an AHNOS support server with a provider interface.

Fig. 3 is a simplified flow chart illustrating a method according to a preferred embodiment of the present invention.

Fig. 4 is another simplified flow chart showing a method of solving failures in DNS resolution, according to a preferred embodiment of the present invention. Fig. 5 is another simplified flow chart showing a method for solving failures in

SMTP email operations according to a preferred embodiment of the present invention.

DESCRIPTION OF THE PREFERRED EMBODIMENTS The present embodiments provide distributed invocation of centralized redundancy. The centralized failure is detected by the distributed systems and configuration in order to use the redundancy is handled locally. Indeed operation of the redundant central resource may be invoked by the customer network edge equipment. In one embodiment service failures or slowdowns by the centralized resources are actively detected. In another embodiment the edge networks poll a support server for notifications about reconfiguration of the central facilities. A third embodiment combines the two systems. A notification system via a support server is used to notify regarding expected or known interruptions, and active detection is used as a backup to cover unexpected breakdowns. A procedure is then entered for reconfiguring the edge apparatus to use the previously redundant facilities, or the user may be notified.

As explained in the introduction, it is generally not possible for invocation of centralized redundancy to be carried out at the edge networks because there is nothing at the conventional edge network that can tell whether an experienced interruption of service is due to local or central problems. Applicant's co-pending US Patent Application No. 11/349,116, filed February 8, 2006, the contents of which are hereby incorporated by reference, teach a device for use at the edge network which monitors healthy operation, that is operation within the confines of the expected protocols at the edge network. Provided that such facilities exist at the edge equipment, it is possible to determine whether or not the failure is local. If there is no local failure and there is still an interruption then the problem can be presumed to be central. In case of such a presumption of centralized service interruption or deterioration, it is then possible to invoke a pre-arranged procedure for redundancy invocation at the central service provider facility, such as moving to a redundant server or collecting instructions from a pre-defined address for handling of the problem. The device of the above-mentioned co-pending application is designed to carry out recovery procedures in the event of unexpected behavior at the edge facilities and can easily be modified to carry out such a pre-arranged procedure for redundancy invocation. For example a DDoS attack on the ISP DNS servers can be handled by having the edge network software identify a problem with address resolution, determine that the edge network is itself sound, and then invoke a procedure for redirecting future DNS requests to an alternate DNS server. Such a solution prevents or reduces perceived service interruption at the edge network, such as suspension of browsing, and furthermore gives the ISP central facility staff precious time to repel the attack with no apparent damage.

The present embodiments generally pertain to home communication or edge network configuration. The above-mentioned co-pending application relates to apparatus for handling network malfunctions at the edge network, repairing bad configurations and changing the way the network currently works. The apparatus provides a method that enables the configuration of home network components by supervisory components at the home network. If necessary, the configuration utilizes assistance from support elements placed on a server at the provider premises, which server is in communication with the apparatus at the edge network. Either way the configuration is automatic and there is no need to gain control of the home network or to carry out the kinds of refreshes of data at the home network that must be initiated by the central service provider facility. The configuration itself is performed by client software placed at the customer premises, possibly in the form of a supervisory layer, but the trigger for a new configuration operation and the data to configure can be set either at the home (edge) -based software or at the server in the provider premises.

Configuration of home network elements is the kind of operation that the supervisory elements are designed for, and thus reconfigurations to redirect communications to redundant resources are a task that can be assigned to such elements. On the other hand it is noted that the issue of distributed invocation of centralized redundancy applies not only to common central facilities such as the above-referred to DNS servers, but may also apply to the centrally located provider's support server. While the present disclosure teaches a possible embodiment of home networks linked to a central facility of a service provider, the invention is equally applicable to other types of edge networks, such as networks in business environments, wireless etc. Other applications such as planned activities of the service provider, interactive messaging etc can also be utilized. As explained above, the preferred embodiments require some form of monitoring at the edge network. An example of such monitoring is an Automated Home Networking Operation System (henceforth AHNOS) working at the customer premises, which includes the above supervisory elements, keeps the home network fully functioning and has an ability to follow pre-defined routines, either invoked locally or triggered by an understanding of a message on or from a centrally located message server. An embodiment of AHNOS is provided by Enure Networks (8 Hasadnaut St., Hertzelya, P.O.Box 12694, 46733, Israel), specifically Enure's network automatic operation client, as described and claimed in the above-mentioned copending application. The principles and operation of an apparatus and method according to the present invention may be better understood with reference to the drawings and accompanying description. δ

Before explaining at least one embodiment of the invention in detail, it is to be understood that the invention is not limited in its application to the details of construction and the arrangement of the components set forth in the following description or illustrated in the drawings. The invention is capable of other embodiments or of being practiced or carried out in various ways. Also, it is to be understood that the phraseology and terminology employed herein is for the purpose of description and should not be regarded as limiting.

Reference is now made to Fig. 1 which illustrates a network architecture 10 comprising edge networks 12 and centralized resources 14 having redundancy 16. In general resource 14 is used. In the event of failure or overload at resource 14, resource 16 can be used in its place, but the edge network needs to know where to address its requests.

Edge network 12 includes a local monitoring unit 18 which determines whether operation of the edge network is within a predetermined specification. The local monitoring unit may be part of the AHNOS 19 referred to above. In a preferred embodiment, local monitoring unit 18 provides a supervising layer that monitors the individual network devices to make sure that each device is currently operating within the specifications of its own protocol.

Additionally provided within the framework of the AHNOS is an interruption unit 20, which determines whether operation of the edge network is undergoing an interruption. The interruption unit may be separate from the local monitoring unit 18 or may be incorporated therein. The interruption unit does not concern itself with protocol specifications but simply notes whether particular protocol services such as DNS requests are being dealt with and if so with what sort of delay. If it seems that service is being unduly delayed then interruption unit 20 signals that all is not well.

An invocation unit 22 is connected to the interruption 20 and local monitoring 18 units. Its task is to determine whether the interruption signaled by the interruption unit is due to local or external causes. If the problem is local then the supervisory layer typically takes care of the problem, possibly with help from external resources. If however the problem is external then the invocation unit invokes the parallel redundancy 16. Parallel redundancy may be invoked simply by replacing target IP addresses at strategic locations in local communication apparatus, and a procedure for such replacement of IP addresses is thus preferably provided. In this way the edge network automatically communicates with the redundant resources in the face of problems at the central network without any intervention of the central resources.

In one embodiment the new IP address is already known at the edge equipment and is simply exchanged with the currently active address. In another embodiment the server supporting the local supervisory layer supplies the IP address when needed through a notification. In a yet further embodiment the server supporting the local supervisory layer always has a valid backup IP address at a predetermined location which is consulted as needed by the edge equipment.

The invocation unit 22 knows, from the supervisory layer, if the edge network is operational. It also knows if regular service is being obtained from central facilities. If the edge network is operational and service is being received then all is well. If the edge network is not functioning correctly and no service is being received then it is inferred that the problem is at the edge network and no invocation is needed.

If the edge network is functioning correctly and service is not being received or is not satisfactory, then it is inferred that the central facilities are in trouble and redundant facilities are looked for via the invocation procedure.

Reference is now made to Fig. 2 which shows in more detail an AHNOS supported by a centralized server and modified for use with the present embodiments. First edge network 30 has no AHNOS. Second edge network 32 includes AHNOS 34 which may be supported by AHNOS support server 36. AHNOS support server 36 comprises a provider interface 38 to allow a service provider to enter configuration data. The modified system thus comprises a mechanism that uses two components:

An AHNOS 34, or AHNOS client,

An AHNOS support server 36 that holds messages in a format or according to a protocol that the AHNOS may understand. Thus the server may be for instance, an HTTP server, holding messages in a way that is available to HTTP. Alternatively, information may be held locally by the AHNOS, as explained above.

The server 36 holds messages from the provider to the AHNOS, in a well known format, such as HTTP. Interface 38 for addition and maintenance of such messages may be provided if necessary. Interface 38 may be implemented as a user- friendly interface for use by a non specialist provider, say at a call center,

Each AHNOS client 34 has a component that has the ability to process such messages and understands how to execute each message it receives from the server. Thus a message to turn to a new DNS server may invoke a procedure to replace the IP address for DNS lookup requests. As an alternative the AHNOS client 34 may have , the necessary data to invoke the procedures described henceforth. That is to say the client may itself store a backup IP address for use in the replacement procedure. . In the lookup embodiment, each AHNOS client 34 checks for new messages upon any or each of the following triggers:

When certain failures or malfunctions occur and are detected at the edge network.

When a predefined period of time elapses (henceforth server polling rate). In the event of a known failure at the provider premises, say the provider main server 14 has failed, or in the case of reprogramming or reconfiguration at the main server, which could involve extensive changes the provider may carry out, all that is required is for a suitable redirection message to be provided at server 36. Then all the AHNOS clients 34 simply poll server 36 and they are able to invoke their redirection procedures to automatically utilize any redundancy provision and move from server 14 to server 16. In this case it is not necessary for the AHNOS client to actively detect the service failure.

Reference is now made to Fig. 3, which is a simplified diagram illustrating an example of an error occurring at the edge network that may be resolved into a redirection.

The devices at the local edge network are continually monitored 40 to ensure that they operate within their specifications and that the edge network shows healthy operation. If they do not then the device is reconfigured or some other action is taken

42. If nevertheless network problems continue to occur 44 then it is assumed that a remote problem is the cause and the redirection procedure is invoked 46.

Reference is now made to Fig. 4, which is a simplified diagram illustrating operation of the flow of Fig. 3 in the event that the symptom is a URL resolution failure. The flow takes into account the various situations of failures inside the customer premises and the provider/third-party premises. Without the present embodiments the user may expect to lose resolution capabilities, and in practice will be unable to reach web sites. As a result he may contact the Internet Service Provider's call center. User dissatisfaction typically results and the service provider has to provide the cost of handling the situation. If there is a known problem the user will be told to wait, until the problem is solved, typically within a certain number of hours. If there is no known problem the call center operator - or a field technician - will assume that the problem lies with the customer and will attempt to analyze and fix the problem on the customer premises. In particular this will take time and use up technical support resources of the provider when the problem is not especially theirs.

Resolution of the problem using an embodiment of the invention: In case of a DNS problem the provider is aware of, the provider can use interface 38 to edit the relevant page on server 36 to provide a suitable redirection message. The message triggers an invocation procedure at the edge network which uses an address provided in the message to update the DNS settings at the edge network. The edge network is thus fully automatically fully configured to carry out the redirection. Alternatively the backup address may already be available at the edge network.

The message in this case would merely trigger the invocation procedure.

The failure resolution procedure as a whole may operate as follows: Local resolution is a straightforward activity of the AHNOS: If a deviation from the well known DNS settings of the user PC/Router occurs, the failure is typically fixed by the AHNOS. That is to say the task of the AHNOS is to keep the home network working and well configured continuously.

If the customer premises is well configured, but a resolution test fails, the

AHNOS may then contact the predefined AHNOS support server or any other emergency server provided for the purpose. In one embodiment the provider may have a redundant set of AHNOS support servers, and in a further embodiment the main server might provide AHNOS support in the form of regular updates, but with the AHNOS knowing of a second server to consult in the event of failure of the main server. The AHNOS server or back up is preferably looked up using a pre-defined IP address. Such a predefined IP address ensures connectivity to the server despite the domain resolution problem. The AHNOS can then obtain any new messages and redirect accordingly. If one of the new messages instructs the AHNOS to change the DNS settings, the AHNOS may then ensure that the change is made wherever necessary at the edge network. Alternatively, the AHNOS may turn to a predefined alternative DNS.

In the event say of a DDoS attack at the provider or a natural disaster or the like there may be no service at all from the provider. If no message concerning a DNS problem is obtained from the server, the AHNOS may handle the problem as an unresolved failure. In this case the user may in one embodiment be redirected to facilities of a different provider and such may be achieved by a predefined alternative DNS. In an alternative embodiment an unresolved failure may be handled by displaying a message, notifying the user that an unknown DNS problem has occurred. A similar example is the handling of a network application access failure. Certain applications, such as games, file sharing etc. demand communication with other users/servers over the Internet. In such a case a closed port on the user's PC/router can for example cause a malfunction of the application. In such an event, the user will fail to work with an application and will have to investigate it by himself. Provider call centers often do not support port management and the user may be left to solve the problem by himself, which he is unlikely to be able to do.

The present embodiments however provide a possible solution that would work broadly as above.

The provider may add a message to the server to open/close ports on the users' PC/router and thus the provider can obtain control over the users' ports status. The provider can then close and open the ports it wishes, and upon occurrence of exceptional situations (viruses, security breaches etc.) change ports state to prevent bad activity by that port.

In another example there may be connectivity problems involving the customer during infrastructure and/or maintenance work. A provider say using an asynchronous transfer mode (ATM) network may need to perform infrastructure work on an active circuit. This can cause connectivity problems of the customer to the network. Without the invention the user may lose connectivity to the Internet and may contact the provider's call center, getting a response such as "there is a known problem that will be fixed within few hours". During that time service will be lost With the present embodiments, the customer can be notified of the problem by polling the provider's server. The provider makes an alternative Virtual Circuit (VC) serviceable and loads the server with connection information needed to reach the alternative virtual circuit. The server is regularly polled by the customers and the new connection information is thus retrieved. The AHNOS client then changes to the alternative Virtual Circuit automatically using the received new connection information. Then, when the original VC is serviceable again, the AHNOS client reconfigures the network to work with the original VC.

In one embodiment the message that is polled can include a time. In a further embodiment the message can include either or both of a start time and an end time. Thus a user can be configured for the alternative virtual circuit between specific hours during which maintenance can be scheduled. The same activation and deactivation times can be included in the embodiments in which the message is actively sent to the end users. With reference to Fig. 5, the issue of handling a mail sending failure due to an

SMTP server malfunctioning is now discussed.

In the conventional case the user finds himself in a state of being unable to send e-mails. Consequently he contacts the provider's call center, only to be told to wait until the problem is solved, e.g., within few hours. With the present embodiments the provider is able to load the AHNOS support server 36 with a message to change the SMTP server address at the customer with an alternate SMTP server address, in other words to actually change the customer's mail settings.

The AHNOS client thus changes the SMTP server address accordingly, and when the original SMTP server is serviceable again, the AHNOS client simply reconfigures the network to work with the original SMTP server. The failure resolution preferably operates as follows:

1. If a deviation from the known SMTP server settings of the user network occurs for no apparent reason, the failure is spotted and fixed by the AHNOS. This assumes that the AHNOS keeps the home network working and well configured continuously.

2. If the customer premises are well configured, but an SMTP server function test fails, the AHNOS contacts the support server 36 using a pre-defined IP address. As explained above, the actual IP address is defined in advance to ensure connectivity to the server in case of a domain resolution problem. New messages are then obtained, for example instructing the AHNOS to change the SMTP server settings. The new configuration is applied to the edge network and the failure is fixed. Alternatively or additionally, the AHNOS may itself include a pre-defined alternative SMTP address to use in the event of non- responsiveness at the support server.

3. If no message concerning a SMTP server problem is obtained from the server, or a locally available SMTP alternative address is undefined or ineffective, the AHNOS may then handle the case as an unresolved failure, for instance to display a message, notifying the user that an unknown SMTP server problem has occurred.

In the above, the change in settings has been described in relation to the need to overcome a failure, or in anticipation of a resource failure or resource maintenance.

However the same methodology can be used where there is no failure at all. For example a service provider may simply wish to reconfigure the settings of his users.

For example, in order to achieve a more balanced load a service provider may wish to group a certain proportion of heavy users with a certain proportion of light users on a particular server. Later on a previously light user may turn into a heavy user and now additional reconfiguration may be required. The present embodiments allow such dynamic reconfiguration.

Likewise a service provider may now carry out a configuration update to the edge network. For example the service provider may wish to reconfigure routers at the edge network.

It is expected that during the life of this patent many relevant devices and systems will be developed and the scope of the terms herein, is intended to include all such new technologies a priori.

It is appreciated that certain features of the invention, which are, for clarity, described in the context of separate embodiments, may also be provided in combination in a single embodiment. Conversely, various features of the invention, which are, for brevity, described in the context of a single embodiment, may also be provided separately or in any suitable subcombination. Although the invention has been described in conjunction with specific embodiments thereof, it is evident that many alternatives, modifications and variations will be apparent to those skilled in the art. Accordingly, it is intended to embrace all such alternatives, modifications and variations that fall within the spirit and broad scope of the appended claims. All publications, patents, and patent applications mentioned in this specification are herein incorporated in their entirety by reference into the specification, to the same extent as if each individual publication, patent or patent application was specifically and individually indicated to be incorporated herein by reference. In addition, citation or identification of any reference in this application shall not be construed as an admission that such reference is available as prior art to the present invention.

Claims

CLAIMSWhat is claimed is:

1. In a network architecture comprising edge networks and centralized resources having redundancy, apparatus for location at an edge network comprising: at least one local monitoring unit for determining whether operation of the edge network is within a predetermined specification; at least one interruption unit for determining whether operation of the edge network is undergoing an interruption; and and at least one invocation unit, associated with the interruption unit and the local monitoring unit for i) inferring that if the edge network is operational with said predetermined specification and is simultaneously undergoing an interruption then a centralized resource is not sufficiently responsive, and ii) following such inferring, invoking redundancy of said not sufficiently responsive resource.

2. Apparatus according to claim 1, wherein said interruption unit is configured to find at least one member of the group comprising: a server-client operation failure, a remote client contact failure, a port malfunction, a DNS resolution failure, an SMTP server failure, and a network connectivity failure.

3. Apparatus according to claim 1, wherein said invocation unit is configured to poll a support server to obtain directions for said invoking redundancy.

4. Apparatus according to claim 3, wherein said directions comprise an absolute IP address.

5. Apparatus according to claim 3, wherein said directions include at least one member of the group consisting of: the address of an alternative server, the address of an alternative DNS server, the address of an alternative SMTP server, a port open/close command, and an alternative virtual circuit address.

6. Apparatus according to claim 1, wherein said invocation unit is configured with preloaded directions for said invoking redundancy.

7. Apparatus according to claim 1, wherein said invocation unit is configured to initially poll a support server to obtain directions for said invoking redundancy and then subsequently to look up preloaded default instructions for said invoking redundancy.

8. Apparatus according to claim 7, wherein said invocation unit is configured such that said subsequently looking up default instructions is carried out if said support server is not available.

9. Apparatus according to claim 7, wherein said invocation unit is configured such that said subsequently looking up default instructions is carried out if invoking using said support server directions is not successful.

10. Apparatus according to claim 1, wherein said at least one monitoring unit comprises a supervisory layer for each one of a plurality of devices on said edge network, such that each device is supervised according to its individual protocol.

11. In a network architecture comprising edge networks and centralized resources having redundancy, a method comprising: determining whether operation of the edge network is within a predetermined specification; determining whether operation of the edge network is undergoing an interruption; inferring that if the edge network is operational with said predetermined specification and is simultaneously undergoing an interruption then a centralized resource is not sufficiently responsive, and following such inferring, invoking redundancy of said not sufficiently responsive resource.

12. Method according to claim 11, wherein said interruption is due to at least one member of the group comprising: a server-client operation failure, a remote client contact failure, a port malfunction, a DNS resolution failure, an SMTP server failure, and a network connectivity failure.

13. Method according to claim 11, comprising polling a support server to obtain directions for said invoking redundancy.

14. Method according to claim 13, wherein said directions comprise an absolute IP address.

15. Method according to claim 13, wherein said directions include at least one member of the group consisting of: the address of an alternative server, the address of an alternative DNS server, the address of an alternative SMTP server, a port open/close command, and an alternative virtual circuit address.

16. Method according to claim 11, comprising using preloaded directions at said edge network for said invoking redundancy.

17. Method according to claim 11, comprising initially polling a support server to obtain directions for said invoking redundancy and then subsequently looking up preloaded default instructions for said invoking redundancy.

18. Method according to claim 17, wherein said subsequently looking up default instructions is carried out if said support server is not available.

19. Method according to claim 17, wherein said subsequently looking up default instructions is carried out if invoking using said support server directions is not successful.

20. Method according to claim 11, wherein said local monitoring is per network device such that each device is supervised according to its individual protocol.

21. In a network architecture comprising edge networks and centralized resources having redundancy, apparatus for location at an edge network comprising: at least one local managing unit for managing said edge network; at least one support server monitoring unit, associated with said managing unit for monitoring a message space at a support server for messages indicating a redirection instruction to an alternative resource, wherein said local managing unit is configured with an invocation function for invoking said alternative resource according to said retrieved message.

22. The apparatus of claim 21, wherein said invocation unit is configured, in the absence of a message at said support server, to i) infer that if the edge network is operational within a predetermined specification and is simultaneously undergoing an interruption of service then a centralized resource is not sufficiently responsive, and ii) following such inferring, invoking said alternative resource.

23. The apparatus of claim 22, wherein said invocation unit is configured to carry out said invoking using default directions stored at said edge network.

24. In a network architecture comprising edge networks and centralized resources having redundancy, apparatus for location at an edge network comprising: at least one local managing unit for managing said edge network; at least one message monitoring unit, associated with said managing unit for monitoring for messages indicating a redirection instruction to an alternative resource, wherein said local managing unit is configured with an invocation function for invoking said alternative resource according to said retrieved message.