Subject: [ippm] IPPM REPORTING MIB data model: Inter table index

From: "STEPHAN Emile FTRD/DAC/LAN" <[email-masked]>
Date: Wed, 31 Jul 2002 18:21:37 +0200

hi,
During the meeting on the compliance of the MIB to the SMI with Andy,
Matt and Merike it appeared that the relation among ippmMeasureTable,
the ippmNetworkMeasure and the ippmAggreggatedMeasure is not explained
enought.

The ippmMeasureTable may be considered as a virtual table with 2
childrens ippmNetworkMeasure  and ippmAggreggatedMeasure. Both of them
extend the ippmMeasureTable using a sparse dependent relationship.

The following document explain the different kind of relationship. The
section "2.2 Sparse Dependent Relationship" corresponds to the model
used in the IPPM REPORTING MIB.

As an example, the index of the table ippmNetworkMeasureTable (same for
ippmAggregatedMeasureTable ) refer to fields which are part of the
definition of ippmMeasureTable:

ippmNetworkMeasureEntry OBJECT-TYPE
	SYNTAX     IppmNetworkMeasureEntry
	MAX-ACCESS not-accessible
	STATUS     current
	DESCRIPTION
	""
	INDEX { ippmMeasureOwner, ippmMeasureIndex }

It means that the creation of an ippmNetworkMeasureEntry creates an
ippmMeasureEntry too.

The goal is to permit future tables to be defined if needed while
preserving the consistency with the existing tables.

regards
Emile

> -----Message d'origine-----
> De : Henk Uijterwaal (RIPE-NCC) [mailto:[email-masked]]
> Envoye : mercredi 31 juillet 2002 14:51
> A : STEPHAN Emile FTRD/DAC/LAN
> Cc : [email-masked]; [email-masked]
> Objet : Re: [ippm] Synchonization state: consistency among owdp and
> ippmmib
> 
> 
> Emile, others,
> 
> 
> > Regarding the clock with "no notion of external 
> synchronization for the
> > time source (e.g., a cesium oscillator is used directly)" 
> what may be
> > the corresponding state ?
> 
> I'd think that the condition for synchronized is that the 
> clocks on both
> sending and receiving end are synchronized to one and the 
> same source, and
> it is thus impossible for one to drift away from the other.
> 
> So, a cesium clock connected to a PC but not to anything else, is
> unsynchronized, a cesium clock connected to a PC and to (say) 
> a clock at a
> standards institute, is synchronized.
> 
> > are there other states to discuss now(e.g. such as 'fail') ?
> 
> Isn't this implementation dependent?  For the MIB/OWDP, we 
> need 3 states:
> 
>   * Unsynchronized
>   * Synchronized
>   * Other
> 
> Other covering any state not being synchronized or 
> unsynchronized, leaving
> it up to the implementor to decide what to do next.
> 
> I don't think that there is a need for a "initializing" 
> state, it is too
> generic and the behaviour of the clock during initialization 
> varies from
> one hardware vendor to the other.  Or to be more precise, for our
> equipment, we use GPS clocks from 2 different vendors and they behave
> completely different from the moment they are switched on until they
> have synchronized themselves.  The same happens when 
> something goes wrong
> (for example, the cable antenna is cut).
> 
> Henk
> 
> 
> 
> 
> >
> > ippmSynchonizationState OBJECT-TYPE
> > 	SYNTAX INTEGER  {
> > 		other(0),
> > 		unsynchronized(1),
> > 		initializing(2),
> > 		synchronized(4)
> > 	}
> > 	MAX-ACCESS read-only
> > 	STATUS     current
> > 	DESCRIPTION
> > " ippmSynchonizationState describes the state of the clock
> > synchronization.
> >
> >
> > Other(0)
> > The status of the synchronization is unknown.
> >
> > unsynchronized(1)
> > The system is not synchronized.
> >
> > initializing(2)
> > The system is receiving synchronization information but is not yet
> > synchronized.
> >
> > synchronized(4)
> > The system is synchronized.
> > "
> >
> > regards
> > Emile
> >
> > _______________________________________________
> > ippm mailing list
> > [email-masked]
> > http://mailhost.advanced.org/mailman/listinfo/ippm
> >
> 
> --------------------------------------------------------------
> ----------------
> Henk Uijterwaal                    Email: [email-masked]
> RIPE Network Coordination Centre     WWW: 
> http://www.ripe.net/home/henk
> Singel 258                         Phone: +31.20.5354414
> 1016 AB Amsterdam                    Fax: +31.20.5354445
> The Netherlands                   Mobile: +31.6.55861746
> --------------------------------------------------------------
> ----------------
> 
> That problem that we weren't having yesterday, is it better? 
> (Big ISP NOC)
> 
> NOTE: My email address (and a hole in our mailing list 
> software) is being
>       abused by a spammer.  We are working on fixing this 
> hole and tracking
>       the spammer down.  If you receive mail from 
> "[email-masked]" that is
>       obviously spam, please send me a copy of the mail 
> including ALL headers.
>       I'm sorry for any inconvenience caused by this.
> 
> 
> 
> 
> 
>