Dismiss
InnovationQ will be updated on Sunday, Oct. 22, from 10am ET - noon. You may experience brief service interruptions during that time.
Browse Prior Art Database

Coordinated Address Resolution Protocol Processing

IP.com Disclosure Number: IPCOM000109492D
Original Publication Date: 1992-Sep-01
Included in the Prior Art Database: 2005-Mar-24
Document File: 4 page(s) / 161K

Publishing Venue

IBM

Related People

Beierle, JP: AUTHOR [+7]

Abstract

A method for performing address resolution protocol (ARP) in a separate processor from the main processor, performing the bulk of the transmission control protocol/internet protocol (TCP/IP) is disclosed. The two processors have unique interfaces in order to share the configuration information needed for ARP processing.

This text was extracted from an ASCII text file.
This is the abbreviated version, containing approximately 52% of the total text.

Coordinated Address Resolution Protocol Processing

       A method for performing address resolution protocol (ARP)
in a separate processor from the main processor, performing the bulk
of the transmission control protocol/internet protocol (TCP/IP) is
disclosed.  The two processors have unique interfaces in order to
share the configuration information needed for ARP processing.

      The structure for the split on the host system is shown in Fig.
1.  The following scenario details how this functional split actually
works:
1. When IP first gets a request to send data to another node, it
looks up the internet address (IA) of the partner host.  From the IA,
it determines which locally attached network adapter the remote host
may be reached from.  Finally, it looks to see if this adapter
supports the IP protocol outboarding (i.e., enhanced IOP function).
   If it does, the IP function looks for a connection end point ID
(CEP_ID) which is used by the IOP for a direct index into the ARP
cache table (see additional detail on ARP cache lists for the actual
format of table (lists)).  The IP code next passes either the CEP_ID
and IA, or if the CEP_ID is not found, just the IA to the IOP.
2. The IOP receives the request and if it contains a CEP_ID, the IOP
goes directly to the list to find the entry (and get the hardware
address).  It then sends the datagram, and returns the unchanged
CEP_ID to the IP requester.
   If there is no CEP_ID, the IOP still goes to the ARP cache and
looks for an IA match.  If found, the datagram can be sent and the
associated CEP_ID is returned to the IP layer.
   If no match is found on the IA address (the remote host has not
sent to or received from this node recently), we continue with the
next step.
3. The IOP ARP code constructs the ARP frame and broadcasts it to the
network.
4. The ARP response allows the IOP to add an entry to the ARP cache
active list and then to send the actual datagram.  The CEP_ID is
assigned, and then returned to the IP layer once the send is
complete.
   NOTE:  If an entry is removed from the ARP cache (e.g., usage
timeo...