Network Working Group E. Stephan Internet-Draft V. Barriac Intended status: Best Current France Telecom RD Practice March 4, 2007 Expires: September 5, 2007 IP Performance Metrics (IPPM) reporting registry draft-stephan-ippm-reporting-registry-01 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. 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. This Internet-Draft will expire on September 5, 2007. Copyright Notice Copyright (C) The IETF Trust (2007). Stephan & Barriac Expires September 5, 2007 [Page 1] Internet-Draft IPPM Reporting Registry March 2007 Abstract The intend of this memo is to set up an IANA registry that collects best current practices in terms of reporting IP Performance Metrics (IPPM) measurements for composition, to users and to end-users. It proposes default values for well known usages and focuses on the identification of the information that should be reported to increase interoperabilty between standard metrics measurements and to facilitate the exchange of measurements results through measurement applications. Stephan & Barriac Expires September 5, 2007 [Page 2] Internet-Draft IPPM Reporting Registry March 2007 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . 6 3. Presentation of the registry . . . . . . . . . . . . . . . . . 7 3.1. Registry . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Initial version of the registry . . . . . . . . . . . . . 7 3.3. Metrics classification part . . . . . . . . . . . . . . . 7 3.4. Info model part . . . . . . . . . . . . . . . . . . . . . 8 3.4.1. data type . . . . . . . . . . . . . . . . . . . . . . 8 3.5. Reporting rules and parameters . . . . . . . . . . . . . . 8 3.5.1. Reporting for composition part . . . . . . . . . . . . 8 3.5.2. Reporting for users and end-users part . . . . . . . . 9 4. End-user metrics to register . . . . . . . . . . . . . . . . . 10 4.1. traceroute . . . . . . . . . . . . . . . . . . . . . . . . 10 4.2. metric to measure VoIP quality . . . . . . . . . . . . . . 10 4.2.1. ituTrFactorEmodel . . . . . . . . . . . . . . . . . . 10 4.2.2. itutMosLqon . . . . . . . . . . . . . . . . . . . . . 10 4.3. Discussion on End user metrics registration . . . . . . . 11 5. IPPM Reporting Registry . . . . . . . . . . . . . . . . . . . 12 5.1. Metrics classification . . . . . . . . . . . . . . . . . . 12 5.1.1. Metrics measurement methods . . . . . . . . . . . . . 14 5.2. raw measure Metrics . . . . . . . . . . . . . . . . . . . 14 5.3. collection metrics . . . . . . . . . . . . . . . . . . . . 14 5.4. Metrics for compositions . . . . . . . . . . . . . . . . . 15 5.4.1. ietfCompOneWayDelayMedian . . . . . . . . . . . . . . 15 5.5. Users metrics applications . . . . . . . . . . . . . . . . 16 5.6. Users metrics applications and End-user metrics . . . . . 16 5.6.1. ietfOneWayDelayMedian applications . . . . . . . . . . 16 5.6.2. ietfOneWayPktLossAverage applications . . . . . . . . 17 5.6.3. ituTmosPESQ . . . . . . . . . . . . . . . . . . . . . 17 5.6.4. ituTrFactorEmodel . . . . . . . . . . . . . . . . . . 17 6. Info Model . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.1. Fields . . . . . . . . . . . . . . . . . . . . . . . . . . 18 6.2. data type . . . . . . . . . . . . . . . . . . . . . . . . 18 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 7.1. Management rules of the IPPM REPORTING REGISTRY . . . . . 19 7.2. End users metrics to register in IANA-IPPM-METRICS-REGISTRY . . . . . . . . . . . . . . . . 19 8. Security Considerations . . . . . . . . . . . . . . . . . . . 20 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21 9.1. Normative References . . . . . . . . . . . . . . . . . . . 21 9.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 23 Intellectual Property and Copyright Statements . . . . . . . . . . 24 Stephan & Barriac Expires September 5, 2007 [Page 3] Internet-Draft IPPM Reporting Registry March 2007 1. Introduction The IPPM WG is working on numerous topics such as the definition of composition of metrics [I-D.ietf-ippm-spatial-composition] and a composition framework [I-D.ietf-ippm-framework-compagg] ; the selection of metrics and parameters for reporting IP Performance metrics to users and end users [I-D.ietf-ippm-reporting],[I-D.shalunov-ippm-reporting] and [I-D.morton-ippm-reporting-metrics]; the storage of an end-user metric not defined by the IPPM WG [I-D.niccolini-ippm-storetraceroutes]. The intend of this memo is to set up an IANA registry that collects best current practices in terms of reporting IP Performance Metrics (IPPM) measurements for composition, to users and to end-users. It proposes default values for well known usages and focuses on the identification of the information that should be reported to increase the usability of standard metrics measurements results by users measurement applications. This memo focuses on the usage so interoperability between measurement systems or probes is out of the scope. The word 'user' means 2 things: someone or some application who is external to the measure and doesn't have access to implicit information which disapears after the measure; someone or some application who is not a specialist of the measurement but of the usage of the results. Such a registry will facilitate the WG activity because working on one metric application will not preclude to work later on other applications of the same metric and on application of metrics being currently defined in the future. As an example defining a default packet size for general usage will not preclude to add later a default packet size for a general application. The content of the reporting registry provides relevant information such as metrics applicability, default values for a metric, default values for a specific application. These pieces of informations are are minor points for IPPM gurus but are still mysterious for other experts, users and obvioulsy end-users. Each metric application described in the registry gives best current practice in terms of default values and reporting of parameters and results and may include a default info model human readable and machine readable. This memo firstly motivates the need of a IPPM reporting registry, Stephan & Barriac Expires September 5, 2007 [Page 4] Internet-Draft IPPM Reporting Registry March 2007 then it introduces the differents part of the reporting registry. Section 4 presents end-users metrics to register in the IANA-IPPM- METRICS-REGISTRY. Section 5 provides the initial version of the IPPM reporting registry. The management of the registry is described is the 'IANA considerations' section. Stephan & Barriac Expires September 5, 2007 [Page 5] Internet-Draft IPPM Reporting Registry March 2007 2. Motivation The IPPM WG has defined 45 metrics including [RFC4737]. They are based on [RFC2330] methodology. Definitions clearly distinguish raw measure (singleton), from set of measures over a period a time (streams) and from statistics. To go further in reporting metrics it is necessary to classify each metric in terms of applicability. This point is presented in section 3.2 and a first classification is given in section 5.1 for 'composition', 'user' and 'end user' metrics. As a metric does not belong exclusively to one category, the classification may be enhanced over time. A metric based on RFC2330 defines a mathematic model for measuring network behavior aspects which may have several valid practical methods. This memo identifies these metrics and gives the list of the current methods in use.This list will be complimented over time. Metrics based on RFC2330 don't provide common use cases. Consequently parameters default values of they parameters are not clearly identified. This memo proposes default values per categories of current usages. This list will be complimented over time. Composition of metrics intrinsically relies on collection of results performed by remote measurement systems and requires the share of the set of metrics that may be combined and the share of parameters that should be exchange. This point is discussed in section 3.4 and sets of metrics that may be combined are given in section 5.4. Reporting metrics measurement results to users require the identification of a set of metrics that may be reported and requires the definition of the parameters and of the results that should reported. This point is discussed in section 3.4 and sets of metrics that may be reported to user are given in section 5.5. Reporting metrics measurement results to end-users require the identification of a set of metrics easy to understand and relevant to end-user applications. This point is discussed in section 3.4 and a first specification metrics that may be reported to end-users are given in section 5.6. Reporting implicitly leads to exchange information. So the need of a common and protocol neutral info model is discuted in section 3.3. Stephan & Barriac Expires September 5, 2007 [Page 6] Internet-Draft IPPM Reporting Registry March 2007 3. Presentation of the registry The registry is designed to collect best current practice in terms of reporting metric application. Application may the domain of applicability of a metrics like raw measure or a real application like VoIP. this approach permits to define metric reporting parameters at a global level (i.e any Type-P) or/and for a dedicaced application (i.e. VoIP) without having any collision in the best practices registered. A default metric application gives the default values as per [I-D.ietf-ippm-reporting]. The registration of the reporting of a metric application (sections 2, 3 of the registry) includes the description of configurations and results information. It may look like section ' 5.2.1. Configuration Information Elements' and section ' 5.2.2. Results Information Elements' of[I-D.niccolini-ippm-storetraceroutes]. 3.1. Registry The registry is designed to be supplemented in the future with default values and parameters of new metric applications. Registrations are done by IANA on the bases of 'Specification Required' as defined in [RFC2434]. 3.2. Initial version of the registry It is in the spirit of this registry to limit the number of initial metric applications. So it focuses on 6 metrics usages like [I-D.ietf-ippm-reporting] but not on the same: Composition of metrics to compute an ietfCompOneWayDelayMedian metric; Composition of metrics to compute an ietfOneWayPktLossAverage metric; Default values for the usage of ietfOneWayDelayMedian for VoIP; Default values for the usage of ietfOneWayPktLossAverage for VoIP; Usage of VoIP ground-truth End-user metrics: MOS and R-Factor. 3.3. Metrics classification part This part classifies metrics in terms of application. the criteria are 'raw measure', 'collection', 'network expert', 'user', 'composition' and 'end-user'. A metric may belong to several criteria. The usage fo each metrics is then described per criteria. Stephan & Barriac Expires September 5, 2007 [Page 7] Internet-Draft IPPM Reporting Registry March 2007 3.4. Info model part The info model part of the registry defines the information to report per metric application. The info model of composition of metrics must be machine readable to help machine-to-machine reporting using NSIS WG model implementation or PSAMP WG passive measurement with IPFIX protocols... The info model of user and end-users metrics must intrinsically be human readable. Furthermore it must be machine readable to facilitate the reporting with technics like Web service. The best way to help machine-to-machine communication consists in defining the information in a protocol neutral langage like XML. 3.4.1. data type Atomic informations to report correspond to parameters described in IPPM metrics definitions. The data part of the registry defines a flat list of data type corresponding to parameters described in IPPM metrics definitions. A data type is defined as per section 5.1 of [I-D.niccolini-ippm-storetraceroutes] and may reuse data types already defined in [I-D.ietf-ipfix-info] and in [I-D.ietf-psamp-info]. 3.5. Reporting rules and parameters The report of parameters and results is defined per metric application i.e. in the composition part, in the user part or in the end-user part of the registry. To help machine-to-machine communication the definition parameters and results may be defined in a XML schema as per section "6. Data Model for Storing Traceroute Measurements" of [I-D.niccolini-ippm-storetraceroutes] . 3.5.1. Reporting for composition part This part of the registry identifies sets of metrics that may be composed. Then it gives the parameters and the results for reporting metrics per metric. Stephan & Barriac Expires September 5, 2007 [Page 8] Internet-Draft IPPM Reporting Registry March 2007 3.5.2. Reporting for users and end-users part This part of the registry gives per user metric the parameters and the results to report for each relevant metrics and application. This part of the registry the parameters and the results to report per user and end-user metric. Stephan & Barriac Expires September 5, 2007 [Page 9] Internet-Draft IPPM Reporting Registry March 2007 4. End-user metrics to register This section presents several well-known metrics that must be registered in the IANA-IPPM-METRICS-REGISTRY because they are intensively used by end-users to monitor the behavior and the performance of the network or of their application. The request of registration is given in 'IANA Considerations' section. 4.1. traceroute As IPPM WG is defining the storage of traceroute measurement results in [I-D.niccolini-ippm-storetraceroutes] the metric traceroute must be registered in the IANA IPPM METRICS REGISTRY. Furthermore the section 5 of this draft gives the information elements for the configuration and for the result of traceroute measurement. These informations elements should be used in the registry for describing the report of a traceroute to end-user. 4.2. metric to measure VoIP quality 4.2.1. ituTrFactorEmodel The R Factor is the output of the E-model planning tool defined in ITU-T G.107.Its value is ranged between 0 and 100. Based on the individual values of several transmission parameters (given by measurements or by default values), it permits an estimation of the end-to-end transmission quality of voice calls as perceived by end- users. Depending on the fact that delay and echo are taken into account or not in the computation, the E-model R factors can be translated into MOS-CQEN or MOS-LQEN (according to ITU-T P.800.1 terminology). 4.2.2. itutMosLqon PESQ (perceptual evaluation of speech quality) is the trademark name Associated with ITU-T P.862. This psychoacoustical (i.e. based on the analysis of speech signal characteristics) intrusive (i.e. needing the sending of a reference signal) model, associated with the mapping function defined in ITU-T P.862.1, allows the determination of MOS-LQON scores(according to ITU-T P.800.1 terminology), which is a metric very well correlated with human perception of end-to-end quality of voice calls. Alternative ways for the determination of MOS-LQON scores are ITU-T standard P.563 and P.564, based on non-intrusive (i.e. passive) measures, respectively on speech signal and RTP/UDP/IP packets Stephan & Barriac Expires September 5, 2007 [Page 10] Internet-Draft IPPM Reporting Registry March 2007 information. 4.3. Discussion on End user metrics registration Metrics measuring VoIP quality are orthogonale to IPPM metrics because the mesure include not only codecs but give a quality as perceived by an end-user. At large registering ITU-T metrics close to IPPM ones would help to distinguish measurement made using different methodology. Stephan & Barriac Expires September 5, 2007 [Page 11] Internet-Draft IPPM Reporting Registry March 2007 5. IPPM Reporting Registry This section defines the initial version of the registry to be maintained by IANA. 5.1. Metrics classification Following is a table of the classification of each metric according to its applicability. Editor note: all the metric are not present. Do we need a 'estimation' category ? 'ID' is the number IANA assigned to the metric. 'Name' is the name the editor of the RFC assigned to the metric. ID Name Application --- --------------------------------- ------------- 0 default unknown 1 ietfInstantUnidirConnectivity raw measure 2 ietfInstantBidirConnectivity raw measure 3 ietfIntervalUnidirConnectivity network expert 4 ietfIntervalBidirConnectivity network expert 5 ietfIntervalTemporalConnectivity user,composition 6 ietfOneWayDelay raw measure 7 ietfOneWayDelayPoissonStream collection 8 ietfOneWayDelayPercentile network expert 9 ietfOneWayDelayMedian user,composition 10 ietfOneWayDelayMinimum user,composition 11 ietfOneWayDelayInversePercentile network expert 12 ietfOneWayPktLoss raw measure 13 ietfOneWayPktLossPoissonStream collection 14 ietfOneWayPktLossAverage user, composition 15 ietfRoundTripDelay raw measure 16 ietfRoundTripDelayPoissonStream collection 17 ietfRoundTripDelayPercentile network expert 18 ietfRoundTripDelayMedian user,composition 19 ietfRoundTripDelayMinimum user,composition 20 ietfRoundTripDelayInvPercentile network expert 21 ietfOneWayLossDistanceStream collection 22 ietfOneWayLossPeriodStream collection 23 ietfOneWayLossNoticeableRate network expert 24 ietfOneWayLossPeriodTotal network expert 25 ietfOneWayLossPeriodLengths network expert 26 ietfOneWayInterLossPeriodLengths network expert 27 ietfOneWayIpdv raw measure 28 ietfOneWayIpdvPoissonStream collection Stephan & Barriac Expires September 5, 2007 [Page 12] Internet-Draft IPPM Reporting Registry March 2007 29 ietfOneWayIpdvPercentile user,composition 30 ietfOneWayIpdvInversePercentile network expert 31 ietfOneWayIpdvJitter raw measure 32 ietfOneWayPeakToPeakIpdv network expert 33 ietfOneWayDelayPeriodicStream collection 34 ietfReorderedSingleton raw measure 35 ietfReorderedPacketRatio network expert 36 ietfReorderingExtent network expert 37 ietfReorderingLateTimeOffset network expert 38 ietfReorderingByteOffset network expert 39 ietfReorderingGap network expert 40 ietfReorderingGapTime network expert 41 ietfReorderingFreeRunx network expert 42 ietfReorderingFreeRunq network expert 43 ietfReorderingFreeRunp network expert 44 ietfReorderingFreeRuna network expert 45 ietfnReordering network expert # # spatial and multicast def of metrics is work in progress # wip ietfSpatialOneWayDelayVector raw measure wip ietfSubpathOneWayDelayStream collection # # following metrics definitions are under investigation. # Metrics names are given here only for providing input # to section 5.4 regarding composition. # wip ietfSubpathOneWayDelayMedian user,composition wip ietfPassiveOneWayDelayMedian user,composition # # TODO add o2g metrics wip ietfOne-to-group-One-way-Delay-Vector wip ietfOne-to-group-One-way-Packet-Loss-Vector wip ietfOne-to-group-One-way-Jitter-Vector wip ietfOne-to-Group-Mean-Delay wip ietfOne-to-Group-Range-Mean-Delay wip ietfOne-to-Group-Max-Mean-Delay wip ietfOne-to-Group-Loss-Ratio wip ietfOne-to-Group-Loss-Ratio-Range # # # following metrics definitions are under investigation. # Metrics names are given here only for providing input to section 5.4 regarding composition. # # Stephan & Barriac Expires September 5, 2007 [Page 13] Internet-Draft IPPM Reporting Registry March 2007 wip ietfCompOneWayDelayMedian user,composition wip ietfCompOneWayPktLossAverage user,composition # # registration is work in progress # wip ietfTraceroute user wip itutMosLqon end user, voip wip ituTrFactorEmodel end user, voip ?? Availability end user 5.1.1. Metrics measurement methods # Several methods are applicable to perform IPDV measurement results. The drawback is that the results are not comparable. # The measurement method must be reported to avoid misunderstanding . ietfOneWayIpdv PDV1: fixed reference of time PDV2: floating reference of time IPDV: absolute reference of time 5.2. raw measure Metrics Reporting such metrics results it out of the scope of the memo because reporting singletons is an internal task of a measurement system. Nevertheless the usage of metrics results require the knowmledge of Some metrics, like delay variation, have multiple well-known measuring approachs while relying on the same definition. some metrics measures e distinguishing well-known measuring approach of the same singleton metric :hat is to propose reporting information to identify these differences. 5.3. collection metrics Collection of metrics are connected to various usages. Collection of singleton metrics results (stream) of the same measure is mostly internal to measurement systems. Reporting such metrics results it out of the scope of the memo because reporting singletons is an internal task of a measurement system. That does not preclude to adress this point later in the registry. Stephan & Barriac Expires September 5, 2007 [Page 14] Internet-Draft IPPM Reporting Registry March 2007 On the other hand, collection of different metrics results of different mesures, spatial metrics, composition metrics and multicast one-to-group metrics, are mostly designed to be exchanged between measurement applications. As they have specific constraints they are adressed in individual sections. 5.4. Metrics for compositions This section gives the metrics a composition metric may be composed of. Then it gives the parameters and results a metric measure must provide to participate to a composition. Then it gives the parameters a composition metric must report. Following is the list of composition metrics (NOTE WELL they are not yet defined: they are given only to determine which kind of information should be reported and which structure this part of the registry should have). ID composition metric --- ----------------------------- wip ietfCompPacketLossAverage wip ietfCompOneWayDelayMedian 5.4.1. ietfCompOneWayDelayMedian ID participating metrics composition metric --- --------------------------------- ------------------------- 9 ietfOneWayDelayMedian ietfCompOneWayDelayMedian wip ietfSubpathOneWayDelayMedian ietfCompOneWayDelayMedian wip ietfPassiveOneWayDelayMedian ietfCompOneWayDelayMedian wip ietfCompOneWayDelayMedian ietfCompOneWayDelayMedian 5.4.1.1. Parameters to report and default values This section describes the default value of the parameters of a delay composition as per [I-D.ietf-ippm-spatial-composition] 5.4.1.2. Results to report Application law start end Src Dst Hi ---------------- ------- ---- ------ ---- ----- ---- default passive y y y y y default others y y y y n TODO: same applies for packet lost average Stephan & Barriac Expires September 5, 2007 [Page 15] Internet-Draft IPPM Reporting Registry March 2007 5.5. Users metrics applications Most of user metrics become end-users metrics when applied to an end- user application. Such metrics are covered in the section below. ID Name Application --- --------------------------------- ------------- 0 default unknown 9 ietfOneWayDelayMedian user 10 ietfOneWayDelayMinimum user 14 ietfOneWayPktLossAverage user 29 ietfOneWayIpdvPercentile user wip ietfSubpathOneWayDelayMedian user wip ietfPassiveOneWayDelayMedian user TODO: defines common reporting section for these metrics as per [I-D.shalunov-ippm-reporting] 5.6. Users metrics applications and End-user metrics This section list end user metrics and then gives the parameters and results each metric application must report. ID Name Application --- --------------------------------- ------------- 0 default unknown 9 ietfOneWayDelayMedian user 10 ietfOneWayDelayMinimum user 14 ietfOneWayPktLossAverage user wip itutMosLqon end user voip quality wip ituTrFactorEmodel end user voip quality 5.6.1. ietfOneWayDelayMedian applications 5.6.1.1. Parameters to report and default values Application pktSize PPS period law Timeout --------------------------- ------- ---- ------ --------- ------- default dflt 10 dflt poisson 2 s default dflt 100 dflt random 2 s rtp.voip 80 50 10 s periodic 400ms Discussion on the packet size: It should be better to consider the payload size to avoid mistake when encapsulation differs (i.e. IP, IPv6...) Stephan & Barriac Expires September 5, 2007 [Page 16] Internet-Draft IPPM Reporting Registry March 2007 5.6.1.2. Results to report Application law start end Src Dst Hi ---------------- ------- ---- ------ ---- ----- ---- default passive y y y y y default others y y y y n 5.6.2. ietfOneWayPktLossAverage applications TODO 5.6.3. ituTmosPESQ TODO 5.6.4. ituTrFactorEmodel TODO Stephan & Barriac Expires September 5, 2007 [Page 17] Internet-Draft IPPM Reporting Registry March 2007 6. Info Model Active measurement relies on the sending of packets from one source to one or more destinations. From the network perspective these packets are a flow. IPFIX WG has already modelized the information model of a flow [ADD REF]. Its info model provides most of the information required to describe the parameters of a measure. PSAMP WG has already modelized per packet information model [ADD REF]. This registry will reused fields and data types already defined in these information models to describe measure parameters and reports. These data models are managed by IANA on the bases of 'Specification Required' as defined in [RFC2434]. Consequently the missing fields and data types will be defined using the rules defines in the IANA section of these documents. 6.1. Fields This section gives the definition of the fields used in the section above. Most of them are already defined in IPFIX or PSAMP info models. 6.2. data type This section gives the definition the data type used in the section above. Most of them are already defined in IPFIX or PSAMP info models. They are designed to be managed by IANA. So missing data types will be added using the rules they give in their IANA sections. Stephan & Barriac Expires September 5, 2007 [Page 18] Internet-Draft IPPM Reporting Registry March 2007 7. IANA Considerations 7.1. Management rules of the IPPM REPORTING REGISTRY Registrations are done by IANA on the basis of 'Specification Required', as defined in [RFC2434]. A document that defines new metrics reporting rules would have an "IANA Considerations" section in which it would describe for each section of the registry the reporting aspects to be registered. 7.2. End users metrics to register in IANA-IPPM-METRICS-REGISTRY IANA is asked to register the following metrics in the IANA-IPPM- METRICS-REGISTRY as described in [RFC4148] . ietfTraceRoute OBJECT-IDENTITY STATUS current DESCRIPTION "ietfTraceRoute" REFERENCE "Reference TODO." ::= { ianaIppmMetrics nn } -- IANA assigns nn itutMosLqon OBJECT-IDENTITY STATUS current DESCRIPTION "ITU-T MOS-LQON PESQ." REFERENCE "Reference ITU-T P.862, P.862.1, P.563, P.564, P.800.1." ::= { ianaIppmMetrics nn } -- IANA assigns nn ituTrFactorEmodel OBJECT-IDENTITY STATUS current DESCRIPTION "ITU-T R-Factor Emodel." REFERENCE "Reference ITU-T G.107." ::= { ianaIppmMetrics nn } -- IANA assigns nn Stephan & Barriac Expires September 5, 2007 [Page 19] Internet-Draft IPPM Reporting Registry March 2007 8. Security Considerations Active measurement: see security section in owd pl, jitter rfcs (editor notes: add references). Active measurement: This method is based on the exchange of packets between one source and destinations. Administrators should secure the configuration steps to avoid measurement systems to be abused for denial of service attacks. passive measurement: The generation of packets which match systematically the hash function may lead to a DoS attack toward the collector. The generation of packets with spoofing adresses may corrupt the results without any possibility to detect the spoofing. Collecting: collection of singletons of raw measure could overload the network the measurement controller is attach to. End user Data Confidentiality : Stephan & Barriac Expires September 5, 2007 [Page 20] Internet-Draft IPPM Reporting Registry March 2007 9. References 9.1. Normative References [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May 1998. [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998. [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Delay Metric for IPPM", RFC 2679, September 1999. [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way Packet Loss Metric for IPPM", RFC 2680, September 1999. [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay Variation Metric for IP Performance Metrics (IPPM)", RFC 3393, November 2002. [RFC4148] Stephan, E., "IP Performance Metrics (IPPM) Metrics Registry", BCP 108, RFC 4148, August 2005. 9.2. Informative References [I-D.ietf-ipfix-info] Quittek, J., "Information Model for IP Flow Information Export", draft-ietf-ipfix-info-15 (work in progress), February 2007. [I-D.ietf-ippm-framework-compagg] Morton, A. and S. Berghe, "Framework for Metric Composition", draft-ietf-ippm-framework-compagg-02 (work in progress), October 2006. [I-D.ietf-ippm-reordering] Morton, A., "Packet Reordering Metric for IPPM", draft-ietf-ippm-reordering-13 (work in progress), May 2006. [I-D.ietf-ippm-reporting] Shalunov, S., "Reporting IP Performance Metrics to Users", draft-ietf-ippm-reporting-01 (work in progress), October 2006. [I-D.ietf-ippm-spatial-composition] Stephan & Barriac Expires September 5, 2007 [Page 21] Internet-Draft IPPM Reporting Registry March 2007 Morton, A. and E. Stephan, "Spatial Composition of Metrics", draft-ietf-ippm-spatial-composition-02 (work in progress), October 2006. [I-D.ietf-psamp-info] Dietz, T., "Information Model for Packet Sampling Exports", draft-ietf-psamp-info-05 (work in progress), October 2006. [I-D.morton-ippm-reporting-metrics] Morton, A., "Reporting Metrics: Different Points of View", draft-morton-ippm-reporting-metrics-01 (work in progress), October 2006. [I-D.niccolini-ippm-storetraceroutes] Niccolini, S., "How to store traceroute measurements and related metrics", draft-niccolini-ippm-storetraceroutes-03 (work in progress), March 2006. [I-D.shalunov-ippm-reporting] Shalunov, S., "Reporting IP Performance Metrics to Users", draft-shalunov-ippm-reporting-03 (work in progress), May 2006. [RFC2678] Mahdavi, J. and V. Paxson, "IPPM Metrics for Measuring Connectivity", RFC 2678, September 1999. [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round-trip Delay Metric for IPPM", RFC 2681, September 1999. [RFC3148] Mathis, M. and M. Allman, "A Framework for Defining Empirical Bulk Transfer Capacity Metrics", RFC 3148, July 2001. [RFC3357] Koodli, R. and R. Ravikanth, "One-way Loss Pattern Sample Metrics", RFC 3357, August 2002. [RFC3432] Raisanen, V., Grotefeld, G., and A. Morton, "Network performance measurement with periodic streams", RFC 3432, November 2002. [RFC3763] Shalunov, S. and B. Teitelbaum, "One-way Active Measurement Protocol (OWAMP) Requirements", RFC 3763, April 2004. [RFC4737] Morton, A., Ciavattone, L., Ramachandran, G., Shalunov, S., and J. Perser, "Packet Reordering Metrics", RFC 4737, November 2006. Stephan & Barriac Expires September 5, 2007 [Page 22] Internet-Draft IPPM Reporting Registry March 2007 Authors' Addresses Stephan Emile France Telecom R D 2 avenue Pierre Marzin Lannion, F-22307 Fax: +33 2 96 05 18 52 Email: emile.stephan@orange-ftgroup.com Barriac Vincent France Telecom R D 2 avenue Pierre Marzin Lannion, F-22307 Fax: +33 2 96 05 18 10 Email: vincent.barriac@orange-ftgroup.com Stephan & Barriac Expires September 5, 2007 [Page 23] Internet-Draft IPPM Reporting Registry March 2007 Full Copyright Statement Copyright (C) The IETF Trust (2007). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Acknowledgment Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA). Stephan & Barriac Expires September 5, 2007 [Page 24]