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

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/