Figure 2 illustrates a very simple bridge model. As you can see, the 2 portals represented can exchange information synchronized by a single clock (notice the synchronism clock and the isochronal queues) or in asynchronous way (notice the request and response queues). Also by Figure 2, it is clear that the transactions of packets can occur bi-directionally, that is, from 0 to portal 1 or vice-versa. The choosing of the kind of communication (isochronal or asynchronous), as well as the communication rate, it is made by data structures contained on the Routing Control Table.

Figure 2: Simplified model of FireWire bridge, with only 2 portals.

Virtual Node ID

In a FireWire bus network, the node (connected devices) IDs have some interesting characteristics. One of them is stability in reset operation in the buses and stability in the path (it depends on the topology of the bus connection) used by the information packet. One and only one portal (called a) portal is the responsible for managing the designation of virtual nodes. Portal A is chosen, during a bus auto-identification phase (on the network initialization), as being, by simplicity, the one that has higher physical ID value. The auto-identification process works like this: each portal transmits at least 2 packets with information about itself to the other portals, including the physical ID used to choose a.So, after this process, all the portals can easily calculate the topology of the implemented network and internally keep registrations of this topology's information.

When a node is removed or added in some bus, a bus reset process is automatically initiated, starting a new bus and node auto-identification procedure. Connected devices easily detect the adding or removal of nodes, just by comparing the topology calculated after this reset with the topology calculated after the previous reset. There is also a periodical operation that serves to update the topological IDs, that is called refresh.