Subject: RE: [Ipoverib] IPoIB architecture/encapsulation

From: "Larsen, Roy K" <[email-masked]>
Date: Mon, 10 Dec 2001 17:05:53 -0800

Vivek,

I'd like to express my strong desire to have IPoverIB packets contain
explicit "ethertype" information.  Although I don't believe the rationale
given to remove an ethertype from the payload is compelling (see in-line
comments below), I believe a compromise can be reached by sending the
ethertype as immediate data. This keeps it out of the payload and uses
existing IBA packet format standards.  I realize immediate data could not be
used with raw data packets, but capabilities outside of UD for IPoverIB are
beyond the scope of what we're trying to get drafted here.

Comments?

Roy Larsen
Intel Corp
[email-masked]
(503) 712-9435

> -----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.

> 
>         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)?

> 
>         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.

> 
>         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.

< 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

---

From: Michael Krause <[email-masked]>
Date: Mon, 10 Dec 2001 18:04:23 -0800

>beyond the scope of what we're trying to get drafted here.

In general, use of immediate data was intended strictly for backward 
compatibility of existing VIA implementations and nearly all of the people 
involved in InfiniBand wanted it removed.  Strongly suggest not relying 
upon this field for anything and not encouraging it use for IPoIB.

Mike