The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2003-Feb> msg00073



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

E2E VoIP over MPLS ('VoMPLS') Header Compression - End-to-End MPLS

  • From: Curtis Villamizar <curtis@fictitious.org>
  • Date: Thu, 20 Feb 2003 10:21:40 -0500
  • cc: curtis@fictitious.org, "'Ash, Gerald R \(Jerry\), ALABS'" <gash@ems.att.com>, "'raymond zhang'" <zhangr@info.net>, "'MPLS@UU.net'" <MPLS@UU.NET>, "'George Swallow'" <swallow@cisco.com>, "'Loa Andersson'" <loa.andersson@utfors.se>, "'GOODE, B \(Bur\), ALABS'" <bgoode@att.com>, "'Dave Cooper'" <cooper@GBLX.net>


In message <000001c2d8f0$d5941e80$3a785b87@mt.att.com>, "Jim Hand" writes:
> 	In many VoIP services I am working with, the most important place for
> bandwidth efficiency is on the access link between the customer premise and
> the provider edge.  There is limited opportunity at the customer premise for
> connection muxing, because of the limited number of connections.  So I think
> it would be necessary to do compression on the access link in many cases
> anyway.

That is where the RTP/UDP/IP header compression can be utilized.
Either Casner's older RFC specifically for PPP or the newer one
(rfc3095) specifically for cellular.

> 	You could then do connection muxing inside the Service Provider's netwo
> rk.
> But in order to do the connection muxing, you would likely have to
> decompress the packets first (perhaps there might be some way around this).
> This would require a place in the network where you would have to do both
> compression/decompresion and connection muxing/demuxing.  That's a lot of
> load at some aggregation points in the network.  With the end-to-end
> compression, we were hoping to push the compression load out toward the
> edges, where there are more boxes to apply to the compression load, and
> avoid it altogether within the SP transport network.

Right.

You can't possibly do MPLS RSVP/TE from the customer edge all the way
to the other customer edge, so voice/MPLS is an immediate non-starter.

The aggregation router will need to decompress headers and forward.
If and only if backbone bandwidth is a pressing issue does any header
compression or multiplexing need to be done in the backbone.

Alternately you need a compression over IP that doesn't require e2e
RSVP/TE MPLS (for some large value of e2e).

> Thanks,
> Jim

What the SPs probably could really use for the access circuit
bandwidth problem is the RTP/UDP/IP header compression done on the
line cards rather than sent to the route processor (to be handled by
the onboard macintosh as one person at an ISP used to like to say when
680x0 was the processor on his routers).  I'm probably not the first
person to think of that, but I don't know that anyone has done it yet.

Curtis