Subject: RE: [Ipoverib] IPoIB architecture/encapsulation

From: "Larsen, Roy K" <[email-masked]>
Date: Wed, 12 Dec 2001 09:08:19 -0800

Vivek,

Implying the protocol type based on 4 bits is the weakest of all our
options.  I certainly wouldn't call it a "signature".  When a link delivers
more than one type of protocol frame to a network stack, I believe the best
engineering solution is to explicitly identify the protocol.  I wish I could
patent that idea but the concept has been in use for over 20 years.  Why
should IPoverIB be any different?  As the 1.0a spec stands today, we can
either put it in the payload or send it as immediate data, but it should be
explicit in my opinion.

Roy

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

Roy, you didn't answer the question I asked .. see below.

Vivek
--
Vivek Kashyap
Linux Technology Center, IBM
[email-masked]
[email-masked]
Ph: 503 578 3422 T/L: 775 3422

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

_______________________________________________
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 11:01:27 -0800 (PST)

Roy,
        That is not how it is. 

        Other IB protocols and data streams are not going to follow
        IPoIB rules. So your comparison to existing standards -
        ethernet for example - is not correct. In ethernet every
        protocol follows the type specification. In our case the rules
        apply to IPv4/ARP and IPv6 only. No one else is bound by
        them. 

        Therefore there is no difference between looking at the first
        4 bits or first 4 bytes or 40 bytes conceptually except that
        looking at the first 4 bits gives you a simpler implementation
        and avoids a pseudo-header.

        The protocol is explicitly defined by the first 4 bits in the
        header. The interface will be asked to distinguish between
        only only 1 (IPv6) or maximum two (IPv4/ARP) packets at the
        QP. Any other packets would be illegal by the virtue of the
        QP's association to specific protocols. So anything else can
        be dropped. Why should I invest in 4 bytes of header which is
        put in the payload - it has to be added when sending the
        packet and removed when receiving. It provides no further
        utility than the 4 bits - it is disambiguating only two
        protocols. 

        Also note that the patent idea that you mention is the one
        that includes the payload identifier in the BTH header, the
        link header. The 'signature' solution will easily work
        interoperably in such a situation. Thus that solution is
        compatible with the best solution that will come in the
        future. That is not the case with other solutions mentioned.

Vivek

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