Subject: RFC 1595: definition of 15-minute intervals

From: Rajul Shah <[email-masked]>
Date: Fri, 05 Jun 1998 11:26:18 -0400

ANSI T1.231 requires the 15-minute intervals for performance 
monitoring to start on the 1/4 hour. However, the definition
in RFC 1595 makes no mention of this. I suspect this was
intentional to simplify matters. (One need not worry about
time moving forwards or backwards by virtue of NTP.:)

Is it correct to assume that the 15-minute intervals specified
in the MIB are NOT required to be on the 1/4 hour? It makes
a big difference implementation wise. 

For example, if the device comes online at 12:02:00, then according
to T1.231, the first complete 15-minute interval will become available
at 12:30:00 (12:15 -> 12:30, 28 minutes after being up). On the other 
hand, as per RFC 1595, the first 15-minute interval would become 
available at 12:17:00 (12:02 -> 12:17, 15 minutes after being up).

Rajul

Rajul Shah
[email-masked]
Tel: (978)250-3344 x285
http://www.avici.com

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Fri, 5 Jun 1998 12:37:12 -0700 (PDT)

> a big difference implementation wise.

That is my understanding.

> available at 12:17:00 (12:02 -> 12:17, 15 minutes after being up).

That is one way to do it.  On the other hand, I see nothing in RFC 1595
or its successor <draft-ietf-atommib-sonetng-02.txt> that _forbids_ an
implementation from starting the intervals on 15-minutes at 1/4 hour
wall-clock boundaries.

> Rajul

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]

---

From: Rajul Shah <[email-masked]>
Date: Mon, 08 Jun 1998 09:15:37 -0400

>
>I see nothing in RFC 1595

How about this snippet of sonetMediumValidIntervals in 1595:

	The value of this object will be n unless the device was 
	brought online within the last (nx15) minutes, in which case
	the value will be the number of complete 15 minute intervals
	the device has been online.

>From the above it's clear that if the device has been online for 15 
(through 29) minutes then the value of the object should be 1. This 
obviously won't be the case if intervals are defined to start on 
the 1/4 hour.

Curious to know what others have already done (or are planning 
to do in this area).

Rajul

Rajul Shah
[email-masked]
Tel: (978)250-3344 x285
http://www.avici.com

---

From: "C. M. Heard/VVNET, Inc." <[email-masked]>
Date: Mon, 8 Jun 1998 10:23:17 -0700 (PDT)

On Mon, 8 Jun 1998, Rajul Shah wrote:

>[Mike Heard wrote:]

I can see how the description clause for sonetMediumValidIntervals
could be interpreted in that way, but I don't think that was the intent.
Here is the complete description clause for sonetMediumValidIntervals
from <draft-ietf-atommib-sonetng-02.txt>:

                 "The number of previous intervals for which valid
                 data has been stored.  A SONET interface must be
                 capable of supporting at least n intervals.
                 The minimum value of n is 4.
                 The default of n is 32.
                 The maximum value of n is 96.
                 The value of this object will be n unless
                 the device was brought online within the last
                 (nx15) minutes, in which case the value will be the
                 number of complete 15 minute intervals the device has
                 been online. In the case where the agent
                 is a proxy, it is possible that some intervals
                 are unavailable.  In this case, this
                 interval is the maximum interval number for
                 which valid data is available."

I think that the intended meaning would be better expressed if the phrases
"for which valid data has been stored" and "for valid data is available"
were replaced by "for which some valid data has been stored" and
"for which some valid data is available", respectively.

> Curious to know what others have already done (or are planning

OK, here is how I have interpreted the requirements.

My agent will align its intervals at 15 minute wall-clock
boundaries.  If it comes on-line at (say) 13:02:00 then its first
interval ends (i.e., is completed) at 13:15:00.  At that point
there is one previous interval interval for which some data
has been stored.  Since this interval does not contain data
representing a full 15 minutes, the various xyzIntervalValidData
object-instances associated with this interval will be set to
false(2) (just as would happen for far-end data during an interval
in which some far end data was missing as a result of near-end defects).

My recollection was that the xyzIntervalValidData objects --
which were not present in RFC 1595 -- were added to
<draft-ietf-atommib-sonetng-02.txt> to allow for just this
situation.  I will search the atommib mail archive later
today and post my findings.

Mike
--
C. M. Heard/VVNET, Inc.
[email-masked]