Geof Cooper (imagen!geof@decwrl.DEC.COM)
Tue, 25 Feb 86 09:40:09 pst
> ... Which broadcast address? If the hardware
> broadcast address, this can be handled easily on machines that support
> only IP and 10Mb/s Ethernet. This is a bit more difficult in the 4.2
> architecture, which supports numerous types of network interfaces
> as well as multiple protocol families. By the time IP or ICMP
> receives the packet, the hardware sender address is not longer around,
> and IP/ICMP neither do ****NOR SHOULD KNOW**** how to tell if a hardware
> address is a broadcast. (emphasis added)
Excuse me, my bogometer just went off with an almost audible clang. Perhaps you
have devised an architecture whereby it is awkward to transmit the information
that a packet was broadcast. It does not follow that this information SHOULD
be obscured. The reason why it should NOT be obscured is exactly what you and
Noel have been talking about -- sometimes a higher level protocol would like to
know information available in the network header. For example, an ICMP
router should probably flag the case where a packet is forwarded to the
interface whence it came. And, as was just mentioned, various services such
as ICMP want to make sure that they don't respond with an error packet to a
request that was broadcast.
Local net information can be thought of as an attribute of the packet, and
passed across the network layer in a modular fashion. The multi-interface device
layer that we use here at Imagen passes these attributes along with the packet
to the higher layer. The format of the local network header is abstracted, and unknown
to the higher layer. The attributes passed include the hardware address, which is
tagged with the interface type, a la 4.2. A special set of "virtual addresses"
is known to the interface. Some of these are things like Internet and XNS-IDP
addresses, which are mostly used at higher levels. One is "NULL" -- no interface
(black hole), and one is "BROADCAST". A packet sent to virtual address "BROADCAST"
causes the interface to make a best effort at broadcasting the packet.
Since the internet layer can get hold of the local address, it can have an interface
to ARP that says: "by the way, here is a binding that I happen to know is true,
please remember it." This greatly enhances ARP performance, and modularity
is not violated. The ARP layer is handed two tagged addresses, one a virtual
address and one a hardware address, and is told to associate the two. If ARP is
not used for particular hardware, the ARP layer just discards the information
about that hardware.
In summary, you CAN pass broadcast and other network-layer information to higher level
protocols, and you can do so in a way that is compatible with the principles of
modularity and layering. What's more, higher level protocols SHOULD be able to
find out this information; witness that I've given you some good uses for the it.
Now, want to fix 4.3? :-)
- Geof Cooper
This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:04 GMT