Cell Relay Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: Interworking between frame relay and ATM networks
In article <64pv7i$2hg@ssbunews.ih.lucent.com>, ronaldd@ihgp3.ih.lucent.com (-Davis,R.H.) wrote: ">"In article <ays-0811971807460001@korea-154.ppp.hooked.net>, ">"Alan Y. Schaevitz <ays@hooked.net> wrote: ">"> ">">Since there are no traffic control and congestion control mechanisms ">">specified in frame relay, there can be no standardized interworking of ">">such. All such traffic/congestion mechanisms in frame relay are ">">proprietary. The rudimentary utilization of FECN, BECN and DE in frame ">">relay do have a translation to ATM's EFCI and CPI bits but this can hardly ">">be labeled traffic or congestion control mechanisms. THe mapping between ">">these bits can be found in the frame relay forum specifications FRF.5 ">">(FR/ATM Network Interworking) and FRF.8 (FR/ATM Service Interworking). ">">THese can be found on the Frame Relay Forums WEB page (www.frforum.com). ">"> ">" ">"there is a service specific convergence sublayer defined for frame ">"relay service over atm (using aal 5). if i recall correctly, it ">"may be found in itu recommendation i.365.1. ">" I think you may be confusing ATM with frame relay. There is an end-to-end reliable transport protocol defined for ATM called SSCOP (Service Specific Connection Oriented Protocol) that is an SSCS implementation (It is specified in the Signalling AAL or SAAL) for the ATM signaling application along with AAL5. However, there is still no such mechanism defined for frame relay. So while the ATM core can have congestion/flow control and end-to-end recovery, the frame relay access cannot. Alan -- Alan Y. Schaevitz AYS Associates ays@hooked.net |
|