[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Network Performance Schema
Title: Message
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
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 to
the NetworkTestTool via a subclass of
ElementStatisticalData 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