Rephrase 10 Pagesw

2.2 Overview of FireWire

FireWire was originally developed by Apple (in 1987) as an extended serial bus technology intended to replace expensive parallel peripheral buses such as PCI (Peripheral Component Interconnect) and ISA (Industry Standard Architecture bus). Over the time, FireWire has evolved into a versatile method for interconnecting wide variety of high-bandwidth consumer electronic devices, peripherals and computers. FireWire is the only existing technology that supports a shared-medium daisy-chained topology and has built-in power distribution. It is believed that a shared-medium is necessary to support ad hoc installation of nodes and reduce cabling costs compared to dedicated medium technologies (such as switched Ethernet or ATM). Each FireWire node is a part of the repeat path. Nodes may have one or more ports to support branching and hence tree topologies. A FireWire cable consists of three pairs of wires, two for data transmission and one for power conductors as shown in Figure 5. All FireWire standards employ shielded twisted pair (STP) cabling. IEEE 1394b also uses plastic optic fiber (POF) and multimode fiber (MMF) for added bandwidth and distance. A FireWire cable cross-section is approximately 5 millimeters in diameter.

The number of nodes on a FireWire serial bus is limited to 63. Upto 1024 serial buses can be bridged together in a single network. The standard for FireWire bridges was still under development at the time of this writing [16]. There exist three versions of the FireWire standard, IEEE 1394-1995 [14], IEEE 1394a [13], and IEEE 1394b [12]. Each standard has successively increased the bandwidth and the reach of the serial bus network. Each standard has also improved upon the bus arbitration mechanism. Table 1 gives a performance summary of the three FireWire standards. Performance of IEEE 1394 has been studied analytically in [20]. References [11] and [17] describe methods of transmitting IP packets over FireWire. In [9], IP over FireWire was compared to IP over Gigabit Ethernet, and it was found that throughput was very similar. Reference [27] provides a detailed capacity utilization analysis of IEEE 1394 FireWire. The rest of this

Power wires

Outer jacket

Outer shield

Signal pair shield

Twisted signal pairs

Power wires

Outer jacket

Outer shield

Signal pair shield

Twisted signal pairs

chapter presents the Firewire architecture and performance issues. Bus arbitration mechanisms are described in detail.

Figure 5. FireWire cable cross-section, taken from [1]

2.3 Basic operation of FireWire

Prior to the normal operation of FireWire a bus configuration phase must take place. Bus configuration is responsible for the “plug-and-play” feature of the network and occurs whenever a node is added to or removed from the bus. This phase includes tree identification and self identification. During tree identification, nodes exchange a series of handshake signals to establish a parent / child relationship among them, and to determine the root node. The root node claims the bus ownership, and plays an important role in bus arbitration and several bus management activities. Usually tree identification fails if there is a loop in the topology. IEEE 1394b provides a solution to this problem by selective disabling of links [12]. Bus configuration also establishes the topology of the network. During self identification each node in the serial bus is assigned a unique address called “self id”, which ranges between 1 and 63. A detailed study of bus configuration in FireWire is given in [1].

Table 1. Summary of FireWire standards

	IEEE 1394	IEEE 1394a	IEEE 1394b
Internode distance	4.5 meters (max)	4.5 meters (max)	100 meters (max)
Maximum hops	16	63	63
Physical medium	STP	STP	STP, POF, MMF
Cable bandwidth	100, 200, 400 Mbps	100, 200, 400 Mbps	Up to 1.6 Gbps
Loop prevention	No	No	Yes
Arbitration	Large idle gaps	Small idle gaps	No idle gaps

All FireWire data transactions are packet based and can be broadly classified as asynchronous or isochronous. Asynchronous transactions are guaranteed in delivery and require an acknowledgement from the receiver. They are unicast in nature. Isochronous transactions are guaranteed in time with a specific bandwidth reserved for them on the serial bus. Up to 80% of the bus bandwidth can be allocated for isochronous transactions. Bandwidth is allocated in portions of 125 microsecond intervals, called cycles. Isochronous transactions are multicast in nature, addressed to one or more nodes based on a channel number. FireWire supports another transaction service called asynchronous streaming, which is guaranteed neither in time nor in delivery. Asynchronous streaming can be unicast or multicast. FireWire data packets are variable in size. Maximum data payload size depends upon the type of transaction and the bandwidth of the FireWire serial bus. Figures 6 and 7 show different packet formats in FireWire. Asynchronous stream and isochronous packets follow the same format.

destination id

t1

rt

tcode

pri

source id

destination offset

data block

data CRC

.

.

.

msb (transmitted first)

lsb (transmitted last)

0

16

22

24

28

31

Destination id includes 6 bit node id (for 63 nodes) and 10 bit

bus id (for 1024 buses).

Tcode represents transaction type,

pri

represents priority (this field is not used),

destination offset represents address location within target nod

e. Other fields are

protocol specific.

destination offset

packet type

-

specific data

header CRC

data block

destination id

t1

rt

tcode

pri

source id

destination offset

data block

data CRC

.

.

.

msb (transmitted first)

lsb (transmitted last)

0

16

22

24

28

31

Destination id includes 6 bit node id (for 63 nodes) and 10 bit

bus id (for 1024 buses).

Tcode represents transaction type,

pri

represents priority (this field is not used),

destination offset represents address location within target nod

e. Other fields are

protocol specific.

destination offset

packet type

-

specific data

header CRC

data block

Figure 6. FireWire asynchronous stream and isochronous packet format, taken from [1]

data length

tag

channel

tcode

sy

header CRC

data block

data block

data CRC

.

.

.

msb (transmitted first)

lsb (transmitted last)

0

16

18

24

28

31

Tag represents data format (protocol specific), channel represen

ts channel address,

tcode

represents transaction code (asynchronous, isochronous, data pac

ket, control packet

etc.), sy represents synchronization code (application specific)

.

data length

tag

channel

tcode

sy

header CRC

data block

data block

data CRC

.

.

.

msb (transmitted first)

lsb (transmitted last)

0

16

18

24

28

31

Tag represents data format (protocol specific), channel represen

ts channel address,

tcode

represents transaction code (asynchronous, isochronous, data pac

ket, control packet

etc.), sy represents synchronization code (application specific)

.

Figure 7. FireWire asynchronous packet format, taken from [1]

FireWire architecture is built upon a four-layer protocol stack as shown in Figure 8. The physical layer implements bus arbitration, defines electrical signaling for data transmission and mechanical interface for cables and connectors. The link layer provides address and channel number decoding and CRC generation and verification for transmitted and received packets. The transaction layer provides request-response services for asynchronous transactions. Isochronous transactions operate independent of this layer. The bus management layer provides support for several bus management activities and bus configuration. FireWire requires three primary bus management nodes for normal operation. They are cycle master, Isochronous Resource Manager (IRM), and bus manager. The cycle master generates and broadcasts cycle start packet every 125 microseconds. A cycle start packet denotes the beginning of the periodic 125-microsecond interval. The root node plays the role of cycle master. The IRM manages serial bus isochronous bandwidth and also allocates multicast channel numbers. The bus manager manages cable power distribution and publishes the topology map and the speed map of the serial bus. A speed map is necessary since FireWire can support nodes/cables of different bandwidth capacity in a single network. Usually, all nodes are capable of performing these bus management activities. However, the operational bus management nodes are elected during the bus configuration phase.

2.4 Bus arbitration in FireWire

FireWire employs a request / grant arbitration mechanism to control access to the shared-medium network. A simple arbitration scheme works as follows:

· Nodes that wish to transmit a packet request the bus owner for permission.

· The bus owner selects a best request based upon certain criteria and issues a grant to the corresponding node.

· Only the granted node transmits its packet, the other nodes continue to request until they receive a grant from the bus owner.

In IEEE 1394-1995 [14] and IEEE 1394a [13] the bus owner is always the root node. In IEEE 1394b [12] all arbitrating nodes perform the role of bus owner in a round-robin basis. A detailed description of FireWire bus arbitration is given in the following sections.

Physical Layer

Link Layer

Transaction Layer

Node

Controller

Cycle Master

IRM

Bus Manager

Bus Management

Layer

Bus

Management

Interface

Transfer Interface

Asynchronous

Isochronous

Software Driver

Serial Bus

Physical Layer

Link Layer

Transaction Layer

Node

Controller

Cycle Master

IRM

Bus Manager

Bus Management

Layer

Bus

Management

Interface

Transfer Interface

Asynchronous

Isochronous

Software Driver

Serial Bus

Figure 8. FireWire protocol stack, taken from [1]

2.4.1 Bus arbitration in IEEE 1394 and IEEE 1394a FireWire

The basic arbitration mechanisms employed in IEEE 1394 and IEEE 1394a are the same, with a few arbitration enhancements proposed in the latter [13]. Figure 9 shows a FireWire data transmission interface (physical layer) with two twisted pairs TPA and TPB that are crosswired within the cable (between nodes). Data transmission in IEEE 1394a FireWire is done via data / strobe signaling. Binary data is transferred across one twisted pair and the strobe signal across the other [12]. The strobe signal changes if the data stays the same. This makes data transfer operation essentially half-duplex. Bus arbitration is performed using arbitration signals. Arbitration signals are not clocked data but rather are steady state signals across the twisted pairs [1]. Arbitration signaling can be bi-directional. Two connected nodes are permitted to drive their lines at the same time. In Figure 9, twisted pairs TPA and TPB have arrows at both ends, which indicates that both the lines must be driven simultaneously for data transmission or arbitration signaling.

TPA

TPA

TPB

TPB

Arbitration

Logic

Repeater

TX/RX

Logic

Arbitration

Logic

Repeater

TX/RX

Logic

TPA

TPA

TPB

TPB

Arbitration

Logic

Repeater

TX/RX

Logic

Arbitration

Logic

Repeater

TX/RX

Logic

Figure 9. IEEE 1394 and IEEE 1394a data transmission interface

When a node wishes to perform a data transaction it must arbitrate for the bus. Bus arbitration can be isochronous or asynchronous depending upon the type of transaction. Arbitrations are based upon the periodic 125-microsecond cycle, the start of which is indicated by a broadcast cycle start packet. Isochronous arbitrations can begin immediately after nodes detect the cycle start packet. Only those nodes that have reserved a specific bandwidth on the bus can perform isochronous arbitration. An arbitrating node signals a request towards its parent. Each parent in turn repeats the request upwards towards its parent until the request reaches the root node. When both parent and child arbitrate for the bus, the parent overrides the child’s request. The root issues a grant signal for the received request, which in turn is repeated downwards until it reaches the requesting node. When the root receives multiple requests (i.e. on several ports) the request at the lowest numbered port is granted. The winning node transmits its isochronous data. The next isochronous arbitration can begin only after all nodes detect a specific amount of idle bus time, the isochronous gap, to make sure that the previous data transmission has completed. Every node can perform only one successful isochronous arbitration in a cycle. The end of isochronous arbitrations is marked by a larger bus idle time. This idle gap time is called the subaction gap. At the detection of a subaction gap nodes can begin their asynchronous arbitrations.

Asynchronous arbitrations also employ the same request / grant signaling as used in isochronous arbitrations. After completion of an asynchronous data transmission, the next arbitration can begin only after all nodes detect a subaction gap. This ensures that asynchronous nodes receive their acknowledgements before a new arbitration begins. An acknowledgement packet does not require arbitration and can be sent immediately on the receipt of an asynchronous packet. Asynchronous transactions are divided into fairness intervals. Every node can successfully arbitrate maximum of once during an asynchronous fairness interval. When a node completes a data transaction it must give up any further arbitration in the current fairness interval. This ensures equal and fair sharing of the FireWire bandwidth between asynchronous nodes. When all arbitrating asynchronous nodes complete their data transmission, the bus goes idle for a long arbitration reset gap. This gap indicates the end of a fairness interval and the beginning of a new one. The arbitration reset gap is larger than the subaction gap. Figure 10 shows a typical arbitration sequence in IEEE 1394 and IEEE 1394a FireWire. IEEE 1394a proposes acknowledge accelerated arbitration and fly-by arbitration that reduce the idle bus period to some extent [13]. Every FireWire node transmits data packets (both isochronous and asynchronous) on all active ports. Intermediate nodes repeat the packet on all ports except on the one on which it was received. Data packets are stripped by the

Cycle

start

=

Isochronous Transactions

=

Asynchronous Transactions (Ack included)

=

Arbitration request/grant overhead

Isochronous gap

Subaction gap

Arbitration reset gap

Cycle N

Cycle

start

=

Isochronous Transactions

=

Asynchronous Transactions (Ack included)

=

Arbitration request/grant overhead

Isochronous gap

Subaction gap

Arbitration reset gap

Cycle N

end nodes in the network (no destination stripping is permitted).

Figure 10. Arbitration sequence in IEEE 1394 and IEEE 1394a

2.4.2 Bus arbitration in IEEE 1394b FireWire

Earlier versions of FireWire alternate between arbitration and data transmission that were separated by distinct idle bus times. Idle bus occupancy vastly reduced the performance of FireWire. IEEE 1394b employs a new beta mode signaling that helps arbitration requesting to be overlapped with data transmission [12]. Arbitration overlapping completely eliminates the idle bus occupancy seen in the previous standards. Beta mode signaling is a version of 8b/10b signaling protocol that is used in Gigabit Ethernet and Fibre Channel specifications. Beta mode signaling does not require both signal pairs for unidirectional data transfer. The signal pairs TPA and TPB can transmit data separately and continuously in opposite directions as shown in Figure 11. TPA and TPB have arrows at opposite ends, which indicates that only one of the lines need to be driven for data transmission or arbitration signaling. This full-duplex nature of the IEEE 1394b bus enables overlapping of arbitration with data transmission. In IEEE 1394b arbitration signals are not steady line states across the twisted pairs but rather are 10-bit symbols called tokens.

TPA

TPA

TPB

TPB

Arbitration

Logic

Repeater

TX/RX

Logic

Arbitration

Logic

Repeater

TX/RX

Logic

TPA

TPA

TPB

TPB

Arbitration

Logic

Repeater

TX/RX

Logic

Arbitration

Logic

Repeater

TX/RX

Logic

Figure 11. IEEE 1394b data transmission interface

In IEEE 1394b the bus owner is not a fixed root node. All arbitrating nodes perform this role in a round-robin fashion. The last node to transmit a packet that does not require an acknowledgement acts as the next bus owner. The node claiming bus ownership is called the BOSS (Bus Owner Supervisor Selector). A node that transmits an isochronous packet, an acknowledgement packet, or an asynchronous stream packet becomes the BOSS and is responsible for making the next arbitration decision. When a node wishes to perform a data transaction it sends out an arbitration request token towards the BOSS. Arbitration tokens are sent out on any active port that is not transmitting (repeating) a data packet. Arbitration tokens propagate in the opposite direction from a data packet. As in IEEE 1394a, IEEE 1394b arbitrations are divided into isochronous and asynchronous intervals. Both isochronous and asynchronous intervals alternate between “even” and “odd” arbitration phases. The concept of an arbitration phase is similar to the fairness interval scheme seen in IEEE 1394a. Any node that has transmitted an asynchronous / isochronous packet in the current phase can arbitrate only for the next / opposite phase. Each asynchronous phase is a fairness interval. In IEEE 1394a, two fairness intervals were separated by an idle bus period, called an arbitration reset gap. However, in IEEE 1394b the BOSS explicitly advances fairness intervals by sending out an “arbitration reset token” that specifies the beginning and the phase of a new fairness interval. When the BOSS sees no pending asynchronous requests for the current phase, it advances the phase by sending an ASYNC_EVEN / ODD token corresponding to the new phase.

Isochronous arbitrations begin when nodes see a cycle start token. When there are no pending isochronous arbitrations the BOSS begins an asynchronous arbitration interval by sending out an ASYNC_EVEN / ODD token. Each node transmits request tokens based upon the current phase and its transaction type. Arbitration request tokens are classified as isochronous or asynchronous and are also prioritized. Intermediate nodes always forward the highest priority request token to the next node. The BOSS issues a grant token towards the highest priority request that it receives. When the BOSS receives two or more requests of the same priority then the request at the lowest port number is granted. Each grant token identifies the current phase and transaction type of the granted request. Every intermediate node can keep the grant for itself or forward it to other nodes based upon the priority of its own request and other requests. A detailed description of IEEE 1394b arbitration is given in [12]. Figure 12 shows a typical arbitration sequence in IEEE 1394b FireWire. It can be seen that successive isochronous and asynchronous packet transactions are separated only by a small arbitration grant overhead. The arbitration grant overhead is the time taken by a grant token to reach the source node and

Cycle

start

Cycle N

Arbitration requesting is overlapped with data transmission.

=

Isochronous Transactions

=

Asynchronous Transactions (Ack included)

=

Arbitration grant overhead

Cycle

start

Cycle N

Arbitration requesting is overlapped with data transmission.

=

Isochronous Transactions

=

Asynchronous Transactions (Ack included)

=

Arbitration grant overhead

the amount of overhead depends upon the propagation and the repeat path delays.

Figure 12. Arbitration sequence in IEEE 1394b

2.5 Performance limitations in FireWire

Though IEEE 1394b offers a higher throughput by completely eliminating the idle bus occupancy seen in earlier versions it still has certain performance limitations, which are discussed in this section.

2.5.1 Lack of spatial reuse

IEEE 1394b envisions the entire network as a single logical serial bus. Every node transmits (repeats) incoming packets on all out-going ports and destination stripping of data packets is not possible. FireWire does not permit concurrent packet transmissions (spatial reuse) over distinct segments of the network. For example, Figure 13 shows an N node FireWire video network with nodes linked in a daisy-chained fashion. In this example, node 2 is sending traffic to node 1 and node 4 to node 6. Though these transmissions occupy non-overlapped (distinct) segments of the network, FireWire does not permit them to occur simultaneously. FireWire bus arbitration schedules these transactions to occur one after one. This limits the throughput of FireWire to single link capacity. To increase the effective throughput of FireWire and to improve its scalability beyond the 63-node limit, it is necessary to incorporate spatial reuse in FireWire. The idea of supporting spatial reuse in large (wide area) daisy-chained networks is not new. An emerging technology that supports this concept is Cisco’s SRP [26]. The scope of SRP is a metropolitan area ring topology network with a limited size of 32 to 64 nodes. SRP nodes store and forward incoming packets and have layer 3 routing capabilities. Congestion and fairness control is accomplished by a distributed control mechanism where control packets are continuously propagated between adjacent nodes in opposite direction from the data packets. Each data transaction involves a processing overhead (packet scheduling) and a store-and-forward overhead at every node. One goal of this thesis is to incorporate spatial reuse feature in IEEE 1394b while preserving the simple repeat path functionality (physical layer) and the request/grant bus arbitration model of FireWire.

…

N

2

1

FireWire medium

3

4

5

6

To Sensor Fusion

Traffic

Traffic

…

N

2

1

FireWire medium

3

4

5

6

To Sensor Fusion

Traffic

Traffic

Figure 13. Lack of spatial reuse in FireWire

2.5.2 Lack of support for priority traffic

FireWire provides QoS guarantees for real-time traffic (like packet video) by isochronous bandwidth reservation. Isochronous nodes reserve a fixed amount of bandwidth on a per cycle basis. This service is not suitable for high-resolution variable bit-rate (VBR) encoded video like MPEG-2 and MPEG-4. Figures 14 and 15 show the rate snapshot of an MPEG-2 and an MPEG-4 video, respectively. The MPEG-2 video rate is 25 frames per second with a mean data rate of about 5 Mbps. The MPEG-4 video rate is 25 frames per second with a mean data rate of about 0.766 Mbps. The isochronous bandwidth reservation scheme lacks the flexibility to react to the rate variations as seen in MPEG-2 and MPEG-4 video traffic. Reserving a bandwidth corresponding to the peak bit-rate will result in a waste of resources. A real-time priority based packet scheduling mechanism will be more suitable for widely used VBR video and will provide efficient use of computing resources [25]. The priority mechanisms in IEEE 1394b FireWire (i.e., the request token priorities) provide a means for alternating between isochronous and asynchronous arbitrations and ensuring bandwidth fairness. It is necessary to incorporate a priority service in FireWire so that QoS for packet video and mission critical applications can be provided by mapping traffic in different priority classes.

0

5

10

15

20

25

012345678910

Time (sec)

Rate (Mbps)

Figure 14. Rate plot for MPEG-2 video

0

0.2

0.4

0.6

0.8

1

1.2

1.4

0123456789101112

Time (sec)

Rate (Mbps)

Figure 15. Rate plot for MPEG-4 video

CHAPTER 3

SPATIAL REUSE FIREWIRE PROTOCOL (SFP)

Spatial reuse FireWire Protocol (SFP) is a request/grant bus arbitration protocol architected for an acyclic daisy-chained network (bus) topology. SFP preserves the simple repeat path architecture of IEEE 1394b FireWire while providing two significant improvements. 1) SFP increases the aggregate throughput of the network by spatial reuse of bandwidth by simultaneous data transport in multiple, distinct segments of the network. 2) SFP provides support for priority traffic, which forms the basis for real-time scheduling towards improved QoS support for packet video. This chapter describes the design principles of SFP.

3.1 Overview of bus arbitration in SFP

The core of SFP is the bus arbitration mechanism used for controlled access to the shared-medium network. A simple SFP arbitration scheme works as follows:

· Arbitration requesting: Nodes that wish to perform a data transaction broadcast a request packet (or “request”) that is cached by every node in the network. Request packets are informative, they contain details about the source and destination nodes involved in a transaction and other data packet properties (such as packet size, priority, etc.)

· Bus owner arbitration decision: The current bus owner (i.e. the arbitration decision making node) examines the multiple requests in its cache and “selects” a group of “compatible” requests. The request selection procedure is described in section 3.4. Two requests are compatible if their corresponding data transactions occupy non-overlapped segments of the network. For example, in Figure 16, the transactions ‘A’ and ‘B’ are compatible. The source nodes corresponding to the selected compatible requests are “granted” (permitted) bus access. The knowledge of multiple requests and the informative nature of requests enable the bus owner to make an “intelligent” arbitration decision. The arbitration decision encompasses several “selection” constraints, such as maximizing the throughput of the network, providing support for high priority traffic and ensuring fairness among like priority nodes.

· Arbitration granting: The bus owner broadcasts a grant packet with information about the “granted” nodes. Nodes that explicitly see a grant for them (in the grant packet) can transmit their data packet concurrently. The grant packet also identifies the destination nodes, which are supposed to strip the next data packet that they receive. Destination stripping enables spatial reuse by limiting bandwidth consumption to the used segments of the network. This work assumes only unicast packets. One of the granted nodes explicitly identified as the next bus owner (in the grant packet) takes-up its role at the end of data transmission.

TPA

TPA

TPB

TPB

Arbitration

Logic

Repeater

TX/RX

Logic

Arbitration

Logic

Repeater

TX/RX

Logic

Request line

Data line

TPA

TPA

TPB

TPB

Arbitration

Logic

Repeater

TX/RX

Logic

Arbitration

Logic

Repeater

TX/RX

Logic

Request line

Data line

Figure 16. SFP network

3.2 SFP data transmission interface

Figure 17 shows a high-level connection interface between two SFP nodes. The communication link has two twisted signal pairs, TPA and TPB. TPA and TPB are not crosswired within the cable, but operate as two independent half-duplex lines (i.e. there is a TPA-TPA link and a TPB-TPB link between adjacent nodes). Standard FireWire cabling can be used in SFP. TPB is called the request line and is dedicated to carrying arbitration requests. TPA or data line exclusively carries data traffic (and also grant packets) between nodes. TPA and TPB are driven by separate half-duplex transmitter/receiver logic. It is expected that TPA and TPB can independently and concurrently carry traffic between nodes. A signaling method similar to beta mode signaling in IEEE 1394b is assumed. SFP will combine power distribution with communication, but power distribution issues are beyond the scope of this work.

Request line

Data

1

2

3

4

5

6

Data line

Request

Data

1

2

3

4

5

6

Request

SFP node

Cycle n

(even)

Cycle n+1

(odd)

…

…

N

N

Request line

Data

1

2

3

4

5

6

Data line

Request

Data

1

2

3

4

5

6

Request

SFP node

Cycle n

(even)

Cycle n+1

(odd)

…

…

N

N

Figure 17. SFP data transmission interface

The TPA interface can operate in two functionalities, repeat mode and blocking mode. When a node operates in repeat mode, it repeats an incoming packet towards its neighbor. When operating in blocking mode, nodes strip the next incoming packet. Blocking mode enables destination stripping of a data packet without the requirement of destination address lookup (a delay overhead) at every node. Normally, nodes always operate in repeat mode. Blocking mode operation is permitted only when nodes see their address explicitly identified in the “destination address list” of a grant packet. Blocking mode nodes switch to repeat mode immediately on stripping the next incoming data packet. Grant packets are always repeated while a data packet can be repeated or stripped. Each node has knowledge of the simple network topology and data packets are always routed towards the destination. A node can source data in one port and concurrently receive (strip) a packet from another port. A network configuration phase as seen in FireWire is assumed in SFP. Network configuration plays a key role in node addressing, topology discovery, and establishment of a root node. The SFP root node plays an important role in various bus management activities and fault tolerance (like assuming the role of bus owner in the failure of one). This work does not study network configuration and fault tolerance issues in detail. It is assumed that there is no loss of arbitration request and grant packets. Network recovery methods used in IEEE 1394b can be easily extended to SFP.

3.3 Arbitration requesting

Arbitration requests in SFP are not 10-bit tokens as used in IEEE 1394b, but rather are distinct packets of information. For every data packet a node wishes to transmit, it must broadcast a request packet claiming access to the shared data line. Each request packet contains the following fields of information:

· Source id: Address of the node from which the data packet originates. Nodes are addressed 1 to N, N being the number of nodes in the network

· Destination id: Address of the node to which a data packet is destined.

· Packet phase: Phase of arbitration. Can be Current or Next. The arbitration phase ensures fairness among like priority nodes.

· Packet size: Size (in bytes) of the data packet for which the request is made.

· Priority: Priority of the data packet for which the request is made. SFP supports three priority classes High, Medium, and Low.

Arbitration request packets are transmitted on the request line (TPB). Since TPB operates in a half-duplex mode there is a need for controlled access to it to prevent packet collisions. This is accomplished by the synchronous request transfer mechanism.

Synchronous request transfer: It is assumed that all nodes in an SFP network are synchronized to a common clock. This synchronization takes place during the network configuration phase before the normal network operations begin. It is expected that each node run an arbitration cycle master whose time cycle continuously alternates between even and odd request intervals. Since the nodes are synchronized, the cycle changes occur in all nodes at the same time. At the start of an even request interval, even numbered (addressed) nodes can transmit newly received request packets (if any) to their right and left neighbors. At the start of an odd request interval, odd numbered nodes can transmit newly received request packets to their neighbors. Every node caches the request it receives and also retransmits it to the neighbors in the appropriate request interval. Nodes do not retransmit an incoming request that is already present in their cache. It can be observed that at any point in time a node may have a maximum of three new request packets to transmit (its own request packet and the packets from its left and right neighbors). So, the duration of a request interval (even and odd) must be long enough to accommodate three request packet transmissions. Request interval length also depends upon the worst-case hop delay in the network. The duration of a request interval, Treq, is,