The MPLS WG Archive

["Rosen, Brian" <Brian.Rosen@marconi.com>]

There is some effort in the MPLS Forum to define VoMPLS for a class of
problems that are best described as severe bandwidth restrictions on
the MPLS link.  It trades off incompatibility with every other
VoXXX for link efficiency.  That spec is getting close to being
finished.

End-to-End delay is currently limited by routers - switches don't
add significant delay.  We can pretty easily build 30 ms end to end
systems using ATM switches.  Router delays are typically much longer,
but then again, some things that are called routers are really
switches, and some real routers have so much hardware that they
don't add much delay, especially for a media stream (which gets to
use cached information effectively).  Still in all, if you see
traceroute giving you 200 ms RT times, better have long tails on
your echo cancel!

Putting a bound on delay would be nice, but I don't see routers
implementing that any time soon.

Brian 

-----Original Message-----
From: Naidu, Venkata
To: Charlap, David; mpls@UU.NET; Rosen, Brian
Cc: 'mpls-ops@mplsrc.com'
Sent: 4/19/01 2:39 PM
Subject: RE: ATM-LSR do they use OSPF/IS-IS or PNNI??

Hi David

Please look at the Voice over MPLS framework document:
http://www.alternic.org/drafts/drafts-k-l/draft-kankkunen-vompls-fw-01.p
df

Presently so many VoIP working groups (MMUSIC/SIP/IPTel etc) have
there own mechanism for end-to-end delay characteristics but at the
applications level.

But in the above draft they made some progress to Voice Traffic 
Engineering using MPLS and Dynamic traffic management. Section 5 
is left unanswered about Requirements for MPLS signaling 
(LDP/CR-LDP and RSVP-TE)

Unfortunately I didn't see any progress after in VoMPLS.

-Venkata Naidu

> > I agree with your points above. However, I don't think there is
> > anything stop MPLS implemented with a hard QoS mechanism like ATM
> > has done. A good LSR with the necessary traffic management
> > infrastructure (queuing and scheduling) can achieve the same
> > level, if not better QoS.
> 
> One clear advantage of ATM is that ATM provides more parameters for
> tuning QoS than RSVP or CR-LDP do.
> 
> None of the current MPLS signaling protocols provide a way to specify
> delay characteristics as part of QoS.  ATM's QoS allows signaling of
> delay and delay variation.  RSVP's ADSPEC object allows the collection
> of delay information, but there is no way to request that the network
> try to establish an LSP that conforms to particular delay
> characteristics.
> 
> Delay information is important for circuit-emulation and for real-time
> streaming applications (like voice/video).
> 
> Of course, delay factors are much less of a problem today (with
> extremely fast backplanes and OC-x interfaces) than they were in the
> recent past (with slower backplanes and DS-x interfaces), but I don't
> think we're yet at the point where they can be completely ignored.
> 
> I think there are still some applications where delay and delay
> variation are important even on today's hardware.
> 
> Of course, there's no reason why delay characteristics 
> couldn't be added
> to either RSVP or CR-LDP in the future.
> 
> -- David
>