Subject: P1394.1 and ARP Format

From: Peter Johansson <[email-masked]>
Date: Tue, 17 Nov 1998 19:57:07 EST

In advance of its posting by the IETF Internet-Drafts editor to the official
sites, a Draft-Johansson-IP1394-Asynch-Streams-00.pdf is available for
download from an informal repository of unofficial copies of the working group
documents, ftp://ftp.symbios.com/pub/standards/io/IETF/IP1394.

Please review this document.

It contains arguments to support the idea that we need to change the ARP and
MCAP packet formats to make them suitable for transmission over P1394.1
bridges.

Although P1394.1 is still work in progress, a case can be made that the
changes proposed are sufficient regardless of the eventual conclusion of the
P1394.1 work. This is so because the changes advocated are designed to provide
the same information that is already in a conventional asynchronous broadcast
write. If P1394.1 can solve its addressing and routing problems within the
scope of the information in asynchronous primary packets, it is also
guaranteed to be able to solve the problems for asynchronous stream packets if
we add the extra information. QED.

Consult the document for more detail; especially read the document if you plan
to attend the P1394.1 working group meeting in Monterey in December.

Regards,

Peter Johansson

Congruent Software, Inc.
98 Colorado Avenue
Berkeley, CA  94707

(510) 527-3926
(510) 527-3856 FAX

[email-masked]

---

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 19 Nov 1998 13:52:47 -0800

Peter,

To summarize your proposal, you suggest we add GASP header to all IP
broadcast, MCAP, and ARP packets sent over the NETWORK_CHANNEL async stream
and modify the ARP format. Mentioned but not specified are changes to the
MCAP packet format and some ramifications to DHCP. I suspect Kenji's DHCP
proposal should add warnings about using the node_id as the 1394 hwaddr,
instead DHCP packets should be IP broadcasted over 1394 links.

A don't see the additional overhead of the GASP header on all IP broadcast
and MCAP packets as an issue. (ARP packet size is actually reduced.) I don't
like the OUI field because it adds no value above the EtherType field in the
link fragment header. The OUI is part of LLC-SNAP. We discussed LLC-SNAP to
death last year and decided it had no value that is not already provided by
the EtherType field. IMHO, OUI had no value last year and it has no value
now.

Your proposal changes ARP to no longer have target information other than
the IP address. This is a non-traditional ARP format but I don't see any
obvious loss in functionality. Do ARP aficionados see any subtle problems?

Your proposal does not address MCAP. The purpose of node ID in MCAP is to
allow packets sent to only affect channels on their own bus through all
devices examining the bus ID portion of the node ID. Also the phy ID portion
of the node ID resolves contention of an IP address mapped to two different
channel numbers by allowing the device with the highest phy_id to retain
ownership. I suspect you will propose moving the node ID in the MCAP header
to the source ID portion of the GASP header. I don't see any loss in
functionality by doing this.

Here is a point for IP/1394 WG members to carefully consider. Will these
proposed changes to IP/1394 be unnecessary, inhibit, or break IP/1394 when
bridges are not part of the network?

IMHO, except for the OUI value duplicating the functionality of the
EtherType in the link fragment header, I don't see any unnecessary or
duplicated functionality. Instead the functionality is moved from MCAP and
ARP to the GASP header, thus I think Peter's proposed changes work for
IP/1394 with or without p1394.1 bridges.

OTHERS PLEASE COMMENT SO WE CAN CLOSE THIS ISSUE, DO A LAST CALL, AND SUBMIT
THE DRAFT TO THE IESG!!!!!

Thanks,

-myron