Subject: sonetSESthresholdSet: itu1995(4)

From: Geoffrey Garner <[email-masked]>
Date: Wed, 14 Feb 2001 14:10:50 -0500

Ken,

Your attached email was forwarded to me by my colleague Leen Mak.  I am
the new Rapporteur
of ITU-T Question 8/13 (previously Q 16/13), which has responsibility
for G.826, G.828, and G.829.

While I don't know the full context of your question, I can provide a
short answer.
Recommendation G.826 applies to PDH paths and, when it was first
written, it was intended
to apply to all SDH paths.  However, since then a new recommendation,
G.828, with improved performance objectives
compared to G.826 (for some of the rates) has been approved.  G.828
applies only to SDH paths.  However, for paths using older equipment
designed prior to the adoption of G.828 (in 3/2000), G.826 can be
applied.   SDH sections (multiplex and regenerator
sections), are covered by Recommendation G.829.  G.829 defines the
various events and parameters (in particular, it gives
the fractions of errored blocks in one second for an SES, for each
rate).  However, it does not have objectives (e.g., there are
no objective values for SESR, ESR, or BBER).  Another point to note is
that while the clauses of G.829 dealing with the multiplex section apply
to all media, the clauses dealing with the regerator section apply only
to radio relay and satellite systems.
In any case, if you wanted to come up with SESR objectives for, e.g.,
the SDH MS, you would not simply use the 0.002 given
for paths in G.826 and G.828 because the block size and errored block
threshold (i.e., percent errored blocks in 1 second) are
different (more precisely, if it were used it would not correspond to
the same level of performance).  (Roughly speaking, you can think of the
SESR as the fraction of time that the average BER exceeds the critical
BER corresponding to the errored block fraction and block size you are
using to define SES).

Finally, I took a quick look at RFC2558, which you referenced in your
email.  The tables in Annex B give the number of errored blocks in 1
second to declare an SES, for each rate, for section, line, and path.  I
saw that they are different from the errored block thresholds given in
G.829 and ANSI T1.231 (which are different from each other) for section
and line.
In addition, the thresholds for path are different from the 30% (2400
blocks in 1 s for STS-Nc or VC-4-Xc and 600 blocks in 1 s for VC-11 and
VC-12) given in G.826 and G.828.  This means only that an SES is being
defined here to correspond to a different average BER level compared
with those documents.

I hope this is useful.

Regards,

Geoff Garner
Lucent Technologies
101 Crawfords Corner Rd.
Room 3C-511
Holmdel, NJ  07733
USA
+1 732 949 0374 (voice)
+1 732 949 3210 (fax)
[email-masked]

> -----Original Message-----
> From: Chapman, Ken [mailto:[email-masked]]
> Sent: Monday, February 12, 2001 19:15
> To: [email-masked]
> Subject: sonetSESthresholdSet: itu1995(4)
>
>
> Can someone out there explain to me exactly how to compute
> the values of SES
> thresholds on SONET/SDH sections, lines, paths and VTs based on G.826?

> It appears to be written specifically for SDH paths. (How
> does it apply to
> sections and lines? VTs?)
> Is it simply indicating a SESR of 0.002, which applies in all
> cases (Table
> 1/G.826), or is there more to it?
>
> It would be nice if Appendix B of RFC2558 could be expanded
> to cover all the
> values for all the choices of sonetSESthresholdSet. :-)
>
>       Ken
>
> ++++++++++++++++++++++++++++++++++++++++++++++
> Ken Chapman           Unisphere Networks, Inc.
> Tel: +1-978-614-5322  5 Carlisle Drive
> Fax: +1-978-692-9992  Westford, MA 01886
> Email: [email-masked]
> ++++++++++++++++++++++++++++++++++++++++++++++
>
>

---

From: Ray Reno <[email-masked]>
Date: Thu, 15 Feb 2001 11:27:20 -0500

I can understand where Ken is coming from (as I'm in the same boat) with
respect to wanting to (potentially) support all available
sonetSESthresholdSet settings, but not necessarily having every applicable
spec (and perhaps not wanting to purchase the absent ones only to obtain an
unkown value or two).

-Ray

-----Original Message-----
From: C. M. Heard [mailto:[email-masked]]
Sent: Wednesday, February 14, 2001 3:57 PM
To: [email-masked]
Subject: RE: sonetSESthresholdSet: itu1995(4)

On Wed, 14 Feb 2001, Ken Chapman wrote:
> Atommib WG,
> I think it would be wise to update RFC2558 to add the reference to G.829 
> for itu1995 (even though G.829 probably was not approved until after
1995).
> (And list ALL the values for ALL the sets in Appendix B.)

Rather than redefining itu1995 I think it would be more appropriate to add
another enumeration, one that specifically refers to G.829.  I do agree that
listing all the threshold sets would be wise.

Mike