[Nml-wg] Metrics for pathfinding

Sun Jun 9 11:43:02 EDT 2013

Guys,

I had a discussion on this topic with Freek and he asked if I would repeat it in an e-mail to the group.  I am going to explain how OpenDRAC does this, but I in no way say this is the correct way to do it.  It just happens to be how we originally did it inside of Nortel.

OpenDRAC has two routing metrics called "cost" and "metric2".  There are historical reasons for the naming I will not get into, but it boils down to two attributes the customer can used for routing.  The routing algorithm in OpenDRAC is a modified dijkstra's configurable to minimize based on hops, cost, or metric2.  We support routing on a single value at a time. We do not care what values are placed in the metrics, we just use them when asked to route minimize on a specific one.  The network administrator can configure any value they deem useful, and we have customers do some interesting things with these values.  For example, we had one customer configure the majority of links at a cost of 1, and certain historically high congestion links a higher value so they were only chosen when no other valid paths existed.  This had the result of diverting dynamically routed circuits from these core links.  Other obvious uses are for modelling link delay is this is a critical attribute for minimization.  SURFnet has also assigned huge values to links when they temporarily want to block a route from being used.

OpenDRAC also supported diverse routing based on node and SRLG values.  We supported a simple model where an administrator could assign a set of integers to a link representing the shared risk.  When asked to route a protected path, or asked to route one path diverse from a second path, we would exclude all nodes and resources with SRLG values from the first path before path computation.  We did not support route optimization for two path simultaneously.  We routed one path then the second.  This could result in blocking of potential protection paths, but simplified our implementation.

John

On 2013-06-06, at 10:09 PM, Aaron Brown <aaron at internet2.edu> wrote:

> Hey Freek,
> 
> On Jun 6, 2013, at 11:45 AM, Freek Dijkstra <Freek.Dijkstra at surfsara.nl> wrote:
> 
>> On 06-06-2013 16:51, Paul Boven wrote:
>> 
>>> [...]
>>> At first glance, I would suggest adding attributes such as length,
>>> weight (preference) and bandwidth - as NML is extensible, should such
>>> extensions be coordinated by the NML-WG, or extensions that NSI
>>> themselves could create? Given the basic nature of these attributes, it
>>> would probably be best to have them centrally registered, to prevent
>>> multiple, incompatible versions (Length in m or km? Bandwidth in b/s or
>>> Mb/s?) from occurring.
>> 
>> I would like to see delay (in ms), (maximum) capacity of Links, and
>> (maximum) capacity and MTU of ports.
>> 
>> The problem with capacity is that it is highly non-trivial for the main
>> technology in use today, Ethernet. Two notes:
>> * Maximum achievable bandwidth of a channel (VLAN) depends on frame size
>> and interframe gap, and header size. (Most technologies define bandwidth
>> of the payload; to avoid these issues, Ethernet defines the bandwidth of
>> the underlying medium)
>> * Ethernet does not work with a achievable bandwidth, but instead
>> defines Committed Information Rate (CIR), Excess Information Rate (EIR),
>> Committed Burst Size (CBS), and Excess Burst Size (EBS).
>> 
>> For this reason, the proposal to make generic definitions was rejected
>> at OGF35, and it was suggested to define technology-specific definition
>> for each technology.
>> 
>> I agree that the above issues are irrelevant for a "rough estimate" as
>> you need. My fear is that we introduce a "rough estimate", an
>> application may later use it to check if it is possible to fit a data
>> flow within a pipe (thus is the bandwidth of the data flow is smaller
>> than the capacity of the pipe). GMPLS is doing this.
>> 
>> For reference, see http://tools.ietf.org/html/rfc6003#section-4.1 for
>> how GMPLS defined the bandwidth. I personally think it is way too complex.
>> 
>> Maybe we have to pick, and make some "experimental" parameter:
>> * Do you want a parameter that describes the capacity of the data flow
>> including or excluding the header?
>> * For Ethernet, do you want a parameter that defines the CIR or PIR
>> (=CIR+EIR), or do you prefer two (or four) parameters?
> 
> Similar to your bandwidth example above, 'delay' has a highly screwing meaning depending on the link (e.g. if an end-to-end link covers 3 physical links and 2 switches, what is its delay? does that include any latency added by the switches? is it average, minimum, or maximum delay?). For bandwidth, in general, I think if folks are really expecting that 9Gbps really means they can send 9000000000 bits of traffic on the link with no issues, they're going to be in for a rude awakening anyway, and it won't much matter with that 9Gbps includes headers or not.
> 
> I think if we can come up with some reasonable defaults that roughly account for what most people are expecting, that's probably fine. If folks find that definition of delay, or bandwidth, or whatever, is not to their liking, they can create a new parameter. The other big thing to think about is how people are going to populate this field. It doesn't matter if the documentation says "this must include headers", or "this must not include headers", because people will likely put in what they think should be in there, and there's not really a good way to say "that's not what i right" unless you have very in-depth knowledge of their network.
> 
> Cheers,
> Aaron
> 
>> 
>> Freek
>> _______________________________________________
>> nml-wg mailing list
>> nml-wg at ogf.org
>> https://www.ogf.org/mailman/listinfo/nml-wg
>> 
> 
> ESnet/Internet2 Focused Technical Workshop
> Network Issues for Life Sciences Research
> July 17 - 18, 2013, Berkeley CA
> http://events.internet2.edu/2013/ftw-life-sciences/
> 
> _______________________________________________
> nml-wg mailing list
> nml-wg at ogf.org
> https://www.ogf.org/mailman/listinfo/nml-wg

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ogf.org/pipermail/nml-wg/attachments/20130609/999e9bb7/attachment.html>