--- 1/draft-ietf-ippm-registry-passive-00.txt 2014-07-04 08:14:39.170030701 -0700 +++ 2/draft-ietf-ippm-registry-passive-01.txt 2014-07-04 08:14:39.210031651 -0700 @@ -1,42 +1,36 @@ IPPM Working Group A. Akhter Internet-Draft B. Claise -Intended status: Standards Track Cisco Systems, Inc. -Expires: October 8, 2014 April 6, 2014 +Intended status: Best Current Practice Cisco Systems, Inc. +Expires: January 5, 2015 July 4, 2014 Passive Performance Metrics Sub-Registry - draft-ietf-ippm-registry-passive-00.txt + draft-ietf-ippm-registry-passive-01.txt Abstract - This memo defines the Passive Performance Metrics sub-registry of the - Performance Metric Registry. This sub-registry will contain Passive - Performance Metrics, especially those defined in RFCs prepared in the - IP Performance Metrics (IPPM) Working Group of the IETF, and possibly - applicable to other IETF metrics. - - IPPM Passive metric registration is meant to allow wider adoption of - common metrics in an inter-operable way. There are challenges with - metric interoperability and adoption (to name a few) due to flexible - input parameters, confusion between many similar metrics, and varying - output formats. + This document specifies the Passive Performance Metrics sub-registry + of the Performance Metric Registry. This sub-registry contains + Passive Performance Metrics, especially those defined in RFCs + prepared in the IP Performance Metrics (IPPM) Working Group of the + IETF, and possibly applicable to other IETF metrics. - This memo proposes a way to organize registry entries into columns - that are well-defined, permitting consistent development of entries - over time (a column may be marked NA if it is not applicable for that - metric). The design is intended to foster development of registry - entries based on existing reference RFCs, whilst each column serves - as a check-list item to avoid omissions during the registration - process. Every entry in the registry, before IANA action, requires - Expert review as defined by concurrent IETF work in progress - "Registry for Performance Metrics" (draft-manyfolks-ippm-metric- + This document specifies a way to organize registry entries into + columns that are well-defined, permitting consistent development of + entries over time (a column may be marked NA if it is not applicable + for that metric). The design is intended to foster development of + registry entries based on existing reference RFCs, whilst each column + serves as a check-list item to avoid omissions during the + registration process. Every entry in the registry, before IANA + action, requires Expert review as defined by concurrent IETF work in + progress "Registry for Performance Metrics" (draft-ietf-ippm-metric- registry). The document contains example entries for the Passive Performance Metrics sub-registry: a registry entry for a passive metric based on octetTotalCount as defined in RFC5102 and a protocol specific passive metric based on RTP packets lost as defined in RFC3550. The examples are for Informational purposes and do not create any entry in the IANA registry. Requirements Language @@ -53,137 +47,170 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. 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." - This Internet-Draft will expire on October 8, 2014. + This Internet-Draft will expire on January 5, 2015. Copyright Notice Copyright (c) 2014 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents - 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 4 - 2. Background and Motivation: . . . . . . . . . . . . . . . . . 6 - 3. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 - 4. Passive Registry Categories and Columns . . . . . . . . . . . 7 - 4.1. Common Registry Indexes and Information . . . . . . . . . 7 - 4.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 7 - 4.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1.3. Status . . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1.4. Requester . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1.5. Revision . . . . . . . . . . . . . . . . . . . . . . 7 - 4.1.6. Revision Date . . . . . . . . . . . . . . . . . . . . 7 - 4.1.7. Description . . . . . . . . . . . . . . . . . . . . . 7 - 4.1.8. Reference Specification(s) . . . . . . . . . . . . . 8 - 4.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 8 - 4.2.1. Reference Definition . . . . . . . . . . . . . . . . 8 - 4.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 8 - 4.3. Method of Measurement . . . . . . . . . . . . . . . . . . 8 - 4.3.1. Reference Implementation . . . . . . . . . . . . . . 8 - 4.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 9 - 4.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 9 - 4.3.4. Output Type(s) and Data Format . . . . . . . . . . . 9 - 4.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 10 - 4.3.6. Run-time Parameters and Data Format . . . . . . . . . 10 - 4.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 10 - 5. Example Generalized Passive Octet Count Entry . . . . . . . . 11 - 5.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 11 - 5.1.1. Element Identifier . . . . . . . . . . . . . . . . . 11 - 5.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 11 - 5.1.3. Status . . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1.4. Requester . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1.5. Revision . . . . . . . . . . . . . . . . . . . . . . 11 - 5.1.6. Revision Date . . . . . . . . . . . . . . . . . . . . 11 - 5.1.7. Metric Description . . . . . . . . . . . . . . . . . 12 - 5.1.8. Reference Specification(s) . . . . . . . . . . . . . 12 - 5.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 12 - 5.2.1. Reference Definition . . . . . . . . . . . . . . . . 12 - 5.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 12 - 5.3. Method of Measurement . . . . . . . . . . . . . . . . . . 12 - 5.3.1. Reference Implementation . . . . . . . . . . . . . . 12 - 5.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 12 - 5.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 12 - 5.3.4. Output Type(s) and Data Format . . . . . . . . . . . 13 - 5.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 13 - 5.3.6. Run-time Parameters and Data Format . . . . . . . . . 13 - 5.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 13 - 6. Example 5min Passive Egress Octet Count Entry on WAN - Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 13 - 6.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 14 - 6.1.1. Element Identifier . . . . . . . . . . . . . . . . . 14 - 6.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 14 - 6.1.3. Status . . . . . . . . . . . . . . . . . . . . . . . 14 - 6.1.4. Requester . . . . . . . . . . . . . . . . . . . . . . 14 - 6.1.5. Revision . . . . . . . . . . . . . . . . . . . . . . 14 - 6.1.6. Revision Date . . . . . . . . . . . . . . . . . . . . 14 - 6.1.7. Metric Description . . . . . . . . . . . . . . . . . 14 - 6.1.8. Reference Specification(s) . . . . . . . . . . . . . 15 - 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 15 - 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 15 - 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 15 - 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 15 - 6.3.1. Reference Implementation . . . . . . . . . . . . . . 15 - 6.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 15 - 6.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 16 - 6.3.4. Output Type(s) and Data Format . . . . . . . . . . . 16 - 6.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 16 - 6.3.6. Run-time Parameters and Data Format . . . . . . . . . 16 - 6.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 16 - 7. Example Passive RTP Lost Packet Count . . . . . . . . . . . . 16 - 8. Example BLANK Registry Entry . . . . . . . . . . . . . . . . 16 - 8.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 17 - 8.1.1. Element Identifier . . . . . . . . . . . . . . . . . 17 - 8.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 17 - 8.1.3. Status . . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1.4. Requester . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1.5. Revision . . . . . . . . . . . . . . . . . . . . . . 17 - 8.1.6. Revision Date . . . . . . . . . . . . . . . . . . . . 17 - 8.1.7. Metric Description . . . . . . . . . . . . . . . . . 17 - 8.1.8. Reference Specification(s) . . . . . . . . . . . . . 17 - 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 17 - 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 17 - 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 18 - 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 18 - 8.3.1. Reference Implementation . . . . . . . . . . . . . . 18 - 8.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 18 - 8.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 18 - 8.3.4. Output Type(s) and Data Format . . . . . . . . . . . 18 - 8.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 18 - 8.3.6. Run-time Parameters and Data Format . . . . . . . . . 18 - 8.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 19 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 19 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 - 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 - 12.1. Normative References . . . . . . . . . . . . . . . . . . 20 - 12.2. Informative References . . . . . . . . . . . . . . . . . 20 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 + 1. Open Issues . . . . . . . . . . . . . . . . . . . . . . . . . 4 + 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 5 + 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 + 4. Background and Motivation . . . . . . . . . . . . . . . . . . 6 + 5. Scope . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 + 6. Passive Registry Categories and Columns . . . . . . . . . . . 7 + 6.1. Common Registry Indexes and Information . . . . . . . . . 8 + 6.1.1. Identifier . . . . . . . . . . . . . . . . . . . . . 8 + 6.1.2. Name . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1.5. Requester . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 8 + 6.1.7. Revision Date . . . . . . . . . . . . . . . . . . . . 8 + 6.1.8. Description . . . . . . . . . . . . . . . . . . . . . 8 + 6.1.9. Reference Specification(s) . . . . . . . . . . . . . 8 + 6.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 9 + 6.2.1. Reference Definition . . . . . . . . . . . . . . . . 9 + 6.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 9 + 6.3. Method of Measurement . . . . . . . . . . . . . . . . . . 9 + 6.3.1. Reference Implementation . . . . . . . . . . . . . . 9 + 6.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 10 + 6.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 10 + 6.3.4. Output Type(s) and Data Format . . . . . . . . . . . 10 + 6.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 11 + 6.3.6. Run-time Parameters and Data Format . . . . . . . . . 11 + 6.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 11 + 7. Example Generalized Passive Octet Count Entry . . . . . . . . 11 + 7.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 12 + 7.1.1. Element Identifier . . . . . . . . . . . . . . . . . 12 + 7.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 12 + 7.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1.5. Requester . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 12 + 7.1.7. Revision Date . . . . . . . . . . . . . . . . . . . . 12 + 7.1.8. Metric Description . . . . . . . . . . . . . . . . . 13 + 7.1.9. Reference Specification(s) . . . . . . . . . . . . . 13 + 7.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 13 + 7.2.1. Reference Definition . . . . . . . . . . . . . . . . 13 + 7.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 13 + 7.3. Method of Measurement . . . . . . . . . . . . . . . . . . 13 + 7.3.1. Reference Implementation . . . . . . . . . . . . . . 13 + 7.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 13 + 7.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 13 + 7.3.4. Output Type(s) and Data Format . . . . . . . . . . . 14 + 7.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 14 + 7.3.6. Run-time Parameters and Data Format . . . . . . . . . 14 + 7.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 14 + 8. Example 5min Passive Egress Octet Count Entry on WAN + Interface . . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 8.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 15 + 8.1.1. Element Identifier . . . . . . . . . . . . . . . . . 15 + 8.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . . 15 + 8.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 8.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 15 + 8.1.5. Requester . . . . . . . . . . . . . . . . . . . . . . 15 + 8.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 15 + 8.1.7. Revision Date . . . . . . . . . . . . . . . . . . . . 15 + 8.1.8. Metric Description . . . . . . . . . . . . . . . . . 16 + 8.1.9. Reference Specification(s) . . . . . . . . . . . . . 16 + 8.2. Metric Definition . . . . . . . . . . . . . . . . . . . . 16 + 8.2.1. Reference Definition . . . . . . . . . . . . . . . . 16 + 8.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 16 + 8.3. Method of Measurement . . . . . . . . . . . . . . . . . . 16 + 8.3.1. Reference Implementation . . . . . . . . . . . . . . 16 + 8.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . . 16 + 8.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 17 + 8.3.4. Output Type(s) and Data Format . . . . . . . . . . . 17 + 8.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 17 + 8.3.6. Run-time Parameters and Data Format . . . . . . . . . 17 + 8.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 17 + 9. Example Passive RTP Lost Packet Count . . . . . . . . . . . . 17 + 10. Example BLANK Registry Entry . . . . . . . . . . . . . . . . 17 + 10.1. Registry Indexes . . . . . . . . . . . . . . . . . . . . 18 + 10.1.1. Element Identifier . . . . . . . . . . . . . . . . . 18 + 10.1.2. Metric Name . . . . . . . . . . . . . . . . . . . . 18 + 10.1.3. URI . . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1.4. Status . . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1.5. Requester . . . . . . . . . . . . . . . . . . . . . 18 + 10.1.6. Revision . . . . . . . . . . . . . . . . . . . . . . 18 + 10.1.7. Revision Date . . . . . . . . . . . . . . . . . . . 18 + 10.1.8. Metric Description . . . . . . . . . . . . . . . . . 18 + 10.1.9. Reference Specification(s) . . . . . . . . . . . . . 18 + 10.2. Metric Definition . . . . . . . . . . . . . . . . . . . 18 + 10.2.1. Reference Definition . . . . . . . . . . . . . . . . 19 + 10.2.2. Fixed Parameters . . . . . . . . . . . . . . . . . . 19 + 10.3. Method of Measurement . . . . . . . . . . . . . . . . . 19 + 10.3.1. Reference Implementation . . . . . . . . . . . . . . 19 + 10.3.2. Traffic Filter Criteria . . . . . . . . . . . . . . 19 + 10.3.3. Measurement Timing . . . . . . . . . . . . . . . . . 19 + 10.3.4. Output Type(s) and Data Format . . . . . . . . . . . 19 + 10.3.5. Metric Units . . . . . . . . . . . . . . . . . . . . 19 + 10.3.6. Run-time Parameters and Data Format . . . . . . . . 20 + 10.4. Comments and Remarks . . . . . . . . . . . . . . . . . . 20 + 11. Security Considerations . . . . . . . . . . . . . . . . . . . 20 + 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 + 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21 + 14. References . . . . . . . . . . . . . . . . . . . . . . . . . 21 + 14.1. Normative References . . . . . . . . . . . . . . . . . . 21 + 14.2. Informative References . . . . . . . . . . . . . . . . . 21 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 -1. Introduction +1. Open Issues + + 1. This draft must be aligned with draft-ietf-ippm-registry-active: + structure, content, examples, etc. + + 2. Do we need definitions for Active Metric and Passive Metric? To + be decided with the authors of ietf-ippm-metric-registry and + ietf-ippm-registry-active + + Active (Performance) Metric: specific to Performance Metrics + metered by an Active Measurement Method. + + Passive (Performance) Metric: specific to Performance Metrics + metered by an Passive Measurement Method. + + 3. See the EDITOR's NOTE within this draft. + + 4. Should the "Measurement Timing" be part of the registry? + + 5. What is difference between "Reference Specification(s)" and + "Reference Definition" + + 6. draft-ietf-ippm-metric-registry contain requester and reviewer + guidelines for performance metrics. Do we have guidelines + specifc to the extra passive performance metric fields in this + document? + +2. Introduction The IETF has been specifying and continues to specify Performance Metrics. While IP Performance Metrics (IPPM) is the working group (WG) primarily focusing on Performance Metrics definition at the IETF, other working groups, have also specified Performance Metrics: The "Metric Blocks for use with RTCP's Extended Report Framework" [XRBLOCK] WG recently specified many Performance Metrics related to "RTP Control Protocol Extended Reports (RTCP XR)" [RFC3611], which establishes a framework to allow new information to be @@ -199,57 +226,75 @@ The Performance Metrics for Other Layers (PMOL) [PMOL], a concluded working group, defined some Performance Metrics related to Session Initiation Protocol (SIP) voice quality [RFC6035], as well as guidelines for defining performance metrics [RFC6390] It is expected that more and more Performance Metrics will be defined in the future, not only IP based metrics, but also protocol-specific ones and application-specific ones. - However, there is currently no Performance Metrics registry in IANA. - "Registry for Performance Metrics" - [I-D.manyfolks-ippm-metric-registry] defines a common registry for - metrics. The registry proposes the creation of two sub-registries, - one for active metrics and another for passive measurements. + "Registry for Performance Metrics" [I-D.ietf-ippm-metric-registry] + specifies a common registry for Performance Metrics. This document + specifies the creation of a sub-registry specific to Performance + Metrics metered by an Passive Measurement Method (passive metrics). + Note that a sister document, "Active Performance Metric Sub-Registry" - There is a sister document for the active metric sub-registry in - "Active Performance Metric Sub-Registry" - [I-D.mornuley-ippm-registry-active]. + [I-D.ietf-ippm-registry-active], specifies a sub-registry for the + active metric (Performance Metrics metered by an Active Measurement. - This document defines the Passive Performance Measurements Sub- - Registry of the Performance Metric Registry. This sub-registry will - contain passive performance metrics that meet the criteria set by the - IETF and review of the Performance Metric Experts. It is expected - that the majority of the metrics will have been defined elsewhere - within the IETF working groups such as IPPM, BMWG, IPFIX, etc. + The Passive Performance Measurements Sub-Registry contains passive + performance metrics that meet the criteria set by the IETF and review + of the Performance Metric Experts. It is expected that the majority + of the metrics will have been defined elsewhere within the IETF + working groups such as IPPM, BMWG, IPFIX, etc. This sub-registry is part of the Performance Metric Registry - [I-D.manyfolks-ippm-metric-registry] which specifies that all sub- + [I-D.ietf-ippm-metric-registry] which specifies that all sub- registries must contain at least the following common fields: the - identifier, the name, the status, the requester, the revision, the - revision date, the description for each entry, and the reference - specifications used as the foundation for the Registered Performance - Metric (see [I-D.manyfolks-ippm-metric-registry]). In addition to - these common fields the passive metrics sub-registry has additional - fields that provide the necessary background for interoperability and - adoption. + identifier, the name, the URI, the status, the requester, the + revision, the revision date, the description, and the reference + specification(s). In addition to these common fields the passive + metrics sub-registry has additional fields that provide the necessary + background for interoperability and adoption. -2. Background and Motivation: +3. Terminology - (from draft-mornuley-ippm-registry-active): + "Registry for Performance Metrics" [I-D.ietf-ippm-metric-registry] + specifies the following terms: Performance Metric, Registered + Performance Metric, Performance Metrics Registry (also known as + Registry), Proprietary Registry, Performance Metrics Experts, + Performance Metrics Directorate, Parameter, Active Measurement + Method, Passive Measurement Method, and Hybrid Measurement Method. + + Capitalized terms used in this document that are defined in the + Terminology section of [I-D.ietf-ippm-metric-registry] are to be + interpreted as defined there. + +4. Background and Motivation + + EDITOR's NOTE: from draft-manyfolks-ippm-metric-registry-00. + Proposal: we can simply refers to draft-ietf-ippm-registry-active-00 + section 5, instead of duplicating text. + + IPPM Passive Performance Metric registration is meant to allow wider + adoption of common metrics in an inter-operable way. There are + challenges with metric interoperability and adoption (to name a few) + due to flexible input parameters, confusion between many similar + metrics, and varying output formats. One clear motivation for having such a registry is to allow a controller to request a measurement agent to perform a measurement using a specific metric (see [I-D.ietf-lmap-framework]). Such a request can be performed using any control protocol that refers to the value assigned to the specific metric in the registry. + Similarly, the measurement agent can report the results of the measurement and by referring to the metric value it can unequivocally identify the metric that the results correspond to. There are several side benefits of having a registry with well-chosen entries. First, the registry could serve as an inventory of useful and used metrics that are normally supported by different implementations of measurement agents. Second, the results of the metrics would be comparable even if they are performed by different implementations and in different networks, as the metric and method @@ -248,171 +293,171 @@ identify the metric that the results correspond to. There are several side benefits of having a registry with well-chosen entries. First, the registry could serve as an inventory of useful and used metrics that are normally supported by different implementations of measurement agents. Second, the results of the metrics would be comparable even if they are performed by different implementations and in different networks, as the metric and method is unambiguously defined. -3. Scope +5. Scope - [I-D.manyfolks-ippm-metric-registry] defines the overall structure - for a Performance Metric Registry and provides guidance for defining - a sub registry. + [I-D.ietf-ippm-metric-registry] defines the overall structure for a + Performance Metric Registry and provides guidance for defining a sub + registry. This document defines the Passive Performance Metrics Sub-registry; passive metrics are those where the measurements are based the - observation of on user traffic. Specifically, this traffic has not + observation of on network traffic, generated either from the end + users or from network elements. Specifically, this traffic has not been generated for the purpose of measurement. A row in the registry corresponds to one Registered Performance Metric, with entries in the various columns specifying the metric. - Section 4 defines the additional columns for a Registered Passive + Section 6 defines the additional columns for a Registered Passive Performance Metric. - As discussed in [I-D.manyfolks-ippm-metric-registry], each entry - (row) must be tightly defined; the definition must leave open only a - few parameters that do not change the fundamental nature of the + As discussed in [I-D.ietf-ippm-metric-registry], each entry (row) + must be tightly defined; the definition must leave open only a few + parameters that do not change the fundamental nature of the measurement (such as source and destination addresses), and so promotes comparable results across independent implementations. Also, each registered entry must be based on existing reference RFCs (or other standards) for performance metrics, and must be operationally useful and have significant industry interest. This is ensured by expert review for every entry before IANA action. -4. Passive Registry Categories and Columns +6. Passive Registry Categories and Columns This section defines the categories and columns of the registry. - Below, categories are described at the 4.x heading level, and columns - are at the 4.x.y heading level. There are three categories, divided - into common information (from [I-D.manyfolks-ippm-metric-registry]), + Below, categories are described at the 6.x heading level, and columns + are at the 6.x.y heading level. There are three categories, divided + into common information (from [I-D.ietf-ippm-metric-registry]), metric definition and an open Comments section. -4.1. Common Registry Indexes and Information +6.1. Common Registry Indexes and Information This category has multiple indexes to each registry entry. It is - defined in [I-D.manyfolks-ippm-metric-registry]: + defined in [I-D.ietf-ippm-metric-registry]: -4.1.1. Identifier +6.1.1. Identifier - Defined in [I-D.manyfolks-ippm-metric-registry]. Definition text to - be copied once source is stable. + Defined in [I-D.ietf-ippm-metric-registry]. Definition text to be + copied once source is stable. -4.1.2. Name +6.1.2. Name - Defined in [I-D.manyfolks-ippm-metric-registry], same comment as - above. + Defined in [I-D.ietf-ippm-metric-registry], same comment as above. -4.1.3. Status +6.1.3. URI - Defined in [I-D.manyfolks-ippm-metric-registry], same comment as - above. + Defined in [I-D.ietf-ippm-metric-registry], same comment as above. -4.1.4. Requester +6.1.4. Status - Defined in [I-D.manyfolks-ippm-metric-registry], same comment as - above. + Defined in [I-D.ietf-ippm-metric-registry], same comment as above. -4.1.5. Revision +6.1.5. Requester - Defined in [I-D.manyfolks-ippm-metric-registry], same comment as - above. + Defined in [I-D.ietf-ippm-metric-registry], same comment as above. -4.1.6. Revision Date +6.1.6. Revision - Defined in [I-D.manyfolks-ippm-metric-registry], same comment as - above. + Defined in [I-D.ietf-ippm-metric-registry], same comment as above. -4.1.7. Description +6.1.7. Revision Date - Defined in [I-D.manyfolks-ippm-metric-registry], same comment as the + Defined in [I-D.ietf-ippm-metric-registry], same comment as above. + +6.1.8. Description + + Defined in [I-D.ietf-ippm-metric-registry], same comment as the above. -4.1.8. Reference Specification(s) +6.1.9. Reference Specification(s) - Defined in [I-D.manyfolks-ippm-metric-registry], same comment as the + Defined in [I-D.ietf-ippm-metric-registry], same comment as the above. -4.2. Metric Definition +6.2. Metric Definition This category includes columns to prompt all necessary details - related to the metric definition, including the RFC reference and - values of input factors, called fixed parameters, which are left open - in the origin definition but have a particular value defined by the - performance metric. + related to the passive performance metric definition, including the + RFC reference and values of input factors, called fixed parameters, + which are left open in the origin definition but have a particular + value defined by the performance metric. -4.2.1. Reference Definition +6.2.1. Reference Definition This entry provides references to relevant sections of the RFC(s) defining the metric, as well as any supplemental information needed to ensure an unambiguous definition for implementations. -4.2.2. Fixed Parameters +6.2.2. Fixed Parameters Fixed Parameters are input factors whose value must be specified in the Registry. The measurement system uses these values. Where referenced metrics supply a list of Parameters as part of their descriptive template, a sub-set of the Parameters will be designated as Fixed Parameters. For example, for RTP packet loss calculation relies on the validation of a packet as RTP which is a multi-packet validation controlled by MIN_SEQUENTIAL as defined by [RFC3550]. Varying MIN_SEQUENTIAL values can alter the loss report and this value could be set as a fixed parameter. A Parameter which is Fixed for one Registry entry may be designated as a Run-time Parameter for another Registry entry. -4.3. Method of Measurement +6.3. Method of Measurement This category includes columns for references to relevant sections of the RFC(s) and any supplemental information needed to ensure an unambiguous method for implementations. -4.3.1. Reference Implementation +6.3.1. Reference Implementation This entry provides references to relevant sections of the RFC(s) describing the method of measurement, as well as any supplemental information needed to ensure unambiguous interpretation for implementations referring to the RFC text. Specifically, this section should include pointers to pseudocode or actual code that could be used for an unambigious implementation. -4.3.2. Traffic Filter Criteria +6.3.2. Traffic Filter Criteria The filter specifies the traffic constraints that the passive measurement method used is valid (or invalid) for. This includes valid packet sampling ranges, width of valid traffic matches (eg. all traffic on interface, UDP packets packets in a flow (eg. same RTP session). It is possible that the measurement method may not have a specific limitation. However, this specific registry entry with it's combination of fixed parameters implies restrictions. These restrictions would be listed in this field. -4.3.3. Measurement Timing +6.3.3. Measurement Timing Measurement timing defines the behavior of the measurement method with respect to timing. Is the measurement continuous? If the measurement is sampled, what is the format of sampling? (eg random packet, random time, etc.) How long is the measurement interval? -4.3.4. Output Type(s) and Data Format +6.3.4. Output Type(s) and Data Format For entries which involve a stream and many singleton measurements, a statistic may be specified in this column to summarize the results to a single value. If the complete set of measured singletons is output, this will be specified here. Some metrics embed one specific statistic in the reference metric definition, while others allow several output types or statistics. Each entry in the output type column contains the following @@ -417,461 +462,475 @@ Each entry in the output type column contains the following information: o Value: The name of the output type o Data Format: provided to simplify the communication with collection systems and implementation of measurement devices. o Reference: the specification where the output type is defined + The output type defines the type of result that the metric produces. It can be the raw result(s) or it can be some form of statistic. The specification of the output type must define the format of the output. In some systems, format specifications will simplify both measurement implementation and collection/storage tasks. Note that if two different statistics are required from a single measurement (for example, both "Xth percentile mean" and "Raw"), then a new output type must be defined ("Xth percentile mean AND Raw"). -4.3.5. Metric Units +6.3.5. Metric Units The measured results must be expressed using some standard dimension or units of measure. This column provides the units. When a sample of singletons (see [RFC2330] for definitions of these terms) is collected, this entry will specify the units for each measured value. -4.3.6. Run-time Parameters and Data Format +6.3.6. Run-time Parameters and Data Format Run-Time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. However, the values of these parameters is not specified in the Registry, rather these parameters are listed as an aid to the measurement system implementor or user (they must be left as variables, and supplied on execution). Where metrics supply a list of Parameters as part of their descriptive template, a sub-set of the Parameters will be designated as Run-Time Parameters. The Data Format of each Run-time Parameter SHALL be specified in this column, to simplify the control and implementation of measurement devices. Examples of Run-time Parameters include IP addresses, measurement point designations, start times and end times for measurement, and other information essential to the method of measurement. -4.4. Comments and Remarks +6.4. Comments and Remarks Besides providing additional details which do not appear in other categories, this open Category (single column) allows for unforeseen issues to be addressed by simply updating this Informational entry. -5. Example Generalized Passive Octet Count Entry +7. Example Generalized Passive Octet Count Entry tbd This section is Informational. This section gives an example registry entry for a generalized the passive metric octetDeltaCount described in [RFC5102]. -5.1. Registry Indexes +7.1. Registry Indexes This category includes multiple indexes to the registry entries, the element ID and metric name. -5.1.1. Element Identifier +7.1.1. Element Identifier An integer having enough digits to uniquely identify each entry in the Registry. TBD by IANA. -5.1.2. Metric Name +7.1.2. Metric Name A metric naming convention is TBD. One possibility based on the proposal in - [I-D.manyfolks-ippm-metric-registry]: + [I-D.ietf-ippm-metric-registry]: Pas_IP-Octet-Delta-General -5.1.3. Status +7.1.3. URI + + urn:ietf:params:performance:metric-something + +7.1.4. Status Current -5.1.4. Requester +7.1.5. Requester TBD -5.1.5. Revision +7.1.6. Revision 0 -5.1.6. Revision Date +7.1.7. Revision Date TBD -5.1.7. Metric Description +7.1.8. Metric Description A delta count of the number of octets observed. -5.1.8. Reference Specification(s) +7.1.9. Reference Specification(s) octetDeltaCount described in section 5.10.1 of [RFC5102] -5.2. Metric Definition +7.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. -5.2.1. Reference Definition +7.2.1. Reference Definition octetDeltaCount described in section 5.10.1 of [RFC5102] -5.2.2. Fixed Parameters +7.2.2. Fixed Parameters As this is the generalised version of the IP delta count metric, there are no fixed parameters. -5.3. Method of Measurement +7.3. Method of Measurement -5.3.1. Reference Implementation +7.3.1. Reference Implementation For .
-5.3.2. Traffic Filter Criteria +7.3.2. Traffic Filter Criteria This measurement only covers IP packets and the IP payload (including the IP header) of these packets. Non-IP packets (BPDUs, ISIS) will not be accounted. Layer 2 overhead (Ethernet headers, MPLS, QinQ, etc.) will also not be represented in the measurement. -5.3.3. Measurement Timing +7.3.3. Measurement Timing This is a continous measurement of the IP octets seen in the traffic selection scope (run-time parameter). The measurement interval is a run time parameter. There is no sampling. -5.3.4. Output Type(s) and Data Format +7.3.4. Output Type(s) and Data Format It is possible that multiple observation intervals are reported in a single report. In such a case concatination of the interval reports (deltaOctetCount, start-time, end-time) is allowed. The delta octet count metric reports a observation start time and end time. o Value: observation-start-time and observation-end-time o Data Format: 64-bit NTP Time-stamp Format o Reference: section 6 of [RFC5905] -5.3.5. Metric Units +7.3.5. Metric Units The measured results are expressed in octets with a data format of unsigned64 as described in [RFC5102] -5.3.6. Run-time Parameters and Data Format +7.3.6. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. o samplingTimeInterval, length of time a single report covers. unsigned32 microseconds [RFC5477] o observationInterface, ifindex of interface to monitor. -1 represents all interfaces. -2 representings WAN facing and -3 represnets LAN facing. unsigned32. o observation direction, unsigned8 where 0 represents incoming traffic on interface, 1 outgoing and 2 represents both incoming and outgoing. -5.4. Comments and Remarks +7.4. Comments and Remarks Additional (Informational) details for this entry -6. Example 5min Passive Egress Octet Count Entry on WAN Interface +8. Example 5min Passive Egress Octet Count Entry on WAN Interface tbd This section is Informational. This section gives an example registry entry for accounting of outgoing WAN IP traffic the passive metric in terms of octetDeltaCount, as described in [RFC5102]. -6.1. Registry Indexes +8.1. Registry Indexes This category includes multiple indexes to the registry entries, the element ID and metric name. -6.1.1. Element Identifier +8.1.1. Element Identifier An integer having enough digits to uniquely identify each entry in the Registry. TBD by IANA. -6.1.2. Metric Name +8.1.2. Metric Name A metric naming convention is TBD. One possibility based on the proposal in - [I-D.manyfolks-ippm-metric-registry]: + [I-D.ietf-ippm-metric-registry]: Pas_IP-Octet-Delta-WAN-egress -6.1.3. Status +8.1.3. URI + + urn:ietf:params:performance:metric-something + +8.1.4. Status Current -6.1.4. Requester +8.1.5. Requester TBD -6.1.5. Revision +8.1.6. Revision 0 -6.1.6. Revision Date +8.1.7. Revision Date TBD -6.1.7. Metric Description +8.1.8. Metric Description A delta count of the number of octets observed outgoing on WAN interface. -6.1.8. Reference Specification(s) +8.1.9. Reference Specification(s) octetDeltaCount described in section 5.10.1 of [RFC5102] -6.2. Metric Definition +8.2. Metric Definition This category includes columns to prompt the entry of all necessary details related to the metric definition, including the RFC reference and values of input factors, called fixed parameters. -6.2.1. Reference Definition +8.2.1. Reference Definition octetDeltaCount described in section 5.10.1 of [RFC5102] -6.2.2. Fixed Parameters +8.2.2. Fixed Parameters As this is a specific version of Pas_IP-Octet-Delta-General that performs metering of all outgoing WAN traffic. o samplingTimeInterval= 300000000, length of time a single report covers. unsigned32 microseconds [RFC5477] o observationInterface= -2, ifindex of interface to monitor. -1 represents all interfaces. -2 representings WAN facing and -3 represnets LAN facing. unsigned32. o observation direction= 1, unsigned8 where 0 represents incoming traffic on interface, 1 outgoing and 2 represents both incoming and outgoing. -6.3. Method of Measurement +8.3. Method of Measurement -6.3.1. Reference Implementation +8.3.1. Reference Implementation For .
-6.3.2. Traffic Filter Criteria +8.3.2. Traffic Filter Criteria This measurement only covers IP packets observed in the WAN outgoing direction. The bytes counted are the IP payload (including the IP header) of these packets. Non-IP packets (BPDUs, ISIS) will not be accounted. Layer 2 overhead (Ethernet headers, MPLS, QinQ, etc.) will also not be represented in the measurement. -6.3.3. Measurement Timing +8.3.3. Measurement Timing This is a continous measurement of the IP octets seen in the traffic selection scope (run-time parameter), each of a 5 minute duration. There is no sampling. -6.3.4. Output Type(s) and Data Format +8.3.4. Output Type(s) and Data Format It is possible that multiple observation intervals are reported in a single report. In such a case concatination of the interval reports (deltaOctetCount, start-time, end-time) is allowed. The delta octet count metric reports a observation start time and end time. o Value: observation-start-time and observation-end-time o Data Format: 64-bit NTP Time-stamp Format o Reference: section 6 of [RFC5905] -6.3.5. Metric Units +8.3.5. Metric Units The measured results are expressed in octets with a data format of unsigned64 as described in [RFC5102] -6.3.6. Run-time Parameters and Data Format +8.3.6. Run-time Parameters and Data Format There are no run-time parameters for this registry entry. -6.4. Comments and Remarks +8.4. Comments and Remarks Additional (Informational) details for this entry -7. Example Passive RTP Lost Packet Count +9. Example Passive RTP Lost Packet Count tbd -8. Example BLANK Registry Entry +10. Example BLANK Registry Entry This section is Informational. (?) This section gives an example registry entry for the . -8.1. Registry Indexes +10.1. Registry Indexes This category includes multiple indexes to the registry entries, the element ID and metric name. -8.1.1. Element Identifier +10.1.1. Element Identifier An integer having enough digits to uniquely identify each entry in the Registry. -8.1.2. Metric Name +10.1.2. Metric Name A metric naming convention is TBD. -8.1.3. Status +10.1.3. URI + + urn:ietf:params:performance:metric-something + +10.1.4. Status Current -8.1.4. Requester +10.1.5. Requester TBD -8.1.5. Revision +10.1.6. Revision 0 -8.1.6. Revision Date +10.1.7. Revision Date TBD -8.1.7. Metric Description +10.1.8. Metric Description A metric Description is TBD. -8.1.8. Reference Specification(s) +10.1.9. Reference Specification(s) Section YY, RFCXXXX -8.2. Metric Definition - -8.2.1. Reference Definition +10.2. Metric Definition +10.2.1. Reference Definition < possible section reference> -8.2.2. Fixed Parameters +10.2.2. Fixed Parameters Fixed Parameters are input factors that must be determined and embedded in the measurement system for use when needed. The values of these parameters is specified in the Registry. -8.3. Method of Measurement +10.3. Method of Measurement -8.3.1. Reference Implementation +10.3.1. Reference Implementation For .
-8.3.2. Traffic Filter Criteria +10.3.2. Traffic Filter Criteria -8.3.3. Measurement Timing +10.3.3. Measurement Timing < list timing requirements and limitations > -8.3.4. Output Type(s) and Data Format +10.3.4. Output Type(s) and Data Format The output types define the type of result that the metric produces. o Value: o Data Format: (There may be some precedent to follow here, but otherwise use 64-bit NTP Time-stamp Format, see section 6 of [RFC5905]). o Reference:
-8.3.5. Metric Units +10.3.5. Metric Units The measured results are expressed in ,
. -8.3.6. Run-time Parameters and Data Format +10.3.6. Run-time Parameters and Data Format Run-time Parameters are input factors that must be determined, configured into the measurement system, and reported with the results for the context to be complete. . -8.4. Comments and Remarks +10.4. Comments and Remarks Additional (Informational) details for this entry -9. Security Considerations +11. Security Considerations This registry has no known implications on Internet Security. -10. IANA Considerations +12. IANA Considerations IANA is requested to create The Passive Performance Metric Sub- registry within the Performance Metric Registry defined in - [I-D.manyfolks-ippm-metric-registry]. The Sub-registry will contain - the following categories and (bullet) columns, (as defined in section - 3 above): + [I-D.ietf-ippm-metric-registry]. The Sub-registry will contain the + following categories and (bullet) columns, (as defined in section 6 + above): Common Registry Indexes and Info o Identifier o Name + o URI + o Status o Requester o Revision o Revision Date o Description @@ -891,53 +950,53 @@ o Measurement Timing o Output Type(s) and Data format o Metric Units o Run-time Parameters Comments and Remarks -11. Acknowledgements +13. Acknowledgements The authors thank the prior work of Al Morton, Marcelo Bagnulo and - Phil Eardley in "draft-mornuley-ippm-registry-active" which was used - both as a template for this document and source of text. + Phil Eardley in "draft-ietf-ippm-registry-active" which was used both + as a template for this document and source of text. -12. References +14. References -12.1. Normative References +14.1. Normative References + + [I-D.ietf-ippm-metric-registry] + Bagnulo, M., Claise, B., Eardley, P., and A. Morton, + "Registry for Performance Metrics", draft-ietf-ippm- + metric-registry-00 (work in progress), July 2014. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. -12.2. Informative References +14.2. Informative References [BMWG] IETF, , "Benchmarking Methodology (BMWG) Working Group, http://datatracker.ietf.org/wg/bmwg/charter/", . + [I-D.ietf-ippm-registry-active] + Morton, A., Bagnulo, M., and P. Eardley, "Active + Performance Metric Sub-Registry", draft-ietf-ippm- + registry-active-00 (work in progress), April 2014. + [I-D.ietf-lmap-framework] Eardley, P., Morton, A., Bagnulo, M., Burbridge, T., Aitken, P., and A. Akhter, "A framework for large-scale measurement platforms (LMAP)", draft-ietf-lmap- - framework-04 (work in progress), March 2014. - - [I-D.manyfolks-ippm-metric-registry] - Bagnulo, M., Claise, B., Eardley, P., and A. Morton, - "Registry for Performance Metrics", draft-manyfolks-ippm- - metric-registry-00 (work in progress), February 2014. - - [I-D.mornuley-ippm-registry-active] - Morton, A., Bagnulo, M., and P. Eardley, "Active - Performance Metric Sub-Registry", draft-mornuley-ippm- - registry-active-00 (work in progress), February 2014. + framework-07 (work in progress), June 2014. [IPFIX] IETF, , "IP Flow Information eXport (IPFIX) Working Group, http://datatracker.ietf.org/wg/ipfix/charter/", . [PMOL] IETF, , "IP Performance Metrics for Other Layers (PMOL) Working Group, http://datatracker.ietf.org/wg/pmol/charter/", . [RFC2330] Paxson, V., Almes, G., Mahdavi, J., and M. Mathis, "Framework for IP Performance Metrics", RFC 2330, May