Subject: RE: [Ipoverib] IPoIB architecture/encapsulation

From: "Grun, Paul" <[email-masked]>
Date: Tue, 11 Dec 2001 11:25:56 -0800

I would like to respond specifically to some claims made below about a
proposal in the IBTA to add a payload type field to the existing IB headers.
I believe it is incorrect to characterize that proposal as having been
"well-received".  

In fact, at least one major vendor (Intel) objected strenuously to the use
of these bits in the header for purposes of anything other than network
analyzers or sniffers.

My position on identifying payload type is the same as was stated by a few
others this morning; the ethertype field should be included in (or near) the
payload data.  (Others on the list will be unsurprise to hear that I believe
the proposal to use immediate data to be an excellent compromise.)

We should *not* rely on the presence of some identifying bits in the
existing IBA headers for the following reasons:
1. First and foremost, those bits do not currently exist.  If they ever do
come into being, some existing implementations will not be able to support
them thus the adoption rate for IPoverIB will be unnecessarily slowed.

2. The proposal in the IBTA suggested that the new bits could be used for
QoS, network analyzers and packet type identification.  There may have been
other suggested applications - I forget.  Each of these suggested
applications of the "payload identification bits" may have a different set
of requirements which could lead to one of several different final results
in the specification.  My point is, that unless the requirements for using
those bits in IPoverIB are well understood in the IBTA before they are
defined, there is significant risk that their use eventual definition (if
they make it into the spec at all) will not meet the needs of IPoverIB.

3. Finally, there doesn't seem to be a strong compelling case for using bits
in the header instead of an ethertype field.

-paul

-----Original Message-----
From: Vivek Kashyap [mailto:[email-masked]]
Sent: Tuesday, December 11, 2001 12:05 AM
To: [email-masked]
Cc: [email-masked]
Subject: RE: [Ipoverib] IPoIB architecture/encapsulation

Roy,

     See below between <VK>

Vivek

---------------------

> -----Original Message-----
> From: Vivek Kashyap [mailto:[email-masked]]
> Sent: Friday, December 07, 2001 1:35 PM
> To: [email-masked]
> Subject: [Ipoverib] IPoIB architecture/encapsulation
>
>
> Folks,
>
>         This is a request to the WG to comment on IPoIB architecture
>         and encapsulation issues. Attached is, based on the documents
>         submitted to the WG and discussions on this malining list,
>         what I believe to be the best solution. Please comment.

<snip>

>          7) IP/ARP encapsulation
>
>          IP packets are encapsulated in the payload of the IB packet.
>
>         +-------+------+---------+---------+-------+---------+-------+
>         |Local  |      |Base     |Datagram |       |Invariant|Variant|
>         |Routing| GRH  |Transport|Extended |Payload| CRC     | CRC   |
>         |Header |Header|Header   |Transport|       |         |       |
>         |       |      |         |Header   |       |         |       |
>         +-------+------+---------+---------+-------+---------+-------+
>
>         The payload will include the IPv4/IPv6 or ARP packet. An
>         'ethertype' i.e. a 4 byte value giving the payload type will
>         not be used. It is unnecessary and doesn't provide any benefit
>         because:
>
>         1. The 'ethertype' was suggested to help filter/demultiplex
>            the packet streams received by the interface. But the
>            interface can receive a random set of packets and this
>            random set of packets can have any payload. A random packet
>            is as likely to alias the 'ethertype' as it is to alias the
>            IPv4/IPv6 or ARP headers. Therefore one cannot depend on
>            'ethertype' to filter/demultiplex the packes.

The QP should only receive packets with the correct Q_Key.  In your
proposal, this would be derived from all-nodes multicast/broadcast join
operation for the configured P_Key.  So I don't see how this will solicit
random packets.  Nevertheless, an Ethernet interface does receive random
packets and seems to cope with this very well using an ethertype.

<VK>
Yes, but any random user can use that Q_Key. Secondly, you will receive
ARP/IPv4 packets on the broadcast MGID by definition. There could be others
if that MGID got used by another IB application.

<VK>

>
>         2. The demultiplexing of the valid packets can be done using
>            the protocol header signatures with equal ease as with
>            introducing an artificial ethertype in the payload.

I am unaware of a deterministic ARP or IP packet signature that comes close
to the speed and simplicity of an ethertype compare.  If there is, wouldn't
it fall into the same aliasing problems you outlined in 1)?

<VK>
     Yes it would. Hence we can't solve the aliasing problem. Ethertype is
not useful for it.

     That leaves demultiplexing ARP/IPv4 (and IPv6). In the first nibble
IPv4 has (version) 4; IPv6 has 6; and ARP's hardware type has 0 (it is a 16
bit entity with allocations within 5 bits at present). So why can't we use
that ?

     In the case of 'ethertype' you are parsing 4 bytes of the header; in
the case of 'signature' you are looking at the first 4 bits.

<VK>

>
>         3. The MTU of the payload is a power of two value. The
>            multicast group (and the links) take the values 256, 512,
>            1024, 2048, or 4096 bytes. If 4 bytes are taken up by the
>            'ethertype' we endup with MTUs of 252, 508, 1020, 2044,
>            4092. Not the best of the situations.

There is nothing magical about a power of 2 MTU.  Ethernet seems to get by
pretty well on 1514.

<VK>
     There is nothing magical but it certainly is more covenient. Not the
best of reasons but nice.

<VK>

>
>         4. There is a proposal in IBTA aiming to include a payload
>            type(IP/ARP etc.) field in the IB header. This would make
>            'ethertype' ie. the type field external to the payload.

This is the most compelling argument.  However, this will most likely
affect
CA design and certainly existing software interfaces.  Because of this, I
seriously doubt that this will make it into existing or imminent profile B
silicon designs and IBA software libraries.  If the IBTA adopts this
proposal without making the utilization of this field optional, and its use
is required by IPoverIB, it could mean a limited deployment and therefore
slow adoption of IPoverIB.

<VK>
      May be I should have listed this first :). I got a good response to
the suggestion in IBTA.

      I am not sure what you mean by making the utilisation of the field
optional. I don't know if you have looked at the proposal; may be we could
discuss it offline (IBTA issues). I'll be restarting the process in LWG  in
the coming days.
<VK>

< snip >

> Vivek
> --
> Vivek Kashyap
> Linux Technology Center,IBM
> [email-masked]
> [email-masked]
> 503 578 3422 (o)
>
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> http://www.ietf.org/mailman/listinfo/ipoverib
>

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

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

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

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 12 Dec 2001 12:06:48 -0800 (PST)

Paul,
        You objected to certain uses but would like to use it for
        network analyzers. That doesn't mean that you are against the
        bits in the header proposal. You merely have an objection to
        certain uses. 

        To distinguish between two protocols you don't need to invent
        a 4 byte header and that too in the payload. The first 4 bits
        of the protocols are providing the right information. It can
        even be a 0 (arp) non-zero (ip) test. Much simpler. 

Vivek

-- 
Vivek Kashyap
IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)