Subject: improving SDH support in rfc2558bis

From: "C. M. Heard" <[email-masked]>
Date: Fri, 22 Mar 2002 15:23:01 -0800 (PST)

Background: On 15 Feb 2002 Kaj Tesink <[email-masked]>
forwarded a message to the AToMMIB list from Farzad Khosravi
<[email-masked]> pointing out numerous things that
are missing from RFC 2558:

1.) No objects to count SDH BBEs (background block errors)
2.) No path trace configuration objects
3.) No STS Path ERDI status or configuration objects
4.) No objects or notifications for SONET/SDH failures
5.) No objects or notifications to support SDH UAS state
6.) No sonetSESthresholdSet enumerations for G.828 and G.829

This was discussed briefly on the mailing list and again during
the SONET-MIB status presentation at the IETF 53 AToMMIB WG
meeting last Tuesday, 19 March 2002.  My suggestions for
were as follows:

- Dealing with items 2-5 clearly requires new objects that
are not presently in SONET-MIB.  Since adding these objcts
to the SONET-MIB would prevent its advancement to Draft
Standard, the preferred approach is to create a "supplemental"
MIB module to deal with the missing functions, assuming that
there is sufficient interest in doing so.  I think that
"sufficient interest" translates to having someone willing to
propose an amendement to the AToMMIB charter and sell it to
the chairs and the ADs and having someone willing to serve
as editor for the supplemental MIB.

- It may be possible to deal with item 1 by adding text
to Section 4.5 of <draft-ietf-atommib-rfc2558bis-00.txt>
(that is Section 3.5 in RFC 2558), and it may be possible
to deal with item 6 by adding one or more
sonetSESthresholdSet enumerations.  Since these modifications
would not impede advancement, they are worth considering for
inclusion in the SONET-MIB if advocates will provide
specific suggestions for updates to the text.

Here is some additional information.

SDH BBEs
--------

BBEs (Background Block Errors) are the SDH counterpart
to SONET CVs.  BBEs count the number of block errors that
occur during seconds that are not SESs or UASs.  A block,
in the generic sense, is a set of consecutive bits that may
or may not be contiguous in time.  The definition depends
on the layer.

At the SDH regenerator section layer (equivalent to the
SONET section layer) I've been unable to find the SDH
definition of a block, and according to ANSI T1.231-1997
the BBE-S parameter "is for further study".

At the SDH multiplex section layer (equivalent to the
SONET line layer) the draft of G.829 that I've been
able to locate on-line (T1A1.3/1999-002) states that
each of the 8 BIP-1s contained in each of the N B2
overhead bytes (N=1, 3, 12, 48, etc.) pertains to a
different block.  Thus, an SDH multiplex section block
error is identical with a SONET line BIP error.  This
agrees with T1.231-1997 Section 8.4.3.1.1.2.  Note
that T1.231-1997 Section 8.4.3.1.1 states that the
line error count shall be either CV-L or BBE-L.

At the path layer, G.826 (08/96) Annex C specifies that
each of the BIP-1s in a BIP-K pertains to the same block,
where K=8 for an SDH HOVC (equivalent to SONET path) and
K=2 for an SDH LOVC (equivalent to a SONET VT path).  Thus,
one SDH path HOVC block error occurs whenever one or more
BIP-8 errors is detected from a B3 byte, and one SDH path
LOVC block error occurs whenever one or more BIP-2 errors
is detected from the BIP-2 field of the V5 overhead byte.
This agrees with T1.231-1997 Sections 8.4.5.1.2 (BBE-P)
and 8.4.7.1.2 (BBE-V).  Note that T1.231-1997 Section
8.4.5.1 (resp. 8.4.7.1) states that the path (resp. VT
path) error count shall be either CV-P or BBE-P (resp.
CV-V or BBE-V).

As some here may recall, the Ethernet 802.3ae Clause 30
WIS managed objects aPathCVs and aFarEndPathCVs are
block error counts -- identical to BBE-P, in fact, except
for their lack of inhibiting during SESs.  The WIS MIB
design team decided to map these objects to the SONET-MIB
objects sonetPathCurrentCVs + sonetPathIntervalCVs and
sonetFarEndPathCurrentCVs + sonetFarEndPathIntervalCVs,
respectively, and to specify in Section 3.5 of
<draft-ietf-hubmib-wis-mib-02.txt> that block errors
rather than BIP-8 errors are accumulated at the path
layer.  This was deemed to be reasonable because for
random errors at rates low enough not to cause SESs the
ratio of BIP-8 errors to block errors is approximately
equal to 1 (see T1.231-1997 Section 8.1.1.1.2 and G.826
(08/96) C.1.5).  It seems reasonable to me for SDH
implementations to use the same rule in order to avoid
the need for separate BBE-P and BBE-V objects;  if there
is general agreement on that point, perhaps text to this
effect can be added to Section 4.5 of
<draft-ietf-atommib-rfc2558bis-00.txt>.

SDH SES Thresholds
------------------

The SES thresholds given in G.784 (06/99) are 30% block
errors at the path level (in agreement with G.826 (08/96))
and 15% at the STM-1 multiplex section level.  No SES
thresholds for the regenerator section level are specified
in G.784 (06/99).  However ...

On Mon, 18 Feb 2002, Farzad Khosravi wrote:
> [ ... ]
> [Newly defined] SES thresholds Standards:
> 	G.828 : Error Performance parameters and objectives for
> international, constant bit rate synchrnous digital paths.
> 	G.829	: Error Performance Events for SDH multiplex and
> regenerator sections.

Perhaps someone with access to these documents can indicate
whether they provide (a) a definition for regenerator section
BBEs (called BBE-S in T1.231) and (b) specifications for SES
thresholds that are more complete than those in G.784 (06/99).

Please note that I have my hands full with many other things
to do, so if this stuff is to move forward it will need an
advocate who has the technical expertise and motivation to
provide specific proposals.

Thanks,

Mike