Re: Network Performance Schema

[Brian Tierney <bltierney@lbl.gov>]

somehow I completely missed your email of April 30th.  Sorry!

I think that what you propose makes sense. Let discuss this more on the  
call tomorrow.


On Tuesday, May 13, 2003, at 06:00 PM, Andrea Westerinen wrote:

> Brian, Although I did not create a "schema document", I did generate  
> this email regarding a possible design. If you look at your example at  
> the end of the document, and the example in my email (both about path  
> delay), you should see lots of overlap and one new parameter (an enum  
> regarding whether we are reporting RT or one-way (Source to Dest, or  
> Dest to Source)).  This was intentional since the schema and the  
> profile go hand in hand.  
>  
> I did not get any feedback on the email (probably too estoteric :-).   
> So, here are some of my specific questions that we could discuss on  
> the call:
>  
> 1. In reading the profile document, you already started to do the  
> schema and were proposing details for the measurements.  If we could  
> get one or two of the basic profiles down (really what data we need),  
> then the schema-tization falls out.  We can start with the basic  
> schema design that I propose below (I have a specific question on that  
> in #2) and add in the profile details.  So, the question is whether we  
> should we focus on one or two basic network measurements for  
> the profile first (not really worrying about the schema now, but the  
> data), generate the schema from that, and then go back and rev the  
> profile document to correspond to the schema.  After this, we could  
> continue to add onto both the profile and schema basically as a  
> pattern.  
>  
> 2. I would recommend breaking out the tool info from the statistics  
> generated by the tool, and also tied to a specific path/pipe or  
> system.  IE, these are the statistics from this tool, for this  
> element. In the profile, these are bunched together, but I think would  
> be valuable to separate.  What are others thoughts on this?
>  
> 3. I would not subclass from NumericSensor in the profile.  I only  
> recommended that as an example of resolution/accuracy properties.  If  
> you see my design below, I use Service for the superclass of the test  
> tool, and StatisticalData as the superclass for the network  
> measurements.  
>  
> Andrea 
>  
>
> -----Original Message-----
> From: Andrea Westerinen [mailto:andreaw@cisco.com]
> Sent: Wednesday, April 30, 2003 1:25 AM
> To: 'nm-wg@ggf.org'
> Subject: Network Performance Schema
>
> Terminology:
> NetworkEntity, Nodes and Paths 
>     CIM corollaries: Nodes are Systems (subclasses are AdminDomain and  
> AutonomousSystem, and ComputerSystem which may be
>     virtual, dedicated to switching or routing, or a user's computer)  
> and NetworkPipes (which may be uni or bi-directional, which
>     tie together two endpoints/interfaces, and which can be broken  
> down into lower level 'pipes' that can be combined in parallel or
>     in series)
> Characteristic
>     CIM corollary: The definition of a property in a class - A  
> subclass of StatisticalData
>     StatisticalData is tied to the entity being reported against, via  
> the association ElementStatisticalData
> MeasurementMethodology and Tools
>     CIM corollary:  Service (subclass to describe network test tools) 
> Observation
>     CIM corollary: The value of a property -> An instance of the  
> subclass of StatisticalData
>  
> To examine one characteristic:  Delay (Roundtrip, One way, Jitter)
>  
> Could define:
> 1. A NetworkTestTool, subclass of CIM_Service with properties:
>     ElementName (tool name)
>     Version
>     TimeAccuracyMethod (enum)
>     TimeResolution
>     TimeAccuracy
> 2. A NetworkPathStatistics, subclass of CIM_StatisticalData,  
> associated tothe NetworkTestTool via  a subclass  
> ofElementStatisticalData with properties:
>     StartTime
>     EndTime
>     Source
>     Destination
>     PacketSize
>     NumberOfPackets
>     PacketSpacing (enum)
>     PacketGap
>     PacketType (enum)
>     PortNumber
>     Priority array (enum)
>     LossThreshold
>     ReportedInfo (enum - RT, S2D, D2S)
> 3. A NetworkPathDelayStatistics, subclass of NetworkPathStatistics,  
> with properties:
>     MedianDelay
>     MinDelay
>     MaxDelay
>     SumOfDelays
>    
> Andrea
>    
>  
------------------------------------------------------------------------ 
-------------------
  Brian L. Tierney,   Lawrence Berkeley National Laboratory (LBNL)
  1 Cyclotron Rd.  MS: 50B-2239,  Berkeley, CA  94720
  tel: 510-486-7381    fax: 510-495-2998   efax:  240-332-4065
  bltierney@lbl.gov   http://www-didc.lbl.gov/~tierney
------------------------------------------------------------------------ 
------------------