[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 draft-ietf-ippm-registry-passive

IPPM Working Group                                             A. Akhter
Internet-Draft                                                 B. Claise
Intended status: Standards Track                     Cisco Systems, Inc.
Expires: September 4, 2014                                 March 3, 2014


                Passive Performance Metrics Sub-Registry
               draft-akhter-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 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-
   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

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].





Akhter & Claise         Expires September 4, 2014               [Page 1]


Internet-Draft            Passive Sub-Registry                March 2014


Status of This Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   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 September 4, 2014.

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



Akhter & Claise         Expires September 4, 2014               [Page 2]


Internet-Draft            Passive Sub-Registry                March 2014


       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



Akhter & Claise         Expires September 4, 2014               [Page 3]


Internet-Draft            Passive Sub-Registry                March 2014


       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.  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
      conveyed in RTCP, supplementing the original report blocks defined




Akhter & Claise         Expires September 4, 2014               [Page 4]


Internet-Draft            Passive Sub-Registry                March 2014


      in "RTP: A Transport Protocol for Real-Time Applications",
      [RFC3550].

      The Benchmarking Methodology" [BMWG] WG proposed some Performance
      Metrics as part of the benchmarking methodology.

      The IP Flow Information eXport WG (IPFIX) [IPFIX] has existing and
      proposed Information Elements related to performance metrics.

      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.

   There is a sister document for the active metric sub-registry in
   "Active Performance Metric Sub-Registry"
   [I-D.mornuley-ippm-registry-active].

   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.

   This sub-registry is part of the Performance Metric Registry
   [I-D.manyfolks-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.






Akhter & Claise         Expires September 4, 2014               [Page 5]


Internet-Draft            Passive Sub-Registry                March 2014


2.  Background and Motivation:

   (from draft-mornuley-ippm-registry-active):

   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
   is unambiguously defined.

3.  Scope

   [I-D.manyfolks-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
   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
   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
   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.





Akhter & Claise         Expires September 4, 2014               [Page 6]


Internet-Draft            Passive Sub-Registry                March 2014


4.  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]),
   metric definition and an open Comments section.

4.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]:

4.1.1.  Identifier

   Defined in [I-D.manyfolks-ippm-metric-registry].  Definition text to
   be copied once source is stable.

4.1.2.  Name

   Defined in [I-D.manyfolks-ippm-metric-registry], same comment as
   above.

4.1.3.  Status

   Defined in [I-D.manyfolks-ippm-metric-registry], same comment as
   above.

4.1.4.  Requester

   Defined in [I-D.manyfolks-ippm-metric-registry], same comment as
   above.

4.1.5.  Revision

   Defined in [I-D.manyfolks-ippm-metric-registry], same comment as
   above.

4.1.6.  Revision Date

   Defined in [I-D.manyfolks-ippm-metric-registry], same comment as
   above.

4.1.7.  Description

   Defined in [I-D.manyfolks-ippm-metric-registry], same comment as the
   above.




Akhter & Claise         Expires September 4, 2014               [Page 7]


Internet-Draft            Passive Sub-Registry                March 2014


4.1.8.  Reference Specification(s)

   Defined in [I-D.manyfolks-ippm-metric-registry], same comment as the
   above.

4.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.

4.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

   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

   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

   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.




Akhter & Claise         Expires September 4, 2014               [Page 8]


Internet-Draft            Passive Sub-Registry                March 2014


   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

   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

   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

   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
   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




Akhter & Claise         Expires September 4, 2014               [Page 9]


Internet-Draft            Passive Sub-Registry                March 2014


   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

   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

   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

   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.







Akhter & Claise         Expires September 4, 2014              [Page 10]


Internet-Draft            Passive Sub-Registry                March 2014


5.  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

   This category includes multiple indexes to the registry entries, the
   element ID and metric name.

5.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

   A metric naming convention is TBD.

   One possibility based on the proposal in
   [I-D.manyfolks-ippm-metric-registry]:

   Pas_IP-Octet-Delta-General

5.1.3.  Status

   Current

5.1.4.  Requester

   TBD

5.1.5.  Revision

   0

5.1.6.  Revision Date

   TBD






Akhter & Claise         Expires September 4, 2014              [Page 11]


Internet-Draft            Passive Sub-Registry                March 2014


5.1.7.  Metric Description

   A delta count of the number of octets observed.

5.1.8.  Reference Specification(s)

   octetDeltaCount described in section 5.10.1 of [RFC5102]

5.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

   octetDeltaCount described in section 5.10.1 of [RFC5102]

5.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

5.3.1.  Reference Implementation

   For <metric>.

   <section reference>

5.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

   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.





Akhter & Claise         Expires September 4, 2014              [Page 12]


Internet-Draft            Passive Sub-Registry                March 2014


5.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

   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

   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

   Additional (Informational) details for this entry

6.  Example 5min Passive Egress Octet Count Entry on WAN Interface

   tbd

   This section is Informational.





Akhter & Claise         Expires September 4, 2014              [Page 13]


Internet-Draft            Passive Sub-Registry                March 2014


   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

   This category includes multiple indexes to the registry entries, the
   element ID and metric name.

6.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

   A metric naming convention is TBD.

   One possibility based on the proposal in
   [I-D.manyfolks-ippm-metric-registry]:

   Pas_IP-Octet-Delta-WAN-egress

6.1.3.  Status

   Current

6.1.4.  Requester

   TBD

6.1.5.  Revision

   0

6.1.6.  Revision Date

   TBD

6.1.7.  Metric Description

   A delta count of the number of octets observed outgoing on WAN
   interface.






Akhter & Claise         Expires September 4, 2014              [Page 14]


Internet-Draft            Passive Sub-Registry                March 2014


6.1.8.  Reference Specification(s)

   octetDeltaCount described in section 5.10.1 of [RFC5102]

6.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

   octetDeltaCount described in section 5.10.1 of [RFC5102]

6.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

6.3.1.  Reference Implementation

   For <metric>.

   <section reference>

6.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.






Akhter & Claise         Expires September 4, 2014              [Page 15]


Internet-Draft            Passive Sub-Registry                March 2014


6.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

   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

   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

   There are no run-time parameters for this registry entry.

6.4.  Comments and Remarks

   Additional (Informational) details for this entry

7.  Example Passive RTP Lost Packet Count

   tbd

8.  Example BLANK Registry Entry

   This section is Informational. (?)

   This section gives an example registry entry for the <type of metric
   and specification reference> .






Akhter & Claise         Expires September 4, 2014              [Page 16]


Internet-Draft            Passive Sub-Registry                March 2014


8.1.  Registry Indexes

   This category includes multiple indexes to the registry entries, the
   element ID and metric name.

8.1.1.  Element Identifier

   An integer having enough digits to uniquely identify each entry in
   the Registry.

8.1.2.  Metric Name

   A metric naming convention is TBD.

8.1.3.  Status

   Current

8.1.4.  Requester

   TBD

8.1.5.  Revision

   0

8.1.6.  Revision Date

   TBD

8.1.7.  Metric Description

   A metric Description is TBD.

8.1.8.  Reference Specification(s)

   Section YY, RFCXXXX

8.2.  Metric Definition

8.2.1.  Reference Definition

   < possible section reference>








Akhter & Claise         Expires September 4, 2014              [Page 17]


Internet-Draft            Passive Sub-Registry                March 2014


8.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.

   <list fixed parameters>

8.3.  Method of Measurement

8.3.1.  Reference Implementation

   For <metric>.

   <section reference>

8.3.2.  Traffic Filter Criteria

   <list filter criteria limitations and allowances >

8.3.3.  Measurement Timing

   < list timing requirements and limitations >

8.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: <section reference>

8.3.5.  Metric Units

   The measured results are expressed in <units>,

   <section reference>.

8.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.




Akhter & Claise         Expires September 4, 2014              [Page 18]


Internet-Draft            Passive Sub-Registry                March 2014


   <list of run-time parameters>

   <reference(s)>.

8.4.  Comments and Remarks

   Additional (Informational) details for this entry

9.  Security Considerations

   This registry has no known implications on Internet Security.

10.  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):

   Common Registry Indexes and Info

   o  Identifier

   o  Name

   o  Status

   o  Requester

   o  Revision

   o  Revision Date

   o  Description

   o  Reference Specification(s)

   Metric Definition

   o  Reference Definition

   o  Fixed Parameters

   Method of Measurement

   o  Reference Implementation




Akhter & Claise         Expires September 4, 2014              [Page 19]


Internet-Draft            Passive Sub-Registry                March 2014


   o  Traffic Filter Criteria

   o  Measurement Timing

   o  Output Type(s) and Data format

   o  Metric Units

   o  Run-time Parameters

   Comments and Remarks

11.  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.

12.  References

12.1.  Normative References

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

12.2.  Informative References

   [BMWG]     IETF, , "Benchmarking Methodology (BMWG) Working Group,
              http://datatracker.ietf.org/wg/bmwg/charter/", .

   [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-03 (work in progress), January 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,
              http://datatracker.ietf.org/wg/ipfix/charter/", .



Akhter & Claise         Expires September 4, 2014              [Page 20]


Internet-Draft            Passive Sub-Registry                March 2014


   [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
              1998.

   [RFC3550]  Schulzrinne, H., Casner, S., Frederick, R., and V.
              Jacobson, "RTP: A Transport Protocol for Real-Time
              Applications", STD 64, RFC 3550, July 2003.

   [RFC3611]  Friedman, T., Caceres, R., and A. Clark, "RTP Control
              Protocol Extended Reports (RTCP XR)", RFC 3611, November
              2003.

   [RFC5102]  Quittek, J., Bryant, S., Claise, B., Aitken, P., and J.
              Meyer, "Information Model for IP Flow Information Export",
              RFC 5102, January 2008.

   [RFC5477]  Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
              Carle, "Information Model for Packet Sampling Exports",
              RFC 5477, March 2009.

   [RFC5905]  Mills, D., Martin, J., Burbank, J., and W. Kasch, "Network
              Time Protocol Version 4: Protocol and Algorithms
              Specification", RFC 5905, June 2010.

   [RFC6035]  Pendleton, A., Clark, A., Johnston, A., and H. Sinnreich,
              "Session Initiation Protocol Event Package for Voice
              Quality Reporting", RFC 6035, November 2010.

   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
              Performance Metric Development", BCP 170, RFC 6390,
              October 2011.

   [XRBLOCK]  IETF, , "Metric Blocks for use with RTCP's Extended Report
              Framework (XRBLOCK),
              http://datatracker.ietf.org/wg/xrblock/charter/", .

Authors' Addresses










Akhter & Claise         Expires September 4, 2014              [Page 21]


Internet-Draft            Passive Sub-Registry                March 2014


   Aamer Akhter
   Cisco Systems, Inc.
   7025 Kit Creek Road
   RTP, NC 27709
   USA

   Email: aakhter@cisco.com


   Benoit Claise
   Cisco Systems, Inc.
   De Kleetlaan 6a b1
   1831 Diegem
   Belgium

   Phone: +32 2 704 5622
   Email: bclaise@cisco.com


































Akhter & Claise         Expires September 4, 2014              [Page 22]


Html markup produced by rfcmarkup 1.123, available from https://tools.ietf.org/tools/rfcmarkup/