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

From: Vivek Kashyap <[email-masked]>
Date: Sat, 23 Feb 2002 18:29:08 -0800 (PST)

> > Not really. If the desire to use 'other' extends to arbitrary
> > protocols, then those protocols need to agree on the format i.e. agree
> > to use the type. With limiting the 'other' protocols to ethertype we
> > are talking about protocols that agree to use the type field and also
> > agree on which type value belongs to whom.
> > 
> First, let me make sure everyone knows where I stand.  My support for
> encoding an LSAP has nothing to do with enabling non-IPoIB protocols.

My comments are general and directed at flushing out the pros and cons
wrt the options. So, didn't mean to imply you in particular were
choosing to implement one way or the other. 

I agree that if type is to be used then non-IPoIB protocols shouldn't
be a consideration. In the earlier mail, I was objecting to formally
including non-IP protocols over the same QPN as a consideration for
the solution. One can always share the QP in a non-compliant way - I
agree with you that no standard can block the use - but then such
implementations can do so with any encapsulation method IPoIB chooses.
So, our consideration should only be for IPv4/6 and ARP/RARP.

[ BTW, I don't think we can call on 'traditional layering' as you call
  it, a for or against case in IPoIB. The IB architecture has a 'type'
  field - it is the QPN, except that it is dynamic and not well
  defined as in the case of ethernet numbers. In this case we get a QP
  and hence a type and then send multiple types over it. So, we are
  really receiving 0x800/0x806 packets on (say) 0x800 and then
  attempting to demultiplex over it again and hence the problem. To
  compound matters we are also saying that 0x86DD ie. IPv6 should also
  be first received as 0x800 and then we will demultiplex it using
  what you call 'traditional layering' i.e. by adding another 'type'
  in the payload or demultiplex by looking at the first 4 bits of the
  received packet.

  So, to be truly a clean architecture we would define separate QPNs
  for every protocol - especially for non-IP protocols. For IPv4 we
  have chosen not to use separate QPNs and there is also the desire of
  some to use IPv6 and non-IP protocols on the same QPN. And that is
  the reason for the need to demultiplex again in the IPoIB interface
  driver. Not because this second level demultiplexing offers a chance
  at a cleaner design.
]

Anyway, I think in the last few mails we have covered all the points
that have been raised on the list. Hopefully, we can build a consensus
in the coming days.

To summarise:

	option (i) 
                use separate QPNs for all protocols. Exchange two QPNs
                in ARP response - one for IPv4 and one for ARP (and
                opcodes). 

		Encapsulate the IP/ARP packet directly as payload.

	option (ii)
                use the first few bits of the payload to distinguish
                between encapsulated protocols.

		Encapsulate the IP/ARP packet directly as payload.

	option (iii)
                define a type field in the payload to specify the
                IP/ARP protocols.

                An IPoIB implementation need only recognise these
                values: 

			One of:

			sub-option (a)
                            The types are - specify some values.

			sub-option (b) 
                            The protocols are assigned the same values
                            as ethernet numbers.

		Encapsulation: 

			4 byte type field followed by the IP/ARP packet.
			The IP MTU is then, at a minimum, link-MTU - 4.

As noted earlier all three options will work. Except for option (i),
the other two cases allow for the sharing of the QPs and therefore any
of them would cause the recommendation on using separate QPs to be
removed from the draft.

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: "Ashwin Kamath" <[email-masked]>
Date: Sun, 24 Feb 2002 11:42:34 -0600

The idea that qpn represents a type is very good. I have one problem with
option 1 wrt traditional mechanisms. In existing mechanisms ARP resolves the
address for all protocol types. In the suggestion below, ARP resolves
addresses for only the ARP type and IP type. So the suggested ARP mechanism
(i) below defeats the generalization. If one has to have a general ARP
mechanism, the ARP should be the same ARP for all ethertypes, and if we say
that the qpn is analogous the ethertype, it cannot be part of  the
link-layer address.

 So in the absence of any counter-suggestion (from me) I think it is fair to
say that the ARP mechanism be specific to IPoIB and so we stick with the
your origial proposal of using a single queue pair for both ARP and and IP,
and if we do want to handle other ethertypes, it needs to use the same link
layer address (including qpn).

 The only counter suggestion that exists to resolve this is not acceptable
due to other reasons. ie if qpn is the type it must not be part of the link
layer address and other methods need to be used to establish it.

-Ashwin.

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf
Of Vivek Kashyap
Sent: Saturday, February 23, 2002 8:29 PM
To: [email-masked]
Subject: RE: [Ipoverib] draft-ietf-ipoib-ip-over-infiniband-00.txt

To summarise:

	option (i)

	option (ii)

	option (iii)

			One of:

			sub-option (a)

			sub-option (b)

		Encapsulation:

Vivek

---

From: [email-masked]
Date: Mon, 25 Feb 2002 23:30:25 +0900

>From: Vivek Kashyap <[email-masked]>
>Date: Sat, 23 Feb 2002 18:29:08 -0800 (PST)

>                            The protocols are assigned the same values

I agree with (iii).
And I recommend/agree with/like sub-option (b). not (a).
Selecting (a) would add more complicated issues, I disagree with (a).

>of them would cause the recommendation on using separate QPs to be

Thanks,
Akihiko

>Vivek

今井です。
今井＠基開統です。
今井＠基開統５開発部です。

---------------------------------------------------------------------------
  今井昭彦  川崎市中原区上小田中4-1-1 川崎工場 本館 16階 北側
  TEL(内) 7113-8706,    TEL(外) 044-754-3456, 044-777-1113*38706

---

From: Vivek Kashyap <[email-masked]>
Date: Tue, 26 Feb 2002 11:12:42 -0800 (PST)

> address for all protocol types. In the suggestion below, ARP resolves

Yes, (i) will work only if both the QPs are exchanged at the same
time. But, as I noted earlier, support for this is not likely. This is
especially so because a common desire seems to be to share the QPs and
not use a separate one for every protocol.

Vivek