The MPLS WG Archive

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



[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 08:25:32 -0500
  • cc: curtis@fictitious.org, hand17@earthlink.net, gash@ems.att.com, zhangr@info.net, MPLS@UU.NET, swallow@cisco.com, loa.andersson@utfors.se, bgoode@att.com, cooper@GBLX.net


In message <20030220150029.0000212f.gabhijit@ee.iitb.ac.in>, Abhijit writes:
> 
> I remember reading some work done on Voice over MPLS directly without using R
> TP/UDP/IP overheads. Is that work going to be a part of MPLS WG? 
> IMO, RTP/UDP/IP is a lot of overhead, compared to VoMPLS approach which actua
> lly serves the same purpose (atleast in bearer path)
> 
> Regards, 
> 
> -abhijit.


That work died a long time ago because it required that e2e (or encaps
device to encaps device) LSPs be used.

MPLS RSVP/TE (or LDP) is **NOT** an end2end virtual circuit
technology.  RSVP/TE is a traffic engineering tool.  It has so far
been successfully very applied to traffic engineering localized to SP
core or SP regions.  With the addition of GMPLS it becomes a bit of a
carrier's swiss army knife, supporting dynamic traffic engineering
over optical and TDM but deployment of GMPLS may be a ways off.

The reason I'm objecting to the drafts that were offerred is that they
also required e2e (compression device to compression device) RSVP/TE
LSPs and as a result may be impractical (ie: doomed to the same fate
of the prior voice/MPLS effort).

Ideally some scheme that allowed end users to encapsulate very
efficiently but also met carrier needs would be best.  That idealized
goal doesn't seem feasible.  For the end user (for example, using
voice over IP from PC to PC) adding delay and increasing packet size
seems the only feasible option.  For the carrier, multiplexing streams
from a gateway seems to me to be a more attractive solution than a
special encapsulation between gateways that requires an e2e (do I need
to repeat the disclaimer on e2e again) RSVP/TE LSP to work.

Curtis

ps - end2end in this sort of context (MPLS, RSVP/TE or LDP) is always
assumed to mean at most edge of the carrier's network, not end user.
This is because end user to end user in an MPLS discussion is so
absurd that it can't possibly be intended as part of the discussion.
E2e is assumed to mean the edge of whatever is being discussed, the
edge is the voice compression/encaps gateways in this context.