[c-nsp] FR and QoS

[Rodney Dunn]

I'll admit I don't know the ATM part that well.
Depending on how you set the pvc up to cause
the backpressure just a service policy that identifies
the queueing you want should work.

And for FR, it should be:

> interface serial x/y.z
>  frame-relay interface-dlci nnn
>   service-policy out shape-and-queue

if that doesn't work it's a bug.

If you need fragmentation you have to
do:

> interface serial x/y.z
>  frame-relay interface-dlci nnn
   map-class dofragment

map-class dofragment
  fragment size blah
  service-policy out shape-and-queue


The goal of MQC is to try and make it transparent
to the underlying hardware implementation.  It's
not perfect but it's much better than it was before.

> What would be *very nice* would be if
>
> interface (atm|frame) x/y.z
>  service-policy out shape-and-queue
>  (pvc|frame-relay interface-dlci)

I'm not sure what you mean here but if I'm reading
it right that's exactly how you should configure
it.  If it doesn't work it's a bug.
The one gotcha where the above doesn't work is
when you need to do fragmentation that has to
be specified under the map-class.  I'm filing a bug
to see if we can move the functionality under the
"shape" policy to make it more simple.

  
odney


On Thu, Dec 09, 2004 at 03:02:26PM -0000, Tim Franklin wrote:
> Rodney Dunn wrote:
> > The proper way to do it is like this:
> >
> > a) Do you need fragmentation based on the
> >    speed of the PVC?  If not, then define
> >    a hiearchical policy (parent to shape and
> >    child to do the queueing) and attach it to
> >    the PVC.
> 
> Do you mean to the PVC, DCLI or sub-interface?
> 
> interface atm x/y.z point-to-point
>  pvc a/b
>   vbr-nrt c b e
>   service-policy out shape-and-queue
> 
> hasn't been particularly successful, although
> 
> interface atm x/y.z point-to-point
>  pvc a/b
>   vbr-nrt c b e
>   service-policy out queue
> 
> has, taking the shaping from the pvc config.
> 
> Likewise
> 
> interface serial x/y.z
>  frame-relay interface-dlci nnn
>   service-policy out shape-and-queue
> 
> doesn't always work, doing the shaping via a map and applying the policy
> from within the map does, at least most of the time.
> 
> What would be *very nice* would be if
> 
> interface (atm|frame) x/y.z
>  service-policy out shape-and-queue
>  (pvc|frame-relay interface-dlci)
> 
> worked everywhere.  It'd be consistent with each other and with the way I'm
> deploying it on physical interfaces, and our provisioning tool would be able
> to understand it.  However, working support for hierarchical policies seems
> variable, to say the least, especially with the 7600 in the mix :(
> 
> Regards,
> Tim.
> 
> --
> ____________   Tim Franklin                 e: tim at colt.net
> \C/\O/\L/\T/   Product Engineering Manager  w: www.colt.net
>  V  V  V  V    Managed Data Services        t: +44 20 7863 5714
>                                             f: +44 20 7863 5876