Subject: Inverse ARP support for IP/ARP over FC

From: Raj Bhagwat <[email-masked]>
Date: Wed, 4 Nov 1998 18:37:23 -0800

I would like to propose including Inverse ARP capability to the IPFC draft.
I can see potential use for this in private loop environments where Open
Replicates are not supported for broadcasts.

In a private loop environment devices typically do extensive polling to
discover other devices. As part of the discovery, they PLOGI into each
device and find out the World Wide Port Name & Port Id among other things
for each device. However, as part of the discovery, it is not possible to
learn the IP address of the device. If we could do this somehow, then the
device can build a table for IP_Addr to WWPN mapping and use it later
without resorting to sending ARP request through Open Replicate.

Inverse ARP is extensively used in WANs, especially Frame Relay. It is easy
to implement. The frame format is exactly similar to ARP Request/Reply. Only
the opcodes are different. The requesting station fills the hardware address
field with the WWPN of the target device and leaves the protocol address
field as zero. The request is sent to a specific station that has the
matching WWPN. The receiving station will fill in its IP address in the
target protocol address field and send the response back.

This mechanism would accommodate stations that don't support Open
Replicates.

----------------------------------------------------------------------------
--------------------
Raj Bhagwat
Gadzoox Networks, Inc.
http://www.gadzoox.com - Bringing Networking to Storage.

---

From: Raj Bhagwat <[email-masked]>
Date: Thu, 5 Nov 1998 10:29:20 -0800

Dennis,

It certainly could be used in public loops also. I don't see any reason to
exclude public loops.

Regards,

Raj.

> -----Original Message-----
> From: Talluto, Dennis [mailto:[email-masked]]
> Sent: Thursday, November 05, 1998 9:43 AM
> To: [email-masked]'; 'Raj Bhagwat'
> Cc: David Kranzler
> Subject: RE: Inverse ARP support for IP/ARP over FC
> 
> 
> This is exactly what I proposed several weeks ago after 
> reviewing the IETF
> proposal for IP, ARP and RARP over HiPPI.  RARP is Reverse Address
> Resolution Protocol, and I believe that it will prove most 
> beneficial in the
> switched FC environment.
> 
> Your proposal below was also meant to include public loops 
> and switches -
> correct??
> 
> Dennis Talluto
> EDS/Infrastructure Systems Templates
> office: 248.853.3521
> email:  [email-masked]
> 
> 
> > ----------
> > From: 	Raj Bhagwat[SMTP:[email-masked]]
> > Sent: 	Wednesday, November 04, 1998 9:37 PM
> > To: 	[email-masked]'
> > Cc: 	David Kranzler
> > Subject: 	Inverse ARP support for IP/ARP over FC
> > 
> > 
> > Inverse ARP is extensively used in WANs, especially Frame 
> Relay. It is
> > easy
> > to implement. The frame format is exactly similar to ARP 
> Request/Reply.
> > Only
> --------------------------------------------------------------
> ------------
> > --
> > --------------------
> > Raj Bhagwat
> > Gadzoox Networks, Inc.

---

From: "Talluto, Dennis" <[email-masked]>
Date: Thu, 5 Nov 1998 12:43:06 -0500

This is exactly what I proposed several weeks ago after reviewing the IETF
proposal for IP, ARP and RARP over HiPPI.  RARP is Reverse Address
Resolution Protocol, and I believe that it will prove most beneficial in the
switched FC environment.

Your proposal below was also meant to include public loops and switches -
correct??

Dennis Talluto

---

From: Jeff Stai <[email-masked]>
Date: Thu, 5 Nov 1998 10:28:03 -0800

hi Raj,

This does seem like a good thing. I do have a question
and an observation...

Question: If the receiving station has more than one
IP address, how does it report them?

Observation: When I was working on the draft for FC-FLA
(Fabric Loop Attach) about two (?) years ago, I was surprised
to discover that every NIC available at that time
apparently supported Open *Broadcast* Replicate. However,
none of them supported Open *Selective* Replicate.
On that basis, I find it curious that Open Replicate
is an issue...

I do think the proposal has merit, independent of the
Open Replicate issue.

thanks! jeff

jeff stai
BROCADE(R) communications systems inc.
15707 rockfield bl #215, irvine ca 92618
949-455-2908vm, 949-455-9287fx
[email-masked]  http://www.brocade.com/

> to implement. The frame format is exactly similar to ARP
Request/Reply. Only
> This mechanism would accommodate stations that don't support Open
------------------------------------------------------------------------
----

---

From: Raj Bhagwat <[email-masked]>
Date: Fri, 6 Nov 1998 17:34:25 -0800

Jeff,

You are probably right. Open Replicate may already be supported on many, if
not all, FC end-stations. But my guess is that it is largely untested at
this point. There is also the issue of Open Replicates not following normal
credit rules. So, it is possible that the broadcast frames may be discarded.
Either way, I think providing an indirect method to do IP_addr to WWPN
mapping could be very useful.

Handling multiple IP addresses mapped to a single WWPN could be tricky.
Either the end-station has to pick a primary IP address and return only that
in the standard Inverse ARP response or we have to enhance the format of
Inverse ARP packet to include multiple IP addresses. One possibility is to
include a field in the ACCEPT frame to indicate how many IP addresses map to
the specific WWPN and then send a separate Inverse ARP response (in standard
format) to each of those IP addresses.

Regards,

Raj.

> From: Jeff Stai [mailto:[email-masked]]
> Sent: Thursday, November 05, 1998 10:28 AM
> To: 'Raj Bhagwat'; [email-masked]'
> Cc: David Kranzler
> > for each device. However, as part of the discovery, it is 
> not possible
> to
> > learn the IP address of the device. If we could do this 
> somehow, then
> the

---

From: Murali Rajagopal <[email-masked]>
Date: Mon, 16 Nov 1998 09:14:26 -0800

Dennis:

Raj is proposing an Inverse ARP (InARP), which is not the same as RARP. I
believe your proposal earlier was regarding RARP. It is easy to get confused
between the two. 

Inverse ARP (RFC 1293/2390) resolves the protocol address (IP in our case)
of the a remote node, when its MAC address (WW_PN in our case) is known.
InARP is not broadcast, because the MAC address is already known.

Reverse ARP (RARP) (RFC 903) resolves the protocol address of the node
sending this broadcast, whose MAC address is known. This will apply if there
is RARP server. The real question is there a need for such a RARP server in
FC? 

-Murali

		-----Original Message-----
		From:	Talluto, Dennis [mailto:[email-masked]]
		Sent:	Thursday, November 05, 1998 9:43 AM
		To:	[email-masked]'; 'Raj Bhagwat'
		Cc:	David Kranzler
		Subject:	RE: Inverse ARP support for IP/ARP over FC

		This is exactly what I proposed several weeks ago after
reviewing the IETF
		proposal for IP, ARP and RARP over HiPPI.  RARP is Reverse
Address
		Resolution Protocol, and I believe that it will prove most
beneficial in the
		switched FC environment.

		Dennis Talluto

		> I would like to propose including Inverse ARP capability
to the IPFC
		> draft.
not possible to
		> learn the IP address of the device. If we could do this
somehow, then the
Relay. It is
Request/Reply.
		> Only
		> the opcodes are different. The requesting station fills
the hardware
		> address
--------------------------------------------------------------------------

---

From: "Infante, Jon" <[email-masked]>
Date: Mon, 16 Nov 1998 10:41:48 -0800

Why not include RARP as well as InARP, or at least be generic in that its
only the type field in LLC header that defines who gets the packet. 
Whether  its IP, ARP, RARP, InARP, ... over FC  our FC part will basically
be the same.

Jon Infante
Emulex Corporation

----------
From:  Murali Rajagopal
Sent:  Monday, November 16, 1998 9:14 AM
To:  'Talluto, Dennis'; [email-masked]'; Raj Bhagwat
Cc:  David Kranzler
Subject:  RE: Inverse ARP support for IP/ARP over FC

Dennis:

-Murali

		-----Original Message-----
		From:	Talluto, Dennis [mailto:[email-masked]]
		Sent:	Thursday, November 05, 1998 9:43 AM
		To:	[email-masked]'; 'Raj Bhagwat'
		Cc:	David Kranzler
		Subject:	RE: Inverse ARP support for IP/ARP over FC

		Dennis Talluto

to the IPFC
not possible to
somehow, then the
Relay. It is
Request/Reply.
the hardware

---

From: Murali Rajagopal <[email-masked]>
Date: Mon, 16 Nov 1998 10:49:10 -0800

Jon:

Including RARP is not an issue, but it applies when a node obtains it IP
address from a RARP Server. I have not heard from any one if such a RARP
Server is an anticipated requirement.

-Murali

		-----Original Message-----
		From:	Infante, Jon [mailto:[email-masked]]
		Sent:	Monday, November 16, 1998 10:42 AM
		To:	[email-masked]'; 'Murali Rajagopal'
		Subject:	RE: Inverse ARP support for IP/ARP over FC

		Why not include RARP as well as InARP, or at least be
generic in that its
		only the type field in LLC header that defines who gets the
packet. 
		Whether  its IP, ARP, RARP, InARP, ... over FC  our FC part
will basically
		be the same.

		Jon Infante
		Emulex Corporation

		----------
		From:  Murali Rajagopal
		Sent:  Monday, November 16, 1998 9:14 AM
		To:  'Talluto, Dennis'; [email-masked]'; Raj
Bhagwat
		Cc:  David Kranzler
		Subject:  RE: Inverse ARP support for IP/ARP over FC

		Dennis:

		Raj is proposing an Inverse ARP (InARP), which is not the
same as RARP. I
		believe your proposal earlier was regarding RARP. It is easy
to get confused
		between the two. 

		Inverse ARP (RFC 1293/2390) resolves the protocol address
(IP in our case)
		of the a remote node, when its MAC address (WW_PN in our
case) is known.
		InARP is not broadcast, because the MAC address is already
known.

		Reverse ARP (RARP) (RFC 903) resolves the protocol address
of the node
		sending this broadcast, whose MAC address is known. This
will apply if there
		is RARP server. The real question is there a need for such a
RARP server in
		FC? 

		-Murali

				-----Original Message-----
				From:	Talluto, Dennis
[mailto:[email-masked]]
				Sent:	Thursday, November 05, 1998 9:43 AM
				To:	[email-masked]'; 'Raj
Bhagwat'
				Cc:	David Kranzler
				Subject:	RE: Inverse ARP support for
IP/ARP over FC

				This is exactly what I proposed several
weeks ago after
		reviewing the IETF
				proposal for IP, ARP and RARP over HiPPI.
RARP is Reverse
		Address
				Resolution Protocol, and I believe that it
will prove most
		beneficial in the
				switched FC environment.

				Your proposal below was also meant to
include public loops
		and switches -
				correct??

				Dennis Talluto

		to the IPFC
				> draft.
				> I can see potential use for this in
private loop
		environments where Open
				> In a private loop environment devices
typically do
		extensive polling to
				> discover other devices. As part of the
discovery, they
		PLOGI into each
				> device and find out the World Wide Port
Name & Port Id
		among other things
		not possible to
		somehow, then the
				> device can build a table for IP_Addr to
WWPN mapping and
		use it later
				> without resorting to sending ARP request
through Open
		Replicate.
		Relay. It is
		Request/Reply.
		the hardware
				> address
				> field with the WWPN of the target device
and leaves the
		protocol address
				> field as zero. The request is sent to a
specific station
		that has the
				> matching WWPN. The receiving station will
fill in its IP
		address in the
				> This mechanism would accommodate stations
that don't
		support Open

---

From: Jeff Stai <[email-masked]>
Date: Thu, 19 Nov 1998 11:48:48 -0800

On Thursday, November 19, 1998 11:34 AM, Murali Rajagopal
[SMTP:[email-masked]] wrote:
> Subject: Responding with mutiple IP Addresses corresponding to one MAC
> address.
> 
> Jeff: Can you explain motivation for such a request to the group.
> 

OK: In my travels I have learned that there are many
existing systems that can have a single node with
more than one IP address. One example is during a
failover, where a device can take on another's IP
address until the failure is resolved.

I imagine there are others that can be cited.

Motivation? I got beat up at T11 for not providing
support for multiple IPs per port in the Name Server!-)
Makes me sensitive to the subject... 

I felt that Raj's reply on the subject showed
how it could be done in an appropriate manner.
If the tools are needed, they should be provided.

That's about all I have to say about the subject.

thanks! jeff

jeff stai

> If any one has good ideas about accommodating more than one IP address
for a
> InARP, I would like to hear from you at the IETF meeting on Dec 9, in
> Orlando, FL. See Jeff Stai's email below. Also, I would encourage you
to
> chat on the email regarding this.
> 
> -Murali
> 
> 		> I can see potential use for this in private loop
> environments where
> 		Open
> 		> In a private loop environment devices typically do
> extensive polling
> 		to
> 		> device and find out the World Wide Port Name & Port Id
> among other
> 		things
> 		> device can build a table for IP_Addr to WWPN mapping
and
> 		> field with the WWPN of the target device and leaves
the
> protocol
> 		address
> 		> field as zero. The request is sent to a specific
station
> that has the
> 		> matching WWPN. The receiving station will fill in its
IP
> address in

---

From: Tracy Edmonds <[email-masked]>
Date: Thu, 19 Nov 1998 15:52:29 -0800

Guys,

I have two comments on this. First, I completely agree with Jeff (maybe even
stronger than Jeff) that IP ports MUST be able to support multiple IP
addresses...this is standard fare for IP enpoints such as routers or even
servers for that matter. There cannot be any debate about this.

Second, the method of find out the IP address of a port and having a NIC
store it away is full of problems beyond the single IP address per port
problem already stated...what you are suggesting is that the NIC will now
have to crack open every packet that comes along to first figure out that
this is a ARP packet...it would then have to lookup in its table to find out
if it has this IP address to WWPN mapping and then contruct an ARP reply
stuffing in the answer and send the answer back up the stack...I don't think
too many NIC vendors are going to find this too appealing. 

In cases where a NIC does not support open replicate in private loop it can
simply perform multiple unicasts to the specific NL_PORTS that it knows are
present on the loop. In the case of a hub that does not support open
replicate there may be a problem in that it may not be possible for the NIC
to detect this situation and resort to unicasts again.

-Tracy

Tracy Edmonds
Troika Networks, inc.
(805) 371-1377 Ext. 13
http://www.TroikaNetworks.com
[email-masked]

> Sent: Thursday, November 19, 1998 11:49 AM
> To: 'Murali Rajagopal'; Jeff Stai; Raj Bhagwat;
> [email-masked]'; Tracy Edmonds (E-mail)
> Cc: David Kranzler

---

From: Murali Rajagopal <[email-masked]>
Date: Thu, 19 Nov 1998 11:34:09 -0800

If any one has good ideas about accommodating more than one IP address for a
InARP, I would like to hear from you at the IETF meeting on Dec 9, in
Orlando, FL. See Jeff Stai's email below. Also, I would encourage you to
chat on the email regarding this.

-Murali

		-----Original Message-----
		From:	Jeff Stai [mailto:[email-masked]]
		Sent:	Thursday, November 05, 1998 10:28 AM
		To:	'Raj Bhagwat'; [email-masked]'
		Cc:	David Kranzler
		Subject:	RE: Inverse ARP support for IP/ARP over FC

		hi Raj,

		(Fabric Loop Attach) about two (?) years ago, I was
surprised

		thanks! jeff

		jeff stai

to the IPFC
		draft.
environments where
		Open
extensive polling
		to
among other
		things
not possible
		to
somehow, then
		the
Relay. It is
		easy
		Request/Reply. Only
the hardware
		address
		> field with the WWPN of the target device and leaves the
protocol
		address
		> matching WWPN. The receiving station will fill in its IP
address in
		the

---

From: Murali Rajagopal <[email-masked]>
Date: Mon, 23 Nov 1998 09:51:15 -0800

Jeff;

If a node has multiple IP addresses corresponding to a single MAC address,
then the preferred way is
to respond to an InARP (Inverse ARP) Request with a single IP address. This
IP address may be used 
as an identifier for the set of all IP addresses corresponding to the single
MAC address.

The idea is similar to that of an Anycast address (in IPv6) which is used as
an identifier for a set of addresses
typically belonging to different nodes.

-Murali

		-----Original Message-----
		From:	Jeff Stai [mailto:[email-masked]]
		Sent:	Thursday, November 05, 1998 10:28 AM
		To:	'Raj Bhagwat'; [email-masked]'
		Cc:	David Kranzler
		Subject:	RE: Inverse ARP support for IP/ARP over FC

		hi Raj,

		thanks! jeff

		jeff stai

to the IPFC
		draft.
environments where
		Open
extensive polling
		to
among other
		things
not possible
		to
somehow, then
		the
Relay. It is
		easy
		Request/Reply. Only
the hardware
		address
protocol
		address
address in
		the

---

From: Murali Rajagopal <[email-masked]>
Date: Mon, 23 Nov 1998 09:57:06 -0800

Dennis:

I have not heard form anybody justifying the need for a RARP Server. While
in general a server-based service has been 
deployed in many non-broadcast technologies for such purposes, it requires a
protocol and detailed procedures.

Note that the ARP configuration presently prohibits the use of an ARP
Server.

I am assuming this issue to be closed unless someone wants to bring in a
proposal along with a strong justification case.

-Murali
Chair IPFC WG
Gadzoox Networks

		-----Original Message-----
		From:	Talluto, Dennis [mailto:[email-masked]]
		Sent:	Thursday, November 05, 1998 9:43 AM
		To:	[email-masked]'; 'Raj Bhagwat'
		Cc:	David Kranzler
		Subject:	RE: Inverse ARP support for IP/ARP over FC

		Dennis Talluto

to the IPFC
environments where Open
extensive polling to
among other things
not possible to
somehow, then the
Relay. It is
Request/Reply.
the hardware
protocol address
address in the

---

From: Jeff Stai <[email-masked]>
Date: Mon, 23 Nov 1998 10:06:52 -0800

hi,

OK. Just wanted to be sure we weren't leaving
a "hole". If this handles it in an appropriate
manner, I'm happy.

jeff

and
the
station
IP