Subject: Re: draft 13 issues

From: Peter Johansson <[email-masked]>
Date: Thu, 4 Feb 1999 16:36:10 EST

In a message dated 99-02-04 13:12:18 EST, [email-masked] writes:

<<1) Signature is still in link fragment header. Signature needs to be removed
per our discussion that ended Jan 13th...>>

As the signature field is removed, I suggest the following language in clause
5.3:

"The recipient of an IP datagram transmitted via more than one 1394 packet
SHALL use both the sender's source_ID (obtained either from the asynchronous
packet header or the GASP header) and dgl to identify all the link fragments
from a single datagram."

Any remaining references to signature in the draft would be edited
appropriately to refer to source_ID.

<<3) What is the "textual descriptor length" after "unicast FIFO offset"?>>

The Unicast_FIFO  entry (with a key value of 0x54) is the LAST entry in the
unit directory---see the directory_length of five. A textual descriptor is a
LEAF. A leaf is a self-contained data structure (which starts with 16-bits of
length and 16-bits of CRC) that could be located anywhere in configuration
ROM. I placed it contiguously after the unit directory to permit everything to
fit within one illustration. The two quadlets of zero that follow are just
part of the textual descriptor leaf structure defined by ISO/IEC 13213:1994;
the real value is in the "IANA" or "IPv4" string.

<<4) Owner of mapping in MCAP used to be identified by bus id and phy id in
MCAP header. Now owner must be identified by source id in GASP header. A
change in section 10.6 indicates this; however, the use of the term owner
occurs in sections 10.3 through 10.6. Something here must change, I suggest
the new section 10.2 MCAP message domain clearly define the term owner as the
16 bit source id in the GASP header.>>

I agree and would add the following as the last paragraph in 10.2:

"Within an MCAP message domain, the owner of a channel mapping is identified
by the source_ID field in the GASP header of an MCAP advertisement. The owner
is the node with the largest physical ID, the least significant six bits of
source_ID."

The reason I am cautious to define ownership in terms of the least significant
six bits is that I do not wish to be concerned with explaining that a bus ID
of 0x3FF and the most significant ten bits of NODE_IDS both represent the
local bus (i.e., MCAP message domain).

Regards,

Peter Johansson

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

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

[email-masked]

---

From: Kenji Fujisawa <[email-masked]>
Date: Sun, 7 Feb 1999 13:51:50 +0900

One more point in draft 13.

As we discussed earlier, I think we should add following rule,
  The (bridge unaware) recipient SHALL ignore ARP request and response
  from remote bus (with different source_bus_ID).
because we don't know how long the (virtual) node_ID is valid (limbo time)
yet.

As you know, this is a partial solution.
If bridge un-aware node ignores ARP packets from remote bus, it can not
send any unicast (Async Write) packets.
But bridge un-aware nodes will NOT harm other nodes.

Best Regards,

Kenji Fujisawa