The MPLS WG Archive

Cell Relay Retreat>MPLS WG Archive>month:2001-Jun> msg00362



[Date Prev][Date Next][Thread Prev][Thread Next]  
  [Date Index][Thread Index][Author Index][Subject Index]

intserv vs diffserv

  • From: neil.2.harrison@bt.com
  • Date: Sun, 24 Jun 2001 10:27:40 +0100
  • Cc: mpls@UU.NET

Robert Raszuk wrote 23 June 2001 18:24

<snipped>
> > And one question regarding diffserv only: does the setting up of
> > packet's DSCP value in domain boundary mean that this packet will be
> > treated in the same way in all nodes of the domain?
> 
> It depends of the configuration of each node and does not 
> have anything
> to do specifically with MPLS. MPLS header is just a vehicle 
> to carry the
> EXP bits. In DS-TE the middle nodes diffserv scheduling configuration
> can be automated via RSVP so you can assume that for such a flows the
> answer would be yes.
> 
> R.
NH=> This is true for the up-state QoS scheduling behaviour.  However,
upstate QoS sheduling and the *importance* of a given application's traffic
are not related.  That is, whether a voice connection is mission critical
(ie must survive) or not (ie can be dropped under failure) cannot be
inferred from the DS EF codepoint alone.  One can also imagine corresponding
cases for the AF classes.

This has some important implications for private VPNs vs generic public
services.  In the former case if DS classes are merged across VPN
populations (eg by using vanilla LDP as the server layer of LSPs to say
client BGP4 distributed LSPs in the RFC2547 model) it is not clear to me how
one can offer solid, and differentiable, survivability SLAs to a given VPN
topology.

One approach may be based on a concept of 'effective BW per LSP' that
defines the VPN topology that is required, and the survivability is a
function of the LSPs effective BW and not on a per pkt DS class basis.  Here
DS scheduling in now only relative to the VPN LSP traffic and not the
general population traffic, and the key metric that the operator is
concerned with is overall MPLS layer VPN LSP topology survival (relative to
other private VPNs and the general public service traffic....again in its
own, but this time 'operator owned', internal VPN). 

An alternative view could be to take each of the DS classes and associate it
with some survivability index.  For illustrative purposes only, let's say
there are N DS classes and M survivability indices.  One might now need to
create NxM LSPs across the network (assuming each N QoS class could be
associated with any of the M survivability indices) and allocate the traffic
at ingress accordingly.  

neil