Changes in the IEEE standard

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.

• 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 update.
• 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.

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.