[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipng
Subject:    (IPng 4960) Re: IPv6 over ATM encapsulation
From:       Dan Grossman <dan () dma ! isg ! mot ! com>
Date:       1997-11-24 19:06:16
[Download RAW message or body]

> >Francis Dupont and I were just discussing the possibility of removing the=
> >null
> >encapsulation option from draft-ietf-ion-ipv6-atm-00.txt.
> >We think that's a good idea for two reasons:
> >- the null encapsulation is fairly limiting and useless =
> >- the less options there are, the likelier (and the better) one can =
> >interoperate
> 
> I will make two points about interoperability 
> 
> 1) If there is a default (and there is - LLC) which is mandatory
> to implement then there is no interoperability problem. 
> 
> 2) Systems today are required to assume that a remote party may
> try to negotiate the encapsulation. That is, a system cannot assume
> that in a SETUP there will only be one BLLI element, or that the 
> first BLLI element will indicate LLC. It can assume that one of the 
> BLLI elements will indicate LLC, otherwise there is a protocol error.
> If the negotiation of an alternate encapsulation is prohibited
> then this may lead to implementations that assume there will only
> be one BLLI element and that it is LLC. This introduces a change
> in the IPV4/ATM and IPV6/ATM behaviours which is likely to cause
> interoperability problems rather than diminish them, given that
> there are likely to be systems that speak both IPV4 and IPV6
> and use the same signalling stack.
> 
> Bryan
> 
We put null encapsulation in RFC 1483 for a reason.  The reason was that for 
ATM VCs that only carry IPV4, a TCP SYN, FIN or ACK will exactly fit into one 
ATM cell (taking into account the AAL5 trailer) if no TCP or IP options are 
turned on.

Obviously, an IPV6 header barely fits into an ATM cell, even if no extension 
headers are used.  However, has anybody taken a look at whether there are 
frequent three-cell scenarios which could become two-cell scenarios by 
removing the SNAP header (common combinations of IPV6 extension headers, TCP 
options and/or very common user data that add up to 82-88 bytes?)  There was a 
thread earlier (which unfortunately got dropped) on the possibility of header 
compression for IPV4;  if we did something like that for IPV6, could we get 
TCP ACKs back down to one cell?

It seems that some people in the IP community snipe at ATM for the alleged 
cell tax.  If this is a sincere concern, then perhaps we ought to be looking 
not to preclude ways of reducing overhead to avoid crossing cell boundaries.

I'd like to see the null encapsulation retained for both PVCs and SVCs.

Dan


--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to majordomo@sunroof.eng.sun.com
--------------------------------------------------------------------

[prev in list] [next in list] [prev in thread] [next in thread]