Network Working Group E. Stephan Internet Draft France Telecom R&D Document: draft-stephan-ippm-multicast-metrics-00.txt February 20, 2002 Category: Informational IPPM Multicast metrics measurement 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 set of spatial metrics for measuring the performance of multicast networks and a set of multicast metrics for measuring the performance of multicast services. It introduces a framework to perform operational multicast metrics measurements coupling SNMP and the IPPM-MIB. Table of Contents 1. Introduction................................................3 2. Motivation..................................................3 3. The IPPM Framework..........................................3 4. Spatial hop one way delay metric............................4 4.1. Metric Name.................................................4 4.2. Metric Parameters...........................................4 4.3. Metric Units................................................4 4.4. Definition..................................................5 5. Spatial One way delay stream metric.........................5 5.1. Metric Name.................................................5 Stephan Informational - Expires August 2002 [Page 1] Internet Draft multicast metrics February 2002 5.2. Metric Parameters...........................................5 5.3. Metric Units................................................5 5.4. Definition..................................................5 6. Spatial One way delay metric................................6 6.1. Metric Name.................................................6 6.2. Metric Parameters...........................................6 6.3. Metric Units................................................6 6.4. Definition..................................................6 7. Multicast Instantaneous One-way Delay Stream................6 7.1. Metric Name.................................................6 7.2. Metric Parameters...........................................6 7.3. Metric Units................................................7 7.4. Definition..................................................7 8. Statistics definitions for Multicast instantaneous One way Delay.................................................7 8.1. Type-P-Multicast-Instantaneous-Hop-One-way-Delay............7 8.2. Type-P-Multicast-Instantaneous-One-way-Delay-Percentile.....7 8.3. Type-P-Multicast-Instantaneous-One-way-Delay-Median.........8 8.4. Type-P-Multicast-Instantaneous-One-way-Delay-Inverse Percentile................................................8 9. Multicast Instantaneous Packet Loss Stream..................8 9.1. Metric Name.................................................8 9.2. Metric Parameters...........................................8 9.3. Metric Units................................................8 9.4. Definition..................................................8 10. Statistics definitions for Multicast instantaneous Packet Loss...............................................8 10.1. Type-P-Multicast-Instantaneous-Packet-Loss-Percentile........9 10.2. Type-P-Multicast-Instantaneous-Packet-Loss-Median............9 10.3. Type-P-Multicast-Instantaneous-Packet-Loss-Inverse Percentile................................................9 11. Multicast Instantaneous Connectivity........................9 11.1. Metric Name..................................................9 11.2. Metric Parameters............................................9 11.3. Metric Units.................................................9 11.4. Definition...................................................9 12. Measurement framework......................................10 12.1. Security....................................................12 12.2. Setup of a multicast instantaneous measure..................12 12.3. Definition of a multicast instantaneous report..............12 12.4. Upload of the multicast instantaneous measure result........12 12.5. Multicast and Spatial metrics computation...................13 13. IPPM-CONTROL-MIB Definition................................13 14. Security Considerations....................................17 14.1. Privacy.....................................................17 14.2. Measurement aspects.........................................17 14.3. Management aspects..........................................18 15. References.................................................18 16. Acknowledgments............................................19 17. Author's Addresses.........................................19 Stephan Informational - Expires August 2002 [Page 2] Internet Draft multicast metrics February 2002 1. Introduction The structure of the memo is as follows: + It defines a set of metrics for measuring the performance of multicast networks. The metrics defined rely on the instantaneous metrics specified in the IPPM WG. The next releases of this memo will specify multicast metrics relying on the existing aggregated metrics. The metrics definition are directly inspired by the WG RFC. + It makes a proposal to perform operational multicast measurements using the IPPM-MIB and SNMP messages to control both the setup and the reporting. The SNMP messages are specified using the SMIv2 NOTIFICATION-TYPE. the metrics specified derivate from those standardized by IPPM Working Group. There are built on notions introduced and discussed in the IPPM Framework document, RFC 2330 [2]. There are companion documents to the IPPM MIB both in the Transport Area and in the Operations and Management Area. The reader should be familiar with these documents. 2. Motivation The network performance required for a multicast application depends on its semantics. The main differences with unicast applications is the asymmetrical connectivity and the variable number of sources and receivers. The IPPM WG has designed metrics for measuring the performance of unicast networks. The IPPM framework is applicable for multicast services. Multicast performance metrics are needed for several reasons: + for designing and engineering the multicast trees of the networks; + for accounting multicast services; + for controlling the quality of the multicast services; + for controlling the performance of the inter domain multicast services. 3. The IPPM Framework The IPPM Framework consists in 3 major components: Stephan Informational - Expires August 2002 [Page 3] Internet Draft multicast metrics February 2002 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; 4. Spatial hop one way delay metric The recommendation of the RFC2330 regarding spatial composition of metric are applicable to the definition of a spatial one way delay over a list of clouds. Such a metric is very useful for the computation of inter domain Type-P-One-way-Delay. 4.1. Metric Name Type-P-spatial-hop-one-way-delay 4.2. Metric Parameters + H0, the address of the sender. + Hn, the address of the receiver. + I, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + T0, a time. + T1,..., Tn a list of time. + dT1,..., dTn a list of time. + P, the specification of the packet type. + a path digest. 4.3. Metric Units The unit is the same as the singleton Type-P-One-way-Delay defined in [4]. The value of a Type-P-spatial-hop-One-way-Delay is either a real number, or an undefined (informally, infinite) number of seconds. Stephan Informational - Expires August 2002 [Page 4] Internet Draft multicast metrics February 2002 4.4. Definition Given a Type P packet sent by the source H0 at T0 to Hn in the path , given the sequence of time of arrival of the packets in , a Type-P-spatial-hop-one- way-delay metric is defined for a hop of the path as flowing: For a real number dTi, the Type-P-spatial-hop-One-way-Delay from Hi to Hi+1 at Ti is dTi means that Hi sent the first bit of a Type-P packet to Hi+1 at wire-time Ti and that Hi+1 received the last bit of that packet at wire-time Ti+dTi. 5. Spatial One way delay stream metric 5.1. Metric Name Type-P-spatial-one-way-delay-stream 5.2. Metric Parameters + H0, the address of the sender. + Hn, the address of the receiver. + I, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + T0, a time. + T1,..., Tn a list of time. + dT1,..., dTn a list of time. + P, the specification of the packet type. + a path digest. 5.3. Metric Units A sequence time. 5.4. Definition Given a Type P packet sent by the source H0 at T0 to Hn in the path , given the sequence of time of arrival of the packets in , a Type-P-spatial-one- Stephan Informational - Expires August 2002 [Page 5] Internet Draft multicast metrics February 2002 way-delay-stream metric is defined as the sequence of the Type-P- spatial-hop-one-way-delay values 6. Spatial One way delay metric 6.1. Metric Name Type-P-spatial-one-way-delay 6.2. Metric Parameters + H0, the address of the sender. + Hn, the address of the receiver. + I, An integer which ordered the hosts in the path. + Hi, exchange points of the path digest. + T0, a time. + T1,..., Tn a list of time. + dT1,..., dTn a list of time. + P, the specification of the packet type. + a path digest. 6.3. Metric Units A time. 6.4. Definition Given a Type P packet sent by the source H0 at T0 to Hn in the path , given a Type-P-spatial-one-way-delay-stream metric value, a Type-P-spatial-one-way-delay metric is defined as the sum of each term of the Type-P-spatial-one-way-delay-stream. 7. Multicast Instantaneous One-way Delay Stream 7.1. Metric Name Type-P-Multicast-Instantaneous-One-way-Delay-Stream 7.2. Metric Parameters + Src, the IP address of a host acting as the source. Stephan Informational - Expires August 2002 [Page 6] Internet Draft multicast metrics February 2002 + Recv1,..., RecvN, the IP addresses of the N hosts acting as receivers. + T0, a time. + dT1,...,dTn a list of time. + P, the specification of the packet type. + D0, a distance (e.g.: the number of hop). + dD1,...,dDn a list of distance. 7.3. Metric Units The value of a Type-P-Multicast-Instantaneous-One-way-Delay-Stream is a set of singletons metrics Type-P-One-way-Delay [4]. 7.4. Definition Given a Type P packet sent by the source Src at T0, given the N hosts { Recv1,...,RecvN } which are located at the distance { D0- dD1,...,D0-dDn } from Src and receive the packet at the time { T0+dT1,...,T0+dTn }, a Type-P-Multicast-Instantaneous-One-way-Delay- Stream is defined as the set of the Type-P-One-way-Delay singleton between Src and each receiver { dT1, dT2,...,dTn }. 8. Statistics definitions for Multicast instantaneous One-way Delay This section was largely written by copying material from section "5. Some Statistics Definitions for One-way Delay" of the RFC2679. Statistics among the set (or a subset) of the receivers are useful when the delay is crucial for the multicast application. 8.1. Type-P-Multicast-Instantaneous-Hop-One-way-Delay Given a Type-P-Multicast-Instantaneous-One-way-Delay-Stream, the Type-P-Multicast-Instantaneous-Hop-One-way-Delay metric is defined as the average of all the delay per hop values (dDi/dTi) in the stream. 8.2. Type-P-Multicast-Instantaneous-One-way-Delay-Percentile Given a Type-P-Multicast-Instantaneous-One-way-Delay-Stream and a percent X between 0% and 100%, the Type-P-Multicast-Instantaneous- One-way-Delay-Percentile metric is defined as the Xth percentile of all the dT values in the stream. Stephan Informational - Expires August 2002 [Page 7] Internet Draft multicast metrics February 2002 8.3. Type-P-Multicast-Instantaneous-One-way-Delay-Median Given a Type-P-Multicast-Instantaneous-One-way-Delay-Stream, the Type-P-Multicast-Instantaneous-One-way-Delay-Median metric is defined as the median of all the dT values in the Stream. 8.4. Type-P-Multicast-Instantaneous-One-way-Delay-Inverse-Percentile Given a Type-P-Multicast-Instantaneous-One-way-Delay-Stream and a time duration threshold, the Type-P-Multicast-Instantaneous-One-way- Delay-Inverse-Percentile metric is defined as the fraction of all the dT values in the stream less than or equal to the threshold. 9. Multicast Instantaneous Packet Loss Stream 9.1. Metric Name Type-P-Multicast-Instantaneous-Packet-Loss-Stream 9.2. Metric Parameters + Src, the IP address of a host acting as the source. + Recv1,..., RecvN, the IP addresses of the N hosts acting as receivers. + T0, a time. + T1,...,Tn + P, the specification of the packet type. 9.3. Metric Units The value of a Type-P-Multicast-Instantaneous-Packet-Loss-Stream is a set of singletons metrics Type-P-One-way-Packet-Loss [6]. 9.4. Definition Given a Type P packet sent by the source Src at T0 and Recv1,...,RecvN the N hosts which should receive the packet at T1,...,Tn a Type-P-Multicast-Instantaneous-Packet-Loss-Stream is defined as the set of the Type-P-One-way-Packet-Loss singleton between Src and each of the receivers {,,...,}. 10. Statistics definitions for Multicast instantaneous Packet Loss Stephan Informational - Expires August 2002 [Page 8] Internet Draft multicast metrics February 2002 This section was largely written by copying material from the section "4. Some Statistics Definitions for One-way Packet Loss" of the RFC2680. 10.1. Type-P-Multicast-Instantaneous-Packet-Loss-Percentile Given a Type-P-Multicast-Instantaneous-Packet-Loss-Stream and a percent X between 0% and 100%, the Type-P-Multicast-Instantaneous- Packet-Loss-Percentile metric is defined as the Xth percentile of all the singleton values in the stream. 10.2. Type-P-Multicast-Instantaneous-Packet-Loss-Median Given a Type-P-Multicast-Instantaneous-Packet-Loss-Stream, the Type-P-Multicast-Instantaneous-Packet-Loss-Median metric is defined as the median of all the singleton values in the Stream. 10.3. Type-P-Multicast-Instantaneous-Packet-Loss-Inverse-Percentile Given a Type-P-Multicast-Instantaneous-Packet-Loss-Stream and a time duration threshold, the Type-P-Multicast-Instantaneous-Packet- Loss-Inverse-Percentile metric is defined as the fraction of all the singleton values in the stream less than or equal to the threshold. 11. Multicast Instantaneous Connectivity 11.1. Metric Name Type-P-Multicast-Instantaneous-Connectivity 11.2. Metric Parameters + Src, the address of a host acting as the source. + Node, the address of a router acting as a multicast repeater. + P, the specification of the packet type. 11.3. Metric Units An integer. 11.4. Definition Given a Type P packet sent by the multicast source Src at T0 and Node a router acting as a multicast repeater, a Type-P-Multicast- Instantaneous-Node-Connectivity is defined as the number of time the packet P is repeated by this node. Stephan Informational - Expires August 2002 [Page 9] Internet Draft multicast metrics February 2002 This metric is useful to consolidate inter domain spatial metrics. It determines the number of branches a node have. 12. Measurement framework Using unicast to establish a multicast measure among a source and a huge number of receivers is not scalable mainly because of the bandwidth consumption of the setup, the duration of the setup and the bandwidth needed to polling the result. To scale with the number of receivers the setup of the measure is done using a message which is sent by the 'multicast' source to the multicast receivers in the multicast flow. The message is specify using the SMIv2 NOTIFICATION-TYPE. It is send by the source in the data flow. The message is a SNMP Trap which is sent to the standard UDP port (162). The framework is usable to get the number of active receivers per branch of the multicast tree. The routers (or sibling) have 'just' to detect the setup messages and to send the current number of multicast branches (existing somewhere in a MIB) and the time of the measure. The consolidation is intrinsic because the setup packet is of the same typeP as the other packets of the stream. It acts as the test packet and use the same path as the multicast packets. The multicast channel may be a group specialized for the measures. Then the number of active branches reported are those corresponding to the source address of the setup. The IPPM-MIB implementation in the receivers and in the intermediary systems may be very very light. The implementation of the IPPM-MIB tables may be virtual. There in no need to record the results. The identification of the measure relies on the owner namespace defined in the IPPM-MIB. It consists only in two tasks: + Capturing the setup and its arrival time; + Sending the results in a SNMP Inform PDU to the NMS described in the setup or to the default one of its the configuration. Partial spatial metrics are computed in each provider IPPM-MIB proxy entity. The broadcaster consults these values to complete the computation of the spatial metrics results. Stephan Informational - Expires August 2002 [Page 10] Internet Draft multicast metrics February 2002 6.1. Inter domain architecture +----------------+ +----------------+ +----------------+ | NMS | | NMS | | NMS | | Provider Foo | |Broadcaster Acme| | Provider Bar | +----------------+ +----------------+ +----------------+ ^ ^ ^ ^ ^ | | | | | | | | | | | | | | | SNMP or Sibling SNMP or Sibling SNMP or Sibling | | | | | | | | | | | | | | | | +------------------+ | +-------------+ | | | | | | | | | | | v v v v v +----------------+ +----------------+ +----------------+ |IPPM-MIB proxy | | mcast-Source | |IPPM-MIB proxy | | Provider Foo | |Broadcaster Acme| | Provider Bar | +----------------+ +----------------+ +----------------+ ^^^ ^ | ^ ^^^ ||| | | | ||| ||| | | | ||| SNMP inform PDU SNMP Trap SNMP inform PDU result mcast-setup result ||| | | | ||| ||| | | | ||| ||| | | | ||| ||| | +------------------+ | ||| ||| +----| mcast-Repeater | | ||| ||| |IPPM-MIB reporting|+ | ||| ||| +------------------+|+ | ||| ||| +------------------+|-----+ ||| ||| +------------------+ ||| ||| | | ||| ||| | | ||| ||| +--------+ +------------+ ||| ||| | | ||| ||| v v ||| +------------------+ +------------------+ | mcast-Receiver | | mcast-Receiver | |IPPM-MIB reporting|+ |IPPM-MIB reporting|+ +------------------+|+ +------------------+|+ +------------------+| +------------------+| +------------------+ +------------------+ Stephan Informational - Expires August 2002 [Page 11] Internet Draft multicast metrics February 2002 In this architecture the Broadcaster send measure setups in the multicast channel and access its providers IPPM-MIB proxies to get the spatial metrics results per domain and to perform results concatenations. It means that the broadcaster have been previously granted to setup a measure and to access to the results of the measure. 12.1. Security The proxy mode provides flexibility and a fine control of the access to the points of measure while permitting lightweight implementations in the points of measure. Different security rules may be applied to the NMS domain and to measurement system domain. SNMP provides different levels of security according to the version used and to the option chosen. SNMPv3 provides a high level of security. A public key may be added both in the ippmMulticastInstantaneousMeasureSetup and in the ippmMulticastInstantaneousMeasureSetup messages to clearly identify the measure. 12.2. Setup of a multicast instantaneous measure The creation of the measure consists in sending the ippmMulticastInstantaneousMeasureSetup message in the multicast channel using a SNMP trap. The NOTIFICATION-TYPE ippmMulticastInstantaneousMeasureSetup is defined in the IPPM-CONTROL-MIB. It setups the measurement of the following singletons directly on the message setup: Type-P-One-way-Delay, Type-P-One-way-Packet-Loss, Type-P-Multicast-Instantaneous-Connectivity, (*) Type-P-spatial-hop-one-way-delay (*) * only applicable for routers. 12.3. Definition of a multicast instantaneous report The definition of the report is included of the definition of the ippmMulticastInstantaneousMeasureSetup. 12.4. Upload of the multicast instantaneous measure result The results of the measure are pushed on the fly by each points of measure to the NMS choosen using the Stephan Informational - Expires August 2002 [Page 12] Internet Draft multicast metrics February 2002 ippmMulticastInstantaneousMeasureReport message sentin a SNMP Inform PDU. The NOTIFICATION-TYPE ippmMulticastInstantaneousMeasureReport is defined in the IPPM-CONTROL-MIB. Note: The results are not pushed in the multicast channel. 12.5. Multicast and Spatial metrics computation The results are pushed to the IPPM-MIB proxy of provider and are usable to compute multicast metric measure and spatial metrics measure defined above. 13. IPPM-CONTROL-MIB Definition IPPM-CONTROL-MIB DEFINITIONS ::= BEGIN IMPORTS IppmMib, InstantaneousUnidirectionalConnectivity, InstantaneousBidirectionalConnectivity, intervalUnidirectionalConnectivity , intervalBidirectionalConnectivity, intervalTemporalConnectivity, onewayDelay, onewayDelayPoissonStream, onewayDelayPercentile, onewayDelayMedian, onewayDelayMinimum, onewayDelayInversePercentile, onewayPacketLoss, onewayPacketLossPoissonStream, onewayPacketLossAverage, roundtripDelay, roundtripDelayPoissonStream, roundtripDelayPercentile, roundtripDelayMedian, roundtripDelayMinimum, roundtripDelayInversePercentile FROM IPPM-MIB MODULE-IDENTITY, NOTIFICATION-TYPE, OBJECT-TYPE, Integer32, Counter32, experimental FROM SNMPv2-SMI OwnerString FROM RMON-MIB protocolDir FROM RMON2-MIB Stephan Informational - Expires August 2002 [Page 13] Internet Draft multicast metrics February 2002 DisplayString, TimeStamp, DateAndTime, TruthValue, RowStatus, StorageType, TEXTUAL-CONVENTION FROM SNMPv2-TC MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP FROM SNMPv2-CONF; ippmControlMib MODULE-IDENTITY LAST-UPDATED "200202111200Z" -- Feb 21, 2002 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 a set of NOTIFICATION-TYPE used to control IPPM metrics measures, pushing alarms and reporting the measures results. -- -- to be assigned by IANA -- ::= { experimental 10001 } -- -- IPPM multicast messages for the setup of the measure -- and the reporting of the result. -- ippmMulticastInstantaneousMeasureSetup NOTIFICATION-TYPE OBJECTS { -- measure setup ippmMeasureOwner, ippmMeasureIndex, -- Network measure setup ippmNetworkMeasureSrcTypeP, Stephan Informational - Expires August 2002 [Page 14] Internet Draft multicast metrics February 2002 ippmNetworkMeasureSrc, ippmNetworkMeasureDstTypeP, ippmNetworkMeasureDst, ippmNetworkMeasureTimeoutDelay, -- report setup ippmReportSetupNMS, } STATUS current DESCRIPTION "The definition of the setup of an instantaneous multicast measure is sent by the broadcasting application or the probe in the multicast channel using a SNMP trap defined in this NOTIFICATION-TYPE. On reception of the ippmMulticastInstantaneousMeasureSetup setup the receiver or the router: + timestamp the arrival time of the setup; + considers the following defaults values; + prepare the ippmMulticastInstantaneousMeasureReport notification; + send the report using a SNMP Inform PDU. Defaults values: IppmMeasureEntry default values: ippmMeasureName: ippmMulticastInstantaneousMeasure; ippmMeasureMetrics: { Type-P-One-way-Delay, Type-P-One-way-Packet-Loss, Type-P-Multicast-Instantaneous-Connectivity, (*) Type-P-spatial-hop-one-way-delay (*) } ippmMeasureBeginTime: 0 ippmMeasureClockPeriodUnit: 0 ippmMeasureClockPeriod: 0 ippmMeasureDurationUnit: 0 ippmMeasureDuration: 0 ippmMeasureHystorySize: 0 ippmMeasureStorageType: other ippmMeasureStatus: createAndGo IppmNetworkMeasureEntry default values: IppmNetworkMeasureClockPattern: 0 Stephan Informational - Expires August 2002 [Page 15] Internet Draft multicast metrics February 2002 IppmNetworkMeasureTimeoutDelay: 0 ippmNetworkMeasureL3PacketSize: 0 ippmNetworkMeasureDataPattern: 0 IppmippmReportSetupEntry default values: IppmReportSetupDefinition: { onSingleton, inInformRequestPDU, clearHistory } ippmReportSetupMetricThreshold: 0 ippmReportSetupEventsDurationThreshold: 0 (*) only considered by routers. " ::= { ippmControlMib 1 } ippmMulticastInstantaneousMeasureReport NOTIFICATION-TYPE -- measure setup ippmMeasureOwner, ippmMeasureIndex, -- Network measure setup ippmNetworkMeasureSrcTypeP, ippmNetworkMeasureSrc, ippmNetworkMeasureDstTypeP, ippmNetworkMeasureDst, -- report of the measure -- timestamp ippmHistoryTimeMark, -- value of the Type-P-One-way-Delay ippmHistoryValue, -- value of the Type-P-One-way-Packet-Loss ippmHistoryValue, -- value of the -- Type-P-Multicast-Instantaneous-Connectivity (*) ippmHistoryValue, -- value of the Type-P-spatial-hop-one-way-delay (*) ippmHistoryValue } Stephan Informational - Expires August 2002 [Page 16] Internet Draft multicast metrics February 2002 STATUS current DESCRIPTION "This NOTIFICATION-TYPE is used by the receiver or the router to push the result of the measure performed according the ippmMulticastInstantaneousMeasureSetup setup. (*) is only applicable for router. { comment: This report definition has to be split to get one for receiver and one for router.} Note: An ippmHistoryValue is indexed using the owner, the owner index, the metric index and the timestamp (e.g.: acme.1.6.0106150820100100). So the metric index identifies which metric result (One-way-Delay, Packet- Loss, Connectivity) the ippmHistoryValue carries." ::= { ippmControlMib 2 } END 14. Security Considerations Since this draft proposes sample metrics based on the One-way Delay singleton metric defined in RFC2679 and RFC2680 it inherits the security considerations mentioned in this RFC. 14.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. 14.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 Stephan Informational - Expires August 2002 [Page 17] Internet Draft multicast metrics February 2002 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. 14.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. 15. References Stephan Informational - Expires August 2002 [Page 18] Internet Draft multicast metrics February 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. 16. Acknowledgments A Kerbe. 17. 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 August 2002 [Page 19] Internet Draft multicast metrics February 2002 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 August 2002 [Page 20]