Apparatus and method for monitoring status of a network element

Abstract

An apparatus and method for monitoring a status of a network element in a communication network is provided. The apparatus includes an interface for transmitting status requests for the network element and receiving status information from the network element, and a controller for controlling transmission of the status requests. The controller is responsive to a status report confirming reachability of the network element, or to a transition from a reachable state, in which the reachability of the network element is valid, to a probe state, to transmit a status request to the network element to reconfirm its reachability status.

Description

BRIEF DESCRIPTION OF THE DRAWINGS

Examples of embodiments of the present invention will now be described with reference to the drawings in which:

FIG. 1 shows a block diagram of communication network nodes exchanging neighbor discovery communications according to the prior art;

FIG. 2 shows a block diagram of the possible states associated with neighbor cache entries for IPv6 neighbor discovery, according to the prior art;

FIG. 3A shows a schematic diagram of an interface according to the prior art;

FIG. 3B shows a schematic diagram of another interface according to the prior art;

FIG. 4 shows a network element according to an embodiment of the present invention;

FIG. 5 shows an example of states for neighbor cache entries according to an embodiment of the present invention; and

FIG. 6 shows a flow diagram of a method for monitoring status of a network element according to an embodiment of the present invention.

DESCRIPTION OF THE EMBODIMENTS

Referring to FIG. 4, a network element 301 according to an embodiment of the present invention comprises an interface 303 for transmitting and receiving communication signals to and from a communication network. The communication interface 303 includes a memory 305 which stores a record of information about neighboring network elements to which the interface is connected or with which the interface has previously communicated, and this record will be referred to as a “neighbor cache”. The neighbor cache includes one or more identifiers for identifying each neighbor network element, and the identifier(s) may include, for example, one or more addresses for each neighboring network element, such as unicast IP addresses. The neighbor cache may also include other information about each neighboring network element such as whether the network element is a host or router and other information which governs how the interface communicates with a neighbor. The neighbor cache also includes a status associated with each neighbor (or network element) entered in the record. Each status is described in more detail below with reference to FIG. 5.

The network element 301 further includes a controller 307 for controlling communications from the network element associated with neighbor discovery, and in accordance with the status associated with each neighbor network element indicated in the neighbor cache.

FIG. 5 shows an example of the various possible states for each entry in the neighbor cache and includes a “no entry exists” state 401, an “incomplete” state 403, a “reachable” state 405 and an “advanced probe” state 407.

When information about a neighbor for which no entry exists in the neighbor cache is to be discovered, the network element transmits a status request, for example, a multicast neighbor solicitation message, an entry for the neighbor is created in the neighbor cache, and an “incomplete” state is assigned to the new entry while the network element awaits a response from the neighbor, including its link-layer address. Multicast neighbor solicitation messages may be repeatedly sent a predetermined number of times, following which the address resolution process is abandoned.

On receiving a status report, for example, a unicast neighbor advertisement message from the neighbor, the entry status in the neighbor cache associated with the neighbor changes to the “reachable” state, and the entry status remains in this state for a period of time. In one implementation, as shown in FIG. 4, a timer is associated with each neighbor cache entry which records the time from which each neighbor was last confirmed as being reachable. On receiving a status report from the neighbor, the timer is set to a time value over which the neighbor is assumed to be reachable. This time value may be sent by the neighbor or may be a set value of the network element. The timer records the time which has elapsed since the status report confirming that the neighbor is reachable was received. If, before the time expires, the neighbor is confirmed to be reachable by some other means, for example, by other protocol(s), the timer may be reset to the original time value on each confirmation that the neighbor is reachable. If the time expires, the entry status changes to the “advanced probe” state 407 (as indicated by the arrow 409), in which the controller 307 (FIG. 4) causes transmission of a (further) status request to the neighbor. In one implementation, the status request is a neighbor solicitation message and may be transmitted as a unicast message.

If the neighbor responds by sending a status report confirming that it is still reachable, the entry status for the neighbor in the neighbor cache changes from “advanced probe” to the “reachable” state as indicated by the arrow 411 in FIG. 5.

On changing to the reachable state, the timer is set to the reachable time value and starts recording the elapsed time from when the last reachability confirmation was received. If the reachable time expires, the entry status again transitions from the reachable state to the advanced probe state, and a new status request is transmitted to the neighbor, and if reachability is confirmed, the cycle is repeated.

If during an “advanced probe” state, no message confirming reachability of the neighbor is received, the entry is deleted from the neighbor cache 305 so that the status transitions from the “advanced probe” state 407 to the “no entry exists” state 401 as indicated by arrow 413.

In this arrangement, each time the “reachable” state expires, the entry status changes directly to an “advanced probe” state which causes the network element to transmit a new status request addressed to the neighbor. Thus, each time the reachable state expires, the network element seeks confirmation from the neighbor that the neighbor is still reachable. In contrast to existing software solutions, this arrangement removes the need for capturing packets from the fast data path in the “stale” state, when the reachable state expires, so that data can continuously flow on the fast path without risk of packet reordering or packet loss resulting from a transition to the “stale” state.

Referring again to FIG. 5, in some embodiments, any one or more of the “stale”, “delay” and “probe” states, shown in broken lines may be omitted altogether or may be included as a selectable option. For example, the “stale”, “delay” and “probe” states may be used for neighbor cache entries which result from the network element learning information about a neighbor as a result of some exchange of information with the neighbor other than the receipt of a solicited neighbor advertisement message. For example, the network element may obtain information about a neighbor from a received status request (shown in broken lines in FIG. 4), e.g. a neighbor solicitation message, which includes, for example, the neighbor's source address. An entry for the neighbor may be created in the neighbor cache and a “stale” state assigned to the entry. When the network element is to initiate a new communication session with the neighbor, the network element sends one or more initial packets, and since the neighbor cache entry does not exist in the fast path, the first packet(s) is (are) extracted to the slow path to verify reachability. In the slow path, the controller changes the state from “stale” to “delay”, to allow the network element to determine from any other source, (e.g. higher layer protocol) whether the neighbor is reachable. If the neighbor is confirmed as reachable, the state of the entry changes to “reachable”. Otherwise, after a predetermined period of time set for the delay state, the state of the entry changes to the probe state in which the network element transmits a neighbor solicitation message to the neighbor. If a response confirming the neighbor's reachability is received, the entry changes from the “probe” state to the “reachable” state. Once in the “reachable” state (either through the “delay” or “probe” state) the controller programs the fast path with the resolved entry, and reinserts the packets from the slow path to the fast path. If on the other hand, no confirmation is received either in response to the first or any subsequent neighbor solicitation, the entry is deleted as indicated by arrow 415 from the “probe” state to the “no entry exists” state 401.

FIG. 6 shows a flow diagram illustrating an example of a method of monitoring status of a network element according to an embodiment of the present invention. The method starts at step 501 with a “No Entry Exists” state in which the neighbor-cache does not contain any entry for a particular neighbor. At step 505, a neighbor entry is created in the neighbor cache, and at step 507, a neighbor solicitation (NS) message is sent. At step 509, the process waits a predetermined length of time for a response to the neighbor solicitation and if a solicited neighbor advertisement (Sol NA) is received, the state of the entry changes from incomplete to “reachable” at step 511.

If, after the wait time at step 509, no response is received, the neighbor solicitation message is resent and a response awaited a further number of times until the number of neighbor solicitation messages reaches a set value, x, (which may have any value), and if no response is received after the last neighbor solicitation message is sent, the process passes to step 515 in which the destination to which the neighbor solicitation message is sent is determined as unreachable.

If at step 509, another message is received from the neighbor, the process passes to step 519, in which the entry changes from the “incomplete” state to the “stale” state and then any buffered data packets can be sent to the neighbor, as indicated at step 535.

Returning to step 511, when the entry is in the “reachable” state, any buffered data packets can be sent. The entry remains in the reachable state for the predetermined reachable time, as indicated by step 523, and once the time has expired, the process passes to step 525 where a decision is made as to whether the state of the entry should proceed to the “advanced probe” state at step, 527 or proceed to the “stale” state at step 519. If the “advanced probe” state is selected, a neighbor solicitation message is sent to the neighbor at step 529. The process waits for a response to the neighbor solicitation at step 531, and if a solicited neighbor advertisement is received, the state of the entry changes from “advanced probe” to “reachable” at step 511. On the other hand, if no solicited neighbor advertisement is received, nor any other indication that the neighbor is reachable, the neighbor solicitation message may be resent and a response awaited a certain number of times as indicated by step 533, where “y” can have any value. If, after the last attempt, no response is received, the entry is deleted and the process passes to the “No Entry Exists” state as indicated at step 501.

If instead of receiving a solicited neighbor advertisement in response to the neighbor solicitation, it is determined by other means (e.g. another message from the neighbor) that the neighbor is reachable, the entry changes from the “advanced probe” state to the “stale” state at step 519, the network element is enabled to send buffered data packets, if any, as indicated by step 535, and the state changes to “delay” at step 537.

In addition to the two routes to the “stale” state described above, the entry may also enter the “stale” state if, during the reachable state, the network element receives a notification from the neighbor that its link layer address has changed, or if a decision is made at step 525 that the “advanced probe” feature is not to be used. Once in the “stale” state (as reached through any of the routes described above, for example), the entry remains in the “stale” state until data is sent to the neighbor, as indicated by step 535. When data is sent, the entry then changes from the “stale” state to the “delay” state (for example by the mechanism described above where packets are sent to the slow path) and the entry remains in this state for a predetermined length of time as indicated at step 539, to provide an opportunity to determine whether the neighbor is reachable by any available means other than sending a neighbor solicitation message. If reachability is confirmed in the “delay” state, the entry changes to the “reachable” state 511. Otherwise, after the delay time, the state of the entry changes to the “probe” state at step 541, where the network element sends a neighbor solicitation message at step 543. The process then waits, at step 545, for a response to the neighbor solicitation message, and if a solicited neighbor advertisement is received, the state of the entry changes from “probe” to “reachable” at step 511. If no response is received within a predetermined wait time, the neighbor solicitation message may be resent a predetermined number of times, z, (which may have any value), after which if no response is received, the entry is deleted and the process passes to the “No Entry Exists” state 501. On the other hand, if during the wait time 545, it is determined that the neighbor is reachable by some means other than a solicited neighbor advertisement, the process proceeds to step 519, in which the state of the entry is changed to “stale” and then any buffered data packets can be sent at step 535.

The embodiment of FIG. 6 allows selection between a neighbor status monitoring process which involves the “advanced probe” state, and one which involves the “stale”, “delay” and “probe” states. Although the embodiment of FIG. 6 is described as using neighbor solicitations and neighbor advertisements as the status request and status report, respectively, it is to be noted that this embodiment may be implemented using any status request or report.

In other embodiments, the apparatus and method may be implemented to transmit a status request in the “reachable state”. In this case the “advanced probe” state is effectively included in or combined with the “reachable” state, so that a separate “advanced probe” state is unnecessary and can be omitted. For example, the “advanced probe” state of the embodiments of FIGS. 5 and 6 can be omitted, and the reachable state used instead to trigger the transmission of a status request.

Although some of the embodiments described above are concerned with monitoring the reachability status of a neighbor, other embodiments may alternatively, or in addition be implemented to monitor the status of one or more other attributes of a neighbor or other network resource.

Other aspects and embodiments of the present invention comprise any one or more features disclosed herein in combination with any one or more other features disclosed herein, an equivalent or variant thereof. In any aspects or embodiments of the present invention, any one or more features disclosed herein may be omitted altogether or substituted by an equivalent or variant thereof.

Numerous modifications and changes to the embodiments described above will be apparent to those skilled in the art.

Claims

1. An apparatus for monitoring status of a network element in a communication network, comprising: transmission means for transmitting a status request,receiving means for receiving a status report containing status information, anda controller for controlling transmission of a status request at least one of (1) in response to the receipt of said status report, (2) during a time period when said status information contained in the received status report is deemed to be valid, and (3) in response to the expiry of said time period.

2. An apparatus as claimed in claim 1, wherein said status comprises a status indicative of whether said network element is reachable.

3. An apparatus as claimed in claim 1, wherein said controller is adapted to cause transmission of said status request a predetermined period of time after one of (1) said status report is received, and (2) a last indication is received confirming said status information contained in said status report.

4. An apparatus as claimed in claim 1, wherein said status request includes a request for the status of a predetermined attribute associated with the network element.

5. An apparatus as claimed in claim 1, wherein said transmission means is adapted to transmit said status request as a unicast transmission.

6. An apparatus as claimed in claim 1, wherein said transmission means is adapted to transmit a further status request subsequent to said status request according to a selected transmission mode depending on the response of said network element to said status request.

7. An apparatus as claimed in claim 6, wherein said transmission mode is a unicast transmission if a status report received in response to said status request indicates that the network element is reachable, and the transmission mode is a multicast transmission if it is determined that the network element, in response to said status request is unreachable.

8. An apparatus as claimed in claim 1, wherein said controller is adapted to cause said transmission means to transmit a status request in response to the receipt of each status report from said network element that is responsive to a previous status request and which indicates that the network element is reachable, and to transmit each status request at least one of (1) a predetermined period of time after the receipt of a respective status report, (2) during a time period when said status information is deemed to be valid, and (3) in response to the expiry of said time period.

9. An apparatus as claimed in claim 8, wherein said predetermined period of time is a time that said network element is assumed to be reachable.

10. An apparatus as claimed in claim 1, wherein said controller comprises a timer for measuring said predetermined time and which is activated by at least one of (1) the receipt of a status report indicating that the network element is reachable and (2) a determination that the network element is reachable.

11. An apparatus as claimed in claim 10, wherein said controller causes transmission of said status request immediately after the timer indicates that the predetermined period of time has expired.

12. An apparatus as claimed in claim 1, further comprising a memory for storing information about said network element and indicating means for indicating a state associated with said information, said indicating means indicating a state indicative of the network element being reachable in response to the receipt of a status report from said network element, and for indicating a state immediately after expiry of said time period indicative of the transmission of said status request.

13. A method of monitoring status of a network element in a communication network, comprising: receiving a status report containing status information from said network element, and transmitting a status request to said network element at least one of (1) in response to the received report, (2) during a time period when said status information is deemed to be valid, and (3) in response to the expiry of said time period.

14. A method as claimed in claim 13, wherein said status indicates whether said network element is reachable.

15. A method as claimed in claim 13, wherein said status request is transmitted a predetermined time after one of (1) said status report is received, and (2) a last indication is received confirming said status information contained in said status report.

16. A method as claimed in claim 13, further comprising transmitting a further status request for said network element at least one of (1) in response to each receipt of a status report from said network element that is transmitted by said network element in response to a status request, (2) during a time period when said status information is deemed to be valid, and (3) in response to the expiry of said time period.

17. A method as claimed in claim 16, wherein each further status request is sent a predetermined period of time after (1) the receipt of a respective status report or (2) a determination that the status information is valid.

18. A method as claimed in claim 13, further comprising creating a record of the status of said network element in response to the receipt of said status report and during or in response to the expiry of said predetermined time period, assigning a state to said record, said state indicating the transmission of said status request.

19. A method as claimed in claim 13, further comprising enabling data to be transmitted to said network element while waiting for a response to said status request.

20. An apparatus for recording the status of a network element, comprising: a recorder for entering an identification of said network element in a record, said recorder being responsive to a message from said network element to assign a first state to said record indicating that said network element is reachable, said recorder being responsive to said message and/or to the expiry of a time period following receipt of said message during which information in said message is deemed to be valid, to assign a second state to said record indicating that a status request is being sent to said network element.

21. An apparatus as claimed in claim 20, further comprising a controller for controlling transmission of said status request in response to detection of said second state.