Four Formal Models of IEEE 1394 Link Layer

The IEEE 1394 standard deals both with the physical requirements and the protocol of the bus. The main feature of the standard is that it supports two modes of transaction: an asynchronous mode and an isochronous mode.

In asynchronous mode, one party (the sender) can send a message of arbitrary length to some other party (the receiver). Such a message may be sent at an arbitrary moment after the sender has gained access to the bus; the only timing restriction is that the interval during which a node may have access to the bus is bounded. In this mode, the receiver must confirm the receipt of the message by sending an acknowledgement.

In isochronous mode the sender is obliged to send messages at fixed rates, and messages are not acknowledged. This service is useful for fast transmission of large amounts of data (e.g., audio/video streams), if certainty at the side of the sender about the receipt of the data by the receiver is not important, whereas the arrival of the data at a constant rate is.

The IEEE 1394 serial bus architecture is roughly as depicted in Figure 1. It consists of a number of nodes (addressable entities that run their own part of the protocol) connected by a serial cable.

The protocol describing the behaviour of a node in asynchronous mode distinguishes three layers:

1. 1.

   The transaction layer (the upper layer, indicated by Trans in Figure 1) offers three types of transactions to the application(s) running on the node: read transactions (read data from another node), write transactions (write data to another node), and lock transactions (have some of its own data processed by another node after which it is transferred back). Such transactions consist of a request and a response; the transaction layer can both handle concatenated response transactions (response follows request immediately) and split transactions (response not necessarily follows immediately on the request it belongs to).

2. 2.

   The link layer (the middle layer, indicated by Link in Figure 1) forms the interface between the transaction layer and the physical components of the bus (consisting of the physical layers, which are connected to each other by a serial cable). The link layer provides two types of services to the transaction layer:

   Data request/response:

   By means of a Link data request, the transaction layer instructs the link layer to send a packet to some particular node or to broadcast a packet to all other nodes. The transaction layer must react on a packet addressed to it by sending an acknowledge packet by means of a Link data response.

   Data indication/confirmation:

   By means of a Link data indication, the link layer indicates the arrival of data (either request or response data). The receipt of an acknowledge packet is indicated to the transaction layer by means of a Link data confirmation.

   The link layer divides the stream of data that it receives from the physical layer into an alternating sequence of subactions and subaction gaps, the latter being time intervals with a specified minimal length during which serial cable resides in an idle state (see Figure 2). A subaction either consists of a single packet (in case of a split transaction, see subaction 1) or of two packets (in case of a concatenated response transaction, see subaction 2). Within each subaction, a packet is delimited by special data start and data end signals¹¹1These and other “signals” of the link layer correspond to analog signals detected or emitted by the physical layer.; the gap between two packets within a subaction must be filled with data prefix signals in order to distinguish these gaps from the subaction gaps.

   Before a packet can be sent, the link layer must first gain access by issuing an arbitration procedure. Moreover, the link layer must transform the requests of the transaction layer into a certain packet format, computing and attaching checksums to parts of the data to be transmitted. It also decides whether incoming packets have been received properly by verifying the attached checksums. Every packet that is sent by any of the nodes is received by the link layer of every node. If a link layer determines that the packet was indeed addressed to the node it is part of, then it forwards the contents of the packet to the transaction layer. The link layer also handles the sending and receiving of acknowledgements.

3. 3.

   The physical connection between a node and the serial line is called the physical layer (the lower layer, indicated by Phy in Figure 1). It listens to and puts signals on the serial cable, measures the lengths of the time intervals during which the cable resides in an idle state, and determines, together with the other physical layers, which node has control over the cable (arbitration). It provides the following services to the link layer:

   Arbitration request/confirmation:

   The link layer instructs the physical layer to start an arbitration procedure by means of a Phy arbitration request. The result of this procedure (either won or lost) is communicated to the link layer by means of a Phy arbitration confirmation.

   Data request/indication:

   The link layer instructs the physical layer to put some signal on the cable by means of a Phy data request. The physical layer indicates to the link layer the detection of a signal on the cable (or information about the status of the cable) by means of a Phy data indication.

   Clock indication:

   To notify the link layer that it can (and should) put a signal on the cable, the physical layer communicates a Phy clock indication.

We proceed to describe in more detail the behaviour in asynchronous mode of the link layer (the middle layer of the three-layered protocol), which is responsible for the construction of packets, the transmission of these over a serial (one-bit) line to other parties, and the computation and verification of checksums.

We model the process behaviour of the link layer according to the state machine depicted in [44, Figure 6-19, Page 170] and the accompanying informal explanation. The part of the state machine defining the behaviour in asynchronous mode has eight states L$n$ ($0\leq n\leq 7$).

The link layer processes maintain a buffer (initially empty) to store a pending request from the transaction layer.

In its initial state, the link layer can either receive a data request from the transaction layer or a data indication from the Phy layer.

At a data request, a packet is constructed from the parameters that have been put into the buffer by the transaction layer. The link layer process then starts a fair arbitration procedure to gain access to the bus. If it wins the arbitration, then the underlying physical layer controls the cable and the link layer enters send mode (see below). However, it may also happen that the physical layer indicates the arrival of data: the packet to be sent is then stored in the buffer and the data is received first.

At a data indication, it must be checked whether the received signal is a Start signal. If so, this means that some other node has control over the cable and is sending a packet; the incoming packet must be received in receive mode. Otherwise, the signal (which is not a Start signal) can be ignored.

To simulate and analyse the interaction of the link layers of $n$ nodes, we need to model the external behaviour of underlying $n$ physical layers connected by a cable, which, together, we shall refer to as the bus.

The bus needs to keep track of which of the $n$ nodes have had control over the bus during a so-called fairness interval; to this aim, it maintains a table of $n$ Booleans. During a fairness interval, each node is allowed to gain control over the bus at most once, by means of a fair arbitration request. It may also access the bus more than once as a consequence of an immediate arbitration request. As soon as the bus has been idle for some specified amount of time and at least one link layer has got access during the running fairness interval, an arbitration reset gap occurs to indicate that every node may, again, be granted access through fair arbitration. The time interval that the bus must idle before such an arbitration reset gap may occur should be longer than that of a subaction gap.

When the bus is in idle state and the link layer of some node requests arbitration, the bus enters decision mode: it checks whether the requesting node already got access during the present fairness interval. If not, the bus confirms the arbitration request by indicating that the node has won arbitration and evolves into a busy state; otherwise, the bus indicates that the arbitration is lost.

When the bus is in busy state, it records which node has control over the bus, and which nodes have requested immediate arbitration. In this state, the bus may still receive fair arbitration requests, but they will be confirmed by reporting that the arbitration was lost. The node that must send a response to the packet put on the bus will issue an immediate arbitration request. No confirmation is sent, however, until the busy node releases its control. Furthermore, as long as some link layer still needs to send signals, the appropriate clock indications must be generated and signals must be distributed.

In distribution mode, the bus delivers signals to all nodes except the one that dispatched it. To obtain a realistic model, the potential loss or corruption of signals is taken into account through a function that assigns an error value to the checksum field of header signals, data signals, and acknowledge signals. Moreover, an extra dummy value will be used to describe the situation in which packets with a invalid length are delivered. The following transmission errors are modelled:

• •

  If the signal is a destination signal, then this signal may be invalidated. However, if this happens, the header checksum (which comes with the next signal) is no longer valid. The bus should register of which nodes invalid destinations have been distributed.

• •

  Any signal, except for header signals having a corrupted checksum according to the above, may be delivered correctly.

• •

  If the signal to be delivered is a header signal, a data signal or an acknowledge signal, then it may be delivered corrupted, or it may not be delivered at all.

• •

  If the signal to be delivered is a data signal, then the packet may be extended by sending a dummy signal immediately after the data signal.

It may happen that more than one node has control over the bus. To resolve such a conflict situation, the bus must wait for End signals from nodes, until only one node has access. Then, a data request is received from this node. If it is not an End signal, the node becomes the busy one and this signal is distributed to all other nodes. However, if the received signal is an End signal, no node has control over the bus anymore; a subactgap signal is then distributed to all nodes, after which the bus returns to its idle state.

To precisely model the lower layers of IEEE 1394, it is sufficient to combine in parallel $n$ Link processes and one Bus process, which describes $n$ Phy processes and a cable. The $\mu$CRL and mCRL2 models given in Annexes A and B follow this approach for $n=2$, with a simple Main process gathering two link layers and a bus.

For model-checking verification (i.e., using a model checker to exhaustively explore and analyze the reachable state space), it is desirable to describe the upper layers as well, namely, the external behaviour of the transaction layer and of the application running on top of it. To this aim, M. Sighireanu introduced in her E-LOTOS model [38] two additional processes: Trans, which represents a transaction layer, and Application, which describes the application and which we note Appli.

The first formal model of the link layer was written in 1997 by B. Luttik and circulated among the COST-247 community. It was reviewed by H. Garavel, J.F. Groote, and M. Sighireanu, who provided comments that led to improvements and simplifications. It was published as an annex (nicely compacted using mathematical symbols) in [27, 28] and, since then, has remained fairly stable. The $\mu$CRL model given in Annex A is close to this original model, with three enhancements:

• •

  It is “machine-readable”, meaning that it can be executed by the $\mu$CRL toolset.

• •

  It uses the map keyword added in the 1997 version of $\mu$CRL [16] to declare non-constructors, whereas the original model [27, 28] used the 1995 version of $\mu$CRL [20], which does not distinguish between constructors and non-constructors.

• •

  It introduces tau internal actions in the Resolve and Distribute sub-processes of the Bus process, in order to eliminate two unguarded recursive calls that existed in the original model and that the $\mu$CRL toolset cannot handle — even if the recursion is actually bounded by the fixed number of Link processes.

In 1997, M. Sighireanu wrote a LOTOS model of the IEEE 1394 link layer, based on the draft $\mu$CRL model of B. Luttik. The development of both models at the same time led to clarifications, enhancements, and simplifications in each of them. The LOTOS model aimed at using the existing CADP toolset [9] to perform model-checking verification, and became an official demo example [41] of CADP in 1997. The LOTOS code was similar in essence to the $\mu$CRL code, but with a few differences:

• •

  As mentioned in Section 2.4, it introduced Trans and Appli processes to describe the upper layers of IEEE 1394, as well as various Main processes specifying 22 verification scenarios.

• •

  The LOTOS model was shorter because it imported predefined libraries containing, e.g., the Boolean and NaturalNumber types.

• •

  The LOTOS model uses conditional rewrite rules (e.g., $C_{1},...,C_{n}\implies L=R$) where the $\mu$CRL model needs to take a detour via user-defined $\mbox{\tt if}(C,E,E^{\prime})$ functions to express conditional equalities.

• •

  The $\mu$CRL rewriter does not consider a fixed ordering of the rewrite rules: it is the modeller’s responsibility to define a confluent term rewrite system. On the contrary, the CÆSAR.ADT compiler [10] for LOTOS assumes that the rewrite rules defining each (non-constructor) function are ordered by decreasing priority; this allows more concise definitions of equality functions (e.g., the eq comparator for type SIGNAL has 16 rules in $\mu$CRL and 2 in LOTOS) and other functions (e.g., is_dest, is_header, is_data, and is_ack need 10 rules each in $\mu$CRL and 2 in LOTOS).

• •

  The LOTOS model renames all local variables i to j, because the former is a reserved LOTOS keyword that denotes the internal action (i.e., Milner’s $\tau$ action). Later versions of CADP lifted this restriction by making it possible to have LOTOS variables or functions named i.

However, in 2023, H. Garavel did a full revision of the LOTOS model, prompted by the development of the LNT model in parallel. The volume of LOTOS code was reduced by one third (from 2091 to 1385 lines), without loss of functionality and still preserving strong bisimilarity. This was done by merging the two versions of the Trans process into one parameterized process, by merging the five versions of the Appli process into another parameterized process, and by introducing the Node process to factorize duplicated LOTOS code. A few other changes were made to simplify the LOTOS code and make it closer to the $\mu$CRL code:

• •

  Like in the $\mu$CRL model, two LOTOS processes Link and Bus have been added to serve as main entry points.

• •

  The definitions of the LOTOS type SIGNAL and of its related types have been aligned on the $\mu$CRL ones by eliminating unnecessary auxiliary tuple types. Yet, to make the LOTOS model easier to understand, the four overloaded constructors sig of type SIGNAL have been renamed to destsig, acksig, datasig, and headersig, respectively (even if LOTOS and LNT also support overloading of constructor functions).

• •

  To reflect the model-checking assumptions of [38, Section 9.2], each of the three types DATA, HEADER, and ACK is directly defined as a singleton (one-value) type, rather than defining it as a two-value type and later providing ad hoc C code that only enumerates one of these two values.

In June 2005, the $\mu$CRL model was translated to mCRL2 by J.F. Groote and distributed as a demo example [15] in the mCRL2 toolset.

The mCRL2 spec is 60% shorter than the $\mu$CRL one (809 non-empty lines in $\mu$CRL vs 327 in mCRL2). Most of this reduction comes from data type definitions, the size of which was roughly divided by 6.4 in mCRL2. This is explained by two factors:

• •

  Like LOTOS, mCRL2 benefits from built-in data types (e.g., Bool, Nat, etc.), together with their basic functions, which need not be defined in every model.

• •

  Like functional languages (ML, Haskell, etc.) and E-LOTOS [22], mCRL2 types can be defined by their constructors. For instance, the SIGNAL type is defined using the struct construct of mCRL2 and the BoolTABLE type is concisely defined using the built-in List datatype. For such types, equality functions, recognizers (i.e., functions, such as is_dest, that check whether an expression matches a given constructor), and projections (i.e., functions, such as first, second, third, and fourth for type quadruple, that extract the various arguments of a constructor) are defined automatically.

• •

  The syntax of the “$\mbox{\bf if }C\mbox{\bf then }A\mbox{\bf else }B$” construct has changed: it is noted “$C\mbox{\tt -> }A\mbox{\tt <> }B$” in mCRL2 and “$A\mbox{\tt <| }C\mbox{\tt |> }B$” in $\mu$CRL.

• •

  In the Link process, the $\mu$CRL definitions of the Link0 and Link7 sub-processes contain summations (i.e., nondeterministic choices) ranging over natural numbers that are not restricted in any way. In the mCRL2 model, these summations are bounded by the number of Link layers.

• •

  In the mCRL2 model, each tau action introduced to guard recursion (see Section 3.1) is replaced by an action internal, which is later abstracted from.

Besides developing a complete LOTOS model and using it for model-checking verification, M. Sighireanu also wrote an E-LOTOS model of the IEEE 1394 link layer that was, rather than the LOTOS model itself, presented in [38, 39, 40]. At this time, the E-LOTOS language was still being standardized and not finalized yet. In essence, the E-LOTOS model bears similarities with the mCRL2 model developed later, notwithstanding the syntactic differences between both languages.

The LNT model presented in Annex D does not derive from this E-LOTOS model, as its history is distinct. In 2022, the LOTOS model (taken in its original version) was partly translated to LNT by Oussama Oulkaid and Marck-Edward Kemeh, as part of an exercise for master students at the University of Grenoble. Their model was later reworked and reshaped by H. Garavel, in order to make it complete and strongly bisimilar to the LOTOS one. Because it had been obtained by systematic translation, this LNT model was very much in the same style as the $\mu$CRL, mCRL2, and LOTOS ones: namely, data types defined as term rewrite systems, and processes defined as state machines extended with local variables that can be read and modified on transitions.

Therefore, H. Garavel entirely revised this LNT model in order to obtain a “better” model that would exploit the characteristic features of LNT and demonstrate the full capabilities of this language. This revision was achieved by progressive transformations, checking at each step that strong bisimilarity is preserved. Concerning data specifications in the resulting LNT model, three main remarks can be made:

• •

  The type definitions in LNT are similar (up to syntax) to mCRL2 ones, except that equality/inequality functions must be requested explicitly (using “$\mbox{\bf with }=$” and “$\mbox{\bf with }<>$” clauses) and that functions for extracting/updating constructor arguments must also be requested (using “with get” and “with set” clauses); this ensures that LNT models are self-contained and not cluttered with useless implicit functions.

• •

  As regards function definitions, the LOTOS rewrite rules ordered by decreasing priority can be systematically translated to LNT pattern-matching case statements. However, this is not the only style permitted by LNT, and not necessarily the most concise and readable one. One can also define functions in a more imperative style, with the usual programming constructs (variable assignments, if-then-else, return statements, etc.), as shown, for instance, in the various functions manipulating values of type BoolTABLE.

• •

  A salient difference between $\mu$CRL, LOTOS, and mCRL2, on the one hand, and LNT, on the other hand, concerns partial functions, i.e., functions that are not defined over the entire domain of their arguments (e.g., function get for the BoolTABLE type or functions getdest, getdcrc, getdata, gethead, getadd, and corrupt for the SIGNAL type). In $\mu$CRL, LOTOS, and mCRL2, partial definition is implicit, in the sense that some equations are not given, e.g., there is no equation to define “get ($n$, empty)”. The LOTOS model of Annex C contains comments to warn about partial definitions, but this is left to the good will of the specifier.

  In LNT, the situation is different: any partial function triggers (based on control- and data-flow analysis) an error, which the specifier is expected to correct, either by properly dealing with the overlooked cases, or by explicitly inserting a “$\mbox{\bf raise }E$” statement at each point where the function might terminate without returning a result — $E$ being either an event declared as an exception that the function can raise, or the predefined event UNEXPECTED denoting an exception that cannot be caught and triggers a run-time error.

• •

  The guarded commands “$\mbox{\tt[}C\mbox{\tt]}\rightarrow A\mbox{\tt [] }\mbox{\tt[}\mbox{\tt not}(C)\mbox{\tt]}\rightarrow B\,$” present in the LOTOS model have been translated to “$\mbox{\bf if }C\mbox{\bf then }A\mbox{\bf else }B\mbox{\bf end if\,}$” statements of LNT. The then and else branches have been permuted, negating the Boolean condition $C$, when $B$ was much shorter than $A$. Also, nested if statements have been flattened whenever possible by using the (Ada-like) elsif clause of LNT.

• •

  When this was convenient, calls to recursive processes have been replaced by the loop statements of LNT, possibly with a break statement to exit the loop. For instance, the Link3, Link5, and Link7 processes of the $\mu$CRL, mCRL2, and LOTOS models have been replaced, in the LNT model, by loop statements. Indeed, in $\mu$CRL, mCRL2, and LOTOS, (finite or infinite) iteration must always be expressed using recursion, with two main drawbacks: (i) the mandatory use of recursion obfuscates the flow of control by requiring the definition of auxiliary recursive processes and “goto-like” calls to these processes; (ii) it also obfuscates the flow of data by requiring, for such processes, as many parameters as there are live variables at the point where these processes are called. Using iteration rather than recursion often leads to simpler, more readable models.

• •

  In some cases, finite loops can be further simplified by turning them into while or for loops. For instance, the sub-process Resolve2 of the $\mu$CRL, mCRL2, and LOTOS models can be rephrased as a while loop, whereas the sub-processes Resolve, SubactionGap, and Distribute can be described using for loops, hereby getting rid of the extra parameters that store the loop variables. Notice that such iterative behaviour was quite clear from the textual description of these processes in [27], but only LNT enables one to express it in natural way.

• •

  Processes that are called only once (especially after recursion has been replaced by iteration) should be expanded in-line at the point where they are called. Doing so, the control flow becomes more readable (as each process call is similar to a “goto”) and many process parameters are eliminated. M. Sighireanu applied this idea when designing her E-LOTOS model: the two $\mu$CRL sub-processes DecideIdle and Link1 were expanded in-line [38, footnotes 7 and 8]. In the LNT model of Annex D, this idea was pushed beyond by also eliminating the sub-processes Link3, Link3RA, Link3RE, Link4DH, Link4RH, Link4RD, Link4RE, Link4BRec, Link4DRec, Link5, Link6, Link7, Resolve, and Resolve2. The sub-process Link4, although called only once, was not expanded in-line, because it is so large that its expansion would have increased the nesting depth too much. Also, a new Link2 sub-process was added to factorize both sub-processes Link2req and Link2resp in a single one. As a result, the Link process has only 6 (mutually recursive) processes in the LNT model, instead of 19 in the other models — maintaining an exact correspondence with the 8 states describing the asynchronous mode [44, Figure 6-19, Page 170] was not considered a requirement for the LNT model.

• •

  Since the in-line expansion of processes often creates variables with nested scopes, three additional transformations may be suitable to keep the LNT model simple:

  • –

    merging different variables that have the same type and are never used simultaneously, so as to decrease the number of variables.

  • –

    enlarging the scope of nested variables by moving their declarations upward, so has to reduce the nesting depth of variable scopes;

  • –

    renaming nested variables declared in the scope of another variable having the same name; for instance, after successively expanding the sub-process Link7 in Link6, Link6 in Link5, and Link5 in Link4DRec, the d variable of Link7 arrives in the scope of the d variable of Link4DRec; even if the innermost variable hides the outermost one in LNT (as in Algol-60), it may be suitable to give these variables different names to avoid confusion.

  These transformations sometimes conflict with each other, and their judicious application cannot be governed by strict laws: it is rather a matter of taste and circumstances.

We are grateful to all those who contributed to the design and verification of the four formal models of the IEEE 1394 link layer, namely: Jan Friso Groote, Marck-Edward Kemeh, Radu Mateescu, Laurent Mounier, Oussama Oulkaid, Charles Pecheur, Judi Romijn, Mihaela Sighireanu, and Bruno Vivien. We also thank the anonymous reviewers for their constructive remarks.