Cell Relay Archive[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index][Thread Index][Author Index][Subject Index] Re: Part 2 - Cell in Frames
In article <FE7B8F19ED647D12.8C93AEE05CE1F949.33C13CE50488AC7D@lp.airnews.net>, Brad Reese <reese@alliancedatacom.com> wrote: > Hi again Miguel, > > Probably the best "Cells In Frames" web page is the 3Com Cells In Frames > web page: > > http://www.alliancedatacom.com/3com-cells-in-frames.htm > > The web page above gives comprehensive information along with > outstanding visual diagrams. Very interesting site. The point remains, though, that within the Ethernet segments you have no QoS. The hope is that the Ethernet load is light enough that whatever VCs your Ethernet-connected end system has set up can provide the QoS guarantees that had been negotiated during the setup phase of each VC from that end system. The fundamental point is that cells in frames is a concept that allows a cheap Ethernet interface at the desktop to be used instead of an ATM NIC (at the desktop). Using switched Ethernet, where each end system has a dedicated interface, helps, but still cannot be considered a guarantee of QoS. I mean, you will have to worry about potential for frame buffering at the switch, which would easily play havoc with any CDV you might have negotiated for any particular VC. A shared Ethernet would make the CDV problem more acute. And CLR would be pretty hard to guarantee. You can also perhaps implement prioritized queuing within those Ethernet segments, to help "guarantee" different QoS for each VC set up by each end system, but now you have to wonder what ATM cells in that payload buy you. I think the point that CiF is the opposite of LANE was excellent, by the way. It pretty much makes the point that both schemes are obviously compromised. As IEEE 802.3 and IP both add in features to attempt to implement QoS guarantees, then the idea of sending ATM cells inside the Ethernet frame sort of loses appeal. The appeal before was only in so far as the backbone of the network was truly ATM, and the Ethernet portion was simply a convenient end system interface to the ATM switch. Lightly loaded, the Ethernet segment can be considered a cheap and fast physical layer. Heavily loaded, that Ethernet segment will undo what QoS guarantees ATM tries to provide. -- Bert manfredi@arl.bna.boeing.com Sent via Deja.com http://www.deja.com/ Share what you know. Learn what you don't.
|
|