Conference noted::atm

In article <[email protected]>, [email protected] (Kouhei Hayakawa, NPB/MS, Osaka HUB6F) writes:

> 	My customer asked me about mechanism of ATMworks350 and 351.
> 	Does the ATM NICs have priority queue mechanism per VCs?
> 	And is there documentations about structure of ATMworks350 and
> 	351? They want to know it.

I'm not familiar with the details of the 351 but I know about the 350
(and 750).

The transmit side of the 350 supports 3 types of VCs:
  CBR
  ABR without flow control
  ABR with flow control

CBR is simple.  There is a large table.  Each time the hardware
is ready to send another cell, the uCode looks in the next slot
in the table.  If there is a VC there and that VC has a cell
ready to send then it is sent.  Otherwise try an ABR VC.

Note that each CBR VC has an assigned bandwidth determined
from the number of slots assigned in the table.  You can't
overbook - the sum of the allocated bandwidths is at most
100% of the wire.

CBR provides two guarantees - a max bandwidth (load) to the
network and a min bandwidth to the user.


All transmit slots that are not used by CBR VCs can be used
by ABR VCs.  ABR VCs are serviced in round robbin "priority".
That is all ABR VCs have the same priority.  All ready ABR VCs
are kept on the transmit ready queue.  Whenever an ABR cell is
send, that VC goes to the end of the queue if it still has
another cell to send and for flow-controled VCs if it still
has at least one credit.

When a flow controled VC that was marked not-ready because
it was out of credits receives a credit and it has at least
one cell to send, it gets added to the end of the ready queue.



The ATMworks 350 has no provision for pacing of ABR VCs.  If only
one ABR VC is ready, all the cells in a packet can get sent at
full line rate (back to back).

The CBR table can be used as a crude/hack way to limit the rate
at which cells are sent into the network.  This can help a lot
if you are sending through a switch with small buffers.  A serious
problem with this approach is that the sum of the allocated
bandwidth must be less than the line rate.  [You can't have
14 VCs each set to 10 megabits.  10*14 is greater than 135.  (I
measure bandwidth by the cell payload so the limit for OC-3C is
135.63 megabits.)]
[posted by Notes-News gateway]

.1 explains how ATMW 350/750 works (means what it supports).

Having a closer look at this unveils that not necessarily all features of an
Adapter are supported by the *device driver* of the OS (i.e. CBR wasn't
supported until DU 4.0)

A note to the usage of ABR:
ATM FORUM ABR means implicitely that you have rate based, end to end flow
control.

.1's usage of the term ABR means something different:
	assuming you have n cells to fill using the scheduling table and
	you filled m (m<n) cells with CBR traffic, the remaining n-m cells
	are *available* to be filled with non-CBR traffic.

Thus, using the wording of the ATM FORUM we only support CBR and UBR (as there's
no ATM FORUM flow control implemented yet).

In addition to .1 I'd like mention what the ATM sub system of DU 4.0x (don't
know about other OS like NT or OVMS) actually supports:
	CBR (with local resource reservation & admission control)
	'paced' UBR	(UBR used according to ATM FORUM's wording)
	UBR with flow control (FLOWmaster)
	UBR without flow control

'paced' UBR: It's locally treated as a CBR VC (means it's scheduled) but the
setup message signals a UBR VC. This might be useful if you cannot or don't want
to have resources allocated within the ATM network but you want to limit the
outbound cell rate (i.e. the next hop switch can't keep up with full line rate).

CBR VCs and paced UBR VCs are actually only available as PVCs with Classical IP
over ATM (CLIP). They're not available as SVCs as RFC 1577 doesn't describe such
things.

If you're going to write your own convergence module you are able to use all
above mentioned traffic classes.

Regarding the ATMW 351 again there might be a difference between what the
Adapter supports and what the device driver supports... And like .1 I'm not
familiar with the details of the 351 yet.

I recommend that you get a copy of the Meteor chip spec from 
Toshiba.  They have nice bound versions available.  If you really 
need detailed information, you can contact me for a spec.  However, 
until we get the ATMworks 351 driver released, I'm pretty busy...

doug

Thank you for useful and quick replies.
I could understand the behavier of ATMworks350 and its device driver.
 
Kohei

    The Toshiba Part number is TC35856F.

    For a while, I've placed the current Meteor Chip Spec on
    
    	ftp://nactoa.hpn.lkg.dec.com/pub/glaser/Meteor/met4kop2.pdf
    	ftp://nactoa.hpn.lkg.dec.com/pub/glaser/Meteor/met4kop2.ps
    
    Note that this describes the 4K VC version of the chip (but includes an
    appendix with the differences).  Initial ATMworks 351 product will use
    the 1K VC version.
    
    Also note that this is not the ATMworks 351 spec.  That board includes
    a SUNI chip and some other minor logic that is not discussed in this
    document.
    
    This specification is Digital and Toshiba Confidential (and is marked
    as such). Both companies require 3rd parties to sign a Non Disclosure
    Agreement to get the document.
    
    Contact the product manager, Ranjeet Sudan ([email protected] or
    SCHOOL::SUDAN or DTN 226-5534) for details on setting up any NDA
    agreements (or other questions for that matter).

	Re .7

	Thank you. Exactly what I was looking for.

	Rudi

In article <[email protected]>, [email protected] (That's noot eentiiirly aaacuuraate ...) writes:

> Thus, using the wording of the ATM FORUM we only support CBR and UBR (as there's
> no ATM FORUM flow control implemented yet).

Thanks for the correction.
[posted by Notes-News gateway]