Parallel constraint based path computation using path vector

[0001] This is the first application filed for the present invention.

[0002] Not Applicable.

[0003] The present invention relates to packet data networks, and in particular to methods for parallel constraint based path computation using path vectors in such a network.

[0004] In modern packet data networks, traffic is routed, hop-by-hop between a source node and a destination node, using a path that is computed and allocated in advance. Typically, computation of the path is based on a set of constrains. For example, the path may require allocation of a particular minimum bandwidth, or quality of service (QOS). With this arrangement, links in the path can be rejected or allocated to the path, based on whether or not they can satisfy the defined constraints. Typical path constraints may, for example, include bandwidth, Quality of Service (QoS), and latency (i.e. message wait times).

[0005] Typically, computation of a path is based on network topology information that is gathered by each node. Such topology information is normally distributed within a network (or portion thereof) by way of Link State Advertisement (LSA) messages that are flooded by each node. Thus, each node uses received LSAs to construct a network topology database covering at least the node's nearest neighbour nodes within the network. Subsequently, when a path set-up message is received by the node, a Dijkstra algorithm can be implemented to use the topology data base to select the optimal link for the next hop in the path. The link identifier can then be added to the path set-up message, which is then forwarded through the link to the next node in the path. By this means, a path can be set up, hop-by-hop through the network.

[0006] This arrangement suffers a number of disadvantages. For example, as the size of the network grows, so too must the size of the topology database maintained by each node. For very large networks, this requirement can place a heavy burden on the node's resources, and increases the time required to search the database to find a route (i.e. select the next link) that satisfies the constraints.

[0007] An additional limitation of this approach is that it cannot readily accommodate intransitive constraints within the network. For example, consider three nodes A, B and C, connected together by pair of links A-B and B-C, as shown in FIG. 1. Conventional constraint-based routing algorithms assume that all path and network constraints are transitive. Thus, if both links A-B and B-C satisfy the path constraints, then the combined path A-B-C, formed by concatenating the two links via node B, will also satisfy the path constraints. However, in the case of intransitive constraints this assumption may not, in fact, be true.

[0008] For example, consider the case of a photonic network, in which node B is a photonic (that is, all-optical) switch. Each link A-B and B-C, taken alone, may satisfy all constraints, and may thus be usable. However, concatenating the two links together through (photonic) node B, to form path A-B-C, may exceed the permissible optical signal reach (e.g. due to dispersion), which would violate a network constraint and thus not be permitted. Another example involves the routing of traffic through node B, between link A-B and link B-C. Conventional routing protocols assume that node B (and every other node, for that matter) is able to map every input port to any output port, so that the required routing of traffic through node B is inherently possible. However, in a network that implements a form of time division multiplexing, node B may not, in fact, be able to route traffic from link A-B to link B-C. An example of this situation would be a case where links A-B and B-C support different sets of timeslots. In such a case, it may not be possible to route traffic from link A-B to link B-C, because they share no common free timeslot. This is a common problem on SONET rings, where timeslots must be unchanged during traversal of all segments on the ring.

[0009] Conventional constraint-based routing protocols can deal with intransitive constraints such as those described above, but only by compounding the size and complexity of the topology database. In particular, the topology database must be expanded to include, in addition to information on each link, information regarding each intra-node route between the links hosted by each node. For a network (or network region) having N links, this increases the size of the topology database by about N² entries. As the size of the network (i.e. number of links N) increases, the size of the topology database and volume of LSA messaging rapidly become unmanageable.

[0010] Accordingly, techniques for constraint-based routing in a large network having intransitive constraints remains highly desirable.

[0011] Accordingly, an object of the present invention is to provide methods for constraint-based routing in a large network having intransitive constraints.

[0012] Thus, an aspect of the present invention provides a method of computing a path through a network between a source node and a destination node. At the source node, an explore message is launched into at least one link hosted by the source node. The explore message includes a path vector containing a node identifier of the source node. At a node intermediate the source node and the destination node, the explore message is received, and each link hosted by the node that can be operably added to the path is identified. A respective node identifier of the node is added to the path vector of the explore message, which is then forwarded through each identified link. At the destination node, the respective path vector is extracted from at least one received explore message.

[0017] It will be noted that throughout the appended drawings, like features are identified by like reference numerals.

[0018] The present invention provides methods for constraint-based routing in a large network having intransitive constraints. Embodiments of the invention are described below, by way of example only, with reference to FIGS. 2a-3b.

[0019] In general, the present invention avoids the need for maintenance of a large topology database at each node, by replacing the conventional LSA flooding and hop-by-hop path computation behaviours with a distributed computing model. Accordingly, the topology data base maintained by each node can be restricted to information in respect of links hosted by the node itself, and intra-node connections between those links. Those of ordinary skill in the art will recognise that each node can thus populate its topology database by internal “self-discovery”, and no flooding of LSA's into the network is required. Since the number of links within the topology database of the node is limited to those links that are hosted by the node, both transitive and intransitive constraints can be accommodated without unmanageably increasing the size of the topology database. Furthermore, since the need for flooding LSA's has been eliminated, network resources are no longer burdened carrying ever increasing numbers of LSA's.

[0020] In order to compute a path through the network, a source node uses its database to select links capable of satisfying at least transitive constraints of the path; generates an “explore” message containing its unique node ID as a path vector; and then forwards the explore message into the selected links. When a node receives an explore message, it uses its database to identify those links that can be added to the path (as indicated by the explore message's path vector). At a minimum, this means that the node must identify those links that can satisfy both transitive and intransitive constraints of the path. Thus, each identified link: meets path bandwidth, QoS requirements, for example; can be reached, through the node, from the link through which the explore message was received; and can be added to the path without violating any network or system constraints (such as dispersion limits). In addition, any links that lead back to a node that is already identified in the path vector are preferably excluded, which prevents explore messages from “doubling back” to a previously visited node and/or circulating endlessly within a closed loop of nodes within the network. The node then adds its unique node ID to the path vector and then forwards the explore message through each of the selected links. By this means, explore messages will propagate through the network from the source node toward the destination node.

[0021] If any paths through the network exist which satisfy all applicable constraints, then corresponding explore messages will arrive at the destination node. The respective path vector of each received explore message traces a viable path through the network. Accordingly, the destination node can examine the path vectors of and/all received explore message (e.g. received within a predetermined time period), and select the best path. This selection may, for example, be based on path length or other criteria, as desired.

[0022] Once the destination node has selected the preferred path, a corresponding path set-up message can be generated and sent back to the source node. Conveniently, the path vector of the selected path can be used to control forwarding of the path set-up message, so that it retraces the path back through the network. As a result, nodes that do not participate in the path will not receive the path set-up message.

[0023] The above-noted method will be described below with reference to FIGS. 2 and 3.

[0024] As may be seen in FIG. 2, for the purposes of example, a network of five nodes includes a source node, a destination node and three intermediate nodes A, B and C. Each of the nodes are interconnected by respective links, and intra-node routes are defined for connecting the links through each node. Each node maintains its own database which contains information detailing the availability of each link hosted by the node; and the availability of each intra-node route between the hosted links. For ease of illustration, only one database is illustrated in the figure. If desired, the availability may be indicated by a binary value (as in the figure) or by means of a link metric in a manner well known in the art.

[0025] For the purposes of the present example, it is assumed that that link AD cannot be concatenated with link SA through intermediate node A for any reason. Possible reasons for such an intransitive constraint may be an inability of node A to map traffic between links SA and AD without violating a latency requirement, or, in the case of a photonic node, photonically concatenating links SA and AD may violate a dispersion limit of the network. In any event, this constraint is reflected in the database of node A. Additionally, it is assumed that the link BD is not available for any reason, and this fact will be noted in the respective database (not shown) of node B. Note that since topology information is not shared between network nodes, for example via conventional LSA messaging, the inability of node A to map traffic between links SA and AD is not conveyed to any other nodes, and thus does not, for example, appear in node B's database. Similarly, the unavailability of link BD is not conveyed to either of nodes A or C, for example.

[0026] As shown in FIG. 2a, the source node S generates an explore message containing its node ID as the first entry in a path vector of the message. The explore message is then flooded into every path hosted by source node S that will support the path constraints. In the illustrated example, all of paths SA, SB and SC are available, so an identical explore message is launched through each link.

[0027] As shown in FIG. 2b, each of intermediate nodes A, B and C respond to the explore message in the same manner. In particular, each node uses its database to select those links that: satisfy the path constraints; are reachable through the node; and do not connect to a node that is already in the path vector. Thus, for example, node A receives the explore message from node S via its link SA. In response to this explore message, node A searches its database, and finds that all of links AS, AB and AD can meet the path constraints. However, link AS leads back to node S, which is already in the path vector of the explore message, and link AD cannot be reached from path SA. Only link AB satisfies all of the criteria. Accordingly, Node A adds its node ID to the path vector, and sends the explore message through link AB.

[0028] Similarly, node B receives the explore message from node S via its link SB. In response to this explore message, node B searches its database, and finds that all of links BA, BD, BC and BS can be reached from link SB. However, link BS leads back to node S, which is already in the path vector of the explore message, and link BD cannot support the path constraints. Only links BA and BC satisfy all of the criteria. Accordingly, Node B adds its node ID to the path vector, and sends the explore message through links BA and BC.

[0029] In the same manner, node C receives the explore message from node S via its link SC. In response to this explore message, node C searches its database, and finds that all of links CB, CD and CS can be reached from link SC, and each of these links can support the path constraints. However, link CS leads back to node S, which is already in the path vector of the explore message. Accordingly, Node C adds its node ID to the path vector, and sends the explore message through links CB and CD.

[0030] As a result of the above operations, the destination node will receive an explore message from node C, with the path vector [S,C], indicating that a viable path can be set up between the source and destination nodes via node C. If desired, the destination node can proceed with set-up of the path immediately upon receipt of this first explore message. Alternatively, it can wait (e.g. for a predetermined period of time) for any other explore messages that may arrive, and then select a preferred path from among the path vectors provided by each of the received explore messages. For example, FIGS. 2c and 2d illustrate that explore messages will continue to flow within the network, following the pattern described above, until all possible paths through the network have been explored and the corresponding explore messages either arrive at the destination node or are discarded (in the case of a non-viable path).

[0031] As may be seen in FIG. 2d, the result of the above process is the assembly of a listing of all viable paths through the network between the source and destination nodes. Based on this information, the destination node can select one or more desired routes, and initiate the set-up of each route. As described above, this selection may be based on the first-arriving explore message, but other criteria may be used. For example, the shortest path may be selected. Alternatively, two or more diverse paths may be selected, in which case the path vectors can be used to maximize the diversity between the paths. Other selection criteria will be readily apparent to those of ordinary skill in the art, without departing from the scope of the present invention.

[0032] Once the desired path(s) has/have been selected, the destination node can initiate setup of the path(s). Various methods may be used for this purpose. For example, the destination node may send an acknowledgement message, which contains the path vector of each selected path, back to the source node. In response to the acknowledgement message, the source node can then launch a path set-up message to trigger hop-by-hop allocation of node and link resources to the path in a generally conventional manner. The only deviation from conventional path set-up processing methods is that, in this case, the path vector can be used to control which nodes and links are allocated to the path, so that nodes that are not part of the path will not receive (and thus will not have to process) the path set-up message.

[0033] In an alternative arrangement, the destination node may simply launch the path set-up message, rather than the acknowledgement. In this case, the path set-up message follows a reverse path vector (or executes a trace-back of the path vector) so that the path is set-up between the destination node and the source node. FIGS. 3a and 3b illustrate respective examples of this path set-up scenario. In particular, FIG. 3a illustrates the route traversed by a path set-up message that retraces the path vector [S,C] accumulated by the first explore message received by the destination node (see FIG. 2b). This path vector also corresponds with a shortest path, at least in terms of the number of hops. FIG. 3b illustrates a scenario in which the path vectors of explore messages received by the destination node are used to select and set up topologically diverse paths. In this case, two paths are set up, in which the respective set-up messages retrace the path vectors [S,C] and [S,B,A].

[0034] 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.