The IP over ATM Mailing List Archive by date

Cell Relay Retreat>List Archive>month:1995-Oct> msg00084



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

Header Compression.

  • From: Grenville Armitage <gja@thumper.bellcore.com>
  • Date: Mon, 23 Oct 1995 10:24:36 -0400
  • CC: ip-atm@matmos.hpl.hp.com, gja@thumper.bellcore.com


Pat,
	[..]

>>Can RFC1144 be used over ATM?  If the final destination
>>lies on the other side of some router, will the negotiation just
>>fail for the TCP connection and just not allow compression and
>>not cause anything to break?

My impression was that RFC1144 was originally contemplated as
a per-link compression scheme. That would suggest that (a) you
could apply it to ATM, and (b) the compression applies between
the two endpoints of the VC. So, your exit router out of the LIS
would have to understand RFC1144 compressed packets in order to
forward such traffic. It is certainly theorectically possible to
specify a SETUP phase negotiation indicating the use of RFC1144
compression. Even easier would be to define a new LLC/SNAP
codepoint indicating "these IP packets have had their headers
compressed". This second approach would be applicable to
either VC-muxing (SNAP carried in B-LLI in SETUP) or LLC/SNAP muxing
(SNAP carried in-band).

I took a bit of a look at the possible impact of RFC1144 compression
on IP/ATM traffic in the following article:

G.J. Armitage, K.M. Adams, "How Inefficient is IP over ATM anyway?",
IEEE Network, January 1995. 


cheers,
gja