Subject: Re: improving SDH support in rfc2558bis

From: Kaj Tesink <[email-masked]>
Date: Wed, 10 Apr 2002 11:19:49 -0400

all,

i like to draw your attention again to Mike's analysis
on this topic since we need to wrapup the 2558bis approval process.
only Mike's items 1 and 6 should be considered for 2558bis;
the others can be put in a supplemental MIB.

is there any further support (with specific proposals) for
items 1 and 6?

SDH advocates, please specify the reference documents
with surrent SES threshold information and BBE
definitions for all layers.

if there are no specific proposed fixes then we have to leave
this issue and declare 2558bis (and 2493bis) ready for advancement.

kaj

At 03:23 PM 3/22/2002 -0800, C. M. Heard wrote:
>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

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

Kaj Tesink
Telcordia Technologies. In.
331 Newman Springs Road
Red Bank, NJ 07701
Email: kaj @research.telcordia.com
Tel: (732) 758-5254
Fax: (732) 758-4177

_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/