Subject: Interop Test Results

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 9 Dec 1999 12:44:58 -0800

The following 10 companies participated in the interop test:
- Intoto
- Microsoft
- Enthink
- Toshiba
- Sony
- Ricoh
- 3A
- NEC
- HCL
- Samsung

All companies originated their own implementations. Platforms represented
were Win98, WinNT 4.0, Win2000, VxWorks, and one other. Config ROM, IP
unicast, IP broadcast, and ARP were well tested. IP Multicast and MCAP
remain untested. Below is a summary, IP/1394 spec issues, implementation
issues, and IEEE p1394.a spec issues.

Summary:
The testing of the Config ROM, IP unicast, IP broadcast, and ARP resulted
from 5 implementations easily interoperating. 3 implementations struggled
but were functional by the end of the test. 1 implementation was barely
interoperable. 1 implementation did not work at all. Discovery of IP/1394
through Config ROM read worked but only because most implementations ignored
the CRC (see implementation issue below). The first test used small ping
packets; several implementations broke upon increasing the size of the ping
packets to between 2000 and 10000 bytes. At various times up to six hosts
were on a single network at a time, but failures started to occur once more
host were added. One participant had tested up to 25 hosts on a single
network in their own lab.

Three companies had implemented MCAP before the test. Of those three, one
had system problems thus nothing worked; another had to combine two
implementations on site to get an operational system - the resulting
implementation did not have MCAP. This left us with just one implementation
of MCAP so we could not test it.

Overall, everyone agreed that this was an extremely useful test and wanted
to have another. The next test will be for MCAP and DHCP over 1394.
Microsoft agreed to host this test in Feb-March '00. Plans for this test
will be discussed on the [email-masked] list. Thanks to all the
participants and their hard work to make this test a success!!!

IP/1394 Spec:
1) Spec says "target IP address in ARP response MUST be ignored". The
restriction was followed. In addition, all implementations placed the target
IP address in the ARP response. Most thought this clause to be unnecessarily
restrictive.
2) Async stream or unicast async write for ARP: Most implementations use
async streams. One implementation handles the corner case of receiving a
unicast ARP request via async write then responding with async write;
otherwise that implementation uses async streams.

Implementation:
1) One implementation misread the BufSize-1 clause.
2) ARP always uses Async Streams
3) Because of the problems uncovered by pinging with large packets, all
should test their implementations with large packets - 2000 to 10000 bytes
seems to be a good range.
4) Every implementation correctly follows the latest IEEE p1394.a spec wrt
finding the Broadcast Channel on the IRM node.
5) Many reads of the Config ROM first the CRC. Some that did found errors -
there was a debate about which implementation was correct. Implementers
should check the CRC and make sure the it is done correctly.
6) One implementation expected the wrong TAG value in the 1394 async stream
packet header. Implementations must conform to the latest p1394.a spec TAG
values for async streams with GASP data.

IEEE p1394.a Spec:
As many of you know several early IP/1394 specified components were moved to
the p1394.a IEEE spec because they had general applicability to all 1394
devices. Overall, this did not cause problems; the Broadcast Channel was
found and used, GASP headers were fine, and TAG values were fine. The one
problem that some thought should be clarified is that no max retry count
exists to learn of the BCM. This caused some minor problems when the IRM/BCM
device was slow to respond to queries, thus causing some devices to force a
bus reset prematurely.

Myron Hattig
WG Co-Chair