Next: Net Panic
The involvement in the standardisation and our simulations, model checking
attempts, protocol derivation and manual proofs have led to a number of
smaller and larger errors, omissions and inconsistencies to be found and
corrected. We mention only the changes in the IEEE standard with a significant
impact on the nature and correctness of the protocol.
Depending on the outcome of the second recirculation ballot (which is
expected to take place in early 2004), the draft standard will be finalised,
or must be adjusted for yet another ballot round. In the latter case, it is
perhaps possible to add graphical descriptions for the net update protocol,
in the form of state machines. In order to conform with accepted IEEE 1394
format, these would have to be complemented with C code, part of which is
already given in the standard. Since net update is so complex, it would help
to have such graphical and precise additional explanation.
- Synchronised bridges The two portals in one bridge are now
required to only change their information in synchronisation with each other.
This greatly simplifies the complexity and description of net update.
- Unmuting The draft standard did not mention when a bridge without
direction must be directed again, this has been included and adjusted many
times. The final version has been adjusted so that a better prime portal is
kept in more situations.
- Portal's tasks The behaviour of a portal and the coordinator task
are considered to be two separate processes, which simplifies the
description of net update.
- Undetected loops Multiple, rapid changes to the net topology may
cause a loops that does not meet the loop criterion, hence is not detected and
may cause net update to not terminate. A separate net reset protocol called
net panic has been introduced to remedy this situation, which is
described in Section 3.3.
- Initial route map The initial value of a portal's route map has
been changed many times, from `vendor dependent' via several different
initialisations to the final requirement which is that no bus id is in use.
- Bus enumeration Although strictly outside the scope of the net
update research, an addressing problem in the bus enumeration protocol was
detected, where an alpha portal contacting the prime portal with 1394.1
routing was not aware of the bus id of the prime portal.
In the final version, the request is sent by the co-portal of the requesting
alpha, once the co-portal's bus (which is nearer to the prime portal) has a
bus id. The request is routed via the net tree towards the prime portal, and
the response is routed via the appropriate bus tree back towards the co-portal
of the requesting alpha, and forwarded over the bridge to its final destination.
- Route map updates Although bridge portals update their route maps
in synchronisation during net update, the cleaning of destroyed bus ids upon
completion of net update is not synchronised and can cause inconsistencies.
The processing of net update information received over the bridge has been
slightly adjusted, and in some cases such information requires net update to
be started again on the co-portal's bus, once the local bus has completed net
- Correctness properties A number of correctness properties have
been defined, which must hold in a stable situation, and which ensure that the
net tree and bus trees have been spanned correctly. These have guided the
construction of an abstract version of the protocol as well as the manual
proofs for the lower level version, and have been added to the IEEE standard
as a normative annex which e.g. enables debugging.
Next: Net Panic