The principle new idea that I gleaned as I read about FireWire isochronous service, was that bus time is divided into fixed time slots of 125 micro seconds, or 8K slots per second. A simple signal on the bus synchronizes various clients. (This is like SONET, which phone companies and others use to manage the capacity of optical links.) A design goal of FireWire is to provide several fluent data streams along with unscheduled service, a bit like a restaurant that makes reservations and also admits walk-ins, as unreserved capacity allows and perhaps to fill in for no-shows.
The above goal and time-dicing scheme immediately suggests the following to me (and may have been the fundamental insight of the designers). Provide a software reservation service that makes bandwidth reservations that are neither in conflict with existing reservations nor incompatible with whatever policies there may be. A reservation would start as the reservation is made and last until the reservation was canceled. (Fancier reservations are possible which are tradable and begin sometime after they are made and expire at negotiated times, etc. Such schemes do not bear on the ideas presented here however.)
We call bus users “units” here. There are two kinds of allocation event here:
There are two levels of bus tenure request, priority and normal. The bus arbitration logic must see and discriminate between these request types. Units without a reservation never assert priority. Units with reservations and in need of the bus assert priority but limit the priority signal so that, the fraction of the slot where they have the bus and signal priority, does not exceed the slot fraction associated with the reservation. If they cease signaling priority the bus arbitration logic may cancel their access, such as when another unit is signaling priority. They must, obviously, quit using the bus for this slot, but they may continue to assert normal priority. They can resume signaling priority as the next slot begins.
A unit that begins a priority request in the middle of a slot may not get its fraction, obviously. If enough time remains in the current slot for the unit’s fraction then it should presumably get is share unless there is transaction overhead which we have otherwise ignored; there may be dead time as the bus switches between units.
Typically the first period of a slot is allocated by the arbitration logic to those asserting priority until they cease, and then to those not asserting priority.
Note that the arbitration logic does not keep track of who has reservations, but merely who proclaims them. In short it is a two priority scheme as far as the hardware is concerned. See this about an earlier bus priority scheme. A hardware audit and debugging unit can be interpolated that keeps track of reservations and observes claims of reservations.
As described above each sending unit must be able to buffer 250 microseconds of data and each receiving unit must have a buffer of 125 microseconds if jitter is to be eliminated. This leads to a 375 microsecond latency.
Contrasted to simpler systems the only extra software mechanism seems to be a reservation master which presumably signals the units about their reservations over the bus, and a hardware method to distinguish priority bus requests. As in ATM but in contrast to SONET, reserved but unused capacity can serve unreserved demand. The restaurant analogy fails for FireWire expels unreserved clients whereas restaurants seldom evict unreserved customers upon arrival of reserved customers. They often hold tables empty for reserved customers instead.
Some of these ideas are indeed presented in 1394 FireWire Hardware Design Considerations where they are referred to as the isochronous mode. This is another introduction to FireWire that covers much politics in the consumer AV arena.
It is easy to imagine isochronous service on each of a sequence of links thru a network. Assuming means of assuring processing necessary to switch the data stream at the switches, this can clearly provide zero cell loss and bounded latency in an ATM like environment, while at the same time, allocating unclaimed reservations for standby traffic.
See OHC for programing specs for a standard hardware interface to FireWire.