The MPLS WG Archive

[David Charlap <david.charlap@marconi.com>]

Aris Kyriakopoulos wrote:
> 
> 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.

Correction: In order for MPLS applications to take advantage of ATM QoS.

There are other ways of running IP over ATM, even though they are not
popular as core technologies.

> 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)?

Assigning any QoS other than best-effort to IP traffic requires some
degree of policy control.  DSCP bits may be used, so can source
addresses, physical interface, L4 information, etc.

> Because to ATM, all IP packets are created equal, right?

Once the packet gets into the ATM VC, there is no IP, just cells.  It is
the edge router (which puts the IP packets into the VC) which must have
the ability to classify the packets and determine what goes where.

Which is exactly the same in the MPLS world.  Once a packet is in an
LSP, it is forwarded according to that LSP's rules.  Yes, a certain
amount of per-packet QoS is available if E-LSPs are used, but the edge
router must still do the bulk of the packet classification - to
determine what LSP to put the packet on and to determine what the EXP
bits should be set to.

> 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.

The host-side software for CLIP/MPOA (when ATM is run to the desktop)
can and does provide the ability to setup application-specific VCs with
different levels of QoS.  There's no reason why an edge device (serving
to gate an IP network into ATM) couldn't do the same thing.

As for ATM switching hardware, there's no reason why non-ATM hardware
can't do the same thing.  ATM hardware has some definite problems when
it comes to MPLS - VC (label) merging is difficult, cell tax, no native
label-stacking mechanism, etc.

> 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.

There's no need to use the ATM-style parameters.  As a matter of fact,
many wouldn't be appropriate without modification anyway, since they are
in terms of cells, not bytes or IP packets.

The IntServ parameters (used by RSVP) are very good for what they
specify.  They just don't specify enough.  But IntServ is extensible. 
There's no reason why additional services couldn't be defined that
contain delay parameters.

-- David