Subject: IPover1394 and bridging

From: thaler thomas <[email-masked]>
Date: Mon, 12 Mar 2001 18:18:15 +0100

Besides providing basic transport capabilities for both IPv4 and IPv6
over 1394 buses, making these protocols bridge-aware will become an
inevitable issue. Currently, as outlined below, support of these
protocols will cause either unacceptable burden to implementations of
1394 bridges and/or show unnecessary resource usage on 1394 buses in a
bridged environment.
A generally agreed solution (an RFC) addressing these issues is, hence,
a strong requirement. 1394 needs a hurdle free solution for IP transport
- otherwise 1394 will never get to the place we all want it to have.

Although it sounds dramatic, current standards are not that far away
from a good solution. I would like to encourage you to show your level
of interest in order to sort out further proceeding.

Regards,
Thomas Thaler

*************************
1394 ARP
Both RFC2734 and Draft-IETF-IPNGWG-1394-01 are based on a 1394 ARP
scheme that is bound to local buses due to two reasons. (a) IEEE 1394.1
specifies in its current draft that GASP messages with sy==0 (as defined
in 1394a-2000 and not modified in RFC 2734) shall not be forwarded to a
bridges co-portal. Additionally, (b) a receiving node of an ARP request
is requested to ignore the message unless the most significant ten bits
of source_ID field match either 0x3FF or the most significant ten bits
of the recipient's node_ID register. Hence, bridging IP from one bus to
another will require some Proxy ARP capabilities of a bridge. Additional
bridge complexity caused is undesirable but could, however, be accepted.
Unfortunately, Proxy ARP would require a unique IP netID for each 1394
bus. I do regard this as both impractical and limiting to build even
small networks based on 1394. Thus, I see a strong requirement to make
1394 ARP work across bridges, which could be achieved with minor
modifications of 1394 ARP as specified in RFC2734: Define the sy field
to a value of 8 and require nodes not to ignore ARP requests originating
from other buses.

Multicast
Another issue that needs be reviewed is IP multicast. Due to the sender
based resource allocation scheme of RFC 2734, implementation over
bridges would cause unnecessary allocation of unused resources such as
channel numbers and cause waste of bandwidth. In RFC 2734 is specified
that owners of group addresses shall periodically send MCAP
advertisements incase another than the default broadcast channel shall
be used for transmission. For two reasons, MCAP advertisements are
meaningful for the local bus only. (a) due to its sy field the message
is not forwarded by bridges and (b) for any bus the multicast address -
channel tuple may be different. Another issue is allocation of resources
(channels) in a network, which should be allocated only if listeners are
present on a specific or "downstream" bus. But, as specified in RFC 2734
section 9.3, intended multicast recipients MAY transmit MCAP
solicitation requests thus not providing a secure means for allocation
and setup of channels.

Both issues are related to both IPv4 and IPv6.

-------------------------------
BridgeCo AG
Thomas Thaler
Ringstrasse 14
8600 Duebendorf
SWITZERLAND

tel: +41 1 802 3334
fax: +41 1 802 3339
[email-masked]