Filter
Top Products
Intel
®
IXP400 Software
Access-Layer Components: ATM Transmit Scheduler (IxAtmSch) API
April 2005 IXP400 Software Version 2.0 Programmer’s Guide
84 Document Number: 252539, Revision: 007
The client calls the VC queue update interface whenever the user of the VC submits cells for
transmission. The structure of the VC queue update interface is compatible with the requirements
of the IxAtmdAcc component.
The client calls the schedule-table-update interface whenever it needs a new table. Internally,
IxAtmSch maintains a transmit queue for each VC.
IxAtmSch also provides a “VC queue clear” interface for use when the client wishes to cancel
pending demand on a particular VC. This interface is useful, for example, when the client wishes to
remove a VC from the system.
6.5.3 Timing and Idle Cells
IxAtmSch does not rely on a hardware clock for timing. Instead, the component derives timing
information from the supplied port transmit rate for each modeled ATM port. IxAtmSch assumes
that T = 1/R seconds pass for sending every ATM cell. IxAtmSch also assumes that all cells
scheduled in a schedule table are transmitted immediately following the cells previously scheduled
by the scheduler on that port. (No cells — other than those scheduled by IxAtmSch — are being
transmitted on the port.)
The client is responsible for calling “update table” in the following timely fashion, if the demand is
always there. Suppose the “update table” calls for a port corresponds to time spending T(1),
T(2),…, where one T(n) is the time needed to transmit cells scheduled in the n’th updated table.
Then, if the demand is always there, the client must call the n’th “update table” before
T(1)+T(2)+…+T(n-1) has passed, assuming the client’s first such call is at time 0. This can be
easily achieved by making sure that port transmission is never empty when the demand is
continuously pouring in.
When all registered VC transmit queues are exhausted, an empty schedule table is returned by the
ixAtmSchTableUpdate interface. It is assumed that the client will instruct the lower layers to
transmit idle cells until new cells are submitted for transmit on a registered VC. IxAtmSch is not
aware of the number of idle cells transmitted in this situation and will reset its internal clock to its
starting configuration when new cells are queued.
A further interface is provided to allow the client to update the transmit port rate of an ATM port
which has already been registered with the IxAtmSch device, and may have established VCs with
pending transmit demand. This interface is provided to cater for the event of line-rate drift, as can
occur on transmit medium.
In the event that the new port rate is insufficient to support all established VC transmit contracts,
IxAtmSch will refuse to perform this modification. The client is expected to explicitly remove or
modify some established VC in this event, such that all established contracts can be maintained and
then resubmit the request to modify the ATM port transmit rate.
Note: If UBR VCs are registered and they specify a PCR that is based on the initial line rate and the line
rate subsequently changes to below the PCR values supplied for the UBR connections, the
scheduler will still allow the port rate change.
6.6 Dependencies
The IxAtmSch component has an idealized local view of the system and is not dependent on any
other IXP400 software component.