The MPLS WG Archive

[neil.2.harrison@bt.com]

Thanks JP,

who wrote 11 August 2005 12:00 <snipped>

> > However...and having said all that.....I am always puzzled why some 
> > folks think really rapid restoration MUST be done for 
> voice.  I can't 
> > believe anyone would clear down a call after 10s, 100s or 
> maybe even a 
> > few 1000 ms of loss.  I know there is some macho 'must equal/beat
> > SDH's
> > 50ms' mindset at work here.....but this is nuts.  I know 
> the folks who
> > set the 50ms defect detection threshold in SDH and this was NOT  
> > done to
> > accomodate voice, or any application for that matter.  It was simply
> > down to the physics and ring topologies being considered.
> >
> 
> That really depends on your targeted SLA ... If indeed the 
> goal is to  
> avoid a drop call, you're absolutely right, 1-2s is probably good  
> enough depending on the VoIP GTW. On the other hand, if you want to  
> avoid any voice quality degradation (in other words, no failure  
> detection by the user), then your rerouting time objective will  
> probably be on the order of a few tens of ms. Is there a golden  
> number one should never exceed ? Certainly not .... but a few 
> tens of  
> ms is undoubtedly a good target reasonably achievable in the vast  
> majority of the failure cases (provided a fast failure detection at  
> the lower level). Many tests have been conducted during the last few  
> years that showed a significant MOS degradation when exceeding a few  
> hundreds of ms.
> 
> JP.
NH=> If we could protect instantly that would be the best.
Unfortunately you can trigger unnecessary protection events by going too
quickly, eg an error event causing one lost OAM pkt, and thus cause more
harm than good......especially if you have to make choice on *which*
traffic to restore if there is a resource shortfall following a failure.
Voice traffic may not be the most important traffic (and BTW there is no
relationship between an application's QoS requirements and its
survivability importance).

So you need some integration period over which you make sure this is a
real failure event and not some transient error event.  And I as I noted
earlier it all depends which layer network you are considering the
failures reside in...the rule (of thumb) is as I stated before: closer
to the duct the faster, closer to the application the slower.  Further,
if you have no sense of harmonisation/alignment across the layer
networks then you can be invoking protection unnecessarily at the wrong
layer network.  This is not a good thing either.

However, I have a question.  What MPLS OAM mechanisms are you assuming
are being used here?  I am not interested in defects in the co-cs mode
layer networks (like SDH, I know about these) but I am particularly
interested to understand what MPLS layer defects you are referring to
(because these cannot be detected by lower layer networks), and what the
entry/exit criteria and consequent actions are that you would use here
and where these are defined.

Note - I note you mention SLAs...and I agree these are very important.
Now an SLA has 2 related (but quite distinguishable) parts:  A part that
defines the amount of unavailability (ie down-time) that is allowed, and
a part that defines the network transfer performance impairments that
are allowed when available (ie up-time).  So in order to define SLAs,
and please note this also includes apportioning impairment allowances to
different operators domains when interworking, then its rather important
to have some standardised metrics and their objectives agreed here for
these 2 parts of the SLA.  However, to define the Network Performance
SLA part you must know whether the trail is up or down....which means
you must have defined the entry/exit criteria for unavailability (as Net
Perf metric collection for SLA purposes must be suspended when
unavailable).....and in order to specify the availability SLA part you
must 1st have clearly defined defects with entry/exit criteria and
consequent actions.  Hence, to even talk about SLAs we must start with
knowing where the defects are defined....hence my question above.

regards, Neil 

_______________________________________________
mpls mailing list
mpls@lists.ietf.org
https://www1.ietf.org/mailman/listinfo/mpls