The MPLS WG Archive

[Bora Akyol <akyol@pluris.com>]

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.