Frame Relay Inverse Arp Frame Format

Inverse Arp Request

When encapsulating other protocols the data field of the Frame Relay packet contains a Network Level Protocol Identification (NLPID) which can be 0xCC (IP), 0x80 (Sub-Network Access Protocol - SNAP) or 0x81 (OSI).

When a SNAP header is identified, the 3-byte Organisational Unique Identifier (OUI) and the 2-byte Protocol Identifier (PID) further identifies the protocol. See the following tables:

OUI

0x00-00-00	XNS
0x00-00-00	IPX
0x00-80-C2	Bridging
0x00-80-9B	AppleTalk

PID

0x81-37	IPX
0x00-07	802.3 bridging
0x80-9B	AppleTalk

In addition, Banyan Vines and DECnet are supported.

Target hardware address is 0x1851, it is from Frame Relay address field.

0x1851 => 0001 1000 0101 0001

000110+0101 => 1100101 => 101 DLCI

So far, DLCI 101 is the target address with which target ip address associates. This is frame relay, DLCI is used by remote stations.

Inverse Arp Reply



Please note DLCI in frame header is same as request frame since frame relay switch will change DLCI value when routing frame. So this is a received frame. Excerpt from RFC 2390:

   The DLCI carried within the Frame Relay header is modified as it
   traverses the network. When the packet arrives at its destination,
   the DLCI has been set to the value that, from the standpoint of the
   receiving station, corresponds to the sending station. For example,
   in figure 1 below, if station A were to send a message to station B,
   it would place DLCI 50 in the Frame Relay header. When station B
   received this message, however, the DLCI would have been modified by
   the network and would appear to B as DLCI 70.

However, 'Target hardware address' doesn't seem correct. (You can tell it should use remote DLCI or others) Please note the following:

   When an InARP message reaches a destination, all hardware addresses
   will be invalid. The address found in the frame header will,
   however, be correct. Though it does violate the purity of layering,
   Frame Relay may use the address in the header as the sender hardware
   address. It should also be noted that the target hardware address,
   in both the InARP request and response, will also be invalid. This
   should not cause problems since InARP does not rely on these fields
   and in fact, an implementation may zero fill or ignore the target
   hardware address field entirely.


Sentence in red -> Basically, receiver does not count on hardware addresses in ARP while using address in frame header.

Sentence in blue -> Target hardware does not matter. So in reply message, just ignore Target hardware address.