The MPLS WG Archive

["Naidu, Venkata" <Venkata.Naidu@Marconi.com>]

Hi David

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

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
>