Subject: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

From: "Rafi Ram" <[email-masked]>
Date: Thu, 1 Jul 2010 14:05:52 +0300

Hi TP-Group, 

A new Internet Draft titled "Throughput SD detection and protection
triggering in MPLS-TP" has been submitted :
http://tools.ietf.org/html/draft-rkhd-mpls-tp-sd-00

This draft describes guide lines for Signal Degrade (SD) link fault
condition detection and the use of MPLS-TP fault management for
triggering protection switching. 

Any comments and discussion are welcome. 

Best Regards,

Rafi

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 09:26:41 -0400

> Any comments and discussion are welcome.

begin FYI -

   o  Criterion for determining signal degrade SHOULD be able to detect
      low BER condition (e.g. 10E-5)
 
BER of 10^-5 for 1500 byte packets (>10^4 bits) translates to > 10%
packet loss.  That would not be a low error rate.  Perhaps you meant
packet drop rate of 10^-5.

FEC today typically tries to reduce error rates that start out on the
10^-12 BER to 10^-15 order of magnitude on a circuit that is working
well.  On a 100 Gb/s wave there are 10^11 bits each second, so bit
error rates are measurable in seconds per bit error.

As long as error rates remain low they are correctable.  These are
correctable FEC errors on an OTN link, not across an LSP and the FEC
to handle these is computationally intensive and must be done in
dedicated hardware.

Even a 10^-10 BER would typically be an almost 100% correctable rate
even though this could be considered a higher than normal rate.  Note:
a resulting 10^-15 is typically considered fully correctable,
sometimes higher since this is 1 uncorrected bit per 10^4 seconds.

For OTN with FEC, the errors are corrected such that they can be
detected while there is still virtually zero packet loss.  Today's
practice is to report increased FEC error rate to management plane
first (let polling record it or raise a minor alarm), then declare the
link down if the situation persists or degrades further.

Again, Ethernet with only a CRC based FCS is another story.  Packet
drop rates are detected and are uncorrectable.  BER in this case can't
be measured (you don't know how many bits in the packet are wrong).
Note that there are already MIBs for this so its just a local matter
of setting threshholds.

- end FYI

This draft adds very little to draft-ietf-mpls-tp-fault-01 except to
say that the method of detection or setting threshholds is out of
scope.  I don't think we need an RFC just to say that.

Curtis

---

From: "Rafi Ram" <[email-masked]>
Date: Wed, 14 Jul 2010 18:40:29 +0300

Dear Curtis,

A typical threshold for signal degrade protection triggering in
transport networks today is BER of 10^-9 to 10^-3 (please refer to
Figure 5-5 GR-253-CORE).

This value should be adapted to specific transport technology and
carrier requirements.

The motivation for this draft is to provide informational overview on
carrier needs for signal degrade detection and the architectural
solution in MPLS-TP. draft-ietf-mpls-tp-fault or
draft-ietf-mpls-tp-linear-protection do not provide this end-to-end
view.

Please notice that some proposals for SD detection in MPLS-TP are based
on OAM which are problematic with respect to the following aspects :

*         Cannot detect low BER condition with reasonable time, false
alarm probability and miss-detect probability
*         Not agnostic to the traffic class or drop precedence marking
of frames transmitted over the link
*         Not agnostic to link congestion level

Best regards

Rafi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of Curtis Villamizar
Sent: Wednesday, July 14, 2010 4:27 PM
To: Rafi Ram
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

"Rafi Ram" writes:

 

begin FYI -

dedicated hardware.

of setting threshholds.

- end FYI

Curtis

_______________________________________________

mpls-tp mailing list

[email-masked]

https://www.ietf.org/mailman/listinfo/mpls-tp

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 14 Jul 2010 18:21:19 +0200

Please be aware that BER 10-x defect detectors are not present in OTN, and
are one of the options in SDH. The OTN and second option in SDH is detecting
the Degraded defect (dDEG) on the basis of M consecutive BAD seconds; M in
the range 2-10, default =7. A second is declared BAD when the number of
errored blocks detected in the second exceeds the SES threshold value. Refer
to G.806 for the specification details.
 
dDEG contributes to signal degrade: SD = dDEG
 
Rationale for this definition of dDEG/SD is to prevent that the protected
connection enters UnAvailable Time (UAT). UAT is entered after 10
consecutive severely errored seconds (SES). If e.g. working connection has
experienced 7 consecutive SESs, then a protection switch is initiated; this
guarantees that there will be at maximum 8 to 9 consecutive SESs detected by
a connection's endpoint and the connection will not enter the UAT state.
 
Regards,
Maarten

  _____  

From: [email-masked] [mailto:[email-masked]] On Behalf
Of Rafi Ram
Sent: woensdag 14 juli 2010 17:40
To: [email-masked]
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Dear Curtis,

A typical threshold for signal degrade protection triggering in transport
networks today is BER of 10^-9 to 10^-3 (please refer to Figure 5-5
GR-253-CORE).

This value should be adapted to specific transport technology and carrier
requirements.

The motivation for this draft is to provide informational overview on
carrier needs for signal degrade detection and the architectural solution in
MPLS-TP. draft-ietf-mpls-tp-fault or draft-ietf-mpls-tp-linear-protection do
not provide this end-to-end view.

Please notice that some proposals for SD detection in MPLS-TP are based on
OAM which are problematic with respect to the following aspects :

*         Cannot detect low BER condition with reasonable time, false alarm
probability and miss-detect probability
*         Not agnostic to the traffic class or drop precedence marking of
frames transmitted over the link
*         Not agnostic to link congestion level

Best regards

Rafi

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: Wednesday, July 14, 2010 4:27 PM
To: Rafi Ram
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

"Rafi Ram" writes:

 

begin FYI -

dedicated hardware.

of setting threshholds.

- end FYI

Curtis

mpls-tp mailing list

[email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 15:29:05 -0400

> transport networks today is BER of 10^-9 to 10^-3 (please refer to

This would be unacceptable link BER after correction to many
customers, certainly in core circuits.

Just a back of the envelope computation says that 10^-3 bit error rate
with 1500 byte packets (10^4 bits) would mean that most of the packets
are dropped.  

	perl -e 'print (exp(log(1.0 - 0.001) * 12000)); print "\n";'
	6.10743300605236e-06

Six in a million full size Ethernet packets gets through at 10^-3 BER.
Not good IMHO.  10^-9 BER is fairly good, with 10^-5 packet drop
(closer to 10^-4 with jumbo packets - still not quite meeting the
goals for HPCC SC use circa 1994 but probably a reasonable point to
trigger protection).

Just putting the slightest bit of thought into this says these numbers
are wrong.  10^-9 BER with 500B average packet is 2.5E-6 packet drop.
A 100 Gb/s link would handle 2.5E-8 PPS and so have an error rate of
100 PPS.  I don't think that will qualify as working just fine.

I'm not looking at GR-253-CORE but I suspect this is a BER before a
FEC correction rather than after, and even then it is high based on
what our customers are expecting.

Curtis

---

From: <[email-masked]>
Date: Wed, 14 Jul 2010 21:40:10 +0100

Curtis...if you think Poisson models of errors in transport networks are
the norm (ie BER) then this is wrong....and this may ease the concerns
you expressed below.  Andy Reid and I measured 100s of transport paths
in BT's networks over several years in the late 80s early 90s and the
background thermal noise (ie BER) error events were almost insignificant
compared to the burst error and short-break events (wrt to the former we
were seeing at least 10^-15 on typical optical, and even some radio,
sections).  The mathematical models of the dominant error bursts we
needed were not trivial and were based on self-similar/chaos-like
behaviour....hardly surprising when the sources were things like the
weather and human activity.  These are the ones to be concerned
about....and if the thermal noise (ie S/N margin) is so bad that Poisson
error mechanisms dominate then we have a have broken section layer
design IMO....fix that instead.

regards, Neil 

> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Curtis Villamizar
> Sent: 14 July 2010 20:29
> To: Rafi Ram
> Just a back of the envelope computation says that 10^-3 bit 
> error rate with 1500 byte packets (10^4 bits) would mean that 
> most of the packets are dropped.  
> 
> Not good IMHO.  10^-9 BER is fairly good, with 10^-5 packet 
> drop (closer to 10^-4 with jumbo packets - still not quite 
> meeting the goals for HPCC SC use circa 1994 but probably a 
> reasonable point to trigger protection).
> 
> Just putting the slightest bit of thought into this says 
> these numbers are wrong.  10^-9 BER with 500B average packet 
> is 2.5E-6 packet drop.
> A 100 Gb/s link would handle 2.5E-8 PPS and so have an error 
> rate of 100 PPS.  I don't think that will qualify as working 
> just fine.
> 
> I'm not looking at GR-253-CORE but I suspect this is a BER 
> before a FEC correction rather than after, and even then it 
> is high based on what our customers are expecting.
> 
> Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 16:48:29 -0400

In message <[email-masked]>
Maarten Vissers writes:
>  
> Please be aware that BER 10-x defect detectors are not present in OTN,
> and are one of the options in SDH. The OTN and second option in SDH is
> detecting the Degraded defect (dDEG) on the basis of M consecutive BAD
> seconds; M in the range 2-10, default =7. A second is declared BAD
> when the number of errored blocks detected in the second exceeds the
> SES threshold value. Refer to G.806 for the specification details.
>  
> Rationale for this definition of dDEG/SD is to prevent that the
> protected connection enters UnAvailable Time (UAT). UAT is entered
> after 10 consecutive severely errored seconds (SES). If e.g. working
> connection has experienced 7 consecutive SESs, then a protection
> switch is initiated; this guarantees that there will be at maximum 8
> to 9 consecutive SESs detected by a connection's endpoint and the
> connection will not enter the UAT state.
>  
> Regards,
> Maarten

Maarten,

The SES criteria is for very low loss rates that persist.  UAS is
immediate.

The criteria for an ES is any error.  The criteria for SES is a small
number of errors (10?).  The criteria for UAS is a higher number of
framing errors (100?), but takes effect as soon as that number is hit.

This is from memory working with TDM and SONET over a decade ago.  If
I'm wrong, I'd appreciate it if someone would correct me.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Wed, 14 Jul 2010 23:49:43 +0200

Curtis,

UAS is not immediate. An UAS represent a second in UAT; UAT starts only if
there have been 10 consecutive SESs.

An SES in SDH is defined as having between 10% and 60% of Errored Blocks;
note that a defect causes a SES as well. The specifications can be found in
Annex B/G.828 (for VC-n, 30% errored blocks) and in clause 5 and 7 of G.829
(for MSn (between 10% and 40% Ebs), RSn (between 10% and 60% EBs)).

G.826: http://www.itu.int/rec/T-REC-G.826/en
G.828: http://www.itu.int/rec/T-REC-G.828/en
G.829: http://www.itu.int/rec/T-REC-G.829/en

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 14 juli 2010 22:48
To: Maarten Vissers
Cc: 'Rafi Ram'; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

The SES criteria is for very low loss rates that persist.  UAS is immediate.

The criteria for an ES is any error.  The criteria for SES is a small number
of errors (10?).  The criteria for UAS is a higher number of framing errors
(100?), but takes effect as soon as that number is hit.

This is from memory working with TDM and SONET over a decade ago.  If I'm
wrong, I'd appreciate it if someone would correct me.

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 15 Jul 2010 00:13:33 +0200

Curtis,

Refer to Y.1563 for the definition of an Ethernet SES. Available/Unavailable
time for Ethernet is also defined on the basis of 10 SESs. See clause
9/Y.1563. A provisional specification for the SES definition defines the SES
to be set if the FLR in the second is >=0.5 (i.e. 50% frame loss).

FEC usage causes that the bit error rate range between almost zero bit
errors after FEC and 1E-3 bit error rate after FEC is very small. The
Enhanced FECs described in G.975.1 make that range almost zero; i.e. its
very good, or very bad after FEC with nothing in between. E.g. 3.5E-3 input
BER has 2.1E-14 output BER and 5.0E-3 input BER has 3.0E-3 output BER (see
I.9/G.975.1).

G.975.1: http://www.itu.int/rec/T-REC-G.975.1-200402-I/en
Y.1563: http://www.itu.int/rec/T-REC-Y.1563/en

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf
Of Curtis Villamizar
Sent: woensdag 14 juli 2010 21:29
To: Rafi Ram
Cc: [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

> transport networks today is BER of 10^-9 to 10^-3 (please refer to 

This would be unacceptable link BER after correction to many customers,
certainly in core circuits.

Just a back of the envelope computation says that 10^-3 bit error rate with
1500 byte packets (10^4 bits) would mean that most of the packets are
dropped.  

Six in a million full size Ethernet packets gets through at 10^-3 BER.
Not good IMHO.  10^-9 BER is fairly good, with 10^-5 packet drop (closer to
10^-4 with jumbo packets - still not quite meeting the goals for HPCC SC use
circa 1994 but probably a reasonable point to trigger protection).

Just putting the slightest bit of thought into this says these numbers are
wrong.  10^-9 BER with 500B average packet is 2.5E-6 packet drop.
A 100 Gb/s link would handle 2.5E-8 PPS and so have an error rate of 100
PPS.  I don't think that will qualify as working just fine.

I'm not looking at GR-253-CORE but I suspect this is a BER before a FEC
correction rather than after, and even then it is high based on what our
customers are expecting.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 18:31:14 -0400

> design IMO....fix that instead.

Thanks Neil.  The optical people here confirm that errors come in
bursts.  Note that fiber is not affected by rain very much.  You could
argue that lightning could create E/M affect a lot of electronics but
it is nothing like radio.  Changing bend radius (moving the fiber in
the physical plant is known to cause errors that can be corrected.  
Vibration can effect the fiber.

Just for simplicity I did the back of the envelope calculations here.
Note the phrases "Just a back of the envelope computation says ..."
and "Just putting the slightest bit of thought into this says ...".
It wasn't intended to be a thesis on error statistics.

Both other vendors and customers indicate that FEC error rates going
up are a good source of early warning for taking a link out of service
and taking corrective action proactively.  This is where an SD
indication in OAM would help, which was after all the original topic.

Anyway, the point is that a BER of 10^-3 to 10^-5 is terrible and I
think that you'd agree that 10^-8 to 10^-9 is borderline acceptable.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 14 Jul 2010 18:51:39 -0400

Maarten,

Thanks.  I was not even close.  Perhaps what I remember is what we had
configurable threshhold set to to get the response we wanted.  In any
case, on a small number of framing errors POS links could be taken
down.  On "dribbling" errors POS links could also be taken down.

I'm quite sure we didn't tolerate 10% errors under any circumstances
either when I was at a provider (actually two IP providers) or at a
router vendor.  To us SONET was a dumb framing protocol used for point
to point POS links (and to an extent that hasn't changed) and we
didn't care much what the SONET recommendation were as long as we
could configure parameters on equipment to get the desired behaviour.

The routers could easily count POS (SONET) framing errors so maybe the
fast responding error handling wasn't related at all to SONET specs.

Curtis

In message <[email-masked]>
Maarten Vissers writes:

Curtis,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: woensdag 14 juli 2010 22:48
To: Maarten Vissers
Cc: 'Rafi Ram'; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

Curtis

---

From: Maarten Vissers <[email-masked]>
Date: Thu, 15 Jul 2010 01:18:56 +0200

Curtis,

I agree with you that the standard values are better being changed for the
application you describe. The SDH/SONET equipment as you remember supports
that. In SONET equipment you could choose the poisson based error rate
method and configure e.g. 1E-9 or 1E-11 (detection may take some time) as SD
trigger, and in burst based error method configure a low number of EBs (e.g.
5%, 1%) as SD trigger.

OTN equipment also support configuration of the number of EBs per second to
determine a BAD second. But when all links run with E-FEC, then your frame
loss due to bit errors will be either 0, or >80% with essentially nothing in
between. From a soft fault (range of values, SD type) the frame loss due to
bit errors is becoming a hard fault (only two values (GOOD, BAD), SF type).

Frame loss (per priority) due to congestion can have a large range of
values; if your committed traffic is being dropped due to congestion, then
SD can be triggered when the FLR (per second, for M seconds) exceeds e.g. 5%
or 10%.

In future all packet links will run over OTN and be protected with OTN FEC
(S-FEC and E-FEC). Possibly bit errors will not longer play a role and we
can/should ignore it as condition in our considerations for packet transport
performance. Only frame/packet loss due to congestion may/should be
considered as performance parameter.

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] 
Sent: donderdag 15 juli 2010 0:52
To: Maarten Vissers
Cc: [email-masked]; 'Rafi Ram'; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

Thanks.  I was not even close.  Perhaps what I remember is what we had
configurable threshhold set to to get the response we wanted.  In any case,
on a small number of framing errors POS links could be taken down.  On
"dribbling" errors POS links could also be taken down.

I'm quite sure we didn't tolerate 10% errors under any circumstances either
when I was at a provider (actually two IP providers) or at a router vendor.
To us SONET was a dumb framing protocol used for point to point POS links
(and to an extent that hasn't changed) and we didn't care much what the
SONET recommendation were as long as we could configure parameters on
equipment to get the desired behaviour.

The routers could easily count POS (SONET) framing errors so maybe the fast
responding error handling wasn't related at all to SONET specs.

Curtis

Curtis,

Regards,
Maarten

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: woensdag 14 juli 2010 22:48
To: Maarten Vissers
Cc: 'Rafi Ram'; [email-masked]; [email-masked]
Subject: Re: [mpls-tp] New ID draft-rkhd-mpls-tp-sd-00

Maarten,

Curtis

---

From: <[email-masked]>
Date: Thu, 15 Jul 2010 08:30:07 +0100

Note the change of thread title.

Maarten,

I agree with some of this but I would urge some caution.  You are
absolutely right to say we *should* be able to largely ignore bit errors
which are caused by a Poisson process (thermal noise is always present),
and if our BOS Tx sections are thermal noise dominated then we should
improve the S/N ratio in some manner. But we should not ignore burst
error events and (in particular) short breaks. 

Several years ago someone who is very active in IETF/ITU wrote to me to
try and better understand the origins of error performance
metrics....such as DM (Degraded Minutes) and SES (Severely Errored
Seconds)... below is my response.  For those who are interested in some
of the history of error performance metrics, especially what happens in
the real world, what is god/bad, etc please read on, if not stop here
(note this is only a summary of some of the key findings, there were
many more important results of our research work that I do not cover
below, eg why error events have non-linear propagation through network
hierarchies and the impacts of uncontrolled bit slips).

regards Neil
===== 

I am personally responsible for throwing DMs out of the ITU performance
standards....but it took me several years despite overwhelming
compelling evidence (which is why I always worry when I see stuff that
is clearly junk getting standardised....hard to get rid of later). 

Andy Reid and I ran a project starting in the late 80s and running
through the 90s to properly quantify real error events/distributions on
all sorts of metallic/radio/optical BOS Tx systems and various PDH/SDH
higher layer path signals.  This work helped shape our understanding of
good/bad OAM and network performance specifications, including the
practical implications for provisioning and mtce.  The equipment we used
was designed/built at our labs to record the binary distance between
errors....I won't go into detail but we had total information.
 
The major mathematical finding was that we could fit a burst-model,
developed by one of the mathematicians at the labs (David Bond), to real
error event distributions...and it fit them all very well. The model had
roots in Mandelbrot maths....so it's a self-similar/chaotic-process at
heart.  Hardly surprising as real error events are generated by weather
(rain, lightning, humidity factors), humans and other processes that
have a self-similar behaviour.
 
The practical consequence of this is that one cannot time-scale long
term objectives and have any confidence that a short-term measurement is
truly indicative of long-term behaviour....you can get a full month's
allowance in minutes and be error-free for weeks after that.  A whole
raft of practical provisioning/mtce rules flowed from this. 

On a well-engineered digital Tx systems there is a massive S/N
ratio....AWGN is therefore not a major factor and Poisson maths is
useless.  Thermal errors on a good optical system @ 140M say should be
the order of less than 1 error per 70 days. Error bursts dominate the
digital Tx world. 

Worth observing at this point that systems fall into 2 populations:
Good (vast majority) and Rogue.  This has significant bearing on the
practical rules for provisioning/mtce and also how we specify OAM stds.
Not going to say any more on this here...think the direction I would
take though is obvious if I did. 

Now when you look at the actual error events themselves on 'good'
systems they are invariably an event of length 'T's with a 'pe' (bit
error probability) of 0.5.  Now contrast this with how G.821 started
life when folks came from the FDM/analogue world where AWGN noise and
Poisson maths did dominate.  They specified both SES and DM based on a
'pe' value that they thought was meaningful for (i) systems and (ii)
applications....SES targeted at data applications DM targeted at voice.
They were completely wrong on BOTH counts, and the ES metric (or more
correctly the Errored-Period) is the only good metric....as I'll explain
why shortly. 

Now you have to understand this:  A DM has SES removed.  Why?  If you
didn't DMs would not exist, ie a SES event would also create a DM event.
A SES is defined as a second with pe >= 10^-3.  A DM is defined as a
minute with pe >=10^-6 (excluding SES as noted earlier). 

In all the years I looked for these metrics I never saw them exhibited
like this.  Why?  Because if I get a real error burst event with pe=0.5
and of length (in time): 

- <0.12ms........ this has a BER of <10^-6 when integrated over 1 minute
and thus only creates an ES event 

- >=0.12ms but <=2ms....... this has a BER of >10^-6 but <10^-3 when
integrated over 1 minute.  Thus we create a ES+DM pair
 
- > 2ms....... this has a BER of >10^-3 when integrated over 1 second.
Thus we create an ES+SES pair (no DM). 

The DM metric is clearly the most daft.....an order_ms event generating
an order_minute metric!  But in fact my observations also apply to the
SES.  As we can see above an order_ms even can give rise to 3 quite
different outcomes depending on a very small change in an error burst's
duration.  This is clearly bad specification and it is the result of
trying to apply meaningless Poisson thinking (ie the 10^-3 and 10^-6
BERs) to digital Tx systems....it's just plain wrong. 

I had not the heart to tell the world SES should also be scrapped as
well as DM.....esp given it took me ~2 years to consign DMs to the
garbage bin despite presenting many years and scores of systems worth or
empirical data to ITU.  Moreover, SES were also the bedrock of the
availability entry/exit criteria....so I thought I had better leave that
one alone.  Note that in subsequent years the definition of the SES
moved to one based on smaller (than 1s) errored blocks....which is a bit
better, but not much. 
 
You also should carefully note these important facts:

- I rarely saw a SES event that was not accompanied by a more major
defect, eg loss of framing.  The practical consequence of this is that
defects are all you really need to measure SESs and availability.  This
is precisely why Y.1711 is very simple in this respect...and also why it
does not fiddle about with worrying whether ES/SES events
should/should-not be included in available time during the transit
periods between available/unavailable states. 

- I fully expected the vast majority of SES events to be of the order of
a few ms in length.  The practical results we saw shocked us.  Only ~
50% SES were like this.  The other 50% could be the order of a second or
few in length....in other words 3 orders of magnitude larger.  We called
these events 'short-breaks'.  These had very different effect on
applications than 'small' SESs.  In fact we undertook a major project to
try and find out what was causing these as they were so damaging...we
never ever really bottomed this out.  And AFAIK they still exist out
there. 

This is also why I have ensured Y.1711 can measure short-breaks.  Not
complex, I have just aligned their definition with how I defined defects
therein.  Also note that those folks who think trying to beat SDH 50ms
prot-sw targets in co-ps mode networks are being a bit silly...as they
trigger on error events that would otherwise go away.  BTW - the 50ms in
SDH is all to do with the physics of rings and what was considered
'practical'....it has NOTHING to do with any application like voice.
 
Hope that helps.......regards, Neil 

> [mailto:[email-masked]] On Behalf Of Maarten Vissers
> Sent: 15 July 2010 00:19
> To: [email-masked]
> Cc: [email-masked]
> I agree with you that the standard values are better being 
> changed for the application you describe. The SDH/SONET 
> equipment as you remember supports that. In SONET equipment 
> you could choose the poisson based error rate method and 
> configure e.g. 1E-9 or 1E-11 (detection may take some time) 
> as SD trigger, and in burst based error method configure a 
> low number of EBs (e.g.
> 5%, 1%) as SD trigger.
> 
> OTN equipment also support configuration of the number of EBs 
> per second to determine a BAD second. But when all links run 
> with E-FEC, then your frame loss due to bit errors will be 
> either 0, or >80% with essentially nothing in between. From a 
> soft fault (range of values, SD type) the frame loss due to 
> Frame loss (per priority) due to congestion can have a large 
> range of values; if your committed traffic is being dropped 
> due to congestion, then SD can be triggered when the FLR (per 
> second, for M seconds) exceeds e.g. 5% or 10%.
> 
> In future all packet links will run over OTN and be protected 
> with OTN FEC (S-FEC and E-FEC). Possibly bit errors will not 
> longer play a role and we can/should ignore it as condition 
> in our considerations for packet transport performance. Only 
> frame/packet loss due to congestion may/should be considered 
> as performance parameter.
> 
> Regards,
> Maarten
> 
>