Overview

The GMPLS path computation entity is expected to consider all user preferences regarding the selection of paths, and to determine one or more optimal paths that have a good likelihood for successful service establishment and that will be operable even when some network resources fail to perform their functions. This chapter looks at why the path computation algorithms described in the previous chapter are not sufficient to handle arbitrary constraints requested by the user, and what can be done to derive suitable algorithms.

What is wrong with the algorithms already described in the previous chapter? For one thing, the user has very little control over the path selection. The algorithms return one shortest path or several disjoint shortest paths. But what if the user does not want shortest paths? For instance, there are multiple reasons why the user would want to avoid using certain arcs or vertices, even if this would make the resulting paths longer. One good example is handling crankbacks. Suppose one or more unsuccessful attempts to set up a service have already been made, and the path computing controller has been notified about all links where the service failed to set up. Arcs representing the failed links must be disregarded in a subsequent path computation; otherwise, the same paths used for the previous attempts will be determined, and the service will fail to set up again. There can also be policy-driven reasons why the user would like to divert a particular service away from certain network...