| Based on this information, a
constraint-based routing process on each node automatically computes
explicit routes for each TT originating from the node, this is, a
label switched path that satisfies the demand requeriments expressed
in the TT's attributes, subject to constraints imposed by resource
availability, administrative policy, and other tolopology
state information. |
| |
| In practice, an operator or automaton, will specify the endpoints of a TT
and attributes which encapsulate the performance expectations and behavioral
characteristics of it. The constraint-based routing framework is then
expected to find a feasible path to satisfy the expectations. |
| |
| A very simple well known heuristic can be used
to find a feasible path if one exists: |
| |
- First, prune resources that do not satisfy the requeriments of
the TT attributes.
- Next, run a shortest path algorithm on the residual
graph.
|
| If a feasible path exists for a single TT, then the above
simple procedure will find it. Additional rules can be specified to break
ties and perform further optimizations. |
| |
|
Implementation Considerations |
| |
| For routers that use topology driven hop by hop IGPs,
constraint-based routing can be incorporated in at least one of two
ways: |
| |
- By extending the current IGP protocols to support
constraint-based routing.
- By adding a constraint-based routing process to each router
which can co-exist with current IGPs.
|
| Additional details associated with implementing constraint-based routing
on layer 3 devices are as follows: |
| |
- Mechanisms for exchange of topology state information between
constraint-based processes.
- Mechanisms for maintainance of topology state information.
- Interaction between constraint-based routing processes and
conventional IGP processes.
- Mechanisms to accomodate the adaptivity requeriments of TTs.
- Mechanisms to accomodate the resilience and survivality
of TTs.
|
