10 messages in net.nether.puck.cisco-nsp[c-nsp] how to validate cell rates?
FromSent OnAttachments
Gert DoeringJan 20, 2005 5:46 am 
Hudson Delbert J Contr 61 CS/SCBNJan 20, 2005 10:58 am 
MADMANJan 20, 2005 11:29 am 
Gert DoeringJan 20, 2005 11:37 am 
Clinton WorkJan 20, 2005 11:49 am 
MADMANJan 20, 2005 12:33 pm 
Gert DoeringJan 20, 2005 12:50 pm 
Gert DoeringJan 20, 2005 1:01 pm 
Clinton WorkJan 20, 2005 1:44 pm 
MADMANJan 20, 2005 2:48 pm 
Actions with this message:
Paste this link in email or IM:
Paste this link in email or IM:
Atom feed for this thread
Paste this URL into your reader:
Subject:[c-nsp] how to validate cell rates?Actions...
From:Clinton Work (clin@scripty.com)
Date:Jan 20, 2005 1:44:40 pm
List:net.nether.puck.cisco-nsp

Gert Doering wrote:

Are the CDVT values specific to the configured VC types? They claim a CDVT value of "750", though I'm not sure what to make out of it, or how to match this to Cisco config statements.

I have only used Alcatel ATM gear a lot. CDVT is supported on both UBR and VBR PVCs. A CDVT value of 750usec is higher than the Alcatel default of 250 usec.

UBR parameters: Peak rate, Min Rate, CDVT VBR parameters: Peak rate, Sustained Rate, CDVT, MBS, CLR

I try to avoid traffic shaping inside the ATM network on ATM PVCs because it causes so many problems when shaping mis-matches occur. If you own the edge equipment on each side of the ATM cloud you can enforce the shapping on the edge equipment. This usually works much better because the edge equipment can take into account packets rather than just ATM cells when enforcing the traffic shaping. You can adjust the DSL port profile to train at a specific up/down rate to avoid the use of PVC traffic shaping.

I'm not sure either what kind of cell variance you get from a Cisco UBR ATM PVC.