Converting from Frame-relay to ATM. Traffic shape question.

Unanswered Question
Aug 27th, 2008

hello, thanks for your time. i've got an existing frame-relay network with about 100 endpoints and i have a project to convert the head-end host DLCI circuit from a frame-relay T1 to an ATM DS3. The DS3 is in place and I have good end to end communication to my test frame-relay circuit, but i have a question regarding shaping. on my old frame-relay circuit i used frame-relay map classes to specify how large each PVC was. what is the equivalent for ATM? here's what i currently have:

interface ATM4/0.650 point-to-point

description Test Frame

mtu 1500

bandwidth 56

ip address

pvc 1/650

cbr 64


no ilmi manage

oam-pvc manage

the only thing slightly puzzling is that "64" is the lowest setting i can specify. nearly all of my remote circuits are 56k, so i don't know how well that would work. what if i only had a 32k PVC? what then? is there a different way i should do this?

also, currently we use end-to-end keepalives over the frame-relay connections, but i can't find an equivalent feature for ATM that makes it work, is there one? or do i have to unconfigure end-to-end keepalives for all these PVCs?

I have this problem too.
0 votes
  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 0 (0 ratings)
Joseph W. Doherty Wed, 08/27/2008 - 16:44

When mixing ATM and frame, remember the impact of ATM cell tax and cell pading. As a rough rule of thumb - you'll want about 15 to 25% more bandwidth for ATM to match the same bandwidth for frame.

So, instead of being concerned about the 64 CBR overdriving the 56 K remote, the reverse might happen.

For a 32 K PVC, if frame, be more concerned about the actual remote link's physical bandwidth rather than a PVC's CIR. Hopefully none of your remote links will be less than a DS0.


This Discussion