The MPLS WG Archive

[Theimer Thomas <Thomas.Theimer@icn.siemens.de>]

Lou,

I just wanted to point out that there is another proposal on the table for end-end compression with MPLS that doesn't even require any changes to existing header compression mechanisms. All that is needed is carrying PPP over MPLS. You can then run any header compression offered by PPP end-end over MPLS (be it RFC 2508/2509 or robust HC or any other scheme). You can even run header compression over non-PPP links (e.g. Ethernet) if they can support MPLS.

The proposal is described in draft-theimer-tcrtp-mpls-00.txt. Its efficiency is much better than the "simple" end-end compression, but it is of course much more complex to process. However, since the compression is done very close to the source, this may still be acceptable (anyway, if the source is connected to the bottleneck link, it makes no difference if compression is one-hop or end-end). One might even link the state of VoIP calls to the compression context if desired. Eric's issue with not knowing higher layer protocols is also a non-issue with end-end compression.

My interpretation of this "consensus" thread is that there is more support for end-end compression than there is for one-hop compression with MPLS. Please correct me if I'm way off here.

Thomas
> -----Original Message-----
> From:	Lou Berger [SMTP:lberger@labn.net]
> Sent:	Friday, July 21, 2000 7:58 PM
> To:	erosen@cisco.com
> Cc:	Lou Berger; Eric Gray; MPLS Mailing List (E-mail); 'George Swallow'
> Subject:	Re: Consensus on compression - draft-ietf-mpls-hdr-comp-00.txt
> 
> Eric,
>          The reason why you'd use the "one hop" approach over simple is 
> that the two compression schemes have vastly different efficiencies.  (17 + 
> 4 bytes/label versus 2 or 4 bytes. see slide 11 of my Adelaide 
> presentation.) IMO the "one hop" approach is best suited for those links in 
> the network that are very tightly constrained.  This may be on very slow 
> speed links or just "slower" speed links, where "slower" is limited by the 
> hardware being used.
> 
> I think your characterization below of an application is valid.  The VPN 
> example came in on a question of why there would ever be multiple 
> labels.  The case I was thinking about is were there is an inner label that 
> indicates VPN and an outer label that indicates an egress.  I didn't mean 
> to be evasive, I just didn't think it was that complicated.  I've also 
> heard mentioned using label stacking where, as with VPNS, the inner label 
> indicates an application session.
> 
> Lou
> 
> At 01:32 PM 7/21/00 -0400, Eric Rosen wrote:
> 
> >I  think the  basic question  is whether  there  is a  use for  a "one  hop"
> >compression strategy.
> >
> >Some  people  have mentioned  voice  traffic  as  an application  for  which
> >compression would be required.  If voice packets tend to be very small, then
> >compression might well be significant, even on higher speed lines.  However,
> >that does not seem to me to be a good application of a "one hop" compression
> >scheme.  It seems much better suited to a scheme which compresses at the LSP
> >ingress and decompresses  at the LSP egress, such as  is described in draft-
> >swallow-mpls-simple-hdr-compress.txt.
> >
> >So we're back to the case of low speed access lines carrying MPLS traffic in
> >a non-voice application,  and I still haven't seen a  clear statement of the
> >need.  You do hint at one:
> >
> >Lou> Think MPLS based access links that support VPNs, as one example.
> >
> >I'm not  aware of a  VPN scheme which  requires running MPLS over  low speed
> >access links.   But let  me see  if I can  guess what  you might  be talking
> >about.
> >
> >One could  imagine a piece of  Customer Premises Equipment  (CPE), a router,
> >which has  an ethernet interface  (to connect to  endusers) and a  low speed
> >wireless interface  (to connect  to the backbone).   One could  also imagine
> >that  when the  CPE  receives an  ethernet packet,  it  assign it  to a  VPN> 
> >according to some  criteria.  One could also imagine  that the CPE maintains
> >an LSP  for each VPN, with  the next LSP  hop being another router  which is
> >reached over the wireless interface.
> >
> >If this  is the  sort of thing  you're talking  about, then I  do see  how a
> >"single hop" header compression scheme could be useful.
> >
> >Of course, you could  say what you're talking about and save  the rest of us
> >the trouble of having to surmise it ;-)
> >
> >I have a little more trouble imagining why a packet on this link would carry
> >more than one label.  But  perhaps the usefulness of the compression doesn't
> >depend on there being more than one label.
> >
> >Whether this is  actually a good solution to the problem  of a multi-VPN CPE
> >connected by a slow link to  the backbone is something on which I'll reserve
> >judgment.
> >
> >Of course, if I haven't guessed  correctly the application you have in mind,
> >then I still don't see the use of the compression.