frame relay to atm conversion tool?

Brennan_Murphy at NAI.com Brennan_Murphy at NAI.com
Fri Jan 10 14:44:36 UTC 2003


I came across a decent Cisco article that discusses how
to calculate traffic shaping parameters for links
that are on one end ATM and the other Frame relay.

http://www.cisco.com/warp/public/121/frf8_shaping.html

The second to the last paragraph in that article
suggests that ATM SCR's should be shaped at
15-20% higher than Frame CIR's. But there is no
corresponding conclusion about how to equate 
burst space.

There's been a few responses from people interested
in helping get a tool together to make these calculations
simpler and more accurate.  I'm still seeking 
comments on this though so if you've got something
to add, please do!  

Once I feel like we've choked out enough comments to
get to work on this, I'll contact those interested
parties offline about next steps. 

Thanks,
BM



-----Original Message-----
From: Peter E. Fry [mailto:pfry at swbell.net]
Sent: Thursday, January 09, 2003 10:46 PM
To: nanog at merit.edu
Subject: RE: frame relay to atm conversion tool?



On 9 Jan 2003 at 17:45, Swaminathan, Sekar wrote:

> Instead of Frame Relay frames, you have to look at the
> payload which is usually IP packets. Here is the formula
> that I would use: [...]

  Specifying an "average packet size" is rough: I've observed that on 
an "average Internet connection" around 35% of packets are 64 bytes, 
35% 1500 bytes, and the remainder scattered about.  The average is 
guaranteed to be a poor match for at least 70% of your traffic.
  Not that it matters.  Most carriers configure FRATM VCCs as 
"1536kbps frame relay = 4500cps", treating fractions accordingly.  
The last thing you want to do is exceed this cell rate (around 
1710kbps at a 1500-byte packet size), as on a policed link you'll 
lose nonconforming cells.  (Actually, a 1536kb frame relay seems to 
be closer to a 1705kb ATM VCC.  Eh, the IWF has to buffer some 
anyway.)  If you increase your cell rates you potentially 
oversubscribe your frame link (and the IWF may disallow it in any 
case).  So if you're tempted to exceed this ratio be very certain of 
your link characteristics.
  Add to that: when a sustained rate is defined (VBR service 
category) the ATM peak rate probably doesn't mean what you would 
expect, so I recommend sustained = peak.  (ABR is the best match for 
data, but isn't often used.)
  As to the original question, I wouldn't recommend translating a 
burstable frame to ATM unless you can order an ABR VCC or get UPC 
and/or frame discard disabled on your link (don't bet on it).  It's 
not likely you can match parameters, so without flow control you're 
essentially looking at reduced performance or packet loss under load. 
 Whatever you do get, I recommend you ask your carrier for a spec.  
You have plenty of variables and relatively robust protocols, meaning 
you could take a shot, miss, and only find out for certain that you 
had when you'd really rather not.  Get it reasonably right, though, 
and it'll do right by you.
  Huh.  Now that I look at it, I need to rethink my own figures yet 
again (I haven't even implemented the last rethink) as I appear to 
have tended toward the conservative in some areas.  Grrr.

Take it easy.

Peter E. Fry



More information about the NANOG mailing list