The MPLS WG Archive

["Aris Kyriakopoulos" <aris@lucent.com>]

Hi David,

No argument about the fact that the ATM QoS model has more features and is 
more mature than the IP QoS model.  However, in order for non-ATM 
applications (specifically IP) to take advantage of ATM QoS, you need to 
be able to translate the IP QoS requirements into ATM signalling.

As far as I am aware, there is no way you can do this in a 
dynamically-routed IP network.  Sure, you can map static IP routes to ATM 
(S)PVCs.  Even then, what mechanisms are there to distinguish between 
different IP flows over the same route (e.g. by ToS, TCP/UDP ports)? 
Because to ATM, all IP packets are created equal, right?  To me, this is 
one of the good reasons to use MPLS: using ATM switching hardware to 
provide IP QoS.  Even though the IP QoS model is not as rich as ATM's, at 
least ATM LSRs provide some sort of QoS mechanism for IP that CLIP/MPOA 
simply do not.

I agree that RSVP and CR-LDP probably need to provide better delay 
information than they currently do in order to support delay-sensitive 
applications.  That is the key, though; these metrics need to be added to 
IP QoS.  Or maybe the IP QoS model needs to be extended to have 1-to-1 
mapping with ATM QoS.  At least on ATM LSRs.

Regards,
Aris






David Charlap <david.charlap@marconi.com>
Sent by: owner-mpls@UU.NET
04/19/2001 01:44 PM

 
        To:     mpls@UU.NET
        cc: 
        Subject:        Re: ATM-LSR do they use OSPF/IS-IS or PNNI??


> 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