Re: IP encapsulation over ARCnet


Brad Clements (bkc@clutx.clarkson.edu)
Mon, 16 Nov 87 18:26:22 EST


Here are some thoughts on IP fragmentation, odd sizes and IP address resolution.

One important thing to keep in mind is that not all ARCNet cards
support long packets.

Not all users will know their ARCnet hardware node ID.
In talking to Billy Cox at Datapoint, we discussed wether or not
to implement an 'arp like' system or simply to map the low byte of the
IP address to the node ID. There are arguements for both options. Mr. Cox
made a good point favoring the ARP style solution in that a particular
user (with a given IP address) may need to move to another computer
due to hardware problems but wish to retain his IP address. If hardware
mapping was involved, he could not do this.

Also, it would be nice for the driver to know which Nodes will accept
long packets and which will not.

I suggest something like this:

1) Implement a simple ARP system that allows a node to indicate wether it
   accepts long or short packets.
2) Keep the Hardware Node ID and IP address and long.short packet flag in a table
   with an appropriate time-to-live.
3) Use the table information to fragment (where necessary) packets and deliver
   to the appropriate hardware address.

The table would be built from replies from broadcast packets (destination ID 0)
If two or more nodes responded to an inquiry for a single IP address, a diagnostic could be passed up through the system and the IP addr completely ignored.

For fragmentation and odd sizes, I suggest something like this (stolen ideas)
The first byte after the packet type byte (packet types proposed are 240 for IP and 241 for ARP) would be a mode byte which indicates odd sizes and first/last
packets in a fragmentation.

Bit 7 6 5 4 3 2 1 0
        First Last Size2 Size1 Size0

Bits 3 through 5 or don't cares.
        The size bits work as follows:

        Actual Packet Size Size2 Size1 Size0
        Packetsize 0 0 0
        253 0 0 1
        254 0 1 0
        255 0 1 1
        256 1 0 0

The actual packet size INCLUDES the packet type and the mode byte.
This gives a hardware maximum packet size of 506 bytes.

If bits 0 - 2 are zero, the packet size is what is indicated by the
packet size byte minus the bytes used by the destination ID/Source ID
and packet length. This would be 3 or 4 bytes for short or long
packets respectively.

If the size bits are not zero, the size indicated in the table above
is the datapacket size not counting destination ID/Source ID or packet length
bytes.

Fragmentation works as follows:
 If a packet does not need to be fragmented
     a) the destination packet size is big enough to receive the IP packet
     b) the first and last bits are set in the mode byte and the size
        bits are set accordingly.
     c) the packet is transmitted and if the TMA bit is set a SUCCESS
        response is passed up to IP.
 If a packet needs to be fragmented:
     a) the destination either can not accept the entire IP packet
     b) The first bit is set for the first packet, the last bit
        is set for the last packet and neither bits are set for middle
        packets.
     c) If the TMA status is not set on ANY of the packets, the entire
        IP packet is discarded and a FAILURE is returned to IP.
        This assumes a TMA timeout of some kind.

     d) The size bits are set accordingly for each packet transmitted.
For the receiving ARC driver:
If the first and last bits are set:
     A) a single IP packet is retrieved after decoding its size from the
        size bits.
     b) The ip packet is passed up the chain.

If the first bit is set:
     a) an 'mbuf' chain is started, indicating which source ID the packets
        are going to be from. The first packet is copied into the mbuf.

If neither the first nor the last bit is set:
     a) a search is made for an mbuf chain with the same source ID.
        If none is found the packet is discarded.
     b) Otherwise the packet is added to the appropriate mbuf chain.
If the last bit is set:
     a) a search is made for an mbuf chain with the same source ID.
        If none is found the packet is discarded.
     b) Otherwise the packet is added to the mbuf chain and the entire
        IP packet is passed up to IP.
     c) The mbuf chain is cleared from memory.

Some notes on how this works:
  The procedure assumes that an ARC driver which did fragment an IP packet
  will always transmit the fragments in the proper order before processing
  any other output.

  This allows for other ARC nodes to send IP fragments to the receiver
  while other fragmented packets are being received. This means that
  enough memory must be available for packet reconstruction.

  Finally this assumes that the receiving ARCnet driver will not enable
  receiving unless memory is available to receive the packet.

  An mbuf chain would have a time-to-live within which time the last
  packet must be received. If the last packet is not received the
  entire chain is discarded.

One possible enhancement is to use bits 3 -5 to indicate the number
of ARC packets remaining to be sent. This would allow the receiver
to pre-allocate enough space when the first packet was received, keep
track of sequencing, and ensure that each packet got through. No mechinism
is defined for retransmitting a missing ARC packet, since the source
assumes that once the TMA bit is set the receiver properly received the
packet.

Using bits 3 - 5 would allow an IP maximum size of 8 * 506 = 4048 bytes.

This scheme suggested here was dreamed up in a few minutes and will probably
need modification. I personally feel that some form of ARP should be
support to allow for flexibility. Packet fragmentation and odd size
handling would be easy to handle using the 'mode byte' concept. This
fragmentation scheme relies on the features of ARCnet itself, in that
the TMA must be looked at (with a timeout) and that a single ARC node
will not transmit IP packet fragments out of sequence.
This scheme can be easily implemented under both receive and transmit
interupts.

Brad Clements



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:39:56 GMT