Subject: RE: SONET PM trap definitions

From: Kaj Tesink <[email-masked]>
Date: Tue, 26 Mar 2002 09:31:47 -0500

David,
yes, i understand your reasoning. this is not
the first time that this point comes up and
digging in the archives of various SNMP
discussion lists will certainly yield many arguments
both for trap-directed polling and for the
trap policy that you're advocating.

this document has been written consistent with
the specs for DS1/E1 and DS3/E3. of course all
these specs have the same issue. the current status
of all these specs is that they're are in the process
of being bumped up in the ietf standards ladder.
so changes or additions at this time would not work.
however, from time to time other additions have been
proposed (for example recent proposals for better SDH
support). so the idea is that if there is sufficient
support and consensus to write some kind of a supplemental
mib module.

therefore my suggestion is that you
- first sound out the atommib list on whether there is
   more support on your proposal
- if there's broader support then write a specific
   proposal incl miblet
- fold that into the yet to be written supplemental
   mib (no editor has been identified yet)

does this make sense.
comments from anybody else out there?

kaj

At 03:39 PM 3/25/2002 -0500, Albert, David wrote:
>Thank you for your reply and I will certainly subscribe
>to the discussion group.  While I agree that severe
>performance problems might result in a linkDown
>trap and cause a management system to poll performance
>monitoring data, this is not the likely expected or desired
>behavior for SONET/SDH performance monitoring.
>
>PM data is typically gathered every 15-minute and 24-hour
>period (sometimes limited to non-zero periods) and recorded
>in the management system for use in service layer management.
>The PM data is often used to demonstrate to compliance with
>performance guarantees that have been made to customers.  Some
>systems also try to use performance data to do predictive failure
>analysis.  Because this data is needed regularly, forcing management
>systems to poll will simply double network traffic (GET/RSP instead
>of TRAP) and increase the load on agents.
>
>There are certain traps whose definition as part of a SONET/SDH
>standard would IMHO greatly increase acceptance of SNMP as a
>management mechanism for telecommunications networks including:
>PM, Faults (LOS, LOF, LOP, AIS, etc.), security, dbChange.
>I would be happy to make a contribution in this area if you think it
>would help.
>
>Regards,
>David Albert
>CIENA
>-----Original Message-----
>From: Kaj Tesink [mailto:[email-masked]]
>Sent: Friday, March 22, 2002 5:56 PM
>To: Albert, David
>Cc: Reddy, Sudheer; [email-masked]
>Subject: Re: SONET PM trap definitions
>
>At 04:56 PM 3/22/2002 -0500, Albert, David wrote:
>>Hello Kaj,
>>    I enjoyed reading your excellent RFC (2558) defining
>>SONET/SDH Interfaces for SNMP.  Do you know whether
>>a MIB definition exists for a PM reporting TRAP (i.e. a
>>standard TRAP that can be sent periodically to a management
>>system notifying it of a newly completed PM interval and the
>>collected PM statistics rather than forcing the manager to
>>poll the interval table?)  If you are aware of a standard that
>>defines such a trap or can point me in the right direction, I
>>would appreciate it.  Thank you!
>>
>>Sincerely,
>>
>>David Albert
>>CIENA
>hi David,
>
>i'm not aware of current standard definitions for such traps;
>there may be enterprise-specific traps. this mib was written based on
>polling assumptions; the nms can set its own polling policy.
>high error situations would generate linkDown traps and may trigger the nms
>to inspect specific pm parameters.
>
>I copy your comments to the discussionlist of the atommib wg
>which is the appropriate forum to discuss these issues. See
>http://www.ietf.org/html.charters/atommib-charter.html
>for subscription info.
>
>this has also some mib extensions for SONET APS.
>
>Note that 2558 is being evaluated right now and implementation experience is
>being requested. Please send your implementation report to
>Faye Ly <[email-masked]>
>Use the compliance clause as guidance.
>
>
>
>kaj
>
>
>
>
>
>
>
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/
>
>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
>_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/_/

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

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

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

---

From: "C. M. Heard" <[email-masked]>
Date: Wed, 27 Mar 2002 10:02:22 -0800 (PST)

On Tue, 26 Mar 2002, Kaj Tesink wrote:
Kaj> therefore my suggestion is that you
Kaj> - first sound out the atommib list on whether there is
Kaj>    more support on your proposal
Kaj> - if there's broader support then write a specific
Kaj>    proposal incl miblet
Kaj> - fold that into the yet to be written supplemental
Kaj>    mib (no editor has been identified yet)
Kaj> 
Kaj> does this make sense.

This sounds very sensible to me.

Kaj> comments from anybody else out there?

I have inserted several comments in-line below.

On Mon, 25 Mar 2002, David Albert wrote:
David> Thank you for your reply and I will certainly subscribe
David> to the discussion group.  While I agree that severe
David> performance problems might result in a linkDown
David> trap and cause a management system to poll performance
David> monitoring data, this is not the likely expected or desired
David> behavior for SONET/SDH performance monitoring.
David> 
David> PM data is typically gathered every 15-minute and 24-hour
David> period (sometimes limited to non-zero periods) and recorded
David> in the management system for use in service layer management.
David> The PM data is often used to demonstrate to compliance with
David> performance guarantees that have been made to customers.  Some
David> systems also try to use performance data to do predictive failure
David> analysis.  Because this data is needed regularly, forcing management
David> systems to poll will simply double network traffic (GET/RSP instead
David> of TRAP) and increase the load on agents.

I've worked on some NEs with TL1 management interfaces that were
required to to through the Telcordia OSMINE process for the NMA
surveillance OS (Operations System).  Such an NE needs to support
at least the subset of GR-833-CORE that is deemed "essential" for
compatibility with NMA, and must therefore support both of the
following methods for getting PM data from the NE to the OS:

- polling:  the OS issues a RTRV-PM command and receives a response
from the NE containing the PM data.   The request may be scoped to
include one or more specific entities within the NE (e.g. SONET
sections, lines, or paths), or it may request PM data for all entities
within the NE.

- autonomous reports:  the OS issues a SCHED-PMREPT command to request
that a PM report be sent autonomously for a particular entity (e.g. a
SONET section, line or path), and the NE issues the requested reports
via the REPT PM autonomous message.  Typically the reporting intervals
coincide with PM collection intervals (15 minutes or 1 day).

The usual behaviour (per GR-833) is for autonomous reports to be turned
off by default.  The surveillance OS requests such reports only when the
PM data is "interesting".  A common procedure is for a so-called
Threshold Crossing Alert (TCA) to trigger a RTRV-PM command for the
current interval data and also to trigger a SCHED-PMREPT command
requesting autonomous reports for future intervals as they are completed.
When the autonomous PM reports cease to indicate troubles, then another
SCHED-PMREPT is issued to turn off the scheduled PM reports.

Note that the SONET-MIB in RFC 2558 (and also the updated draft in
http://www.ietf.org/internet-drafts/draft-ietf-atommib-rfc2558bis-00.txt)
has no notification definitions for TCAs, no objects to set PM thresholds,
no mechanism analogous to SCHED-PMREPT for scheduling PM reports, and no
notification definitions analogous to REPT PM.  All of these things would
need to be added in order to support the PM surveillance paradigm sketched
above. This observation also applies to the other trunk MIBs.

David> There are certain traps whose definition as part of a SONET/SDH
David> standard would IMHO greatly increase acceptance of SNMP as a
David> management mechanism for telecommunications networks including:
David> PM, Faults (LOS, LOF, LOP, AIS, etc.), security, dbChange.

Indeed, besides PM reports (TL1: REPT PM) and TCAs (TL1: REPT EVT),
some other notable omissions from all the trunk MIBs are the failure
notifications, which indicated by TL1 autonomous messages REPT ALM or
REPT EVT (depending on whether the failure is alarmed or not alarmed).
These do not pertain to defects (as is the case for the various status
objects in the SONET-MIB) but rather to failures (which have soaking
times of 2.5 +/- 0.5 to be raised and 10.0 +/- 0.5 seconds to be cleared).
Besides the autonomous messages TL1 also provides the commands RTRV-ALM
and RTRV-COND to retrieve the current alarmed and non-alarmed standing
conditions.  Appropriate notification definitions, reporting control
objects, and current status objects would need to be added to provide
SNMP equivalents for these capabilities.

dbChange notifications (TL1 REPT DBCHG automomous messages) relate to
provisioning, and that is another area that the trunk MIBs do not
really cover.  Such notifications make sense only in the context of a
set of provisioning objects and cannot be properly defined in isolation.
They would, however, be a potentially useful part of a standardized trunk
provisioning MIB.

I would think that security notifications (relating to login failures
and the like) would be out-of-scope here, and in fact are already
covered by the security aspects of SNMPv3.

Note that in all of the above cases the TL1 management model assumes
that autonomous notifications are sent via a reliable transport
mechanism, so it would be more appropriate to use INFORMs rather
than TRAPs.  SNMPv1 is inadequate for that.

David> I would be happy to make a contribution in this area if you think it
David> would help.

Several parties have expressed interest in most of the above items, as
well as in adding 1-day PM intervals (which the trunk MIBs do not now
support).  I agree with Kaj's advice on how to start, but I'd like to
add that one of the necessary steps -- assuming that your initial
sounding out for a supplemental MIB effort gathers sufficiently broad
support -- is to get the work item added to the AToMMIB charter.

Regards,

Mike Heard