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]