The MPLS WG Archive

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



[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: "Jim Hand" <hand17@earthlink.net>
  • Date: Fri, 21 Feb 2003 10:56:00 -0500
  • Cc: "'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>
  • Importance: Normal

	Maybe we need to re-write draft-ash-e2e-crtp-hdr-compress-00 to clarify.  I
will look into this.

	This draft does require RSVP TE e2e over the MPLS part of the network, but
it does not require that MPLS or RSVP TE be extended to CE's.  And it does
not require that the original compressor and decompressor be attached to
MPLS.

	Also, it does require that routers other than MPLS "P" routers have the
ability to support compression and decompression.   But that does not mean
that these routers will have to *perform* compression and decompression on
each compressed packet.  Routers that support compressed packets on both
input links and output links should only have to perform a
decompression/compression cycle on a small fraction of the total number of
packets.  Most compressed packets would be switched from input to output
without performing decompression and compression.

Thanks,
Jim

> draft-ash-e2e-vompls-hdr-compress-00 requires e2e rsvp/te mpls for the
> above definition of e2e which I hope I don't have to repeat with every
> email message.
>
> draft-ash-e2e-crtp-hdr-compress-00 requires either of two conditions.
> 1) e2e rsvp/te mpls (for the above definition of e2e), 2) every router
> along the way knows how to do compression and decompression.
>
> Case #2 is the one that SP are saying is impractical because the PE
> CPU is overloaded with too many PPS.  Except for this practical matter
> case #2 is every bit as good a solution for the CE-PE links as rfc2508
> over PPP links (with most CE-PE being PPP).  Needless to say that
> makes case #2 completely absurd in the core (comp/decomp on oc192c
> interfaces).
>
> That brings us to draft-ash-e2e-vompls-hdr-compress-00 requires e2e
> rsvp/te mpls and draft-ash-e2e-crtp-hdr-compress-00 case 1 which
> requires e2e rsvp/te mpls plus requires every hop in the path to
> support comp/decomp making it even worse.
>
> Curtis
>
>
> > > -----Original Message-----
> > > From: Curtis Villamizar [mailto:curtis@fictitious.org]
> > > Sent: Wednesday, February 19, 2003 11:25 AM
> > > To: Ash, Gerald R (Jerry), ALABS
> > > Cc: curtis@fictitious.org; raymond zhang; MPLS@UU.net;
> George Swallow;
> > > Loa Andersson; GOODE, B (Bur), ALABS; Hand, James C, ALABS;
> > > Dave Cooper
> > > Subject: Re: E2E VoIP over MPLS ('VoMPLS') Header Compression
> >
> > >
> > > Please correct me if I'm wrong but your drafts seem to
> require end2end
> > > MPLS where RTP/UDP/IP/MPLS normally requires just end2end
> IP.  Since
> > > you are providing new RSVP/TE objects the assumption seems to be
> > > RSVP/TE MPLS edge to edge.  If traffic engineering is done within
> > > regions as can be done with current RTP/UDP/IP/MPLS regardless of
> > > whether LDP is also used, that works fine and scales
> extremely well.
> > > E2E RSVP/TE MPLS all the way to each peice of VOIP gear
> is unlikely to
> > > scale well in a single provider and is almost certain to become a
> > > severe problem crossing SP boundaries.
> > >
> > > Curtis
> > >
> >
> >