Subject: Re: [Ipoverib] draft-ietf-ipoib-ip-over-infiniband-00.txt

From: Vivek Kashyap <[email-masked]>
Date: Fri, 22 Feb 2002 12:25:05 -0800 (PST)

> 
> One Comment about Vivek/Jerry's Feb.6 draft.
> 
> >> >The QPs advertised for IP
> >> >         communication MUST NOT be used for other protocols.
> >> 
> >> It is unclear if this can be enforced or worthwhile to restrict so why 
> >> state it.  If used for anything else, this is a local implementation 
> >> problem to resolve.
> >
> >        Yes, it was discussed and agreed (I think) that we will use
> >        SHOULD. 
> 
> I think this sentence should be deleted.
> Because I think it is not recommendation but implementation-dependent that
>  if QP(s) for IP is shared with others or not.
> 

This sentence is related to the comment in the draft about resolving
the encapsulation format. We should try and resolve it in the coming
10 days or so (March, 2nd is the cut-off for drafts).

I present the issues below and hopefully enough people will join in to
allow the chair to call a consensus.

MUST is equivalent to the IBA model: --- (i)

        The IB architecture identifies data streams based on the QP
        that is associated with them. It does not include a type
        field.  

        This reasoning would suggest (say) we use a unique QP for
        IPv6. This QP (IPv6_QP) would be the one resolved during ND
        and is therefore expected to send and receive only IPv6
        packets.

        Thus the protocols can be directly encapsulated in the IB
        payload. 

        This model therefore makes it a MUST to separate the data
        streams using the QPs.

The above model can be applied to all possible protocols on IB. Thus
we need to have a separate QP for IPv6 and a separate one for IPv4.
This is what was suggested in the draft with the caveat that the
section will be effected based on the resolution of the
'type'/encapsulation issue.

We get a separate QPN using ND for IPv6. Get one for IPv4 using ARP.
Now, we could choose to return two (one for IPv4 and one for ARP).

As far as I can tell the choice is to exchange only one QPN for IPv4
and related protocols (ARP and its op-codes).

Thus we are now called upon to distinguish between these two types of
packets. There are two ways to do this:

a) Protocol signature bits  --- (ii)

   The QP is filtering the packets to just the two protocols. The two
   protocol headers are sufficiently different to separate the
   protocols by considering the first bits in the protocols as
   defining a 'type' field.

   The driver thus checks the type to determine the upper layer but
   does not 'step over' the field when it passes the packet to the
   upper layer.

b) A 'type' in the payload --- (iii)

   One can add a type field in the payload that in turn indicates the
   encapsulated protocol. 

So, we can do one of (i), (ii) or (iii). All three will work. Of the
three, (ii) and (iii) are the better options if we want to keep the
QPN exchange (in the case of IPv4, IPv6 is unaffected) limited to only
one. One could define a separate encapsulation for IPv4 and v6 but I
doubt if many are keen on that.

That leaves the solution to (ii) or (iii). 

With (ii) we keep ourselves limited to the IP specific protocols -
such as IPv6/IPv4/ARP. This is really the scope of IPoIB and so is
fine. 

However, some people have voiced the opinion that they would really
like to use 'other' protocols over the same QP. This can be
accomplished by adding a 'type' in the payload.

This solution of course depends on the meaning of 'other'. If it is
arbitrary protocols then there is no good solution since the arbitrary
protocols may follow their own rules and hence clash with any
encapsulation scheme we choose.

We could alternatively say that the ethernet numbers for
IPv6/IPv4/ARP/RARP will be used for the respective encapsulation. We
don't restrict the use of other values - but the 'others' are 
restricted to ethernet numbers. An IPoIB interface driver, of course,
is free to reject anything other than IPv6/v4/ARP/RARP.

I am ok with either of (ii) or (iii). Depending on the consensus
(hopefully called in the next few days) the draft can be updated and
submitted by March 2nd.

Vivek
-- 
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: [email-masked]
Date: Mon, 25 Feb 2002 22:21:07 +0900

Vivek,

>We should try and resolve it in the coming

Yes.

>b) A 'type' in the payload --- (iii)

Thanks.

>accomplished by adding a 'type' in the payload.

Yes, I said that and need it.

>encapsulation scheme we choose.

If we select 'ii' (type field in payload),
it is simple and easy to distinguish what the protocol of a received packet is.
I like it.

>restricted to ethernet numbers.

I think we should just use "ETHER TYPES" defined by RFC 1700.

> An IPoIB interface driver, of course,

Agree.

Thanks,
Akihiko