RE: frame relay to atm conversion tool?
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: BW = IP bandwidth in bits per second (bps) PS = average IP packet size; typically 256 bytes AO = AAL5 Overhead = 8 bytes OH = overhead factor Ceiling((PS+AO)/48) * 53 = ------------------------ PS Ceiling((256+8)/48) * 53 6 * 53 = ------------------------ = ------ = 1.24 (for our 256B example) 256 256 EBW = effective ATM bandwidth in cells per second BW * OH = ------- 53*8 Thus for 512 Kbps IP bandwidth, you need 1497 cps ATM bandwidth assuming 256 byte average packet size. SCR should be at least this. The PCR could be the line rate or equal to SCR. The MBS could be 32 cells (1 MTU packet size at least) for low jitter applications and as high as 256 cells for bursty applications. -Sekar -----Original Message----- From: Brennan_Murphy@NAI.com [mailto:Brennan_Murphy@NAI.com] Sent: Thursday, January 09, 2003 3:08 PM To: nanog@merit.edu Subject: frame relay to atm conversion tool? I'm trying to locate a tool (eg, spreadsheet) to convert throughput on a frame circuit to an ATM circuit. So, for example if you have a 512k CIR with burst to 1024k and 80% of the time you get your burst bandwidth and you want to convert that link to ATM, what corresponding SCR/PCR/MBS values would you need. I'm less concerned with Frame vs ATM protocol overhead than I am with calculating the difference in the way the burst bandwidth is meted out. Any recommendations? Supposing no one knows of such a tool. Would anyone be interesting in helping me put one together? Best Regards, -BM
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
participants (2)
-
Peter E. Fry -
Swaminathan, Sekar