[c-nsp] ASR9k Bundle QoS in 6.0.1

[Adam Vitkovsky]

> From: Saku Ytti [mailto:saku at ytti.fi]
> Sent: Thursday, June 02, 2016 3:38 PM
> To: Adam Vitkovsky
> Cc: Robert Williams; cisco-nsp at puck.nether.net
> Subject: Re: [c-nsp] ASR9k Bundle QoS in 6.0.1
>
> On 2 June 2016 at 15:55, Adam Vitkovsky <Adam.Vitkovsky at gamma.co.uk>
> wrote:
>
> Hey,
>
> > Arguably there are some benefits in using central arbiter but I'm not
> > really convinced.
>
> I don't believe this how ASR9k works. Considering I have no idea how it
> works, it's pretty bold statement. I'm fit for management.
>
Believe it or not that's how it works, I'm not making this up :).


> > In case of a central arbiter there are out of band links to it. So the
> > requests are sent only to two arbiters (primary/backup).
>
> But for what purpose. What can we possibly gain? Why does fabric1 need to
> know I'm going to use capacity of fabric2? Signalling this information has non-
> trivial cost.
>
Don't think of it as fabric1 and fabric2 but rather as one single crossbar fabric to which inputs and outputs are connected via LAG links. So in case one fabric plane dies one lag member dies on each input and output.

Now let's talk about the arbitration.
For every tick an arbitration process has to know which VOQs would like to transmit to which crossbar outputs as well as what are the relative priorities of the VOQs –in order to know which VOQs should be served first.
To avoid egress fabric drops, for every access request the arbitration process has to confirm with a particular egress port whether it can accept the cell/frame and only if answered positively it can grant access to an input.
First the arbitration process relies access requests for all non-empty VOQ to their desired crossbar outputs, then subset of those will be answered with access grant by the egress outputs and among those the arbitration process will try to find maximal (not to confuse with maximum) match starting from VOQs with highest priority.

Now I chose to use term "arbitration process" on purpose.

It could either mean decentralized arbiters like in MX.
I guess they are using some sort of m-cast messaging so that each arbiter can send a msg that will be heard by all the other arbiters saying: these are my VOQs that need to talk to these outputs and they have these priorities does anyone have any objections e.g. some outputs responding: this output is full at this priority level so no one at this priority level can talk to it. Then follow up query: from the remaining/granted requests does any other input wants to talk to the same output from a VOQ of same priority? –if yes there would need to be some tiebreaking to decide which of the inputs gets to talk to the desired output first). Since all arbiters are doing this decision independently it is essential that they all come to the same conclusion i.e. all of them will pick the same one input among themselves that will start first.

Or it can mean a central arbiter like in ASR9k.
That is the inputs communicate with outputs via central Arbiter –and access messages between inputs, outputs and arbiter are relayed via out-of band links –not cutting into efficient fabric BW.
So no need for back and forth m-cast messages between independent arbiters at each LC arguing who should Tx first.


Now that I look at the length of this post I'm thinking I should write some blog on this, start with basics and build up reader's knowledge step by step before mixing all building blocks together into complex concepts.
As throwing some nuggets here and there like this might actually introduce even more confusion.


adam














        Adam Vitkovsky
        IP Engineer

T:      0333 006 5936
E:      Adam.Vitkovsky at gamma.co.uk
W:      www.gamma.co.uk

This is an email from Gamma Telecom Ltd, trading as “Gamma”. The contents of this email are confidential to the ordinary user of the email address to which it was addressed. This email is not intended to create any legal relationship. No one else may place any reliance upon it, or copy or forward all or any of it in any form (unless otherwise notified). If you receive this email in error, please accept our apologies, we would be obliged if you would telephone our postmaster on +44 (0) 808 178 9652 or email postmaster at gamma.co.uk

Gamma Telecom Limited, a company incorporated in England and Wales, with limited liability, with registered number 04340834, and whose registered office is at 5 Fleet Place London EC4M 7RD and whose principal place of business is at Kings House, Kings Road West, Newbury, Berkshire, RG14 5BY.
---------------------------------------------------------------------------------------
 This email has been scanned for email related threats and delivered safely by Mimecast.
 For more information please visit http://www.mimecast.com
---------------------------------------------------------------------------------------