| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Based on the recent email discussion on
scheduling, my following comments.
First, MAC-protocols on rings are required to
coordinate access to the shared medium in a fair manner. If one omits
this protocol, one easily can construct cases where some of the nodes
are unable to transmit. Thus, the MAC will be a crucial part of the
standard.
For ring-speeds of 1 Gbit/s and above, the shared
media can only exploited by simultaneaous access to the medium by many nodes and
by destination removal).
Here, there are only two mechanisms, either a
slotted transmission structure (ATM) or buffer insertion to cope with variable
packet lengths (IP). In case of a slotted structure, packets have to be
segmented at the transmit nodes and reassembled at the receiver nodes. In a ring
with n nodes, each receiver node should have n reassembly machines. With
insertion buffers (transit buffers) complete IP packet can be handled, and this
is today the preferred way. Any thoughts in direction of 802.5 and FDDI
for medium access make no sense.
The insertion buffers are in the transmission path
and therefore all decisions have to operate at full link speeds. Buffers and
complicated scheduling as in Diffserv at 10 Gbit/s, or in future even above that
bit rate, are doable but require a lot of silicon space. Thus, are costly. It
should be the goal to create a standard that allows a small insertion buffer
size and rather simple scheduling. Three classes of traffic on the ring, as
already discussed in emails, would fit completely. This already means that three
parallel insertion buffers must be handled at link speed. This parallel
structure is required to allow for overtaking of packets between the three
priority classes. The jitter of the lowest class becomes of course larger,
but the delay bounds of the higher class traffics can be guaranteed, which is
the most crucial factor in IP-telephony and IP-multimedia. Other QoS policies
should be done above the MAC. Ring nodes should be considered as nodes that have
shared transmission links to all other nodes. Once the packet is given to
the MAC or clocked onto the transmission medium, there is no need for level-3,
etc switching control.
Having a long history in the design and
implementaion of multi-Gbit/s shared-medium rings, the buffers in the
transit path operate for me, without any discussion, always in
cut-through mode. Once on the medium, the packet should be delivered to the
destination with minimal interference by the access traffic of the same
class. I recently learned however that in contrast to my assumption, the
Cisco SRP operates their transit buffers as store-and-foreward. Each
packet is completely received in the transit buffer before forwarding.
Performance will show the difference in end-to-end delay. I like to point out that end-to-end delay will become the most
dominant performance measure in the very near future.The requirements of the
carriers will change when IP-telephony and IP-MM becomes a commodity and
carrier-grade service have to be guaranteed in a simular fashion as in
circuit-switching. When considering only 2.5 Gbit/s and 10 Gbit/s SONET/SDH or
10 GbE the difference will not be very crucial. However, for rings in the lower
bit-rate region in public access, campus, or in-building areas,
providing a huge market, the difference might have an impact on a
broad success of the standard. Scheduling between the insertion
buffers and the transmit buffers can in the same way be done both in
cut-through and store-and-foreward mode. In principle, rings with cut-through
and store-and-forward nodes having the same buffer structure would work
together. Even scheduling between buffers could be different. What has to
be the same is the MAC fairness mechanism.
Best regards
Harmen R. van As
------------------------------------------------------------------
Prof.Dr. Harmen R. van As Institute of Communication Networks Head of Institute Vienna University of Technology Tel +43-1-58801-38800 Favoritenstrasse 9/388 Fax +43-1-58801-38898 A-1040 Vienna, Austria http://www.ikn.tuwien.ac.at email: Harmen.R.van-As@xxxxxxxxxxxx ------------------------------------------------------------------ |