A method of creating/terminating a connection associated with an end-to-end path defined through a communications network. According to the invention, cross-connection download/undownload processes in each intermediate node of the end-to-end path are triggered substantially in parallel. A confirmation message indicative of successful completion of respective download/undownload processes in each intermediate node is subsequently propagated to an end-node of the path.

CROSS-REFERENCE TO RELATED APPLICATIONS

MICROFICHE APPENDIX

Not Applicable.

TECHNICAL FIELD

The present invention relates to connection creation and termination in communications networks, and in particular to connection creation/termination using parallel cross-connection download/undownload processes.

BACKGROUND OF THE INVENTION

Within the modern communications network space, various standards are used to create and terminate connections. Among these, there is Multi-Protocol Label Switching (MPLS); Generalized Multi-Protocol Label Switching (GMPLS); Label Distribution Protocol (LDP);Private Network-Network Interface (PNNI); Resource Reservation Setup Protocol (RSVP), and others. As is known in the art, all of these connection-oriented protocols (such as, for example, MPLS/GMPLS; LDP/CR-LDP); PNNI; RSVP etc.) provide a protocol for computing a path through a network, and reserving resources of each node involved in the path. Typically, for each node of the path, resource reservation involves designating involved input and output ports, as well as a portion of the bandwidth capacity of each designated port required for the connection. However, in order to set-up the end-to-end connection, and thereby enable a flow of subscriber traffic, each node must compute and set up the cross-connection through its switch fabric between the designated ports. This step of computing and establishing the cross-connection is referred to herein as “downloading” the cross-connection. The reverse process, that is the removal of the cross-connection so that resources of the node can be released for use by other connections, is referred to herein as “undownloading” the cross-connection. The process of downloading cross-connections is illustrated inFIG. 1, for the example of the proposed Constrain-based Routed-Label Distribution Protocol (CR-LDP).

FIG. 1shows a representative path2mapped through a CD-LDP network between an ingress node4and an egress node6, and traversing three intermediate nodes N1-N3. As shown inFIG. 1, once the path2has been computed and resources reserved (at8), a Label_Map message10is propagated hop-by-hop from the egress node6. In response to the Label_Map message, each intermediate node N1-N3downloads (at12) the required cross-connection through the node between respective input and output ports for which resources have been reserved to the connection. Thus, for example, the respective controller unit (not shown) of intermediate node N3computes the cross-connection between ports F and G, and then establishes the computed cross-connection through its switch fabric (not shown), so that subscriber traffic of the connection will be properly routed through that node. Upon successful completion of the download, the Label_Map message10is then forwarded to intermediate node N2, which executes the cross-connection download between its ports D and E. Upon successful completion of the download, node N2forwards the Label_Map message10to node N1, and so on, until the Label_Map message10arrives at the ingress node4. The ingress node4responds to the Label-Map message10by notifying the subscriber (not shown) that the connection2has been established, and is ready to convey traffic, and logs the connection for billing purposes.

A directly analogous process is used when the connection is to be terminated, and the resources released. Thus, as shown inFIG. 2, a Label_Withdraw message (continuing the above CR-LDP example) is propagated hop-by-hop through the connection2from the egress node6. In response to the Label_Withdraw message14, each intermediate node N1-N3un-downloads the cross-connection through the node, so that switch fabric and port resources dedicated to the connection2are released. Upon successful completion of the un-download, the Label_Withdraw message14is then forwarded to the next node, and so on. When the Label_Withdraw message14arrives at the ingress node4, termination of the connection is complete and can be logged for billing purposes.

A limitation of the above connection creation/termination process is that connection download and undownload process require a certain amount of time to complete. For example, in large routers or switches, the process of computing and establishing a cross-connection between input and output ports can take a relatively long time. Since this operation must be performed in each node involved in the connection2, the cumulative time required to create the connection can become significant. This is particularly disadvantageous in the case of failure restoration, where it becomes necessary to create a protection connection around a failed link. Clearly, any delay in restoring traffic flow between the ingress and egress nodes4and6is undesirable, and should be minimised.

Accordingly, techniques for efficiently downloading/undownloading cross-connections in a network remain highly desirable.

SUMMARY OF THE INVENTION

An object of the present invention is to provide a method of efficiently downloading/undownloading cross-connections in a network.

Accordingly, an aspect of the present invention provides a method of creating/terminating a connection associated with an end-to-end path defined through a communications network. According to the invention, cross-connection download/undownload processes in each intermediate node of the end-to-end path are triggered substantially in parallel. A confirmation message indicative of successful completion of respective download/undownload processes in each intermediate node is subsequently propagated to an end-node of the path.

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

The present invention provides a method of creating/terminating a connection associated with an end-to-end path defined through a communications network. A representative embodiment of the invention is described below with reference toFIGS. 3 and 4.

In general, the present invention operates by triggering the download/undownload process in each intermediate node of the path substantially in parallel. A confirmation message is then propagated through the path as the process is successfully completed in each node. In the case of a CR-LDP network illustrated inFIG. 3, this can be accomplished by adding a “Download_Trigger” message type to the CR-LDP standard. Accordingly, upon completion of the conventional path computation and resource reservation signalling (at8), the egress node6launches the Download_Trigger message18through the path2toward the ingress node4. The Download_Trigger message18thus propagates hop-by-hop through the path2. At each intermediate node N1-N3, the Download_Trigger message18is forwarded to the next adjacent node with minimum delay. At the same time, however, the cross-connection download12is initiated. Consequently, respective downloads will be executed in all the intermediate nodes in parallel.

Following launch of the Download_Trigger message18, the egress node6also launches the conventional CR-LDP Label_Map message10, which is then propagated hop-by-hop toward the ingress node4. In this case, the CR-LDP protocol is modified such that, the Label_Map message10does not cause initiation of the cross-connection download12. Instead, the Label_Map message10is simply held in each intermediate node N1-N3until the node's respective download12has successfully completed. Once this occurs, the Label_Map message10is forwarded to the next adjacent node in the path2. As may be seen, the Label_Map message10therefore serves as a “confirmation message” indicating successful download of cross-connections in each node of the end-to-end path2.

Because the Label_Map message10is held in each intermediate node until successful completion of that node's cross-connection download12, the actual timing of the launch of the Label_Map message10by the egress node6is not critical. For example, the Label_Map message10may be launched immediately following the Download_Trigger message18. At the first intermediate node (i.e. node N3inFIG. 3) the Download_Trigger message18is immediately forwarded (to N2inFIG. 3) and the Label_Map message10held until completion of node N3's download process12. Since downloads typically take about the same amount of time in each node, the Label_Map message will arrive at node N2at about the same time that node's download process is completing. In such a case, the Label_Map message10would then be forwarded (to N1inFIG. 3) with minimal further delay. The same situation will normally exist in each intermediate node of the path, so that most of the propagation delay experienced by the Label_Map message10will occur in the first intermediate node (node N3) of the path2, as may be seen inFIG. 3.

As may be appreciated, parallel execution of download processes in each involved node of the path2dramatically reduces the total time required to set up the end-to-end connection, as compared to conventional methods in which cross-connections are downloaded consecutively as the Label_Map message10propagates through the path.

Referring now toFIG. 4, a directly analogous process can be implemented to undownload cross-connections, and thereby release node resources for use in other connections. In the case of a CR-LDP network, an “UnDownload_Trigger” message type can be added to the CR-LDP standard. Accordingly, to complete the connection termination signalling (at20), the egress node6launches the UnDownload_Trigger message22, which propagates hop-by-hop through the connection. At each intermediate node N1-N3, the UnDownload_Trigger message22is forwarded to the next adjacent node with minimum delay. At the same time, however, the cross-connection undownload16is initiated. Consequently, respective undownload procedure16will be executed in all the intermediate nodes in parallel.

Following launch of the UnDownload_Trigger message22, the egress node6also launches the conventional CR-LDP Label_Withdraw message14, which is then propagated hop-by-hop toward the ingress node4. In this case, the CR-LDP protocol is modified, such that the Label_Withdraw message14does not cause initiation of the undownload process16. Instead, the Label_Withdraw message14is simply held in each intermediate node until that node's respective undownload process16has successfully completed. Once this occurs, the Label_Withdraw message14is forwarded to the next adjacent node in the path. As may be seen, the Label_Withdraw message therefore serves as a “confirmation message” indicating successful undownload of cross-connections in each node of the end-to-end path2.

Because the Label_Withdraw message14is held in each intermediate node N1-N3until successful completion of that node's undownload process16, the actual timing of the launch of the Label_Withdraw message14by the egress node6is not critical. For example, the Label_Withdraw message14may be launched immediately following the UnDownload_Trigger message22. At the first intermediate node (node N3inFIG. 4) the UnDownload_Trigger message22is immediately forwarded (to N2inFIG. 4) and the Label_Withdraw message14held until completion of node N3's undownload process16. Since the undownload process typically takes about the same amount of time in each node, the Label_Withdraw message14will arrive at node N2at about the same time that node's undownload16is completing. In such a case, the Label_Withdraw message14would then be forwarded (to N1inFIG. 4) with minimal further delay. The same situation will normally exist in each intermediate node of the path2, so that most of the propagation delay experienced by the Label_Withdraw message14will occur in the first intermediate node (node N3) of the path, as may be seen inFIG. 4.

In the foregoing description, the present invention is described by way of a representative embodiment deployed in a CR-LDP network. However, those of ordinary skill in the art will recognise that the present invention can equally be deployed in any network designed for connection-oriented traffic flows. As such, it will be appreciated that the present invention is in no way limited to the specific example described above with reference toFIGS. 3 and 4.

The embodiment(s) of the invention described above is(are) intended to be exemplary only. The scope of the invention is therefore intended to be limited solely by the scope of the appended claims.