Subject: Re: Unicast FIFO entry

From: "Hattig, Myron" <[email-masked]>
Date: Thu, 4 Feb 1999 09:42:28 -0800

Why not just use the value of the 48 bit offset instead of an offset of an
offset that is counted in quadlets. This seems way too confusing. To clarify
my suggestion ;-), just store the value of 48 bit IP unicast offset in the
unit directory.

We have not discussed the value of this entry, so I'll add my 2 cents. Peter
thinks this entry is a good idea so nodes can query the unit directory info
instead of performing ARP. I agree with him that this is a good idea.

-myron

> -----Original Message-----
> From: Kenji Fujisawa [mailto:[email-masked]]
> Sent: Thursday, February 04, 1999 5:13 AM
> To: [email-masked]
> Subject: Unicast FIFO entry
>
>
> Hi,
>
> Since I'm not familiar with CSR, this may be a stupid question.
>
> "7.3 Unicast FIFO entry" says,
> : The unicast_FIFO_offset field SHALL contain the offset, in quadlets,
> : from the base address of initial register space, 0xFFFF
> F000 0000, to
> : the address of the unicast FIFO register for the unit. All unit CSRs
> : SHALL be located at or above address 0xFFFF F001 0000; therefore the
> : value of unicast_FIFO_offset SHALL NOT be less than 0x4000.
>
>
> If the unicast_FIFO_offset field in the ConfigROM has 24bit width,
> it seems that the upper bound of the unicast FIFO is 0xFFFF F3FF FFFC.
>
> Is my understanding correct?
>
> Best Regards,
>
> Kenji Fujisawa
>

---

From: Peter Johansson <[email-masked]>
Date: Thu, 4 Feb 1999 13:52:40 EST

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

<<Why not just use the value of the 48 bit offset instead of an offset of an
offset that is counted in quadlets. This seems way too confusing. To clarify
my suggestion ;-), just store the value of 48 bit IP unicast offset in the
unit directory.>>

ISO/IEC 13213:1994 (aka IEEE Std 1212-1991) defines a key_type for directory
entries that point to CSRs. See 8.2.4 in that standard. The meaning of the
24-bit immediate value in the directory entry is a quadlet offset from the
base of initial register space.

We could define TWO key values, Unicast_FIFO_Hi and Unicast_FIFO_Lo (of
key_type "immediate") and split the 48-bit address of the unicast FIFO between
them.

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, 4 Feb 1999 13:50:38 -0800

I think separate entries for Unicast_FIFO_Hi and Unicast_FIFO_Lo make
the spec more readable to a wider audience. I don't think there is an
implementation advantage of one approach over the other.

-myron

> From: Peter Johansson [mailto:[email-masked]]
> Sent: Thursday, February 04, 1999 10:53 AM
> Subject: Re: Unicast FIFO entry
>
>

---

From: Peter Johansson <[email-masked]>
Date: Thu, 4 Feb 1999 17:41:01 EST

In a message dated 99-02-04 16:50:48 EST, [email-masked] writes:

<<I think separate entries for Unicast_FIFO_Hi and Unicast_FIFO_Lo make the
spec more readable to a wider audience. I don't think there is an
implementation advantage of one approach over the other.>>

One man's meat is another man's poison...

I happen to think that one entry is more readable, simpler---but it's hard to
work up much enthusiasm to debate the matter.

Unless there is some obvious consensus on the reflector, I'm going to treat
this matter as editorial and leave the draft the way it is.

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: Mon, 8 Feb 1999 09:46:36 -0800

Peter,

Comments below ...

> In a message dated 99-02-06 01:37:48 EST,
> [email-masked] writes:
>
> <<Can we use Unit_Location entry for this purpose?>>
>
> P1212r is in the process of obsoleting Unit_Location, but I'm
> sure that can be
> reversed if necessary.
>
> More to the point, Unit_Location is a leaf entry. Why not
> just design a leaf
> entry for IP1394 that suits ALL of our needs?
>
> One example:
>
>                      1                   2                   3
>  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |             length            |              CRC              |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |           ether_type          |        unicast_FIFO_hi        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                        unicast_FIFO_lo                        |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                           IP_address                          |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Peter, do you agree with Kenji's comments about that the IP address
should not be part of the unit directory?

> The leaf illustrated above contains all the information in an
> ARP response
> that is NOT discoverable from other 1394-specific mechanisms
> such as the bus
> information block or self-ID packets.
>
> Of course, this proposal raises some new questions:
>
> * Is ether_type redundant? After all, Unit_Spec_ID and
> Unit_SW_Version in the
> unit directory uniquely identify an RFC.

Yes EtherType is redundant.

> * If ether_type isn't redundant, should it be bound to a FIFO
> or bound to a unit directory?

EtherType is redundant so it should not be bound to a FIFO.

> * Does a unit support more than one IP address? If so, how?
> Extend the leaf
> structure to support multiple IP address quadlets? Create an
> IP_Address entry
> for the unit directory that points to an IP address leaf and
> permit any number
> of these leaves? Permit multiple Unicast_FIFO entries, use
> the leaf format
> above and allow each IP address to have a different unicast
> FIFO address?

Multiple IP address options: have a unique 48 bit offset for
each IP address, or re-use the same 48 bit offset for both IP
addresses. I can't imagine any way of using a unique 48 bit
offset per IP addr without binding the IP addr with the offset
within the unit directory. Placing the IP address in the unit
directory is a bad idea (see Kenji's comments); therefore
multiple 48 bit offsets that include an IP addr are bad idea.
This leaves us with a single 48 bit offest for all IP packets
destined to a single unit even if the packets are destined
to multiple IP addresses within a single unit.

> * Should IP unicast be permissible for ARP requests? We
> already allow it for ARP responses.

How would unicast ARP requests be used?

> Personally, I favor the last solution and would propose:
>
> a) The creation of a Unicast_FIFO leaf entry for the unit
> directory, key value
> 0xB8, whose 24-bit value is the offset of a unicast FIFO
> leaf. Permit only one
> of these entries per unit directory;
>
> b) The unicast FIFO leaf would contain a 48-bit FIFO address,
> only; and
>
> c) Modify the Internet-Draft so that unicast ARP requests are
> permitted if one
> has discovered the unicast FIFO address by other methods. The
> usefulness of
> these ARP requests is not to discover the unicast FIFO address but to
> determine whether or not the unit is responsive to a
> particular IP address.

As you state, there is no reason to include the 48 bit offset for
traditional use. The stated use for a unicast ARP request is to
determine if a unit is responsive to a particular IP address. Usually
a PING (ICMP Echo Request) does this, not an ARP request.

Since the 48 bit offset in the unit directory limits implementations
within a device with multiple IP address, and so far, the 48 bit offset
only benefits to unicast ARP requests, I'm leaning toward just leaving
the 48 bit offset out of the unit directory. Are there additional
uses of the 48 bit offset?

-myron

---

From: Joseph Joy <[email-masked]>
Date: Mon, 8 Feb 1999 11:59:33 -0800

I do not see any real benefit to keeping the 48bit offset in the unit
directory, and hence, in the interest of simplicity, it seems better to
leave it out.

Putting IP address(es) in the config ROM is a bad idea. In addition to the
issue of multiple IP addresses, there is also the issue of changes to IP
addresses (examples: (1) DHCP and (2) IP address failover in
high-availability solutions). It would be messy to link the contents of
config ROM to dhcp and other upper-level protocol activity.

-----Original Message-----
From: Hattig, Myron [mailto:[email-masked]]
Sent: Monday, February 08, 1999 9:47 AM
To: [email-masked]
Subject: Re: Unicast FIFO entry

Peter,

Comments below ...

-myron