qos routing mechanisms and ospf extensions
DESCRIPTION
QoS Routing Mechanisms and OSPF Extensions. Roch A. Guerin, Ariel Orda, and Douglas Williams. Propose extensions to OSPF to support QoS They discuss path selection algorithms link advertisement mechanisms. Goal: - PowerPoint PPT PresentationTRANSCRIPT
QoS Routing Mechanisms and OSPF Extensions
Roch A. Guerin, Ariel Orda, and Douglas Williams
Propose extensions to OSPF to support QoS
They discuss path selection algorithms link advertisement mechanisms
Goal: improve likelihood of being routed on a
path capable of providing the desired QoS
As little impact on existing OSPF protocol as possible
trade off between simplicity and optimality
Framework
Network design: both best-effort and QoS packets all routers are QoS capable routers can advertise the amount of
resources they have left focus on unicast
flow specifies its desired QoSprotocol returns a path based on
requirementspath could be next-hop or full pathonce a path is identified the flow is
pinned to it
Simplifications
Focus on satisfying bandwidth requirements over minimum number of hops
does not take into account delay sensitive flows
Protocol metrics
Link available bandwidth - current amount of available bandwidth
Hop count - used as a measure of path cost, assume that a path with less hops would consume less network resources
Exact pre-computed paths
Based on Bellman-Ford shortest path algorithm
modify BF to compute maximum available bandwidth on link
At ith iteration of BF we can identify the path with the maximum available bandwidth among paths of at most i hops
On-demand Computationof Paths
More useful in instances where there are a limited number of requests for QoS requests
Based on how often you update the routing tables, on demand can yield better routes due to more updated information
no need to store a routing table
Uses Dijkstra’s algorithmSince Dijkstra is already used in OSPF
implementation would be easierAs algorithm runs only consider links
which can support the bandwidth requirement
Sort the list of next hops based on maximum available bandwidth
Approximate Pre-Computed Paths
Dijkstra-basedQuantize bandwidth valuesmay result in loss of accuracyThe range of possible bandwidth
values are mapped onto fixed number of quantized values (for example low, medium, and high)
Minimum hop count paths are computed for each of the quantized values
flows are then assigned to the path that can carry the smallest value equal to or greater than what it requests
While the algorithm runs, for each of the quantized values it removes from consideration all links which cannot support the required bandwidth
Complexity of Path Selection Algorithms
Worst case Dijkstra O(M log N)Worst case Bellman-Ford 0(H*M)
M: number of edges N: number of links H: upper bound on the number of hops
in a shortest path
H can be as large as N-1, but in practice is usually much smaller
can impose restriction on H making H<<N effectively making the complexity O(M)
Bellman-Ford also allows hop count as a secondary criterion without modifications such as quantizing
If we use approximate pre-computed path selection with Q quantized values its worst case complexity is O(Q*(M log N))
comparable to Bellman-Ford at the expense of sub-optimal solutions
Advertisement of Link State Information
Assumed that each router maintains updated database of the network topology, including the current available bandwidth of each link
Link-state information distribution is according to OSPF specification
The important question is when to distribute this information
An ideal situation would be one where all routers have the most up to date view of the network
This would call for very frequent updates, one every time the available bandwidth on a link changes
neither scalable nor practical
Could use periodic updates Major changes in available bandwidth
could go unnoticed for a full periodBetter to use a hybrid of the two
strategiesSend an update when the current
value of the link is above or below some threshold (say 2)
This implies that when a flow needs b units of bandwidth links with advertised bandwidths of 2b are “safe” and we can discard paths with b/2.
This leads to a new metric, certaintyThere are several ways to incorporate
this into the path selection process
Probabilistic Approach
The bandwidth value can be thought of as a random variable in the range (bl/2, 2*bl) where bl is the last advertised value
assuming uniform distribution you can compute for each bandwidth requirement b the success probability of the link and then run the Bellman Ford algorithm on it
This would mean that we would need to compute a different path for each value of b
Thus this approach is too complex in the case of pre-computed routes.
Simple Approach
Run the standard Bellman Ford algorithm outputting a N*H routing table
let 0.5 <= be the risk proneness of the decision maker, where lower values indicate a higher level of risk
let Hr be the number of hops the decision maker is willing to trade for safety
Then with a request for b units of bandwidth: from the table get hmin, the minimal number
of hops for a path with at least *b units from the table get hmax, the minimal number
of hops on a “safe” path if hmin + Hr >= hmax choose the safe path otherwise choose the path from the table with
maximal bandwidth having at most hmin + Hr
hops
Elaborating on Approach #2
A problem of approach #2 is that efficient paths may be disregarded
We can extend approach #2 by: erasing the links with values less than b/2 assigning a cost of 0 to safe links assigning a cost of 1 to links in the range
(b/2,2b) run the Bellman Ford algorithm with the new
cost function
This results in a huge table which identifies for each bandwidth value and for each number of hops, a path with no more than h hops that has a minimal number of non-safe links with respect to the bandwidth value
gives the decision maker more options
higher complexity in terms of running time and table size
since there are a maximum of M distinct bandwidth values the time and space complexity is O(M*H*M) and O(M*H*N)
Reducing the Complexity of Approach #3
Want to handle the problems of the simple approach without the complexity of the previous approach
Let bmax be the maximal value a link bandwidth can attain
Issue an update when a threshold is crossed
The update advertises the threshold that is closest to its current bandwidth value
This way the ratio between the actual and advertised bandwidth values are kept within the .5 … 2 range
The number of different advertised values is now O(log(bmax)) instead of O(M) as in the previous approach
time and space complexity are reduced to O(M*H*log(bmax)) and O(N*H*log(bmax))
Conclusions
The algorithms presented provide tradeoffs between complexity, accuracy, and ease of implementation
focused mainly on bandwidthfuture work:
relationship with call admission validating their claims with simulation