Subject: RE: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4

From: Ajoy C Siddabathuni <[email-masked]>
Date: Mon, 15 Apr 2002 14:25:04 -0700 (PDT)

Most IPoverXXX protocols defined so far defined their wire formats
such that they are extensible to other protocols if need be or such
that they co-existed with other protocols sharing the same resources.
I guess the whole argument behind having an ethertype field was to use
it to multiplex disparate protocols over the same QP or for legacy purposes;
if this is really the case, then I dont see why LLC/SNAP need not be 
supported. 

Frame formats -

a) If LLC/SNAP was used then you automatically get a 32bit-word alignment
   for the IP-Datagram.
   
   The frame would look something like --
   
   LRH (8bytes)
   GRH (40 bytes)*
   BTH (12 bytes)
   DETH (8 bytes)
               LLC       OUI     EthType
   LLC/SNAP <AA-AA-03><00-00-00><xx-xx>   (8bytes)
   IPv4/IPv6 Datagram
   ICRC
   VCRC
   
b) Embedding just the  ethtype - the frame would look like -- also gives
   you the alignment - but is a non-std way of doing things (with reserved
   fields etc in the format).

   LRH (8bytes)
   GRH (40 bytes)*
   BTH (12 bytes)
   DETH (8 bytes)
   
    Rsvd   EthType
   <??-??><xx-xx>  (4bytes)
   IPv4/IPv6 Datagram
   ICRC
   VCRC
----

My opinion on this is that if EthType is ever supported, it should be
supported using the std mechanism (a) to be consistent with how other
IPoverXXX protocols have been defined in the past. (See RFCs -ATM: 2225,
1577, 1483 SMDS:1209 FR:1294)

If the WG feels that in the foreseeable future, only IP will ever be
supported, then yes there is no need for the Ethtype - ie. leave it alone,
you can still get the IP datagram 32bit aligned right after DETH. On the
other hand, if the WG feels that we do it the way our ancestors have done it
there is enough argument already in place for supporting llc/snap hdrs.

~Ajoy

>X-Sender: [email-masked]
>Date: Mon, 15 Apr 2002 10:20:49 -0700
>To: Yaron Haviv <[email-masked]>, "'H.K. Jerry Chu'" 
<[email-masked]>, "[email-masked]'" <[email-masked]>, 
"[email-masked]'" <[email-masked]>
>From: Michael Krause <[email-masked]>
>Subject: RE: [Ipoverib] consensus call on EtherType, min MTU and DHCPv4
>Mime-Version: 1.0
>X-Mailman-Version: 1.0
>List-Id: IP over InfiniBand WG Discussion List <ipoverib.ietf.org>
>X-BeenThere: [email-masked]
>
>At 10:31 AM 4/14/2002 +0200, Yaron Haviv wrote:
>>Jerry,
>>
>>We must stop expending the definition somewhere so we get the spec out
>>This is IPoIB we are talking about, there is no need for LLC/SNAP, and we
>>just need the Ethertype
>
>The consensus is that people want to have the full range of Ethertype 
>values supported.  As such, this needs to be specified independent of the 
>IP over IB specification so that everyone may use these values without 
>requiring them to implement IP over IB.
>
>Mike
>
>
>_______________________________________________
>IPoverIB mailing list
>[email-masked]
>https://www1.ietf.org/mailman/listinfo/ipoverib

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

---

From: Vivek Kashyap <[email-masked]>
Date: Mon, 15 Apr 2002 15:11:54 -0700 (PDT)

> if this is really the case, then I dont see why LLC/SNAP need not be 

It takes another 4 bytes and provides no new information. The issues
you indicate above are equally addressed by a 'type' field.

We can get alignment at a 32-bit word by using a) no header b) 4 byte
header c) 8 byte header d) a 4*n, n=3.... header.

'No header case' is disallowed as per WG consensus. Otherwise, the
4-byte ethertype field is equally viable as the 8 byte LLC/SNAP field.
It has the advantage of being 4 bytes smaller.

> 1577, 1483 SMDS:1209 FR:1294)

How about RFC2734 ? There is nothing standard about this.

[ As another example one can even use a 2 byte header if it works out
for the hardware -i.e. if one can DMA to a 2 byte boundary, the IP
header will land at a 4 byte boundary. ]

Vivek

-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)