System and method for rejecting a request to alter a connection

A method for rejecting a request to alter a connection includes establishing a first connection with a first node and a second connection with a second node. The second connection passes through the first node and has an associated first end-to-end state. The method also includes transmitting, for relay by the first node to the second node, a first request to alter the second connection with the second node so that the second connection will have an associated second end-to-end state. The method additionally includes receiving a rejection message from the first node indicating that the first request to alter the second connection failed. The method further includes transmitting a second request to alter the second connection with the second node to ensure that the second connection is again in the associated first end-to-end state.

TECHNICAL FIELD

This invention relates generally to the field of communication networks and more specifically to a system and method for rejecting a request to alter a connection.

BACKGROUND

An optical network uses optical signals to communicate information among the nodes of the network. This information often includes both data (e.g., a file that is being downloaded, packets carrying voices of a phone call, or the contents of a webpage) and signaling (e.g., commands or messages between nodes containing status or setup information). In some optical networks the data may be transferred using a data channel (e.g., a datalink) while the signaling is communicated using a control channel. The connections that carry both the data and the signaling may, at times, need to be modified. For example, a connection may need to be deleted. Currently, protocols, such as Resource Reservation Protocol-Traffic Engineering (RSVP-TE), do not clearly specify procedures for the rejection of a request to alter a connection. In certain situations this may lead to stranded resources and may prevent consistent end-to-end connections. Instead of dealing with the problem of not being able to reject the request, various standards bodies are attempting to address the side effects of the failure with complex protocol extensions. For example, protocol extensions to cleanup stranded resources where there is a loss of communications.

SUMMARY OF THE DISCLOSURE

Particular embodiments provide a system and method for rejecting a request to alter a connection that substantially eliminates or reduces at least some of the disadvantages and problems associated with previous methods and systems.

In accordance with a particular embodiment, a method for rejecting a request to alter a connection includes establishing a first connection with a first node and a second connection with a second node. The second connection passes through the first node and has an associated first end-to-end state. The method also includes transmitting, for relay by the first node to the second node, a first request to alter the second connection with the second node so that the second connection will have an associated second end-to-end state. The method additionally includes receiving a rejection message from the first node indicating that the first request to alter the second connection failed. The method further includes transmitting a second request to alter the second connection with the second node to ensure that the second connection is again in the associated first end-to-end state.

In accordance with another embodiment, a method for rejecting a request to alter a connection includes establishing a first connection with a first node and a second connection with a second node. The first node and the second node have established a third connection with each other. The third connection has an associated first end-to-end state. The method also includes receiving from the first node a first request to alter the third connection between the first node and the second node so that the third connection will have an associated second end-to-end state. Furthermore, the method includes transmitting the first request to the second node. Upon determining that the first request failed, the method also includes transmitting a rejection message to the first node indicating that the first request to alter the third connection failed. The method additionally includes receiving a second request to alter the third connection between the first node and the second node to ensure that the third connection is again in the associated first end-to-end state.

In accordance with yet another embodiment, a method for rejecting a request to alter a connection includes establishing a first connection with a first node and a second connection with a second node. The first node and the second node have established a third connection with each other. The method additionally includes transmitting a first request to alter the third connection between the first node and the second node. The method also includes, upon a first amount of time after the first request was transmitted having elapsed without receiving a response from the first node, transmitting a second request to alter the third connection between the first node and the second node. The method further includes receiving a response from the first node indicating the first node is able to comply with the requested alteration.

In accordance with another embodiment, a system for rejecting a request to alter a connection includes an interface operable to establish a first connection with a first node and a second connection with a second node. The second connection passes through the first node and has an associated first end-to-end state. The system also includes a processor coupled to the interface and operable to transmit, for relay by the first node to the second node, a first request to alter the second connection with the second node so that the second connection will have an associated second end-to-end state. The interface is further operable to receive a rejection message from the first node indicating that the first request to alter the second connection failed. The processor is further operable to transmit a second request to alter the second connection with the second node to ensure that the second connection is again in the associated first end-to-end state.

In accordance with yet another embodiment, a system for rejecting a request to alter a connection includes an interface operable to establish a first connection with a first node and a second connection with a second node. The first node and the second node have established a third connection with each other. The third connection has an associated first end-to-end state. The interface is also operable to receive from the first node a first request to alter the third connection between the first node and the second node so that the third connection will have an associated second end-to-end state. The system also includes a processor coupled to the interface and operable to transmit the first request to the second node. The processor is further operable to, upon determining that the first request failed, transmit a rejection message to the first node indicating that the first request to alter the third connection failed. The interface is further operable to receive a second request to alter the third connection between the first node and the second node to ensure that the third connection is again in the associated first end-to-end state.

In accordance with another embodiment, a system for rejecting a request to alter a connection includes an interface operable to establish a first connection with a first node and a second connection with a second node. The first node and the second node have established a third connection with each other. The system also includes a processor coupled to the interface and operable to transmit a first request to alter the third connection between the first node and the second node. The processor is also operable to, upon a first amount of time after the first request was transmitted having elapsed without receiving a response from the first node, transmit a second request to alter the third connection between the first node and the second node. The interface is further operable to receive a response from the first node indicating the first node is able to comply with the requested alteration.

Technical advantages of particular embodiments include providing a node with a way to reject a request to alter a connection that reduces or avoids stranding resources resulting from the altered connection.

DETAILED DESCRIPTION OF THE DRAWINGS

FIG. 1is a block diagram illustrating an example embodiment of a node coupled to two other nodes. Nodes110,120and130are physically coupled to one another via links151and152to form network100. In addition, nodes110,120and130may also be logically coupled to one another via connections (not depicted). A connection may represent a pairing of interfaces associated with two different nodes. The connection between two nodes may be irrespective of the links or physical coupling of the nodes. For example, there may be a connection between node110and130even though they are not directly coupled to each other. Thus, node110may be able to send messages to node130. Any messages sent from node110to node130via the connection would pass through node120. These connections allow nodes110,120and130to communicate both data, such as files or WebPages, and signaling, such as control messages, routing messages, and link management messages, between each other using links151and152. Data and signaling may be referred to collectively as messages. Because node120is between nodes110and130, it may operate as a relay, passing on messages from one node to the other.

In certain situations one of nodes110,120or130may desire to alter its connection with one of the other nodes. The alteration may range from deleting the connection to performing various administrative modifications to the connection. However, for any of a variety of reasons the requested alteration may be rejected. For example, the requested alteration may need to be rejected for operational needs (e.g., loss of communications, damage to a link, or controller failure) or for administrative reasons (e.g., graceful shutdown of the controller during software upgrades, placing a resource in a test mode which prevents it from being modified or released, or manual protection switch modes). Unfortunately, current protocols, such as Resource Reservation Protocol-Traffic Engineering (RSVP-TE), do not clearly specify the procedures to be used to reject a request to alter a connection. This may lead to resources being stranded. To avoid stranding resources particular embodiments may allow nodes110,120and130to reject a request to alter a connection if they determine that the requested alteration has failed or otherwise cannot be complied with. Upon receiving the rejection the node that originally sent the alteration request may return to is original state (e.g., its state before it attempted the alteration). Furthermore, in some embodiments, the node that originally requested the alteration may send an additional request requesting that the connection revert back to its original state. This may help to ensure a consistent end-to-end state for a connection even if an intermediary node along the path used by the connection initially makes a change in response to the requested alteration.

Network100may be any type of network employing any suitable topology, such as a ring network, a star network, a bus network, a mesh network, or any other type of network that may be desired. For example, if network100was a ring network it may use a unidirectional path-switched ring (UPSR) topology or a bidirectional line switched ring (BLSR) topology. Furthermore, network100may utilize protocols such as Resilient Packet Ring (RPR) protocols. An RPR protocol may refer to a protocol for ring-based packet transport, where packets are added, passed through, or dropped at each node (e.g. node110). According to some embodiments, network100may utilize any suitable transmission technique, such as Ethernet, Synchronous Optical Network (SONET), or wavelength division multiplexing (WDM) techniques (e.g. dense wavelength division multiplexing (DWDM)). In addition, network100may employ RSVP-TE and/or synchronous transport signal (STS). In some embodiments, network100may communicate information in packets. A packet may comprise a bundle of data organized in a specific way for transmission. A packet may carry any suitable information such as voice, data, audio, video, multimedia, control, signaling, other information, or any combination of the preceding. The packets may comprise any suitable multiplexed packets, such as time division multiplexed (TDM) packets. One or more packets may be organized within a frame in a specific way for transmission.

Packets or frames may be communicated within portions of network100using an optical signal transmitted as light pulses. As an example, an optical signal may have a frequency of approximately 1550 nanometers and a data rate of 10, 20, 40, or over 40 gigabits per second. These light pulses may travel through any type of fiber suitable to transmit a signal. According to one embodiment, the fiber may include an optical fiber. An optical fiber typically comprises a cable made of silica glass or plastic. The cable may have an outer cladding material around an inner core. The inner core may have a slightly higher index of refraction than the outer cladding material. The refractive characteristics of the fiber operate to retain a light signal inside of the fiber.

Network100may comprise, or be a part of, a local area network (LAN), a wide area network (WAN), a cellular network, a global distributed network such as the Internet, an Intranet, an Extranet, a radio network (RN), a CDMA network, a GSM network, a TDMA network, a satellite network or any other form of wireless or wireline networking.

Nodes110,120and130may be referred to as network entities and may include any suitable type of networking device such as a cross connect, a database, a regenerating unit, dense wavelength division multiplexers (DWDMs), access gateways, endpoints, softswitch servers, trunk gateways, access service providers, Internet service providers, or any other device operable to route packets to, from or within network100. For simplicity, only node110's internal components have been depicted. In other embodiments, node110may comprise more or fewer internal components, and one or more of the components may be external to node110. Nodes120and130may comprise similar components.

Processor112may be a microprocessor, controller, or any other suitable computing device, resource, or combination of hardware, software and/or encoded logic operable to provide, either alone or in conjunction with other node110components, such as memory114and interface116, node functionality. Such functionality may include providing various features discussed herein to a network, such as network100. Such features may include generating/interpreting a request to alter a connection. Similarly, processor112may also be used in generating/interpreting a rejection of the request to alter the connection. In some embodiments the features implemented by processor112may also include a timer. The timer may start when a request is sent and stop when a response is received or after a predetermined amount of time.

Memory114may be any form of volatile or non-volatile memory including, without limitation, magnetic media, optical media, random access memory (RAM), read-only memory (ROM), removable media, or any other suitable local or remote memory component. Memory114may store any suitable instructions, data or information, including software and encoded logic, utilized by node110. For example, in some embodiments memory114may store any information, data, commands or instructions needed by processor112to be able to interpret, process and respond to a rejection message.

Interface116may be used in the communication of signaling and/or data between node110and nodes120and130. For example, node110may receive a rejection message from node130via interface116. The number and type of interfaces116included with node110may be based on the number and type of networks to which node110is coupled. For example, node110may be coupled to an optical network and a broadcast network. In such a situation interface116may comprise a point-to-point optical interface and a broadcast network interface.

Modifications, additions, or omissions may be made to network100without departing from the scope of the invention. The components of network100may be integrated or separated according to particular needs. Moreover, the operations of network100may be performed by more, fewer, or other devices. Additionally, operations of network100may be performed using any suitable logic. As used in this document, “each” refers to each member of a set or each member of a subset of a set.

FIG. 2is a signaling diagram illustrating an example embodiment of signaling between nodes during an administrative modification to a connection. Nodes210may be similar to nodes110,120, and130described above with respect toFIG. 1. Furthermore, like nodes110,120and130, nodes210may be coupled serially in a point-to-point manner. More specifically, node210ais directly coupled to node210band indirectly coupled to node210c; node210bis directly coupled to both nodes210aand210c; and node210cis directly coupled to node210band indirectly coupled to node210a. Thus, any messages sent between nodes210aand210cmay have to pass through node210bbefore arriving at its final destination.

While in practice nodes within a network may send a variety of different signals and messages, for purposes of the signaling diagram depicted inFIG. 2three different types of signals are used. More specifically,FIG. 2includes path messages (paths220and230), notify messages (notify240), and reservation request messages (resv250and resv260). A path message may follow the route used for transmitting data (e.g., the same links and nodes used by the connection). Along the way the path message may create path states in the routers and may enable routers to learn the previous-hop and next-hop node for the session. While in practice a path message may comprise several different fields, only the administrative status bit (or field) and the reflect bit (or field) have been depicted. The administrative status bit may be used to indicate an administrative change such as turning on or turning off alarm monitoring for the specific connection. The reflect bit may be used to indicate that the sending node wants the receiving node to respond with the status of the administrative change being request. A notify message may be used to indicate the failure status of the administrative change from intermediary nodes. Similar to the path message, the notify message may in practice contain several different fields, but only the administrative status bit and the ErrorSpec Type Length Value (TLV) field are depicted. The ErrorSpec TLV field may comprise a value having a certain type of error associated therewith. A resv message may follow the reverse path of the path message. Along the way the resv message may create and maintain a reservation state in each router along the path. Like the path message, only the administrative status bit and the reflect bit are depicted. Assume, for purposes of this signaling diagram, that there is a connection between node210aand210cthat passes through node210b. Further assume that the link between node210band210cinitially is damaged.

For any of a variety of reasons, such as to turn on or turn off alarm monitoring or to release resources, node210amay have determined that it wants to modify its connection with node210c. Accordingly, node210afirst sends path220ato node210cvia node210b. Within path220athe administrative status bit is set to 0 and the Reflect bit is set to 1. While node210cis the intended recipient, path220amay first be received by node210bbecause the connection between nodes210aand210cgoes through node210b

Upon receiving path220a, node210bmay transmit path220aas path230a. Path230amay be similar to path220a, more specifically, the administrative status bit of path230ais set to 0 and the reflect bit of path230ais set to 1. Path230ais essentially the same message retransmitted by node210b. However, because the link between nodes210band210cis damaged node210cmay not receive path230aand thus may not be able to send an acknowledgement message back to node210b.

After sending path230anode210bmay wait a predetermined amount of time for an acknowledgement from node210c. In some embodiments this predetermined amount of time may be long enough to allow adequate time to receive an acknowledgement from node210cbut short enough to allow adequate time for node210ato receive notify240before node210atimes out and assumes that node210bdid not receive path230a. Upon the expiration of the predetermined amount of time, node210bmay send notify240in which a value has been placed in the ErrorSpec TLV field and the administrative status bit has been set to 1.

Once node210areceives notify240it knows that its request to alter the connection with node210chas failed. This may be because the administrative status bit was set to 1, when node210awas expecting it to be set to 0. More specifically, the administrative status bit of notify240is complimentary of the administrative status bit of path220asignifying that the requested alteration has been rejected.

Then node210amay send path220bwith the administrative status bit set to 1 and the Reflect bit set to 1. This may be done to ensure that nodes210aand210brevert back to their previous state. In other words, after path220bis received by node210bnodes210a,210b, and210cmay be back to their original state before path220awas sent. This may be desirable because nodes210aand210bmay have made changes in anticipation of the requested alteration. Unfortunately node210cdid not receive path230aand so may be unaware of the requested modifications. This may cause the resources represented by node210cto become stranded if nodes210aand210bwere to have transitioned to the new state while node210cremained in the old state. Thus, by sending path220brequesting nodes210aand210brevert back to their previous state, all three nodes may be in the previous state (the last state node210cwas aware of) when the link is repaired and node210cis again connected to node210b.

Some time after the damaged link has been repaired node210asends path220cwhich may be similar to path220a. It should be noted that in some embodiments node210amay not know when the damaged connection is repaired and thus several path messages may be sent and rejected before one actually gets through. Because the link has been repaired, node210cmay be able to receive path230band to respond to it by sending node210bresv250. Both the administrative status bit and the Reflect bit of resv250may be set 0.

As with path220, node210bmay forward resv250to node210aas resv260. Thus, like resv250, both the administrative status bit and the reflect bit of resv260are set to 0. When node210areceives resv260it will know that path220cwas successfully received by node210c. More specifically, because the administrative status bit is set to 0 (as it was in path220csent by node210a) node210aknows that node210cis able to make the requested modification contained within path220c. Then, at point270the requested alteration is performed and all three nodes210are in the same state. For example, alarm monitoring may be enabled at all three nodes.

FIG. 3is a signaling diagram illustrating an example embodiment of signaling between node during the deletion of a connection. Nodes310may be similar to nodes110,120, and130described above with respect toFIG. 1. Furthermore, like nodes110,120and130, nodes310may be coupled to one another serially in a point-to-point manner. More specifically, node310ais directly coupled to node310band indirectly coupled to node310c; node310bis directly coupled to both nodes310aand310c; and node310cis directly coupled to node310band indirectly coupled to node310a. Thus, any messages sent between nodes310aand310cmay have to pass through node310bbefore arriving at its final destination.

While in practice nodes within a network may send a variety of different signals and messages, for purposes of the signaling diagram depicted inFIG. 3three different types of signals are used. More specifically,FIG. 3includes notify messages (notify340), path messages (path320and330) and PathERR messages (pathErr350and360). The notify message depicted inFIG. 3may be similar to the notify message described above with respect toFIG. 2. However, for purposes of this signaling diagram only the delete bit is depicted. The delete bit may be used to indicate a request to delete a connection. The path message depicted inFIG. 3may be similar to the path message described above with respect toFIG. 2. However, for purposes of this signaling diagram the delete bit is depicted instead of the administrative status bit. A PathERR message may be sent when an error occurs with a particular path message. The PathERR message may be sent to the node that sent the path message. The PathERR message may be advisory and thus may not alter the state of the connection. Similar to the other messages the PathERR message may contain several different bits (or fields) but only the path state removed (PSR) bit is depicted. The PSR bit may be used to indicate that a particular path, or portion of a connection, has been removed or deleted. Assume, for purposes of this signaling diagram that the cross-connect of node310ais temporarily in test mode when notify340ais first sent and thus is unable to receive notify340a.

For any of a variety of reasons, such as removal of stranded resources, maintenance at intermediary nodes requiring the removal of all associated resources end-to-end, node310bmay desire to delete a connection. Accordingly, node310bfirst sends notify340ato node310b. The delete bit of notify340ais set to 1 indicating that node310bwants to delete the connection. However, because the cross-connect of node310ais in a test mode node310adoes not receive notify340a.

Traditionally, if node310bdid not receive some sort of acknowledgement or response from node310awithin a predetermined amount of time it would begin a forced deletion of the connection. However, in particular embodiments, rather than performing a forced deletion, node310bmay wait for a period of time and then retry sending the notify message. More specifically, after waiting a predetermined amount of time node310bsends notify340b. As before with notify340a, the Delete bit of notify340bis set to 1 indicating that node310bwants to delete the connection.

By this time node310ahas finished with its testing and thus is able to receive notify340b. Upon receiving notify340band determining that it is able to comply with the request to delete the connection, node310awill send path320; both the Delete bit and the Reflect bit of path320are set to 1. Note that the delete bit for both notify340band path320is set to 1 indicating to node310bthat the request to delete the connection has not been rejected.

When node310breceives path320it sends path330to node310c. Path330may be similar to path320. More specifically, both the Delete bit and the Reflect bit of path330are set to 1. When node310creceives path330it replies with PathERR350and at point370cuninstalls the cross-connect associated with the connection, effectively deleting that portion of the connection. PathERR350contains a Path State Removed bit which node310chas set to be 1, indicating that it has uninstalled the cross-connect associated with the connection.

As with path320, when node310breceives pathERR350it transmits a similar pathERR360to node310a. As with pathERR350, pathERR360contains a Path State Removed bit that has been set to 1 indicating that node310bhas uninstalled the cross-connect associated with the connection. Once node310bhas sent pathERR360, it uninstalls the cross-connect associated with the connection at point370b, effectively deleting that portion of the connection. Similarly, once node310areceives pathERR360indicating that node310bhas uninstalled its cross-connect, node310amay uninstall its cross-connect at point370a. It should be noted that uninstalling the three cross-connects at points370does not affect any other connections between nodes310. More specifically, deleting the cross-connects associated with the connection between nodes310aand310cmay not effect a connection between nodes310band310ceven though it may use the same link.

FIG. 4is a flowchart illustrating an example embodiment of a method for rejecting a request to alter a connection. This method may involve three nodes within an optical network, such as nodes110,120and130of network100depicted inFIG. 1. The method begins with steps400,410and420where the three nodes establish connections with one another. More specifically, a first connection is established between a first node and a second node, a second connection is established between the second node and a third node, and a third connection is established between the first node and the third node. Each connection may represent a pairing between interfaces of the respective node. As discussed above a connection between two nodes may involve any number of intermediary links or nodes. Assume that this is the case for the third connection and that the third connection between the first and third nodes passes through the second node.

At step430the first node transmits a first request to alter the third connection. The alteration may involve deleting or removing the connection, or performing an administrative modification, such as turning on or turning off alarm monitoring or releasing resources end-to-end. In some embodiments the first request may comprise a path message with the various values entered into various fields based, in part, on the requested alteration. For example, if the first node wants to delete the third connection the path message may be transmitted with the delete bit set to 1. Because the requested alteration is to be made to the third connection, the first request may be relayed by any intermediary nodes along the path used by the third connection. More specifically, the second node may relay the first request to the third node.

After the second node has received the first request and transmitted it to the third node the second node may expect to receive an acknowledgement (ACK) message from the third node indicating that it has received the first request. When the second node does not receive the expected acknowledgement (or if it receives an negative acknowledgement (NACK)) it may determine that the first request has failed. This is shown at step440. The amount of time the second node may wait for an acknowledgment from the third node may be long enough to allow the third node to respond but short enough to allow the second node to send a rejection message to the first node before the first node resends the first request.

At step450the second node determines the cause of the failure. For example, where the second node did not receive the expected ACK message, the second node may determine that the third node is unavailable or the link has been damaged. As another example, if the second node received a NACK message from the third node, then the NACK message may contain a reason why the third node is unable to make the requested alteration.

At step460the second node generates a value for the ErrorSpec TLV field which may be included in a rejection message sent to the first node. The ErrorSpec TLV may be an error code which the first node may recognize. The value of the ErrorSpec TLV may be based on the second node's determination of the cause of the failure.

At step470the second node transmits a rejection message to the first node. In some embodiments the rejection message may be a notify message. Included within the rejection message may be the value of the ErrorSpec TLV field determined at step460. The rejection message may also include a value complementary to a value within the first request. For example, if the first request was a path message with the delete bit set to 1, then the rejection message may be a notify message with the delete bit set to 0. This complementary value, along with the value of the ErrorSpec TLV field, may alert the first node that while the first request may have been successfully received the by the second node, the third node was not able to comply.

Because the requested alteration is to the third connection which includes intermediary nodes, it may be important that any nodes or links used along the route or path of the third connection are also modified in accordance with the requested alteration. Unfortunately, when one of the nodes is unable to receive the request, when it becomes available it may be stranded (e.g., the third node may think the third connection exists, while the first and second nodes have deleted it). In order to help prevent this, when the first node receives the rejection message from the second node it may attempt to ensure that any changes, modification or alterations made by any of the nodes along the path used by the third connection return to their previous state. This may allow the third node to return to service or otherwise become able receive messages again, while the connection is still in the state it was before the third node become unavailable. Thus, the end-to-end state of the connection is preserved.

To accomplish this end-to-end consistency, at step480the first node transmits a second request to alter the third connection. This second request essentially requests that the third connection revert back to the way it was before the first node sent the first request. As before, this may involve the first node sending a path message. However, this time the delete bit may be set to 0 since the first node is attempting return the third connection to its previous state and no longer wants the connection deleted.

Modifications, additions, or omissions may be made to the method without departing from the scope of the invention. The method may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order without departing from the scope of the invention.

FIG. 5is a flowchart illustrating another example embodiment of a method for rejecting a request to alter a connection. Similar to the method depicted inFIG. 4, this method may involve three nodes within an optical network, such as nodes110,120and130of network100depicted inFIG. 1. The method begins with steps500,510and520where the three nodes establish connections with one another. More specifically, a first connection is established between a first node and a second node, a second connection is established between the second node and a third node, and a third connection is established between the first node and the third node. Each connection may represent a pairing between interfaces of the respective node. As discussed above a connection between two nodes may involve any number of intermediary links or nodes. Assume that this is the case for the third connection and that the third connection between the first and third nodes passes through the second node.

At step530the second node transmits a first request to alter the third connection. Because the second node is an intermediary node along the path used by the third connection the request may be different than the request sent by the first node in the method depicted inFIG. 4. More specifically, as opposed to sending a path message, the second node may send a notify message. For example, if the second node wants to make an administrative modification to the third connection it may generate and transmit a notify message in which the administrative status field is set to 0.

In some situations the first node may not be able to receive the first request. For example, the first node may be in a test mode preventing it from being able to send or receive messages to or from other nodes. In a typical optical network, when the first amount of time lapses without a response from the first node the second node may initiate a forced deletion of the third connection. However, because the first node was not able to receive the command deleting the connection, when it becomes available again it will think the third connection is still available while the second and third nodes have deleted the third connection in response to the forced deletion. According to particular embodiments, if at decision step540a first amount of time elapses without the second node receiving a response or acknowledgment from the first node then, at step550, the second node transmits a second request to alter the third connection.

Unlike the second request sent inFIG. 4that was designed to revert the third connection back to its previous state, the second request transmitted at step550may be similar to the first request. More specifically, if the first request comprised a notify message having the administrative status field set to 0, then the second request may similarly comprise a notify message having the administrative status field set to 0.

This cycle of waiting a first amount of time and then retransmitting similar requests may continue until a response from the first node is received at step560. For example, once the first node finishes performing its tests, it may become available again and would therefore be able to respond to the request form the second node. Regardless of whether the first node is able to respond to the first or the twentieth request from the second node, the response may be the same. This may be because, from the perspective of the first node, this is the first time the second node has sent the request. In certain situations the response may comprise a path message, similar to the path message sent inFIG. 4. Because this message is in response to the request from the second node it may contain similar values in the various corresponding fields of the response. For example, because the administrative status bit of the first request was set to 0, the first node may set the administrative status bit of the response to 0.

Modifications, additions, or omissions may be made to the method without departing from the scope of the invention. The method may include more, fewer, or other steps. Additionally, steps may be performed in any suitable order without departing from the scope of the invention.

While this disclosure has been described in terms of certain embodiments and generally associated methods, alterations and permutations of the embodiments and methods will be apparent to those skilled in the art. Accordingly, the above description of example embodiments does not constrain this disclosure. Other changes, substitutions, and alterations are also possible without departing from the spirit and scope of this disclosure, as defined by the following claims.