mpls/te as end-system qos

["Greene, Jeremy" <Jeremy.Greene@sonusnet.com>]

It seems that mpls/te/cr could be a better end-system QoS solution than some
of the existing solutions (rsvp/intserv, diff-serv). Particularly when using
diff-serv aware mpls/te/cr/rsvp-te.

When using CR with mpls/te, the two worlds of te and end-system qos seem to
have considerable overlap.

Particularly if an end-system's LSP can either be automatically
merged/stacked or explicitly stacked (based on a new rsvp/te resource class)
within the provider network. And you even get mulit-homing control and
resiliency features.

So, one question is, why not always use rsvp-te, lsps and cr, even from
end-systems (assuming label stacking is supported)? I suppose having
end-systems run ospf-te and mpls could be a hassle. Or is it just too hard
to scale in the network? But even so, for some large nodes, it still could
be very desirable.

Part of the motivation for this is that it seems that there is very little
support for rsvp/intserv (to signal either diff-serv or mpls in the provider
network) in routers today (except for cisco) while there's very wide-spread
support for rsvp-te. So an end-system has few other options if it wants to
even request a hop-by-hop service, let alone a CR path. Any vendors care to
comment on this?

Jeremy