The MPLS WG Archive

[Lou Berger <lberger@labn.net>]

Bora,
         It works just like standard IP header compression.  (It is after 
all, just a minor extension to it.)  "[...]the access box terminates the 
one hop compression and then sends normal MPLS packets [...]"  is what is 
documented.    Just like in normal IP header compression, a decompressor 
could compress on the outgoing link, but this isn't the norm.

Lou

At 11:27 AM 7/21/00 -0700, Bora Akyol wrote:
>I for one think that the one hop strategy is unacceptable especially if this
>continues "one hopping" through to the core routers. If the access box
>terminates the one hop compression and then sends normal MPLS packets then 
>this
>is OK; otherwise, this is a major change in the architecture and should be
>avoided at all costs.
>
>Bora
>
>
>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.