The MPLS WG Archive

[neil.2.harrison@bt.com]

Hemant,

Good question.  The answer depends on having a definition of what
constitutes the 'up' and 'down' states of the LSP.  [I will restrict the
scope of the discussion which now follows to the pt-pt case for reasons I
hope are obvious]

LSPs really need 2 dependent performance categories associated with them:
1	Availability, ie % time in the 'up' state
2	QoS metrics, eg lost pkts/octets, errored pkts, delayed >Xs pkts,
etc (which may be on a per DS-class basis say)

QoS metrics are only meaningful when the LSP is in the available
state.......so any QoS SLA associated with an LSP requires a prior
availability SLA to be in place.

{Aside: Above does not apply to the IP fabric except on an end-end basis
since it is cnls.  That is, the memoryless nature of forwarding and the
inter-dependency of forwarding and the IGP (ie required
stability/convergence) means that a cnls fabric mutates failures into QoS
hits.  There is nothing wrong with this.....this is the required design
behaviour.  However, the key significance of this observation is that any
*objectives* for availability/QoS metrics within the IP layer network are
only meaningful on an end-end basis, ie they cannot be easily (see Note)
partitioned to smaller subnetwork elements.  Note - Subnetwork partitioning
may be possible on a coarse domain level, say between ASs, providing a fixed
NNI interconnection point applies, ie traffic is always forced through a
given point.}

Now, to define the availability of an LSP one needs to define the
availability entry/exit criteria.  Please note that I would strongly advise
against associating any QoS metrics (and the many-fold OR'd combinations
possible) in the specification of such availability entry/exit criteria as
the problem will very quickly become too complex (and costly to measure).
The most pragmatic way to define the availability entry/exit criteria is to
base them soley on defects....and if one is sensible, again for simplicity
reasons, one should also try and temporally harmonise the defect entry/exit
criteria as well.

Once the availability entry/exit criteria are defined then we now have a
base against which to start/stop QoS metric aggregation.

So the answer to your question is 'it depends of how long the switching
takes relative to the unavailability entry criteria' (which has to have some
time parameter associated with it of course, so let's call this T):
A	if one can switch to a back-up LSP in t<=T then one should simply
take the 'QoS hit', ie some value of lost pkts/octets say.....and this would
also apply to any later revertive switching back to the original LSP;
B	if one cannot switch to a back-up LSP in t<=T then the QoS metrics
should be suspended (note that the QoS counters should be back-dated to the
onset (t') of this event, ie at t' = t-T).

In case A then QoS metric aggregation is simply *transferred* from the
working to back-up LSP as if nothing had happened (what has really happened
from a customer perspective is a 'short-break', but it was below the
unavailability threshold).  You should not be associating different QoS
metrics with the 2 LSPs since, from the LSPs perspective (or the customer
using it) the end-end source/sink trail points are unchanged by the prot-sw
action.

I have skipped many nuances/detail in the above, but I hope you grasp the
thrust of the issues that need addressing.  The required behaviour is
described/specified in detail in draft-harrison-mpls-oam-00.txt.

regards, Neil



> -----Original Message-----
> From: Hemant P. Kelkar [mailto:hemant@cyberspace.org]
> Sent: 29 August 2001 11:12
> To: mpls-ops@mplsrc.com
> Cc: mpls@UU.NET
> Subject: Label Statistics at the time of LSP switching
> 
> 
> Hi,
> I have a doubt regarding the MPLS input and output label statistics. 
> Usually an LSP can be denoted by input:output label & 
> interfaces (simplest
> case)
> When LSP switching occurs, the backup LSP identified by the new
> input:output label & interfaces.
> For these two cases (working and bakcup LSP) there will be 
> different sets
> of statistics counters.
> What is done with the working statistics counters, when the LSP is
> switched. Are they restored when the LSP is restored or they 
> are reset and
> statistics is referred by the new statistics counters(associated with
> backup LSP).
> regards,
> Hemant
>