Disclaimer
The Author of this posting offers the information contained within this posting without consideration and with the reader's understanding that there's no implied or expressed suitability or fitness for any purpose. Information provided is for informational purposes only and should not be construed as rendering professional advice of any kind. Usage of this posting's information is solely at reader's own risk.
Liability Disclaimer
In no event shall Author be liable for any damages whatsoever (including, without limitation, damages for loss of use, data or profit) arising out of the use or inability to use the posting's information even if Author has been advised of the possibility of such damage.
Posting
You usually configure your ATM side "typical" for ATM PVCs. The provider should map your ATM sides's PVC to your other side's frame-relay PVC. I.e. your provider will need to provide you what frame-relay DLCIs maps to what ATM VPI/VCIs. As far each side is concerned, it generally doesn't realize the other side is using a different WAN cloud technology.
BTW, one thing to note, for the same "kind" of local side WAN links (e.g. T1s), frame-relay has less overhead then ATM, so the frame-relay side can transmit faster than the ATM side can physically accept. I.e. you can have drops and/or queuing latencies within the provider's cloud. (This can be managed with shaping.)
Also BTW, with ATM, its "CIR" (such as VBR's SCR) may be enforced by the interface, if configured. I.e. if you're used to relying on sustained rates above your frame-relay PVC's CIR, such as using full port speed, you might set VBR's SCR to the PCR value. (Also note, my experience, if PCR is less than port rate, ATM vendor will likely enforce the PCR.)
