Subject: Re: [ipoverib] Scope of QPN in ARP Request

From: "H.K. Jerry Chu" <[email-masked]>
Date: Wed, 13 Feb 2002 09:06:47 -0800 (PST)

>Jerry,
>
>
>        In a message a few days back Roy suggested a detailed
>        description instead of this sentence. The suggested text
>        clarifies the points a lot better and we can use that
>        instead. 
>
>Vivek
>
>P.S.    RFC826 does not define the format and contents of the hardware
>        address. It is perfectly feasible to format the structure in
>        any way an IPoverFoo finds necessary. So, if it makes people
>        more comfortable if they exchange two QPNs in the ARP packets
>        then it is fine by me. Exchanging two QPNs doesn't double the
>        traffic. 
>        We have not defined it that way though.

Yes, but the key is a single "hardware address" for ARP purpose. I even
tinkered with an idea of including a QPN map in the hardware address
for load-balancing/QoS purpose (e.g. QPN1 for TCP, QPN2 for UDP, QPN3
for high priority traffic...) in the past. It would work as long as
the map is static. If the map ever changes, it is equivalent to changing
hardware address, and one must trigger gratuitous ARP. I have not
pursued this idea further because it is a little radical and the benefit
is not clear.

Jerry

>
>> 
>> This is an old thread that I missed. But I just discovered the
>> clarification clause in the encapsulation draft is completely unnecessary.
>> The original suggestion of the ARP responder using the QPN in an ARP
>> request for sending only ARP response but not IP pkts won't work anyway
>> because it violates the ARP RFC. RFC826 only supports the notion of
>> a node's "hardware address", and it doesn't support a separate "hardware
>> address" for IPv4 from the one for ARP reply. QPN as part of IB "hardware
>> address" can have only one value for both ARP and IPv4 frames, period.
>> 
>> Vivek, I suggest we strike out the sentence "All IP communication to the
>> relevant IPoIB interface MUST be directed to this QPN." in 6.1.1b.
>> It's completely superfluous and might cause unnecessary confusion.
>> 
>> Jerry
>>  
>> >> In the Ethertype thread, it was implied by some that the QPN could be used
>> >> to demultiplex all protocols carried by IPoIB.  For this to be true, nodes
>> >> receiving the ARP request broadcast can not assume that the source link
>> >> address is the destination link address for IPv4 frames.  That is, it is
>> >> only guaranteed to accept ARP replies.
>> >> 
>> >> The encapsulation draft must be clear on the scope of the QPN carried in 
an
>> >> ARP request.  If it only specifies the ARP reply queue, then a single ARP
>> >> request/reply transaction can not identify both IPv4 endpoints.
>> >> 
>> >> Since limiting the scope of the QPN in this way would double ARP traffic, 
I
>> >> would like to propose the encapsulation draft state that the QPN specified
>> >> in the ARP request source hardware address MUST be able to except all ARP
>> >> and IPv4 protocol frames.
>> >> 
>> >
>> >Yes, that is correct. The QPN included in the ARP request/reply MUST
>> >accept both IPv4 and ARP packets in IBA's unreliable mode. Otherwise
>> >we need to exchange two QPNs or exchange two messages.
>> >
>> >Vivek
>> >
>> >> Roy
>> >> 
>> >> _______________________________________________
>> >> IPoverIB mailing list
>> >> [email-masked]
>> >> https://www1.ietf.org/mailman/listinfo/ipoverib
>> >> 
>> >
>> >
>> >-- 
>> >Vivek Kashyap
>> >Linux Technology Center, IBM
>> >[email-masked] 
>> >[email-masked] 
>> >503 578 3422 (o)
>> >
>> >_______________________________________________
>> >IPoverIB mailing list
>> >[email-masked]
>> >https://www1.ietf.org/mailman/listinfo/ipoverib
>> 
>> 
>> _______________________________________________
>> IPoverIB mailing list
>> [email-masked]
>> https://www1.ietf.org/mailman/listinfo/ipoverib
>> 
>> 
>
>
>-- 
>Vivek Kashyap
>Linux Technology Center, IBM
>[email-masked] 
>[email-masked] 
>503 578 3422 (o)

_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 13 Feb 2002 10:26:31 -0800 (PST)

> the map is static. If the map ever changes, it is equivalent to changing

Totally agree that the 'hardware' address must be kept static. That
condition is not modified if two QPNs are exchanged: 1 for IPv4 and 1
for ARP traffic. So, if there is a thought that such a solution
produces a more clean solution in keeping with IB architecture then we
need to consider it.

> pursued this idea further because it is a little radical and the benefit

Yes, I am sure that due to the nature of IBA which associates QPN to
various streams, the load-balancing/QoS issues occurred to a lot of
us. Such a solution though is complex and an overkill. Especially if
this QPN map is subject to change on a regular basis. Even without a
change, the length of the exchange list is a cumbersome issue.

To satisfy the load-balancing/QoS desires one would still like to
associate a QPN per protocol and/or specific streams such as you have
indicated (QPN1 for TCP, QPN2 for UDP, QPN3 for high priority etc.).
With that in mind, I have proposed a solution that fits the criteria
of : interoperability with the basic IPoIB UD mode and leveraging the
load-balancing/QoS infrastructure based on separate QPNs. The idea is
very simple: the hardware address is kept static (it will be the
address we define for encapsulation) and uses a static set of flags
that indicate that the IP node is capable of supporting QPN based
streams such as described above. 

Please refer to draft-kashyap-ipoib-advanced-capabilities-00.txt.

Vivek