Network Working Group E. Stephan Internet Draft France Telecom R&D Document: draft-stephan-ippm-mib-01.txt January 11, 2002 Category: Informational IPPM 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..........................................3 3. The SNMP Management Framework...............................3 4. Overview....................................................4 4.1. Textual Conventions.........................................5 4.2. Structure of MIB............................................5 4.2.1. The ippmOwner Group.........................................5 Stephan Informational - Expires December 2001 [Page 1] Internet Draft IPPM MIB January 2002 4.2.2. The ippmSystem Group........................................5 4.2.3. The ippmMeasureGroup........................................6 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.......................7 4.5. Resource Sharing Among Multiple Management Stations.........7 4.6. Row Addition Among Multiple Management Stations.............8 5. Conventions used in this document...........................8 5.1. Packet of type P............................................8 5.2. Internet addresses..........................................9 5.3. Owner index namespace.......................................9 6. IPPM-MIB conceptual presentation...........................10 6.1. IPPM-MIB diagram...........................................10 6.2. programming interface......................................11 6.2.1. Measure control............................................11 6.2.2. Result log.................................................11 6.2.3. reporting..................................................11 6.2.4. logical calls..............................................11 6.3. SNMP mapping...............................................11 7. measurement architectures..................................12 7.1. Proxy mode.................................................12 7.2. probe mode.................................................13 7.3. Reporting mode.............................................15 7.4. gateway mode...............................................16 7.5. Security...................................................17 8. Reporting mode integration with the control and test protocols................................................18 8.1. Integration in the IPPM-MIB................................18 8.2. managing the measure setup/teardown in the IPPM-MIB........18 8.3. writing the measure results in the IPPM-MIB................18 8.4. Reporting..................................................19 8.5. Metric measure implementations.............................19 8.5.1. synchronized setup.........................................19 8.5.2. on the fly setup...........................................19 8.6. Alarming...................................................19 8.7. Default value..............................................19 9. Definition.................................................19 10. Security Considerations....................................46 10.1. Privacy.....................................................46 10.2. Measurement aspects.........................................46 10.3. Management aspects..........................................47 11. References.................................................47 12. Acknowledgments............................................49 13. Author's Addresses.........................................50 1. Introduction This memo defines a MIB for managing the measures using the IP performance metrics specified by the IPPM Working Group. Stephan Informational - Expires July 2002 [Page 2] Internet Draft IPPM MIB January 2002 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]. 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, Stephan Informational - Expires July 2002 [Page 3] Internet Draft IPPM MIB January 2002 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 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. Stephan Informational - Expires July 2002 [Page 4] Internet Draft IPPM MIB January 2002 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. 4.2. Structure of MIB The objects are arranged into the following groups: - ippmOwnersGroup - 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. Stephan Informational - Expires July 2002 [Page 5] Internet Draft IPPM MIB January 2002 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 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. Stephan Informational - Expires July 2002 [Page 6] Internet Draft IPPM MIB January 2002 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. 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 administrator can find the management station that owns the resource and negotiate for it to be freed. A network administrator may decide to unilaterally free resources another management station has reserved. Stephan Informational - Expires July 2002 [Page 7] Internet Draft IPPM MIB January 2002 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. 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. Stephan Informational - Expires July 2002 [Page 8] Internet Draft IPPM MIB January 2002 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 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. Owner index namespace The dynamic rows created by an owner are identified in its namespace. An identifier of an instance of an object of is defined as a list of objects in the clause INDEX. An identifier of an owner namespace consists in an list of objects where the first object type is OwnerString. The object identifier part which identify the instance begins with this owner OwnerString value. So the remaining fields value may be chosen independently from a namespace to another. it allows the user to choose values for the remaining fields of the INDEX clause without checking for these fields values existence in the MIB tables. It permits to the owner to use the same fields values across MIBs implementation. It avoids polling to be done to determine the next free index. It avoids that index to be used by another application while it has be determine free. Stephan Informational - Expires July 2002 [Page 9] Internet Draft IPPM MIB January 2002 6. IPPM-MIB conceptual presentation 6.1. IPPM-MIB diagram Conceptual view of objects configured using the IPPM-MIB. +--------------------------------------------------------+ | IPPM-MIB entity | | | | +---------------------+ +-------------------+ | | | | | | | | | Measure scheduler | | Result storage | | | | | | | | | | ^ | | ^ ^^^ | | | | | | | | ||| | | | | | | | | ||| | | | +----------|----------+ +-|---|||-----------+ | | | | ||| | | +----------|--------------|---|||-----------+ | | | | owner | ||| | | | | | Acces | ||| | | | | | Control | ||| | | | | | | ||| | | | +----------|--------------|---|||-----------+ | | | | ||| | +------------------|--------------|---|||----------------+ | | ||| | | ||| +----------------+ | +----------+-+ ||| +-------------+ | ControlMeasure | | | GetResult | ||| | CreateResult| |----------------+-+ |------------| ||+--+-------------| | | | | || | | | owner | | owner | || | owner | | privateNdx | | privateNdx | || | privateNdx | | metrics | | metric | || | metrics | | scheduler | | timestamp | || | timestamp | | addresses | +------------+ || | value | | status | || +-------------+ +----------------+ || || +---------------------------+| | | +---------+---------+ +------+-----------------+ |GetMeasureResults | |GetMeasureMetricResults | |-------------------| |------------------------| | | | | | owner | | owner | | privateNdx | | privateNdx | +-------------------+ | metric | +------------------------+ Stephan Informational - Expires July 2002 [Page 10] Internet Draft IPPM MIB January 2002 The managed objects of the IPPM-MIB are the measures and the results. 6.2. programming interface This section describes a Conceptual programming interface for the integration of the IPPM-MIB in a point of measure. 6.2.1. Measure control A measure is created/deleted/suspended using through the ControlMeasure() call. 6.2.2. Result log A result of a measure is created using a CreateResult() call. Results belong to a measure and are managed internally according to the measure object. 6.2.3. reporting Results are reported using the method GetResult(), GetMeasureMetricResults() and GetMeasureResults() respectively to get a singleton result, the singletons result of a metric measure and finally to get the singletons result of a measure. 6.2.4. logical calls Objects are managed using 5 main primitives: controlMeasure(); CreateResult(); GetResult(); GetMeasureMetricResults(); GetMeasureResults(). 6.3. SNMP mapping ControlMeasure() corresponds to a SNMP set-request on a conceptual row of ippmMeasureControlEntry and on a conceptual row ippmSamplerControlEntry. CreateResult() is a internal interface for adding measure results in the ippmHistoryTable. GetResult() corresponds to a SNMP get-request on a result. GetMeasureMetricResults() corresponds to a SNMP walk on the results of a metric measure subtree. Stephan Informational - Expires July 2002 [Page 11] Internet Draft IPPM MIB January 2002 GetMeasureResults() corresponds to a SNMP walk on the results of a measure subtree. 7. measurement architectures There are four main measurement architectures. 7.1. Proxy mode +----+ +----+ |NMS1| |NMS2| +----+ +----+ ^ ^ | | +----------+ +----------+ | | SNMP or Sibling | | v v +----------------+ |IPPM-MIB entity | +----------------+ ^ ^ | | OWDP-Control | | +----------+ +----------+ | | v v +----------------+ +------------------+ | Packets-Sender |--OWDP-Test-->| Packets-Receiver | +----------------+ +------------------+ In proxy mode the different NMS access the IPPM-MIB entity to query for measurements. The IPPM-MIB controls that the NMS is granted to perform the measure asked. Each NMS access the results of its measurements in the IPPM-MIB statistics table. The measurements setup/teardown and the data collection are done using the control protocol and the test protocol. In this mode the NMS does not depend nor on the control protocol nor on the test protocol. The entities involved in the measure do not need to implement the IPPM-MIB nor SNMP. This mode permits lightweight implementation in the point of measures and heterogeneous control protocols to coexist. Stephan Informational - Expires July 2002 [Page 12] Internet Draft IPPM MIB January 2002 Finally the proxy is a check point where measure activity may be logged and where access to measure setups may be controlled finely. That provide a reliable architecture to manage the security of a measurement system. 7.2. probe mode In this mode the IPPM-MIB is implemented directly in each point of measure. +----+ +----+ |NMS1| |NMS2| +----+ +----+ ^ ^ | | | | SNMP SNMP | | | +------------------------+ | | | +------------------------+ | | | | | | | | | | | | | v v v v +----------------+ +------------------+ |IPPM-MIB entity | |IPPM-MIB entity | +----------------+ +------------------+ | Packets-Sender |--OWDP-Test-->| Packets-Receiver | +----------------+ +------------------+ The measurements setup/teardown are done directly using the SNMP protocol. Each NMS access directly the results of the measurement in the IPPM-MIB statistics group. Each IPPM-MIB controls that the NMS is granted to perform the measure asked. In this mode there is no need for a control protocol while the implementation of the IPPM-MIB and SNMP increases the complexity of the point of measure. It increases the complexity of the probes management because the network manager has to configure all the probes each time there is a Stephan Informational - Expires July 2002 [Page 13] Internet Draft IPPM MIB January 2002 modification in the system of measurement. Stephan Informational - Expires July 2002 [Page 14] Internet Draft IPPM MIB January 2002 7.3. Reporting mode In reporting mode, the protocol SNMP is only used to read the results of the measures in the IPPM-MIB and to inform the NMS that an event has occurs. +----+ +----+ |NMS1| |NMS2| +----+ +----+ ^ ^ ^ ^ | | | | SNMP| SNMP| | | | | | | | | | OWDP | OWDP |Control |Control | | | | | | +------------------------------+ | | | | | | | +--|---------------------------+ | | | | | | | | +--|--|------------------------+ | | | | | | | | | +--------+---------------------+ | | | | | | | | | | | | | | | | | | v v v v v v v v +------------------+ +------------------+ |IPPM-MIB reporting| |IPPM-MIB reporting| | entity | | entity | +------------------+ +------------------+ | Packets-Sender |--OWDP-Test-->| Packets-Receiver | +------------------+ +------------------+ Each NMS consults directly the results of the measurement in the IPPM- MIB statistics table. The configuration of the probe is done using SNMP or another local or remote interface. Typically the activation of a measure by the control protocol creates a measure in the IPPM-MIB table. The results of the measure are logged on the fly in the IPPM-MIB history table. IPPM measures are mostly one way. There are 2 modes for activating a one way measures. The first mode setup both the sender and the receiver. The second mode setup only the sender. In this case the receiver has a daemon which activate the measure on the fly in the receiver point of Stephan Informational - Expires July 2002 [Page 15] Internet Draft IPPM MIB January 2002 measure (typically when an well known port is touched). The integration of the IPPM-MIB with the control and the test protocol is detailed in the section 7. 7.4. gateway mode The gateway mode combines the proxy mode and the reporting mode. +-------+ +------+ | NMS1 | | NMS2 | +-------+ +------+ ^ ^ | | SNMP SNMP | | | +----------------------------------------+ | | | +-------------+ +------------------+ | | | | | +----------------------------------------+ | | | | | | | | | v v | | | | +---------------------+ | | | | | IPPM-MIB scheduler | | | | | | entity | | | | | +---------------------+ | | | | | control server | | | | | +---------------------+ | | | | ^ ^ | | | | | | | | | | OWDP-Control protocol | | | | | | | | | | +-----+ +-------+ | | | | | | | | v v v v v v +---------+---------+ +----------+---------+ |IPPM-MIB | Packets | | Packets |IPPM-MIB | |reporting| Sender | | Receiver |reporting| | entity | |--OWDP-Test-->| | entity | +---------+---------+ +----------+---------+ The NMS measurement queries are registered in the IPPM-MIB scheduler and performed by the control and the test protocol. NMS consult directly the result in the corresponding points of measure. Stephan Informational - Expires July 2002 [Page 16] Internet Draft IPPM MIB January 2002 7.5. Security The proxy mode provides flexibility and a fine control of the access to the points of measure while permitting lightweight control protocol and test protocol implementations in the points of measure. Different security rules may be applied to the NMS domain and to measurement system domain. The probe mode security relies on SNMP security. SNMP provides different levels of security according to the version used and to the option chosen. SNMPv3 provides a high level of security. The reporting mode has 2 security domains. The control of the measures setup relies on the control and the test protocol security mechanisms. The control of the access to the result depends on the SNMP security mechanisms. The gateway mode security relies on the security of the proxy mode and of the reporting mode. Stephan Informational - Expires July 2002 [Page 17] Internet Draft IPPM MIB January 2002 8. Reporting mode integration with the control and test protocols The IPPM-MIB standardizes the parameters for configuring IPPM metrics measures and for reporting the results. It introduces the concept of owner namespace to permit fast configuration and reporting across multiple points of measures. A measure is a distributed object describing a task to be performed by the control and the test protocols. An measure is identified by its owner and its owner index. This identifier is the same in all the points of measure. As it is determine by the owner there is no negotiation needs between the NMS and the points of measure before activating the measure. A measure is mainly defined by its identifier, the metrics to measure, the description of the end points addresses and the description of the scheduling of the measure. A measure is setup by distributing this description of to the points of measure involved. The distribution does not need to be synchronized. 8.1. Integration in the IPPM-MIB Control protocol, test protocol and the IPPM-MIB share the same semantic. The parameters used are sibling. The interoperability between the IPPM-MIB and the test and control protocols relies on the use of the conceptual programming interface described in the section 6. It consists basically in pushing the measure setup/teardown parameters and the results values from the measure software to the IPPM-MIB. 8.2. managing the measure setup/teardown in the IPPM-MIB The creation of the measure consists only in transferring the measure description from the measurement software to the MIB. The protocol used may be the control protocol or the test protocol. The management of the measure is done using the ControlMeasure(). The protocol which provide the parameters of the measure to manage may be the control protocol of the test protocol. The measures created are only readable in the MIB. 8.3. writing the measure results in the IPPM-MIB Results have to be pushed from the measure task to the MIB. Stephan Informational - Expires July 2002 [Page 18] Internet Draft IPPM MIB January 2002 Adding result of a measure consists only in transferring the result from the measurement software to the MIB. The protocol which provides the result may be the control protocol or the test protocol. Writing a result is done using the CreateResult(). The protocol which provide the result of the measure may be the control protocol of the test protocol. 8.4. Reporting The IPPM-MIB is a distributed interface where a an measure is identified by the owner and the owner index. The NMS reads the results of the measure corresponding to the list of (owner,ownerIndex) they are allowed to consult. They can not created derived metrics. 8.5. Metric measure implementations Metric measure implementation depends on the measurement software design and on the metrics itself. 8.5.1. synchronized setup In that case the measure creation is done by the control protocol in IPPM-MIB of the points of measures before the measure is started. 8.5.2. on the fly setup In that case the measure creation is done by the control protocol in IPPM-MIB of the packet sender before the measure is started. The measure creation is done by the control protocol in IPPM-MIB of the packet receiver when the first packet is received. The packet carries the parameters for the measure creation. 8.6. Alarming Not yet specified. 8.7. Default value The default values correspond to Ipv4 best. 9. Definition IPPM-MIB DEFINITIONS ::= BEGIN IMPORTS MODULE-IDENTITY, Stephan Informational - Expires July 2002 [Page 19] Internet Draft IPPM MIB January 2002 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 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 Stephan Informational - Expires July 2002 [Page 20] Internet Draft IPPM MIB January 2002 "(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. 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. Stephan Informational - Expires July 2002 [Page 21] Internet Draft IPPM MIB January 2002 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 { 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 Stephan Informational - Expires July 2002 [Page 22] Internet Draft IPPM MIB January 2002 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); 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 Stephan Informational - Expires July 2002 [Page 23] Internet Draft IPPM MIB January 2002 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 } ippmOwnersGroup OBJECT IDENTIFIER ::= { ippmMib 2 } ippmSystemGroup OBJECT IDENTIFIER ::= { ippmMib 3 } ippmMeasureGroup OBJECT IDENTIFIER ::= { ippmMib 4 } ippmSamplerGroup OBJECT IDENTIFIER ::= { ippmMib 5 } ippmStatisticGroup OBJECT IDENTIFIER ::= { ippmMib 6 } -- -- ippmOwnersGroup -- -- The ippmOwnersControlGroup objects are in charge of the management of the access of the owners to the measurements. . -- -- ippmOwnersControlTable 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 ippmOwnersControlTable using the conceptual row mechanism described in the RMON2. The control of the access to the results of the measures is managed in the table ippmResultControl. " ::= { ippmOwnersGroup 1 } ippmOwnersControlEntry OBJECT-TYPE SYNTAX IppmOwnersControlEntry MAX-ACCESS not-accessible Stephan Informational - Expires July 2002 [Page 24] Internet Draft IPPM MIB January 2002 STATUS current DESCRIPTION "The description of the resources the agent granted to a SNMP application. For example, an instance of ippmOwnersControlEntryOwner with a ownerString 'acme', which represents the 14th owner created in ippmOwnersControlTable would be named ippmOwnersControlEntryOwner.14. Notes: The OwnerAndIndexControlIndex value is a local index managed directly by the agent. It is not used in anyway in the other IPPM tables." INDEX { ippmOwnersControlIndex } ::= { ippmOwnersControlTable 1 } IppmOwnersControlEntry ::= SEQUENCE { ippmOwnersControlIndex INTEGER, ippmOwnersControlGrantedMetrics BITS, ippmOwnersControlGrantedRules BITS, ippmOwnersControlEntryOwner OwnerString } ippmOwnersControlIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-create STATUS current DESCRIPTION "The index of the entry." ::= { ippmOwnersControlEntry 1 } ippmOwnersControlGrantedMetrics OBJECT-TYPE SYNTAX BITS MAX-ACCESS read-create STATUS current DESCRIPTION " Defines the metrics granted to an owner." ::= { ippmOwnersControlEntry 2 } ippmOwnersControlGrantedRules OBJECT-TYPE SYNTAX BITS { all(0), readonly(1), permanent(2), sender(2), receive(3), report(4), Stephan Informational - Expires July 2002 [Page 25] Internet Draft IPPM MIB January 2002 alarm(5) } MAX-ACCESS read-create STATUS current DESCRIPTION "Defines the rules this owner may act as in the current IPPM MIB instance. all(0): The owner is granted with all the rules. readonly(1): The measures (not only the metrics) allowed to this owner are setup by the manager of the point of measure. The owner can not add new measures for these metrics. The creation and the configuration of the measures corresponding to these metrics are managed by the manager of the point of measure. permanent(2): The measures (not only the metrics) allowed to this owner are determined by the manager of the point of measure. The owner can not add new measures for these metrics. The creation and the first configuration of the measures corresponding to these metrics are managed by the manager of the point of measure. The owner may modify the measures parameters of the entries of the corresponding ippmMeasureControlEntry which access is read-write. Typically that permits the owner to suspend the measures, to change the begin and end of the measures. sender(3): The owner may only activate measures for theses metrics that send packets from the current point of measure. This flag is only suitable for network measures. It shall be ignored for derived metrics. receiver(2): The owner may only activate measures for theses metrics that receive packets on the current point of measure. This flag is only suitable for network measures. It shall be ignored for derived metrics. Such control increases the security. The owner may not generate packets from the probe. report(4): The owner may setup derivated metrics on the measures corresponding to these metrics. alarm(5): The owner may setup alarm on the results of the measures metrics. e.g.: if the owner Acme is granted with the metric Instantaneous- Unidirectional-Connectivity as a Receiver in the current point of measure, then Acme can not setup a Instantaneous-Unidirectional- Connectivity to another point of measure. Stephan Informational - Expires July 2002 [Page 26] Internet Draft IPPM MIB January 2002 " DEFVAL { 1 } ::= { ippmOwnersControlEntry 3 } ippmOwnersControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "The status of this table entry." ::= { ippmOwnersControlEntry 3 } ippmOwnersControlEntryOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "Identifies the manager which owns this entry." ::= { ippmOwnersControlEntry 4 } -- -- ippmResultControlTable -- ippmResultControlTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmResultControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION " ippmResultControlTable controls finely the access of an owner to the measure results of other owners. An owner may grant another to read the result of its measure. Entries may exist in ippmResultControlTable even is the measures to be shared are not yet defined. Deleting a measure entry in the ippmMeasureControlTable does not delete the entries corresponding to this measure in the ippmResultControlTable." ::= { ippmOwnersGroup 2 } ippmResultControlEntry OBJECT-TYPE SYNTAX IppmResultControlEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry allows an owner to read the results of a measure owned by another owner. It permits 2 typical usages: Stephan Informational - Expires July 2002 [Page 27] Internet Draft IPPM MIB January 2002 creating derived measurements on these results; reading the results from a remote NMS. Example: if acme.12 is a One-way-Delay(6) measure Acme may allows Peter to make derived metrics On the results of this measure. " INDEX { ippmResultControlOwner, ippmResultControlIndex} ::= { ippmResultControlTable 1 } IppmResultControlEntry ::= SEQUENCE { ippmResultControlOwner OwnerString, ippmResultControlIndex INTEGER, ippmResultControlMeasureOwner OwnerString, ippmResultControlMeasureIndex INTEGER, ippmResultControlGrantedOwner OwnerString, ippmResultControlStatus RowStatus, } ippmResultControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION " The owner of this of this result control row." ::= { ippmResultControlEntry 1 } ippmResultControlIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-create STATUS current DESCRIPTION " The index of this result control row. The value is managed by the owner. On creation a SNMP error 'inconsistentValue' is returned if this value is already in use by this owner." ::= { ippmResultControlEntry 2 } ippmResultControlMeasureOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION "The owner of the measure to be shared. The couple ippmResultControlMeasureOwner, ippmResultControlMeasureIndex identifies absolutely a measure" ::= { ippmResultControlEntry 3 } ippmResultControlMeasureIndex OBJECT-TYPE Stephan Informational - Expires July 2002 [Page 28] Internet Draft IPPM MIB January 2002 SYNTAX INTEGER MAX-ACCESS read-create STATUS current DESCRIPTION "The owner index of the measure to be shared." ::= { ippmResultControlEntry 4 } ippmResultControlGrantedOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-only STATUS current DESCRIPTION "The owner which is granted to access to the result of the measure described by the couple ippmResultControlMeasureOwner, ippmResultControlMeasureIndex." ::= { ippmResultControlEntry 5 } ippmResultControlStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-only STATUS current DESCRIPTION " The status of this table entry. Once the entry status is set to active." ::= { ippmResultControlEntry 6 } -- -- 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 { other(0), NTP(1), GPS(2), CDMA(4), } MAX-ACCESS read-only Stephan Informational - Expires July 2002 [Page 29] Internet Draft IPPM MIB January 2002 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 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 Stephan Informational - Expires July 2002 [Page 30] Internet Draft IPPM MIB January 2002 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 "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 Stephan Informational - Expires July 2002 [Page 31] Internet Draft IPPM MIB January 2002 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 "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: Stephan Informational - Expires July 2002 [Page 32] Internet Draft IPPM MIB January 2002 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 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 } Stephan Informational - Expires July 2002 [Page 33] Internet Draft IPPM MIB January 2002 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 -- -- 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. Stephan Informational - Expires July 2002 [Page 34] Internet Draft IPPM MIB January 2002 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, ippmMeasureControlClockPeriod Integer32, ippmMeasureControlDurationUnit Integer32, ippmMeasureControlDuration Integer32, ippmMeasureControlHystorySize Integer32, ippmMeasureControlStorageType StorageType, ippmMeasureControlOwner OwnerString, ippmMeasureControlStatus RowStatus } ippmMeasureControlIndex OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-create STATUS current DESCRIPTION "The owner index of the measure. The value is managed by the owner. An SNMP error 'inconsistentValue' is returned if this this value is already in use by this owner." ::= { ippmMeasureControlEntry 1 } ippmMeasureControlName OBJECT-TYPE SYNTAX INTEGER MAX-ACCESS read-create 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 { Stephan Informational - Expires July 2002 [Page 35] Internet Draft IPPM MIB January 2002 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), 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." Stephan Informational - Expires July 2002 [Page 36] Internet Draft IPPM MIB January 2002 ::= { 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) } 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) } Stephan Informational - Expires July 2002 [Page 37] Internet Draft IPPM MIB January 2002 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 } ::= { 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 } ippmMeasureControlStorageType OBJECT-TYPE SYNTAX StorageType MAX-ACCESS read-create STATUS current DESCRIPTION "This object defines whether this row and the measure controlled by this row are kept in volatile storage and lost upon reboot or if this row is backed up by non-volatile or permanent storage. Possible values are: other(1), volatile(2), nonVolatile(3), permanent(4), readOnly(5)" DEFVAL { nonVolatile } ::= { ippmMeasureControlEntry 10 } ippmMeasureControlOwner OBJECT-TYPE SYNTAX OwnerString MAX-ACCESS read-create STATUS current DESCRIPTION Stephan Informational - Expires July 2002 [Page 38] Internet Draft IPPM MIB January 2002 "The owner that configured this entry." DEFVAL { "acme" } ::= { ippmMeasureControlEntry 11 } 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 12 } -- -- ippmHistoryTable -- ippmHistoryTable OBJECT-TYPE SYNTAX SEQUENCE OF IppmHistoryEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "A list of measure history entries." ::= { 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. Stephan Informational - Expires July 2002 [Page 39] Internet Draft IPPM MIB January 2002 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, 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 } Stephan Informational - Expires July 2002 [Page 40] Internet Draft IPPM MIB January 2002 -- -- 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 } 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." Stephan Informational - Expires July 2002 [Page 41] Internet Draft IPPM MIB January 2002 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 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 Stephan Informational - Expires July 2002 [Page 42] Internet Draft IPPM MIB January 2002 ::= { 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. 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 Stephan Informational - Expires July 2002 [Page 43] Internet Draft IPPM MIB January 2002 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 -- -- -- -- -- 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 Stephan Informational - Expires July 2002 [Page 44] Internet Draft IPPM MIB January 2002 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 { 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 } Stephan Informational - Expires July 2002 [Page 45] Internet Draft IPPM MIB January 2002 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{ ippmOwnersGroup, ippmSystemGroup, ippmMeasureGroup, ippmSamplerGroup, ippmStatisticGroup } ::= { ippmCompliances 1 } END 10. Security Considerations 10.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. 10.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 Stephan Informational - Expires July 2002 [Page 46] Internet Draft IPPM MIB January 2002 "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. 10.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 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. 11. References Stephan Informational - Expires July 2002 [Page 47] Internet Draft IPPM MIB January 2002 [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. [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. Stephan Informational - Expires July 2002 [Page 48] Internet Draft IPPM MIB January 2002 [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. [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. 12. Acknowledgments A Kerbe. Stephan Informational - Expires July 2002 [Page 49] Internet Draft IPPM MIB January 2002 13. 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. 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 July 2002 [Page 50]