Network Working Group E. Stephan
Internet Draft France Telecom R&D
Document: draft-stephan-ippm-mib-00.txt June 29, 2001
Category: Informational
IP measurement MIB
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1] except that the right to
produce derivative works is not granted.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Abstract
This memo defines a portion of the Management Information Base (MIB)
for use with network management protocols in TCP/IP-based internets.
In particular, it defines objects for managing measures using the IP
performance metrics specified by the IPPM Working Group.
Table of Contents
1. Introduction................................................2
2. The IPPM Framework..........................................2
3. The SNMP Management Framework...............................3
4. Overview....................................................4
4.1. Textual Conventions.........................................4
4.2. Structure of MIB............................................5
4.2.1. The ippmOwner Group.........................................5
Stephan Informational - Expires December 2001 [Page 1]
Internet Draft IPPM MIB June 2001
4.2.2. The ippmSystem Group........................................5
4.2.3. The ippmMeasureGroup........................................5
4.2.4. The ippmSampler Group.......................................6
4.2.5. The ippmStatistic Group.....................................6
4.3. Resource Sharing Among Multiple Applications and Agents.....6
4.4. Control of Remote Measurement Devices.......................6
4.5. Resource Sharing Among Multiple Management Stations.........7
4.6. Row Addition Among Multiple Management Stations.............7
5. Conventions used in this document...........................8
5.1. Packet of type P............................................8
5.2. Internet addresses..........................................8
5.3. Default value...............................................9
6. Definition..................................................9
7. Security Considerations....................................32
7.1. Privacy....................................................33
7.2. Measurement aspects........................................33
7.3. Management aspects.........................................33
8. References.................................................34
9. Acknowledgments............................................36
10. Author's Addresses.........................................36
1. Introduction
This memo defines a MIB for managing the measures using the IP
performance metrics specified by the IPPM Working Group.
It specifies the objects to manage the measure of performance metrics
standardized by IPPM Working Group. There are built on notions
introduced and discussed in the IPPM Framework document, RFC 2330
[2]. The reader is assumed to be familiar with this document.
This memo defines a Management Information Base (MIB) so it is
intended to be respectful of the "Boilerplate for IETF MIBs" defined
in http://www.ops.ietf.org/mib-boilerplate.html.
There are a number of companion documents to the IPPM MIB both in the
Transport Area (See section 2) and in the Operations and Management
Area (See section 3). The reader should be familiar with the RMON MIB
model.
Part of the text in this memo is taken directly from these documents.
2. The IPPM Framework
The IPPM Framework at present consists of 3 major components:
A general framework for defining performance metrics, described
in the Framework for IP Performance Metrics, RFC 2330 [2].
Stephan Informational - Expires December 2001 [Page 2]
Internet Draft IPPM MIB June 2001
A set of standardized metrics which conform to this framework.
The IPPM Metrics for Measuring Connectivity, RFC 2678 [3]. The One-
way Delay Metric for IPPM, RFC 2679 [4]. The One-way Packet Loss
Metric for IPPM, RFC 2680 [5]. The Round-trip Delay Metric for IPPM,
RFC 2681 [6].
Emerging metrics which are being specified in respect of this
framework.
3. The SNMP Management Framework
The SNMP Management Framework consists of five major components:
An overall architecture, described in RFC 2571 [7].
Mechanisms for describing and naming objects and events for the
purpose of management. The first version of this Structure of
Management Information (SMI) is called SMIv1 and described in STD 16,
RFC 1155 [8], STD 16, RFC 1212 [9] and RFC 1215 [10]. The second
version, called SMIv2, is described in STD 58, RFC 2578 [11], STD 58,
RFC 2579 [12] and STD 58, RFC 2580 [13].
Message protocols for transferring management information. The
first version of the SNMP message protocol is called SNMPv1 and
described in STD 15, RFC 1157 [14]. A second version of the SNMP
message protocol, which is not an Internet standards track protocol,
is called SNMPv2c and described in RFC 1901 [15] and RFC 1906 [16].
The third version of the message protocol is called SNMPv3 and
described in RFC 1906 [16], RFC 2572 [17] and RFC 2574 [18].
Protocol operations for accessing management information. The
first set of protocol operations and associated PDU formats is
described in STD 15, RFC 1157 [14]. A second set of protocol
operations and associated PDU formats is described in RFC 1905 [19].
A set of fundamental applications described in RFC 2573 [20] and
the view-based access control mechanism described in RFC 2575 [21].
A more detailed introduction to the current SNMP Management Framework
can be found in RFC 2570 [22].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the mechanisms defined in the SMI.
This memo specifies a MIB module that is compliant to the SMIv2. A
MIB conforming to the SMIv1 can be produced through the appropriate
translations. The resulting translated MIB must be semantically
equivalent, except where objects or events are omitted because no
Stephan Informational - Expires December 2001 [Page 3]
Internet Draft IPPM MIB June 2001
translation is possible (use of Counter64). Some machine readable
information in SMIv2 will be converted into textual descriptions in
SMIv1 during the translation process. However, this loss of machine
readable information is not considered to change the semantics of the
MIB.
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. Objects in the MIB are
defined using the subset of Abstract Syntax Notation One (ASN.1)
defined in the SMI. In particular, each object type is named by an
OBJECT IDENTIFIER, an administratively assigned name.
The object type together with an object instance serves to uniquely
identify a specific instantiation of the object. For human
convenience, we often use a textual string, termed the descriptor, to
refer to the object type.
4. Overview
Although the number of measurements devices that implement the IPPM
metrics is growing there is not currently any standardized management
interface to manage remotely these metrics. This memo defines a
Management Information Base for managing remotely the standardized
IPPM metrics. The MIB architecture is directly inspired by the
RFC2819 [23] and the RFC2021 [24] which specify the MIB for remote
monitoring devices.
As the specification of new metrics is a continuous process this memo
defines a framework for the integration of the future standardized
metric.
This MIB is intended to handle multiple concurrent SNMP applications
access. They are not in constant contact with the measurement
devices. For this reason, this MIB allows continuous measures
collection and statistics computation.
This MIB differs from the RMON model mainly on 2 aspects. Each SNMP
application manages its own range of indexes. The timeFilter is
absolute.
The objects defined in this document are intended as an interface
between an SNMP agent and an SNMP management application and are not
intended for direct manipulation by humans.
4.1. Textual Conventions
Three new data types are introduced as a textual convention in
this MIB document, TypeP and GMTDateAndTime and GmtTimeFilter.
Stephan Informational - Expires December 2001 [Page 4]
Internet Draft IPPM MIB June 2001
4.2. Structure of MIB
The objects are arranged into the following groups:
- ippmOwnerGroup
- ippmSystemGroup
- ippmMeasureGroup
- ippmSamplerGroup
- ippmStatisticGroup
All groups in this MIB are mandatory.
4.2.1. The ippmOwner Group
This group controls the SNMP applications which are granted to
manage the measurement device.
4.2.2. The ippmSystem Group
This group consists of a set of parameters describing the clock
synchronisation over the time.
This group is the most important part of the memo.
Section 6.3. of the IPPM Framework said that
"Those who develop such measurement methodologies should strive to:
+ minimize their uncertainties/errors,
+ understand and document the sources of uncertainty/error, and
+ quantify the amounts of uncertainty/error."
The aim of this group is to have these values available to compute
reliable statistics. Then the implementation of this group is
mandatory either the time synchronization is automatic or not.
4.2.3. The ippmMeasureGroup
This group controls all the measures. It consists of the
ippmMetricsTable, ippmMeasureControlTable and ippmHistoryTable.
The SNMP agent describes in the ippmMetricsTable the local
implementation of the standardized metrics.
The customers of the agent manage their measures in the
ippmMeasureControlTable and in the auxiliaries measures tables.
ippmMeasureControlTable holds the management part of a measure while
Stephan Informational - Expires December 2001 [Page 5]
Internet Draft IPPM MIB June 2001
the technical parameters are handled in the corresponding auxiliary
table.
The results of the measures are logged in the ippmHistoryTable.
4.2.4. The ippmSampler Group
This group controls the network measures defined by the customers.
The results are saved in the ippmHistoryTable.
ippmSamplerControlTable is an auxiliary table of
ippmMeasureControlTable in charge of the configuration of the network
measure.
4.2.5. The ippmStatistic Group
ippmStatisticControlTable is an auxiliary table of
ippmMeasureControlTable in charge of the consolidation of the results
previously performed and saved in the ippmHistoryTable. The resulting
statistics are saved in the ippmHistoryTable.
4.3. Resource Sharing Among Multiple Applications and Agents
The network administrator controls the owner string and the owner
index range provided by the management applications wishing to share
the measurement device.
An instance of an object managed by a SNMP application is
systematically identified by the application OwnerString and by the
private index provided by the application.
Because the application manages its private range of index, it simply
provides one when it wishes to create a new control entry. For the
same reason an application may duplicate the same control entry on
multiple devices.
4.4. Control of Remote Measurement Devices
Due to the complex nature of the available functions in these
devices, the functions often need user configuration. In many cases,
the function requires parameters to be set up for a data collection
operation. The operation can proceed only after these parameters are
fully set up.
Functional groups in this MIB have one or more tables in which to
set up control parameters, and one or more data tables in which to
place the results of the operation. The control tables are typically
read/write in nature, while the data tables are typically read/only.
Stephan Informational - Expires December 2001 [Page 6]
Internet Draft IPPM MIB June 2001
Because the parameters in the control table often describe
resulting data in the data table, many of the parameters can be
modified only when the control entry is not active. Thus, the method
for modifying these parameters is to de-activate the entry, perform
the SNMP Set operations to modify the entry, and then re-activate the
entry. Deleting the control entry causes the deletion of any
associated data entries.
4.5. Resource Sharing Among Multiple Management Stations
When multiple management stations wish to use functions that
compete for a finite amount of resources on a device, a method to
facilitate this sharing of resources is required. The OwnerString
mechanism is provided for each management station initiated function
in this MIB to avoid these conflicts and to help resolve them when
they occur. Each function has a label identifying the initiator
(owner) of the function. This label is set by the initiator to
provide for the following possibilities:
A management station may recognize resources it owns and no
longer needs.
A management station may grant another one to use or manage part
of its resources.
A network operator can find the management station that owns the
resource and negotiate for it to be freed.
A network operator may decide to unilaterally free resources
another network operator has reserved.
There is often default functionality that the device or the
administrator of the probe (often the network administrator) wishes
to set up.
The owner object of the resources owned by the device itself or by
the network administrator is set to a string starting with 'monitor'.
4.6. Row Addition Among Multiple Management Stations
The applications allowed to manage the measurement device are
previously registered in the agent. The indexes of the rows which
belong to a manager include both the manager owner string and a
integer index. The value of the index is provide by the manager not
by the agent.
The addition of new rows is achieved using the RowStatus method
described in RFC 1903 [2]. In this MIB, rows are often added to a
table in order to configure a function. This configuration usually
involves parameters that control the operation of the function. The
agent must check these parameters to make sure their are appropriate
given restrictions defined in this MIB as well as any implementation
specific restrictions such as lack of resources.
Stephan Informational - Expires December 2001 [Page 7]
Internet Draft IPPM MIB June 2001
5. Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC-2119 [25].
The following conventions are used throughout the IPPM MIB.
5.1. Packet of type P
The section 13 of the IPPM framework [2] introduces the generic
notion of a "packet of type P" because in some contexts the metric's
value depends on the type of the packets involved in the metric. In
the definition of a metric the type P will be explicitly defined,
partially defined or left generic. Measurement of metrics defined
with generic type P made specific when performing actual
measurements. This naming convention serves as an important reminder
that one must be conscious of the exact type of traffic being
measured.
The standardization of the management of the IPPM measures relies on
the capability to configure finely and unambiguously the type P of
the packets and the parameters of the protocols suites of the type P.
RMON2 introduced the concept of protocols identifiers. The RFC2895
[26] specifies a macro for the definition of protocol identifier. The
RFC2896 [27] defines the protocols identifiers for different
protocols encapsulation trees.
The type P implementation relies on the MACRO PROTOCOL-IDENTIFIER
defined for identifying the protocol in the RMON2. It is achieved by
defining the TypeP as new syntax in a SMIv2 TEXTUAL-CONVENTION.
5.2. Internet addresses
The section 14 of the IPPM framework defines for the common case of a
unidirectional path through the Internet the term "Src" and "Dst".
"Src" denotes the IP address of the beginning of the path, and "Dst"
denotes the IP address of the end.
The section 3 of the RMON PI Reference specifies the Protocol
Identifier Encoding rules which consists briefly in a recursive
length value format. "Src" and "Dst" are protocol identifier
parameters. Their values are encoded in separated fields using the
protocol identifier encoding rule but without trailing parameters.
The packet encapsulation defined in an instance of TypeP embeds the
format of "Src" and "Dst" and their values. These addresses type and
Stephan Informational - Expires December 2001 [Page 8]
Internet Draft IPPM MIB June 2001
value depend on the type P of the packet, IP version 4, V6, IP in
IP... Both participate to the completion of the packet encoding.
Examples:
RFC2896 defines the protocols identifiers ip and ipip4. Should there
be a Internet tunnel end-point of the IP address 192.168.1.1 in the
tunnel 128.2.6.7. The TypeP of the source address of the tunnel, Src,
is 8.0.0.8.0.0.0.0.17.2.0.0 (ip.ipip4). The trailer 2.0.0 in the
TypeP indicates that there are 2 parameters. In the IPPM context
these 2 parameters are provided in Src which has the value
10.4.192.168.1.1.4.128.2.6.7.
5.3. Default value
They are mostly used as illustrations.
6. Definition
IPPM-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY,
NOTIFICATION-TYPE,
OBJECT-TYPE,
Integer32,
Counter32
FROM SNMPv2-SMI
OwnerString
FROM RMON-MIB
protocolDir
FROM RMON2-MIB
DisplayString,
TimeStamp,
DateAndTime,
TruthValue,
RowStatus,
TEXTUAL-CONVENTION
FROM SNMPv2-TC
MODULE-COMPLIANCE,
OBJECT-GROUP,
NOTIFICATION-GROUP
FROM SNMPv2-CONF;
ippmMib MODULE-IDENTITY
LAST-UPDATED "200107101500Z" -- July 10, 2001
ORGANIZATION "France Telecom - R&D"
CONTACT-INFO
"Postal : Emile Stephan
Stephan Informational - Expires December 2001 [Page 9]
Internet Draft IPPM MIB June 2001
France Telecom - R&D, Dpt. CPN
2, Avenue Pierre Marzin
Technopole Anticipa
22307 Lannion Cedex
FRANCE
Tel: + 33 2 96 05 36 10
E-mail: emile.stephan@francetelecom.com"
DESCRIPTION
"This memo defines a portion of the Management
Information Base (MIB) for use with network management
protocols in TCP/IP-based internets. In particular, it
defines objects for managing measures using the IP
performance metrics specified by the IPPM Working
Group."
::= { experimental 10000 } -- to be assigned, set to 10000
to be syntically correct.
OwnerString ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"(re)defines OwnerString using V2 convention."
SYNTAX DisplayString
--
--
-- A absolute, GMT timer using UTC like convention.
--
--
GMTDateAndTime ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d-1d-1d,1d:1d:1d,2d"
STATUS current
DESCRIPTION
"A date-time specification.
field octets contents range
----- ------ -------- -----
1 1 year* 0..256
2 2 month 1..12
3 3 day 1..31
4 4 hour 0..23
5 5 minutes 0..59
6 6 seconds 0..59
7 7-8 1/10 milliseconds 0..9999
*Notes: 0 stands for year 2000.
Stephan Informational - Expires December 2001 [Page 10]
Internet Draft IPPM MIB June 2001
For example, "0102192015100500" represent 8:15pm, 10
seconds and 50 ms GMT on 19 February 2001 and is
displayed as 01-02-19,20:15:10,0500"
SYNTAX OCTET STRING (SIZE (8))
GmtTimeFilter ::= TEXTUAL-CONVENTION
STATUS current
DESCRIPTION
"GmtTimeFilter TC is inspired by the TimeFilter defined
in the RMON2. The reference of the time of TimeFilter is
the local value of sysUptime while GmtTimeFilter uses a
absolute reference of time.
GmtTimeFilter is intended to be used for the index of a
table. It allows an application to download only those
rows changed since a particular time. A row is
considered changed if the value of any object in the row
changes or if the row is created or deleted.
Each new conceptual row will be associated with the
timeMark instance which was created at the value of
ippmTimeSysTimer.
It is intended to provide an absolute timestamp index
for the result of measures. Typically to each singleton
produced by an IPPM measure is associated the timemark
corresponding to the moment of the measure.
illustrations:
Consider the 2 tables measureTable and resultTable
measureTable OBJECT-TYPE
SYNTAX SEQUENCE OF MeasureEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION ""
::= { fooMib 1 }
INDEX { measureIndex }
resultTable OBJECT-TYPE
SYNTAX SEQUENCE OF ResultEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION ""
::= { fooMib 2 }
INDEX { measureIndex, resultTimeMark }
ResultEntry {
Stephan Informational - Expires December 2001 [Page 11]
Internet Draft IPPM MIB June 2001
resultTimeMark TimeFilter,
resultCounts Counter
}
Should there be two measure rows in the measure table
(measureIndex == 1, measureIndex == 2) which produced
results asynchronously (e.g. made at Poisson intervals
or sibling) and log them in the result table.
Measure 1 produced the result 34 at time
0102192015100500 GMT, while row 2 produced the value 54
most recently (10ms later) at time 0102192015100600 GMT,
and both rows are updated on several later occasions
such that the current values are 37 and 53 respectively.
Then the following resultCounts instances would exist.
resultCounts.1.0102192015100500 34
resultCounts.2.0102192015100600 54
resultCounts.1.0102192015100950 65
resultCounts.1.0102192015100600 57
resultCounts.2.0102192015100800 48
resultCounts.2.0102192015100850 53
resultCounts.1.0102192015110050 49
resultCounts.1.0102192015110200 37
The following get-bulk explains how a NMS retrieves the
results of the measures.
get-bulk(nonRptrs=1, maxReps=10, resultCounts.1);
returns:
resultCounts.1.0102192015100500 == 34
resultCounts.1.0102192015100950 == 65
resultCounts.1.0102192015100600 == 57
resultCounts.1.0102192015110050 == 49
resultCounts.1.0102192015110200 == 37
# return lexigraphically-next two MIB instances
get-bulk(nonRptrs=0, maxReps=2,
resultCounts.1.0102192015100600,
resultCounts.2.0102192015100600);
returns:
resultCounts.1.0102192015100950 == 65
resultCounts.2.0102192015100800 == 48
resultCounts.1.0102192015100600 == 57
resultCounts.2.0102192015100850 == 53
get-bulk(nonRptrs=0, maxReps=2,
resultCounts.1.0102192015110200,
resultCounts.2.0102192015110200);
Stephan Informational - Expires December 2001 [Page 12]
Internet Draft IPPM MIB June 2001
returns:
return lexigraphically-next two MIB instances
no 'resultTable' counter values at all are
returned because neither counter has been updated since
time 0102192015110200"
SYNTAX GMTDateAndTime
TypeP ::= TEXTUAL-CONVENTION
DISPLAY-HINT "1d."
STATUS current
DESCRIPTION
"This textual convention is used to describe the
protocols encapsulation list of a packet, and is used as
the value of the SYNTAX clause for the type of the Src
and Dst of a IPPM measure. The RFC2895 specifies a macro
for the definition of protocols identifiers while its
companion document, the RFC2896 defines a set of
protocols identifiers.
Notes: An IPPM TypeP does not differ from RMON2
Protocols identifiers but TypeP usage in IPPM MIB
differs from Protocol identifier usage in RMON2. A IPPM
measure is active so generally TypeP does not describe
the link layer (i.e. ether2...). Valid Internet packets
are sent from Src to Dst. Then the choice of the link
layer relies on the Internet stack.
For example, the RFC2896 defines the protocol identifier
'16.0.0.0.1.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0' which
represents ether2.ip.tcp.telnet and the protocol
identifier 16.0.0.0.1.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0
which stands for ether2.ip.ipip4.udp. The corresponding
TypeP are '12.0.0.8.0.0.0.0.6.0.0.0.23.3.0.0.0'
(ip.tcp.telnet) and 12.0.0.8.0.0.0.0.4.0.0.0.17.3.0.0.0
(ip.ipip4.udp)."
SYNTAX OCTET STRING
-- IPPM Mib objects definitions
ippmCompliances OBJECT IDENTIFIER ::= { ippmMib 1 }
ippmOwnerGroup OBJECT IDENTIFIER ::= { ippmMib 2 }
ippmSystemGroup OBJECT IDENTIFIER ::= { ippmMib 3 }
ippmMeasureGroup OBJECT IDENTIFIER ::= { ippmMib 4 }
ippmSamplerGroup OBJECT IDENTIFIER ::= { ippmMib 5 }
ippmStatisticGroup OBJECT IDENTIFIER ::= { ippmMib 6 }
--
-- ippmOwnerGroup
Stephan Informational - Expires December 2001 [Page 13]
Internet Draft IPPM MIB June 2001
--
-- The ippmOwnerAndIndexControlGroup grants block of private indexes
to the NMS applications.
--
--
ippmOwnerAndIndexControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF IppmOwnerEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A NMS entity wishing to create and activate remote Ippm
measurements in an agent must previously be registered
in the ippmOwnerAndIndexControlTable using the
conceptual row mechanism described in the RMON2.
Notes:
The control of the access to the IPPM MIB is outside the
scope of this table. As that point is crucial objects
will be added in a further release to provide the NMS
with the capability to grant other entities to use their
ressources.An object to manage the metrics granted per
owner will be added too."
::= { ippmOwnerGroup 1 }
ippmOwnerAndIndexControlEntry OBJECT-TYPE
SYNTAX IppmOwnerAndIndexControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The description of the resources the agent granted to a
SNMP application.
An application may be granted with multiple ranges.
Entries can be only created and deleted. Deleting the
control entry causes the deletion of any associated data
entries.
There is no relation between an owner range of indexes
and the resources reserved for this owner.
For example, an instance of
ippmOwnerAndIndexControlEntryOwner with a ownerString
'acme', which represents the 14th owner created in
ippmOwnerAndIndexControlTable would be named
ippmOwnerAndIndexControlEntryOwner.14.
Notes:
Stephan Informational - Expires December 2001 [Page 14]
Internet Draft IPPM MIB June 2001
The OwnerAndIndexControlIndex value is a local index
managed directly by the agent. It is not used in anyway
in the other IPPM tables.
{ discussion:
administrative information fields should be added for
each owner such as IP address, management station name,
network manager's name, location, email, or phone
number.}"
INDEX { ippmOwnerAndIndexControlIndex }
::= { ippmOwnerAndIndexControlTable 1 }
IppmOwnerAndIndexControlEntry ::= SEQUENCE {
ippmOwnerAndIndexControlIndex INTEGER,
ippmOwnerAndIndexControlRangeBegin INTEGER,
ippmOwnerAndIndexControlRangeEnd INTEGER,
ippmOwnerAndIndexControlStatus RowStatus,
ippmOwnerAndIndexControlEntryOwner OwnerString
}
ippmOwnerAndIndexControlIndex OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The index of the entry."
::= { ippmOwnerAndIndexControlEntry 1 }
ippmOwnerAndIndexControlRangeBegin OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-create
STATUS current
DEFVAL { 500 }
DESCRIPTION
"The first index of the range."
::= { ippmOwnerAndIndexControlEntry 2 }
ippmOwnerAndIndexControlRangeEnd OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-create
STATUS current
DEFVAL { 2500 }
DESCRIPTION
"The last index of the range."
::= { ippmOwnerAndIndexControlEntry 3 }
ippmOwnerAndIndexControlStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
Stephan Informational - Expires December 2001 [Page 15]
Internet Draft IPPM MIB June 2001
STATUS current
DESCRIPTION
"The status of this table entry."
::= { ippmOwnerAndIndexControlEntry 4 }
ippmOwnerAndIndexControlEntryOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Identifies the manager which owns this entry."
::= { ippmOwnerAndIndexControlEntry 5 }
--
-- ippmSystemGroup
--
--
ippmSystemTimer OBJECT-TYPE
SYNTAX GMTDateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The current time of the system."
::= { ippmSystemGroup 1 }
ippmSystemSynchonizationType OBJECT-TYPE
SYNTAX INTEGER {
none(0),
NTP(1),
GPS(2),
other(3)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"ippmSystemSynchonizationType describes the mechanism
used to synchronise the system.
none
There is no synchonisation available.
NTP
The system is synchronised using the network
time protocol. The NTP synchronisation must be described
finely in the ippmSystemSynchonizationDescription.
GPS
The system is synchronised using the GPS.
Other
Stephan Informational - Expires December 2001 [Page 16]
Internet Draft IPPM MIB June 2001
The synchronisation process must be defined
extensively in the ippmSystemSynchonizationDescription.
"
::= { ippmSystemGroup 2 }
ippmSystemSynchonizationDescription OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The description of the synchronisation process."
::= { ippmSystemGroup 3 }
ippmSystemClockResolution OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"ippmSystemClockResolution provides the precision of the
clock used for the measures. The unit is 1/10 of
millisecond. For example, the clock on an old Unix host
might advance only once every 10 msec, and thus have a
resolution of only 10 msec."
::= { ippmSystemGroup 4 }
ippmSystemSynchronisationTime OBJECT-TYPE
SYNTAX DateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The time when occurs the last synchronisation of the
clock. The last synchronisation must be set even if the
synchronisation is not automatic."
::= { ippmSystemGroup 5 }
ippmSystemClockAccuracy OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The most recent accuracy of the clock computed. The
accuracy must be compute even if the synchronisation is
not automatic."
::= { ippmSystemGroup 6 }
ippmSystemClockSkew OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
Stephan Informational - Expires December 2001 [Page 17]
Internet Draft IPPM MIB June 2001
"The most recent skew of the clock computed. The
ippmSystemSkew must be compute even if the
synchronisation is not automatic."
::= { ippmSystemGroup 7 }
ippmSystemPrevClockAccuracy OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The previous accuracy of the clock measured. The
ippmSystemPrevClockAccuracy must be computed even if the
synchronisation is not automatic."
::= { ippmSystemGroup 8 }
ippmSystemPrevClockSkew OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The previous skew of the clock measured. The
ippmSystemPrevClockSkew must be computed even if the
synchronisation is not automatic."
::= { ippmSystemGroup 9 }
--
--
--
-- ippmMeasureGroup
--
--
--
ippmMetricTable OBJECT-TYPE
SYNTAX SEQUENCE OF ippmMetricEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This table describes the current implementation. This
table is mandatory. Each IPPM standardized metric must
be described in the table. "
::= { ippmMeasureGroup 1 }
ippmMetricEntry OBJECT-TYPE
SYNTAX IppmMetricEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
Stephan Informational - Expires December 2001 [Page 18]
Internet Draft IPPM MIB June 2001
"An entry describes the static capabilities of a metric
implementation."
INDEX { ippmMetricIndex }
::= { ippmMetricTable 1 }
IppmMetricEntry ::=
SEQUENCE {
ippmMetricIndex INTEGER,
ippmMetricCapabilities BITS,
ippmMetricDescription DisplayString,
ippmMetricMaxHistorySize INTEGER
}
ippmMetricIndex OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"ippmMetricIndex defines an unambiguous index for each
standardized metric.
A metric has the fixed index in impMetricTable
corresponding to the chronological order of the
standardization of the metric memos defining the metrics
that is the RFCs order and the sequential order of the
metrics definition in each memo.
The IPPM RFC are:
RFC Title
-------------------------------------------------
RFC2678 IPPM Metrics for Measuring Connectivity
RFC2679 A One-way Delay Metric for IPPM
RFC2680 One Way Packet Loss Metric for IPPM
RFC2681 Round-trip for Delay Metric for IPPM
The resulting indexes are:
Metric Index
-------------------------------------------------
Instantaneous-Unidirectional-Connectivity 1
Instantaneous-Bidirectional-Connectivity 2
Interval-Unidirectional-Connectivity 3
Interval-Bidirectional-Connectivity 4
Interval-Temporal-Connectivity 5
One-way-Delay 6
One-way-Delay-Poisson-Stream 7
One-way-Delay-Percentile 8
One-way-Delay-Median 9
One-way-Delay-Minimum 10
One-way-Delay-Inverse-Percentile 11
Stephan Informational - Expires December 2001 [Page 19]
Internet Draft IPPM MIB June 2001
One-way-Packet-Loss 12
One-way-Packet-Loss-Poisson-Stream 13
One-way-Packet-Loss-Average 14
Round-trip-Delay 15
Round-trip-Delay-Poisson-Stream 16
Round-trip-Delay-Percentile 17
Round-trip-Delay-Median 18
Round-trip-Delay-Minimum 19
Round-trip-Delay-Inverse-Percentile 20
"
::= { ippmMetricEntry 1 }
ippmMetricCapabilities OBJECT-TYPE
SYNTAX INTEGER {
notImplemented(0),
implemented(1)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"notImplemented
the metric is not implemented.
implemented
the metric is implemented."
DEFVAL { implemented }
::= { ippmMetricEntry 2 }
ippmMetricDescription OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"A textual description of the metric implementation."
::= { ippmMetricEntry 3 }
ippmMetricMaxHistorySize OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Specifies the maximal size of the archive of this
metric in the ippmHistoryTable."
::= { ippmMetricEntry 4 }
--
-- ippmMeasureControlTable
--
Stephan Informational - Expires December 2001 [Page 20]
Internet Draft IPPM MIB June 2001
--
ippmMeasureControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF IppmMeasureControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"The table of all the IPPM measures which are running in
the device. They may not be active.
a measure consists in a subset of metrics to compute.
The results of the measure may be saved in the
ippmHistoryTable. The configuration of the measure sets
the size of the history requested in
ippmMeasureControlHystorySize.
The maximal number of MIB objects to be collected in the
portion of ippmHistoryTable associated with this metric
depends the value of the ippmMetricMaxHistorySize.
The value of each metric ippmMeasureControlHystorySize
must not be over the value of ippmMetricMaxHistorySize
corresponding to this metric in ippmMetricTable.
"
::= { ippmMeasureGroup 2 }
ippmMeasureControlEntry OBJECT-TYPE
SYNTAX IppmMeasureControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A SNMP entity wishing to create and activate a
measurement adds a new entry in the
ippmMeasureControlTable.
Typically the configuration operation set the values of
the conceptual row parameters using an unused owner
index and sets the status of the row to createAndGo.
An SNMP error 'inconsistentValue' is returned if the
owner index is out of range."
INDEX { ippmMeasureControlOwner, ippmMeasureControlIndex }
::= { ippmMeasureControlTable 1 }
IppmMeasureControlEntry ::=
SEQUENCE {
ippmMeasureControlIndex INTEGER,
ippmMeasureControlName DisplayString,
ippmMeasureControlMetrics BITS,
ippmMeasureControlBeginTime GMTDateAndTime,
ippmMeasureControlClockPeriodUnit Integer32,
Stephan Informational - Expires December 2001 [Page 21]
Internet Draft IPPM MIB June 2001
ippmMeasureControlClockPeriod Integer32,
ippmMeasureControlDurationUnit Integer32,
ippmMeasureControlDuration Integer32,
ippmMeasureControlHystorySize Integer32,
ippmMeasureControlOwner OwnerString,
ippmMeasureControlStatus RowStatus
}
ippmMeasureControlIndex OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The owner index of the measure. Its value must be in
the range of indexes granted to that customer. The index
is managed by the owner in its range of index. An SNMP
error 'inconsistentValue' is returned if the index of
the owner is out of range."
::= { ippmMeasureControlEntry 1 }
ippmMeasureControlName OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-write
STATUS current
DESCRIPTION
"The name of the instance of the metric. It illustrates
the specificity of the metric and includes the metric
and the typeP.
example: IP-port-HTTP-connectivity"
::= { ippmMeasureControlEntry 2 }
ippmMeasureControlMetrics OBJECT-TYPE
SYNTAX BITS {
none(0), -- reserved
Instantaneous-Unidirectional-Connectivity(1),
Instantaneous-Bidirectional-Connectivity(2),
Interval-Unidirectional-Connectivity(3),
Interval-Bidirectional-Connectivity(4),
Interval-Temporal-Connectivity(5),
One-way-Delay(6),
One-way-Delay-Poisson-Stream(7),
One-way-Delay-Percentile(8),
One-way-Delay-Median(9),
One-way-Delay-Minimum(10),
One-way-Delay-Inverse-Percentile(11),
One-way-Packet-Loss(12),
One-way-Packet-Loss-Poisson-Stream(13),
One-way-Packet-Loss-Average(14),
Stephan Informational - Expires December 2001 [Page 22]
Internet Draft IPPM MIB June 2001
Round-trip-Delay(15),
Round-trip-Delay-Poisson-Stream(16),
Round-trip-Delay-Percentile(17),
Round-trip-Delay-Median(18),
Round-trip-Delay-Minimum(19),
Round-trip-Delay-Inverse-Percentile(20)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Defines the metrics to compute within this measure. A
measure may be configured for the result of different
metrics singletons to be archive in the
ippmHistoryTable. The ippmMetricIndex of the created
result has the value of the bit index of the
corresponding ippmMeasureControlMetrics as explained
above in the ippmMetricIndex definition.
Example:
A measure asking for One-way-Delay(6) and One-way-
Packet-Loss(12) generated a flow of singletons which are
logged in the ippmHistoryTable. The singletons created
for the One-way-Delay measure have a value of
ippmMetricIndex of 6 while the created singletons for
the One-way-Packet-Loss measure have a value of
ippmMetricIndex of 12."
DEFVAL { { One-way-Delay, One-way-Packet-Loss } }
::= { ippmMeasureControlEntry 3 }
ippmMeasureControlBeginTime OBJECT-TYPE
SYNTAX GMTDateAndTime
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the time at which the measure starts."
::= { ippmMeasureControlEntry 4 }
ippmMeasureControlClockPeriodUnit OBJECT-TYPE
SYNTAX INTEGER {
year(1),
month(2),
week(3),
day(4),
hour(5),
second(6),
ms(7),
us(8),
ns(9)
}
Stephan Informational - Expires December 2001 [Page 23]
Internet Draft IPPM MIB June 2001
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the unit of the measure period."
DEFVAL { 6 }
::= { ippmMeasureControlEntry 5 }
ippmMeasureControlClockPeriod OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the among of time between 2 sampling
intervals.
Notes:
This interval generates a flow of periodical instants
which may be transformed as a flow of unpredictable
instants of measure by the
ippmSamplerControlClockPattern."
DEFVAL { 60 }
::= { ippmMeasureControlEntry 6 }
ippmMeasureControlDurationUnits OBJECT-TYPE
SYNTAX INTEGER {
year(1),
month(2),
week(3),
day(4),
hour(5),
second(6),
ms(7),
us(8),
ns(9)
}
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the unit of the measure duration."
DEFVAL { 6 }
::= { ippmMeasureControlEntry 7 }
ippmMeasureControlDuration OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the duration of the measure."
DEFVAL { 120 }
Stephan Informational - Expires December 2001 [Page 24]
Internet Draft IPPM MIB June 2001
::= { ippmMeasureControlEntry 8 }
ippmMeasureControlHystorySize OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the size of the history for each metric of
this measure.
Notes:
This parameter is common to all the results of metrics
of the current measure."
DEFVAL { 120 }
::= { ippmMeasureControlEntry 9 }
ippmMeasureControlOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The owner that configured this entry."
DEFVAL { "acme" }
::= { ippmMeasureControlEntry 10 }
ippmMeasureControlStatus OBJECT-TYPE
SYNTAX RowStatus
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The status of this table entry. Once the entry status
is set to active, the associate entry cannot be
modified."
DEFVAL { 4 }
::= { ippmMeasureControlEntry 11 }
--
-- ippmHistoryTable
--
ippmHistoryTable OBJECT-TYPE
SYNTAX SEQUENCE OF IppmHistoryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A list of measure history entries."
Stephan Informational - Expires December 2001 [Page 25]
Internet Draft IPPM MIB June 2001
::= { ippmMeasureGroup 3 }
ippmHistoryEntry OBJECT-TYPE
SYNTAX IppmHistoryEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"This sample is associated with the
ippmMeasureControlEntry which set up the parameters for
a regular collection of these samples.
The couple ippmMeasureControlOwner value,
ippmMeasureControlIndex value in the index identifies
the ippmMeasureControlEntry on whose behalf this entry
was created.
The ippmMetricIndex value in the index identifies the
ippmMetricEntry on whose behalf this entry was created.
It identifies the type of the metric performed.
The ippmHistoryTimeMark value is the absolute time when
the ippmHistoryValue was performed.
Example:
A one way delay measure is created by the entity 'acme'
using the owner index 1 and setting the 6th bit
(corresponding to One-way-Delay) of
ippmMeasureControlMetrics to 1.
Consider that the result of the one way delay measured
for acme on the day 15 of June at 8h20mn 10s 10ms is 23.
The result is identified as the singleton
ippmHistoryValue.acme.1.6.0106150820100100 and stored
with value 23.
Its value may be retrieved using a get-
next(ippmHistoryValue.acme.1.6.0106150820100099) which
returns (ippmHistoryValue.acme.1.6.0106150820100100 ==
23). The ippmMetricIndex value of '6' corresponds to the
6th metric of ippmMetricTable which is Type-P-One-way-
Delay.
"
INDEX { ippmMeasureControlOwner, ippmMeasureControlIndex,
ippmMetricIndex, ippmHistoryTimeMark }
::= { ippmHistoryTable 1 }
IppmHistoryEntry ::=
SEQUENCE {
ippmHistoryTimeMark GMTDateAndTime,
Stephan Informational - Expires December 2001 [Page 26]
Internet Draft IPPM MIB June 2001
ippmHistoryValue INTEGER
}
ippmHistoryTimeMark OBJECT-TYPE
SYNTAX GMTDateAndTime
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The mark time corresponding to the instant of measure
of the result."
::= { ippmHistoryEntry 1 }
ippmHistoryValue OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The value."
::= { ippmHistoryEntry 2 }
--
-- ippmSamplerGroup
--
--
--
-- ippmSamplerControlTable
--
--
ippmSamplerControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF IppmSamplerControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A sampler is a measure which performs network measures
and provides a flow of results.
This table extends the ippmMeasureControlTable. A
sampler is a specific measure.
A sampler performs several metrics measure per packet
exchange. Each step of a measure produces a singleton
result per metric. The timestamped results are saved in
the ippmHistoryTable."
::= { ippmSamplerGroup 1 }
Stephan Informational - Expires December 2001 [Page 27]
Internet Draft IPPM MIB June 2001
ippmSamplerControlEntry OBJECT-TYPE
SYNTAX IppmSamplerControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A SNMP entity wishing to create and activate a sampler
adds a new entry in the ippmMeasureControlTable and in
IppmSamplerControlTable.
Typically the configuration operation set both the
values of the new ippmMeasureControlEntry and of the new
IppmSamplerControlEntry and sets the status of the row
to createAndGo.
An SNMP error 'inconsistentValue' is returned if the
index is out of range.
The ippmMeasureControlMetrics is set to a list of
metrics to be computed from the same raw packet
exchange. Each step of measure delivers a singleton per
chosen metric. Results are timestamped and saved in the
ippmHistoryTable."
INDEX { ippmMeasureControlOwner, ippmMeasureControlIndex }
::= { ippmSamplerControlTable 1 }
IppmSamplerControlEntry ::=
SEQUENCE {
ippmSamplerControlSrcTypeP TypeP,
ippmSamplerControlSrc OCTET STRING,
ippmSamplerControlDstTypeP TypeP,
ippmSamplerControlDst OCTET STRING,
ippmSamplerControlClockPattern OCTET STRING,
ippmSamplerControlTimeoutDelay Integer32,
ippmSamplerControlL3PacketSize Integer32,
ippmSamplerControlDataPattern OCTET STRING
}
ippmSamplerControlSrcTypeP OBJECT-TYPE
SYNTAX TypeP
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Defines the type P of the source address of the packets
sent by the measure."
DEFVAL { '0400008000100'H } -- ->ip: 4.0.0.8.0.1.0
::= { ippmSamplerControlEntry 1 }
ippmSamplerControlSrc OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
Stephan Informational - Expires December 2001 [Page 28]
Internet Draft IPPM MIB June 2001
STATUS current
DESCRIPTION
"Specifies the address of the source of the measure.
It is represented as an octet string with specific
semantics and length as identified by the
ippmSamplerControlSrcTypeP.
For example, if the ippmSamplerControlSrcTypeP indicates
an encapsulation of 'ip', this object length is 4,
followed by the 4 octets of the IP address, in network
byte order."
DEFVAL { '04C0210415'H } -- -> ip: 192.33.4.21
::= { ippmSamplerControlEntry 2}
ippmSamplerControlDstTypeP OBJECT-TYPE
SYNTAX TypeP
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Defines the type P of the destination address of the
packets sent by the measure."
DEFVAL { '0400008000100'H } -- ->ip: 4.0.0.8.0.1.0
::= { ippmSamplerControlEntry 3 }
ippmSamplerControlDst OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the address of the destination of the
measure.
It is represented as an octet string with specific
semantics and length as identified by the
ippmSamplerControlDstTypeP.
For example, if the ippmSamplerControlDstTypeP indicates
an encapsulation of 'ip', this object length is 4,
followed by the 4 octets of the IP address, in network
byte order."
DEFVAL { '04C0220414'H } -- -> ip: 192.34.4.20
::= { ippmSamplerControlEntry 4 }
ippmSamplerControlClockPattern OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"This cyclic clock shapes the profile of the instants of
measurement according to an arbitrary distribution law.
Stephan Informational - Expires December 2001 [Page 29]
Internet Draft IPPM MIB June 2001
The clock resolution is ippmMeasureControlClockPeriod.
The bits of the clock set to the value 1 determine the
valid instants of measurement. A measure is to be
processed if and only if the current bit value is 1.
This pseudo-random clock pattern allows the
configuration by the NMS of numerous kind of sampling
law such as periodic or Poisson."
DEFVAL { '1111'B } -- 100% periodic
::= { ippmSamplerControlEntry 5 }
ippmSamplerControlTimeoutDelay OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
UNITS "Milliseconds"
DESCRIPTION
"Specifies the delay after which the packet is
considered lost."
DEFVAL { 1 }
::= { ippmSamplerControlEntry 6 }
ippmSamplerControlL3PacketSize OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"Specifies the size of the packets send at the last
network layer in the sense of the TypeP definition."
DEFVAL { 64 }
::= { ippmSamplerControlEntry 7 }
ippmSamplerControlDataPattern OBJECT-TYPE
SYNTAX OCTET STRING
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The current field defines the round robin pattern used
to fill the packet."
DEFVAL { 'FF'H }
::= { ippmSamplerControlEntry 8 }
--
--
-- ippmStatisticGroup
--
--
--
Stephan Informational - Expires December 2001 [Page 30]
Internet Draft IPPM MIB June 2001
--
-- ippmStatisticControlTable
--
--
ippmStatisticControlTable OBJECT-TYPE
SYNTAX SEQUENCE OF IppmStatisticControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A statistic is a measure which performs computation on
data saved in the ippmHistoryTable.
This table extends the ippmMeasureControlTable. A
statistic is a specific measure.
A statistic measure may compute several metrics. Each
step of a statistic computation produces a singleton
result per metric. The results are saved in the
ippmHistoryTable."
::= { ippmStatisticGroup 1 }
ippmStatisticControlEntry OBJECT-TYPE
SYNTAX IppmStatisticControlEntry
MAX-ACCESS not-accessible
STATUS current
DESCRIPTION
"A SNMP entity wishing to create and activate a
statistic measure adds a new entry in the
ippmMeasureControlTable and in
ippmStatisticControlTable.
Typically the configuration operation set both the
values of the new ippmMeasureControlEntry and of the new
IppmStatisticControlEntry and sets the status of the row
to createAndGo.
An SNMP error 'inconsistentValue' is returned if the
index is out of range.
The ippmMeasureControlMetrics is set to a list of
metrics to be computed from a set of values saved in the
usrHistoryTable. Each step of the computation delivers a
singleton per chosen metric. The result may be saved in
the ippmHistoryTable."
INDEX { ippmMeasureControlOwner, ippmMeasureControlIndex }
::= { ippmMeasureControlTable 1 }
IppmStatisticControlEntry ::=
SEQUENCE {
Stephan Informational - Expires December 2001 [Page 31]
Internet Draft IPPM MIB June 2001
ippmStatisticControlHistoryMetric INTEGER,
ippmStatisticControlHistoryOwner OwnerString,
ippmStatisticControlHistoryOwnerIndex INTEGER
}
ippmStatisticControlHistoryMetric OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The reference to the metric value saved in the
ippmHistoryTable."
::= { ippmSamplerControlEntry 1 }
ippmStatisticControlHistoryOwner OBJECT-TYPE
SYNTAX OwnerString
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The reference to the owner of this history."
::= { ippmSamplerControlEntry 2 }
ippmStatisticControlHistoryOwnerIndex OBJECT-TYPE
SYNTAX INTEGER
MAX-ACCESS read-create
STATUS current
DESCRIPTION
"The reference to the owner index of this history."
::= { ippmSamplerControlEntry 3 }
-- Compliance statements
IppmCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which
implement the IPPM MIB"
MODULE -- this module
MANDATORY-GROUPS{ ippmOwnerGroup, ippmSystemGroup,
ippmMeasureGroup, ippmSamplerGroup, ippmStatisticGroup }
::= { ippmCompliances 1 }
END
7. Security Considerations
Stephan Informational - Expires December 2001 [Page 32]
Internet Draft IPPM MIB June 2001
7.1. Privacy
The privacy concerns of network measurement are intrinsically limited
by the active measurements. Unlike passive measurements, there can be
no release of existing user data.
7.2. Measurement aspects
Conducting Internet measurements raises both security and privacy
concerns. This memo does not specify an implementation of the
metrics, so it does not directly affect the security of the Internet
nor of applications which run on the Internet. However,
implementations of these metrics must be mindful of security and
privacy concerns.
There are two types of security concerns: potential harm caused by
the measurements, and potential harm to the measurements. The
measurements could cause harm because they are active, and inject
packets into the network. The measurement parameters MUST be
carefully selected so that the measurements inject trivial amounts of
additional traffic into the networks they measure. If they inject
"too much" traffic, they can skew the results of the measurement, and
in extreme cases cause congestion and denial of service.
The measurements themselves could be harmed by routers giving
measurement traffic a different priority than "normal" traffic, or by
an attacker injecting artificial measurement traffic. If routers can
recognize measurement traffic and treat it separately, the
measurements will not reflect actual user traffic. If an attacker
injects artificial traffic that is accepted as legitimate, the loss
rate will be artificially lowered. Therefore, the measurement
methodologies SHOULD include appropriate techniques to reduce the
probability measurement traffic can be distinguished from "normal"
traffic.
Authentication techniques, such as digital signatures, may be used
where appropriate to guard against injected traffic attacks.
7.3. Management aspects
There are a number of management objects defined in this MIB that
have a MAX-ACCESS clause of read-write and/or read-create. Such
objects may be considered sensitive or vulnerable in some network
environments. The support for SET operations in a non-secure
environment without proper protection can have a negative effect on
network operations.
SNMPv1 by itself is not a secure environment. Even if the network
itself is secure (for example by using IPSec), even then, there is no
Stephan Informational - Expires December 2001 [Page 33]
Internet Draft IPPM MIB June 2001
control as to who on the secure network is allowed to access and
GET/SET (read/change/create/delete) the objects in this MIB.
It is recommended that the implementors consider the security
features as provided by the SNMPv3 framework. Specifically, the use
of the User-based Security Model RFC 2574 [18] and the View-based
Access Control Model RFC 2575 [21] is recommended.
It is then a customer/user responsibility to ensure that the SNMP
entity giving access to an instance of this MIB, is properly
configured to give access to the objects only to those principals
(users) that have legitimate rights to indeed GET or SET
(change/create/delete) them.
8. References
[1] Bradner, S., "The Internet Standards Process -- Revision 3", BCP
9, RFC 2026, October 1996.
[2]Paxson, V., Almes, G., Mahdavi, J. and M. Mathis, "Framework for
IP Performance Metrics", RFC 2330, May 1998.
[3] Mahdavi J. and V. Paxson, "IPPM Metrics for Measuring
Connectivity", RFC 2678, September 1999.
[4] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Delay
Metric for IPPM", RFC 2679, September 1999.
[5] Almes, G., Kalidindi, S. and M. Zekauskas, "A One-way Packet
Loss Metric for IPPM", RFC 2680, September 1999.
[6]Almes, G., Kalidindi, S. and M. Zekauskas, "A Round-trip Delay
Metric for IPPM.", RFC 2681, September 1999.
[7] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for
Describing SNMP Management Frameworks", RFC 2571, April 1999.
[8] Rose, M., and K. McCloghrie, "Structure and Identification of
Management Information for TCP/IP-based Internets", STD 16, RFC
1155, May 1990.
[9] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 16,
RFC 1212, March 1991.
Stephan Informational - Expires December 2001 [Page 34]
Internet Draft IPPM MIB June 2001
[10] M. Rose, "A Convention for Defining Traps for use with the
SNMP", RFC 1215, March 1991.
[11] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., and S. Waldbusser, "Structure of Management Information
Version 2 (SMIv2)", STD 58, RFC 2578, April 1999.
[12] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., and S. Waldbusser, "Textual Conventions for SMIv2", STD 58,
RFC 2579, April 1999.
[13] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M., and S. Waldbusser, "Conformance Statements for SMIv2", STD 58,
RFC 2580, April 1999.
[14] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple
Network Management Protocol", STD 15, RFC 1157, May 1990.
[15] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Introduction to Community-based SNMPv2", RFC 1901, January 1996.
[16] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser,
"Transport Mappings for Version 2 of the Simple Network Management
Protocol (SNMPv2)", RFC 1906, January 1996.
[17]Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message
Processing and Dispatching for the Simple Network Management
Protocol (SNMP)", RFC 2572, April 1999.
[18] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM)
for version 3 of the Simple Network Management Protocol (SNMPv3)",
RFC 2574, April 1999.
[19] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol
Operations for Version 2 of the Simple Network Management Protocol
(SNMPv2)", RFC 1905, January 1996.
[20] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC
2573, April 1999.
[21] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-basedAccess
Control Model (VACM) for the Simple Network Management Protocol
(SNMP)", RFC 2575, April 1999.
[22] Case, J., Mundy, R., Partain, D., and B. Stewart, "Introduction
to Version 3 of the Internet-standard Network Management
Framework", RFC 2570, April 1999.
Stephan Informational - Expires December 2001 [Page 35]
Internet Draft IPPM MIB June 2001
[23] Waldbusser, S., "Remote Network Monitoring MIB", STD 59, RFC
2819, Lucent Technologies, May 2000
[24] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021, International
Network Services, January 1997.
[25] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[26] Remote Network Monitoring MIB Protocol Identifier Reference. A.
Bierman, C. Bucci, R. Iddon. RFC RFC2895 ,August 2000.
[27] Remote Network Monitoring MIB Protocol Identifier Macros. A.
Bierman, C. Bucci, R. Iddon. RFC RFC2896, August 2000.
9. Acknowledgments
A Kerbe.
10. Author's Addresses
Emile STEPHAN
France Telecom R & D
2 avenue Pierre Marzin
F-22307 Lannion cedex
Phone: (+ 33) 2 96 05 11 11
Email: emile.stephan@francetelecom.com
Full Copyright Statement
"Copyright (C) The Internet Society (2001). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist its implementation may be prepared, copied, published and
distributed, in whole or in part, without restriction of any kind,
provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
Stephan Informational - Expires December 2001 [Page 36]
Internet Draft IPPM MIB June 2001
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Stephan Informational - Expires December 2001 [Page 37]