This module defines a MIB for Round Trip Time
(RTT) monitoring of a list of targets, using a
variety of protocols.
The table structure overview is a follows (t:
indicates a table, at: indicates an augmented
table, and it: indicates table with the same
indices/control as parent table):
RTTMON MIB
|--- Application Group
| |--- Application Identity
| |--- Application Capabilities
| |--- Application Reset
| |t-- Supported RTT Types
| |--- Truth Value
| |t-- Supported Protocols
| |--- Truth Value
| |t-- Application Preconfigured
| |--- Script Names
| |--- File Paths
| |--- Responder control
| |t-- Control Protocol Authentication
|
|--- Overall Control Group
| |t-- Master Definitions Table
| | |--- Global Configuration Definitions
| | |--- Config for a single RTT Life
| | |it- Echo Specific Configuration
| | |it- Echo Path Hop Address Configuration
| | |it- File I/O Specific Configuration
| | |it- Script Specific Configuration
| | |at- Schedule Configuration
| | |at- Reaction Specific Config
| | |at- Statistics Capture Configuration
| | |at- History Collection Configuration
| | |at- Monitoring Operational State
| | |at- Last RTT operation
| |
| |t-- Reaction Trigger Table
| |at- Reaction Trigger Operational State
|
|--- Statistics Collection Group
| |t-- Statistics Capture Table
| |--- Captured Statistics
| |--- Path Information
| |--- Distribution Capture
| |--- Mean and Deviation Capture
| |it- Statistics Collection Table
| |it- Statistics Totals Table
| |t-- HTTP Stats Table
| |t-- Jitter Stats Table
|
|--- History Collection Group
| |t-- History Collection Table
| |-- Path Information
| |-- Completion Information per operation
|
|--- Latest Operation Group
| |t-- Latest HTTP Oper Table
| |t-- Latest Jitter Oper Table
DEFINITIONS:
conceptual RTT control row -
This is a row in the 'Overall Control
Group'. This row is indexed via the
rttMonCtrlAdminIndex object. This row
is spread across multiple real tables
in the 'Overall Control Group'.
probe -
This is the entity that executes via a
conceptual RTT control row and populates
a conceptual statistics row and a
conceptual history row.
Rtt operation -
This is a single operation performed by
a probe. This operation can be a single
Rtt attempt/completion or a group of Rtt
attempts/completions that produce one
operation table entry.
ARR Protocol Definition:
The format of the RTT Asymmetric Request/Responses
(ARR) protocol is as follows:
The ARR Header (total of 12 octets):
4 octet -> eyecatcher: 'WxYz'
1 octet -> version : 0x01 - protocol version
1 octet -> command : 0x01 - logoff request
0x02 - echo request
0x03 - echo response
0x04 - software version request
0x05 - software version response
2 octet -> sequence number (Network Byte Order)
4 octet -> response data size (Network Byte Order)
The ARR Data:
n octets -> request/response data
: 'AB..ZAB..ZAB..'
For software version request/response the
protocol version octet will contain the version
number of the responder. Thus the sequence
number, etc will not be included.
For snaLU0EchoAppl and snaLU2EchoAppl all character
fields will be in EBCDIC.
The response data should be appended to the
origin request data. This allows data
verification to check the data that flows in
both directions. If the response data size is
smaller than the request data size the original
request data will be truncated.
An example would be:
Request: / Response:
'WxYz' / 'WxYz'
0x01 / 0x01
0x02 / 0x03
0x0001 / 0x0001
0x00000008 / 0x00000008
'ABCDEF' / 'ABCDEFGH'
NOTE: We requested 8 bytes in the response and
the response had 8 bytes. The size of the
request data has no correlation to the
size of the response data.
NOTE: For native RTT request/response (i.e.
ipIcmpecho) operations both the 'Header'
and 'Data' will be included. Only the
'sequence number' in the Header will be
valid.
NOTE: For non-connection oriented protocol the
initial RTT request/response operation will
be preceded with an RTT request/response
operation to the target address to force
path exploration and to prove
connectivity. The History collection table
will contain these responses, but the
Statistics capture table will omit them to
prevent skewed results.
ication is only valid when the RttMonRttType
is 'echo' or 'pathEcho'.
A rttMonConnectionChangeNotification indicates that a
connection to a target (not to a hop along the path
to a target) has either failed on establishment or
been lost and when reestablished. Precisely, this
has resulted in rttMonCtrlOperConnectionLostOccurred
changing value.
If History is not being collected, the instance values
for the rttMonHistoryCollectionAddress object will not
be valid. When RttMonRttType is not 'echo' or 'pathEcho'
the rttMonHistoryCollectionAddress object will be null.
rttMonConnectionChangeNotification object is superseded by
rttMonNotification.
rttMonTimeoutNotification
.1.3.6.1.4.1.9.9.42.2.0.2
meoutNotification indicates the occurrence of
a timeout for a RTT operation, and it indicates the
clearing of such a condition by a subsequent RTT
operation. Precisely, this has resulted in
rttMonCtrlOperTimeoutOccurred changing value.
When the RttMonRttType is 'pathEcho', this
notification will only be sent when the timeout
occurs during an operation to the target and not to
a hop along the path to the target. This also
applies to the clearing of the timeout.
If History is not being collected, the instance values
for the rttMonHistoryCollectionAddress object will not
be valid. When RttMonRttType is not 'echo' or 'pathEcho'
the rttMonHistoryCollectionAddress object will be null.
rttMonTimeoutNotification object is superseded by
rttMonNotification.
rttMonThresholdNotification
.1.3.6.1.4.1.9.9.42.2.0.3
resholdNotification indicates the
occurrence of a threshold violation for a RTT operation,
and it indicates the previous violation has subsided for
a subsequent RTT operation. Precisely, this has resulted
in rttMonCtrlOperOverThresholdOccurred changing value.
When the RttMonRttType is 'pathEcho', this
notification will only be sent when the threshold
violation occurs during an operation to the target and
not to a hop along the path to the target. This also
applies to the subsiding of a threshold condition.
If History is not being collected, the instance values
for the rttMonHistoryCollectionAddress object will not
be valid. When RttMonRttType is not 'echo' or 'pathEcho'
the rttMonHistoryCollectionAddress object will be null.
rttMonThresholdNotification object is superseded by
rttMonNotification.
rttMonVerifyErrorNotification
.1.3.6.1.4.1.9.9.42.2.0.4
rifyErrorNotification indicates the
occurrence of a data corruption in an RTT operation.
rttMonVerifyErrorNotification object is superseded by
rttMonNotification.
rttMonNotification
.1.3.6.1.4.1.9.9.42.2.0.5
tification indicates the occurrence of a
threshold violation, and it indicates the previous
violation has subsided for a subsequent operation.
When the RttMonRttType is 'pathEcho', this
notification will only be sent when the threshold
violation occurs during an operation to the target and
not to a hop along the path to the target. This also
applies to the subsiding of a threshold condition.
If History is not being collected, the instance values
for the rttMonHistoryCollectionAddress object will not
be valid. When RttMonRttType is not 'echo' or 'pathEcho'
the rttMonHistoryCollectionAddress object will be null.
rttMonReactVar defines the type of reaction that is
configured for the probe ( e.g jitterAvg, rtt etc ).
In the rttMonReactTable there are trap definitions
for the probes and each probe may have more than
one trap definitions for various types ( e.g rtt,
jitterAvg, packetLoossSD etc ). So the object rttMonReactVar
indicates the type ( e.g. rtt, packetLossSD, timeout etc )
for which threshold violation traps has been generated.
The object rttMonEchoAdminLSPSelector will be valid only
for the probes based on 'mplsLspPingAppl' RttMonProtocol. For
all other probes it will be null.
rttMonNotification object is superseded by
rttMonNotificationV2.
rttMonLpdDiscoveryNotification
.1.3.6.1.4.1.9.9.42.2.0.6
dDiscoveryNotification indicates that the LSP Path
Discovery to the target PE has failed, and it also indicates
the clearing of such condition. Precisely this has resulted in
rttMonLpdGrpStatsLPDFailOccurred changing value.
When the rttMonLpdGrpStatsLPDFailOccurred is 'false', the
instance value for rttMonLpdGrpStatsLPDFailCause is not valid.
rttMonLpdGrpStatusNotification
.1.3.6.1.4.1.9.9.42.2.0.7
dGrpStatusNotification indicates that the LPD
Group status rttMonLpdGrpStatsGroupStatus has changed indicating
some connectivity change to the target PE.
This has resulted in rttMonLpdGrpStatsGroupStatus changing
value.
rttMonNotificationV2
.1.3.6.1.4.1.9.9.42.2.0.8
tification indicates the occurrence of a
threshold violation, and it indicates the previous
violation has subsided for a subsequent operation.
Enhanced version of rttMonNotification which replaces
rttMonCtrlAdminTag with rttMonCtrlAdminLongTag object.