Subject: Re: RFC2558 updates

From: "Faye Ly" <[email-masked]>
Date: Tue, 04 Dec 2001 17:38:36 -0800

Subra,

Does turning SD or SF bits on in the lineStatus object
DON'T cause protection switch?  Thanks.

-faye

>From: Subrahmanya Hegde <[email-masked]>
>To: "C. M. Heard" <[email-masked]>
>CC: AToMMIB Mailing List <[email-masked]>
>Subject: Re: RFC2558 updates
>Date: Tue, 04 Dec 2001 15:23:26 -0800
>
>Hi Heard
>   Thanks for your comments.
>
>  As per our Engineers here, SD and SF are related to
>line level. It is also applicable in APS Space.
>
>Can you review section 6.2.1.1.6.E of GR-253 and let us know whether
>you still think that SD and SF need not be in 'SONET-MIB"?
>
>Subra
>
>
>"C. M. Heard" wrote:
>
> > On Tue, 4 Dec 2001, Subrahmanya Hegde wrote:
> > >   We have not found about SD(Signal Degrade) and SF(Signal Failure)
> > > conditions in any objects in the MIB.
> > >
> > > Information about SD and SF are found in Sept 2001 version of GR-253
> >
> > I don't have that version of GR-253 in front of me, but my recollection
> > is as follows:
> >
> > SD = Estimated Bit Error Ratio > Signal Degrade Threshold (10^-5 to 
>10^-9)
> >
> > SF = Estimated Bit Error Ratio > SIgnal Fail Threshold (10^-3 to 10^-5)
> >       OR
> >      Near-End Section or Line Layer Defect (LOS, LOF, AIS-L)
> >
> > Error rates are determined by observing BIP-L in the B2 overhead byte,
> > and occur over some observation time determined by the implementation.
> >
> > > We request that  sonetLineCurrentStatus object is extended to include 
>SD
> > > and SF information.
> >
> > SD and SF are not really defects, they are derived conditions used
> > specifically to control linear APS.  The SONET APS-MIB, which recently
> > passed WG last call and awaits IESG action, has objects to set the
> > SD and SF thresholds and to monitor the number of SD and SF occurrences
> > (see draft-ietf-atommib-sonetaps-mib-05.txt).  So I don't really think
> > SD and SF belong in sonetLineCurrentStatus.
> >
> > > Definition in the MIB
> > >
> > >  sonetLineCurrentStatus OBJECT-TYPE
> > >               SYNTAX  Integer32 (1..6)
> > >               MAX-ACCESS  read-only
> > [snip]
> > >                  The various bit positions are:
> > >                   1   sonetLineNoDefect
> > >                   2   sonetLineAIS
> > >                   4   sonetLineRDI"
> > >                ::= { sonetLineCurrentEntry 1 }
> > >
> > > Requested Update:
> > >
> > >  sonetLineCurrentStatus OBJECT-TYPE
> > >               SYNTAX  Integer32 (1..30)
> > >               MAX-ACCESS  read-only
> > [snip]
> > >                  The various bit positions are:
> > >                   1   sonetLineNoDefect
> > >                   2   sonetLineAIS
> > >                   4   sonetLineRDI
> > >                   8   sonetLineSD
> > >                   16 sonetLineSF"
> > >                ::= { sonetLineCurrentEntry 1 }
> >
> > Questions aside of whether SD and SF really belong in this
> > object, this is not one of the revisions permitted by RFC
> > 2578 Section 10.2.  (It would have been better for these
> > objects to have used the BITS syntax so that they could
> > have been extensible, but their original definitions in
> > RFC 1595 pre-dated that device.)
> >
> > Why don't you have a look at the APS-MIB
> >
> > 
>http://www.ietf.org/internet-drafts/draft-ietf-atommib-sonetaps-mib-05.txt
> >
> > and see if the objects therein will do what you want?
> >
> > Regards,
> >
> > Mike
>

_________________________________________________________________
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp