Method for managing services in a generalized-multi-protocol label switching, GMPLS, controlled network

1. A method for managing services in a Generalized-Multi-Protocol Label Switching, GMPLS, controlled network under conditions of a disrupted control plane connectivity, wherein nodes of said network use a Resource Reservation Protocol with Traffic Engineering extensions, RSVP-TE, to allocate and provision resources of said network, said method comprising the steps of:

(a) evaluating local RSVP Path or Resv state data by any of said network nodes acting as a sending node, the sending node having sent at least once a signalling message to a receiving node without receipt of an acknowledgement message from said receiving node within a configurable time to determine an IP address of a node being located after the non-responsive receiving node along a service path; and

(b) sending the signalling message by the sending node to the determined IP address of the next node located behind the non-responsive receiving node along a service path,

wherein if a node of said network detects that it did not receive a Path/Resv Refresh message from a neighbouring node along the signal path, the node sends at least one RSVP-TE protocol state verification message comprising a Path state verification (PathVerify) message directed to the upstream neighbouring node or a Resv state verification (ResvVerify) message directed to the downstream neighbouring node,

wherein the node after having sent a configurable number of RSVP-TE protocol state verification messages to the neighbouring node along the signal path receives neither a Path/Resv Refresh nor Tear message from the neighbouring node, the node sends a control plane connectivity disruption, CPCD, alarm message to the service ingress node of the respective service,

wherein the ingress node of the service after having received the control plane connectivity disruption, CPCD, alarm message is adapted to notify a management plane and/or a service operator of the respective service that the service has become at least partially unmanageable

due to a detected control plane connectivity disruption, CPCD, in the signal path and/or to trigger service restoration procedures,

wherein if PathModify, PathTear or ResvErr message reaches the neighbouring node of the non-responsive receiving node having caused the control plane connectivity disruption, CPCD, of the respective service, the neighbouring node sends the message directly to the IP address of the next node located after the non-responsive receiving node in the downstream direction, and

wherein the next node located after the non-responsive receiving node in the downstream direction forwards the message along the signal path of the service until it reaches the egress node of the respective service to possibly release or reprovision network resources associated with the respective service.

2. The method according to claim 1 , wherein if the sending node does not receive an acknowledgement message from the node located behind the non-responsive receiving node along the service path the sending node repeats the evaluating step and the sending step until it receives an acknowledgement message from one of the addressed nodes along the service path or until the addressed node is the service egress or ingress node of the respective service and is not responsive.

3. The method according to claim 1 , wherein if a node of said network detects that it did not receive a Path/Resv Refresh message from a neighbouring node along the signal path, the node sends at least one RSVP-TE protocol state verification message comprising a Path state verification (PathVerify) message directed to the upstream neighbouring node or a Resv state verification (ResvVerify) message directed to the downstream neighbouring node.

4. The method according to claim 3 , wherein the neighbouring node after receipt of a RSVP-TE protocol state verification message looks up a RSVP-TE protocol state of the service specified in the received RSVP-TE protocol state verification message in a local Path/Resv state database.

5. The method according to claim 4 , wherein the neighbouring node responds to the received RSVP-TE protocol state verification message with a Path/Resv Refresh message if the requested RSVP-TE protocol state is found in the Path/Resv state database of said neighbouring node.

6. The method according to claim 5 , wherein the neighbouring node responds to the received RSVP-TE protocol state verification message with a Path/Resv Tear message, if the requested RSVP-TE protocol state is not found in the Path/Resv state database of the neighbouring node.

7. The method according to claim 3 , wherein a node after having sent a configurable number of RSVP-TE protocol state verification messages to a neighbouring node along the signal path receives neither a Path/Resv Refresh nor Tear message from the neighbouring node, the node sends a control plane connectivity disruption, CPCD, alarm message to the service ingress node of the respective service.

8. The method according to claim 7 , wherein the ingress node of the service after having received the control plane connectivity disruption, CPCD, alarm message is adapted to notify a management plane and/or a service operator of the respective service that the service has become at least partially unmanageable due to a detected control plane connectivity disruption, CPCD, in the signal path and/or to trigger service restoration procedures.

9. The method according to claim 8 , wherein if ResvModify, ResvTear or PartErr message reaches the neighbouring node of the non-responsive receiving node having caused the control plane connectivity disruption, CPCD, of the respective service, the neighbouring node sends the message directly to the IP address of the next node located after the non-responsive receiving node in the upstream direction, wherein this node forwards the message along the signal path of the service until it reaches the ingress node of the respective service to possibly release or reprovision network resources associated with the respective service.

10. The method according to claim 7 , wherein if a temporarily failed non-responsive node having caused a control plane connectivity disruption, CPCD, of the service comes back into service and detects that it does not receive a Path/Resv Refresh message from at least one of its neighbouring nodes it sends at least one Path or Resv state verification message (Path/Resv Verify) to the at least one neighbouring node to check the existence of states associated with the respective service to which the at least one neighbouring node, depending whether the verified state exists or not, responds with a PathRefresh/ResvRefresh message to confirm the validity of the service, or a PathTear/ResvTear message to release network resources associated with the respective service.

11. The method according to claim 1 , wherein the signalling message is sent by said sending node to the IP address of the next node located behind the non-responsive receiving node in an IP data packet along a route indicated in an IP routing table of the sending node.

12. The method according to claim 1 , wherein the signalling messages are formed by RSVP-TE messages transported in a data communication network, IP DCN, serving the control plane.