1. 1394.1 Overview (working slide set)
November 30, 1999
Dr. David V. James, Sony
These slides are intended to supplement contributions from: Dr. David V. James, Sony
Presented at p meeting, October 14-15, Rennes France

2. (selective routing between buses)
What is a bridge?
(selective routing between buses)
A bridge routes packets between buses: Async packets are routed based on their destination_ID address Isoch packets are accepted based on their channel_ID, and are retransmitted with a new channel_ID.

3. Bus bridge topologies Two portals, one on each bus
A bus bridge has two intimiately linked “portals”
Each portal appears as a node on its attached bus.
The async routing tables are stable; these don’t change unless the topology changes (net refresh or net reset)
The isoch routing tables are dynamic; these are changed by the isochronous connect and disconnect operations.
Two portals, one on each bus
forwards async by destinationID
async routing tables are stable
forwards isoch by channel number
isoch routing entries are dynamic

4. Bus reset results A bus reset does several things:
(c.0)
(c.1)
A bus reset may (and often does) change node state.
To prevent (possibly missguided) access of the change state, remote-node access is temporary blocked after a bus reset.
The “blocking” mechanism is the assignment of a new busID, after bus reset.
Other nodes can “unblock”, when the rediscover the new device address.
A bus reset does several things:
a new bus number is assigned
a courtesy notification is broadcast

5. Subnet disconnection
e.1
e.2
e.1
a.0
a.1
d.0
d.1
When two subnets are split apart, one is declared to be the victim. Both sides of the split bus are assigned new busID addresses The victim scrubs all “dirty” busID addresses, in preparation for reconnect
Both subbuses get new busIds Dirty “victim” subnet is “scrubbed”

6. Subnet reconnection
f.1
f.4
f.2
a.0
a.1
g.0
g.1
When subnets are joined, new busID addresses are assigned.
A new busID is assigned to the rejoined bus (consistent with bus-reset generates new busID rule)
Other survivor buses keep their assigned busID addresses (survivor is USED, victim is FREE)
Other victim buses are assigned new busID addresses (survivor is DIRTY, victim is USED)
New busIDs are assigned: To all merged (bus reset) nodes To unaffected victim buses (due to USED/DIRTY conflict)

7. Isochronous connections
(one talker & multiple listeners)
Isochronous connections involve one talker and multiple listener/controller pairs.

8. Isochronous connection (A)L T C
Connection assumptions:
controller, talker, listener anywhere
disconnect if any are “lost”
async: channel but no bandwidth
An isochronous connection is established by a controller.
The isochronous connection enables communications between a talker and listener.
The connection requires the presence of a controller, talker, and listener.

9. Isochronous connection (B)L’ T C’
Common connection:
same talkerEui/plugID
distinct controller listener nodes
(example: common listener bus)
The talker can sometimes be connected by a different controller.
The controller can be on the talker bus, the listener bus, or any other bus.
Each listener is associated with a controller; these controllers may be different or the same.

10. Overlaid connections L’ L T T C’ C L’ L T C’ C
An overlaid connection is formed when two connections share a common path (or a common portion of a path) between the talker and listener.
An overlaid connection “stops” when the common path is reached.
At the common path, a bridge count reflects the number of listening portals; the count is always less than 64, because it reflects the number of local (not remote) connections. L’ L T C’ C

11. Persistent connectionsL’ L L’ L C” T C’ C T C’ L” C
? ?
The concept of a persistent connection was explored but abandoned.
A connection is defined to be persistent if it is unaffected by route-table changes (assuming, of course, that the physical path remains).
Reasons for abandoning this concept are:
1) Complexity. Its easy for each listener to keep track of its talking node. HOWEVER, its harder for each talking node to keep track of its listening node, particularly when tracing in the talker-to-listener direction.
2) Redundancy. Route changes may be accompanied by better-route alternatives, as illustrated in the right half of the figure. Redundant transmissions represent an inefficient use of bandwidth. L’ L L’ L T T C’ C C’ C

12. Source quarantine (bridge-aware)
Source quarantines are “set” when busIDs change from DIRTY-to-FREE.
The intent is to prevent the use of possibly stale EUI-to-nodeID translations.
A quarantine forces the rejection of remote-bus transactions, based on the packet’s source_ID address.
Each bridge portal maintains 64 bits, where each bit corresponds to a different source_ID.phyID addresses on the bus.

13. Quarantine detection/removal (aware requester)
res
res
req
req
Quarantined requester:
request accepted, response returned
distinct rcode/scode identifies problem
Quarantine release:
FirstSwap transaction clears quarantine
(sequence number possible)
A bridge-aware requester detects the quarantine when its request is rejected at the destination-path portal.
The requester clears the quarantine condition using a FirstSwap transaction (this is accepted by the first portal on the requester-to-responder path).
The FirstSwap transaction returns a sequence number, whose purponse is described in the following slide.

14. Quarantine recovery (aware requester)
res
res
req
req
(discard)
When first quarantined, the bridge-aware requester purges its EUI-to-nodeID translation cache.
On demand, the bridge-aware requester rediscovers and caches new EUI-to-nodeID translations (not illustrated).
The transaction can then be repeated, using the updated EUI-to-nodeID translation to produce the new destination_ID address.
A sequence number in the previously illustrated FirstSwap transaction (previous slide) allows the requester to determine when an additional purge of the EUI-to-nodeID translations is unnecessary.
The intent is to reduce the number of redundant discovery sequences.
Quarantine recovery:
Discard EUI-to-nodeID translations
(or ignore, based on sequence number)

15. Source quarantine (legacy)
For legacy devices, the source quarantine is performed in a similar fashion.
The difference is that the controller, after sensing discarded response, lifts the quarantine and commands the device to invalidate its implicit/explicit EUI-to-nodeID translations.
Of course, the controller is also responsible for monitoring the device state and (when necessary) issuing additional commands to restore the AV/C device to its normal operational state.

16. Quarantine detection (legacy)
res
req C
Quarantined requester (the same):
request accepted (ack_complete), discarded
controller’s response-frame timeout occurs
A quarantined legacy device receives an ack_complete, but the posted write request is never forwarded.
The controller detects the lack of an AV/C status-frame writeback.
The controller may read the bridge’s quarantine bits to determine this occurred.

17. Quarantine recovery (legacy)
list
list
talk
talk C C
Quarantine recovery:
FinalSwap transaction clears quarantine
Consumer reactivates the talker
Quarantine recovery is performed by the controller.
The first step is device-dependent: existing EUI-to-nodeId translations are purged (in the worst case, this could mandate a bus reset).
The controller uses a FinalSwap transaction to clear the quarantine.
Then, the controller can continue to access the legacy device is a standard fashion.

18. Event merging Events are signals that are broadcast to all.
Events are 1-bit indications, so they can be easily merged.
A source address is provided, for routing and identification purposes. (the source address is normally maintained, but sometimes lost)
A time stamp is also provided.

19. GASP event overload 4 input with one output, so something is lost src
tgt
4 input with one output, so something is lost
Events are implemented as not-flow-controlled GASP packets.
On a congested bus, the number of received events may exceed the bridge’s adjacent-bus retransmission capacity.

20. Merged event parameters
merge point
OR’d
source
events
timeOfBirth
source
events
timeOfBirth
When events are merged, the source reflects the merge location (the source address is used for routing purposes).
The newest time is selected.
The event bits are OR’d together.
source
events
timeOfBirth
newest time