Internet DRAFT - draft-akhter-opsawg-perfmon-ipfix

draft-akhter-opsawg-perfmon-ipfix






Network Working Group                                          A. Akhter
Internet-Draft                                             Cisco Systems
Intended status: Standards Track                               H. Scholz
Expires: January 31, 2013                                VOIPFUTURE GmbH
                                                           July 30, 2012


    IPFIX Information Elements for RTP Flow Performance Measurement
                draft-akhter-opsawg-perfmon-ipfix-03.txt

Abstract

   There is a need to be able to quantify and report the performance of
   RTP based applications.  This performance data provides information
   essential in validating service level agreements, fault isolation as
   well as early warnings of greater problems.  This document describes
   IPFIX Information Elements related to RTP performance measurement of
   network based applications.  In addition, to the performance
   information several non-metric information elements are also included
   to provide greater context to the reports.  The measurements use
   audio/video applications as a base but are not restricted to these
   class of applications.  These new IPFIX Information Elements can
   describe the entire duration of an RTP stream or a smaller time slice
   of it.

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 January 31, 2013.

Copyright Notice

   Copyright (c) 2012 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



Akhter & Scholz         Expires January 31, 2013                [Page 1]

Internet-Draft                IPFIX PerfMon                    July 2012


   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.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  5
   3.  General Usage  . . . . . . . . . . . . . . . . . . . . . . . .  6
     3.1.  Quality of Service (QoS) Monitoring  . . . . . . . . . . .  6
     3.2.  Fault Isolation and Troubleshooting  . . . . . . . . . . .  6
   4.  New Information Elements . . . . . . . . . . . . . . . . . . .  7
     4.1.  Transport Layer  . . . . . . . . . . . . . . . . . . . . .  7
       4.1.1.  perfObservationType  . . . . . . . . . . . . . . . . .  7
       4.1.2.  perfIntervalStartMilliseconds  . . . . . . . . . . . .  8
       4.1.3.  perfIntervalEndMilliseconds  . . . . . . . . . . . . .  9
       4.1.4.  perfSampleOffsetMilliseconds . . . . . . . . . . . . . 10
       4.1.5.  perfSampleTimeMilliseconds . . . . . . . . . . . . . . 11
       4.1.6.  perfStreamState  . . . . . . . . . . . . . . . . . . . 12
       4.1.7.  perfPacketLoss . . . . . . . . . . . . . . . . . . . . 13
       4.1.8.  perfPacketExpected . . . . . . . . . . . . . . . . . . 13
       4.1.9.  perfPacketLossRate . . . . . . . . . . . . . . . . . . 14
       4.1.10. perfPacketLossEvent  . . . . . . . . . . . . . . . . . 14
       4.1.11. perfPacketInterArrivalJitterAvg  . . . . . . . . . . . 15
       4.1.12. perfPacketInterArrivalJitterMin  . . . . . . . . . . . 15
       4.1.13. perfPacketInterArrivalJitterMax  . . . . . . . . . . . 16
       4.1.14. rtpPacketizationTime . . . . . . . . . . . . . . . . . 17
       4.1.15. rtpPacketizationChange . . . . . . . . . . . . . . . . 17
       4.1.16. perfDuplicates . . . . . . . . . . . . . . . . . . . . 18
       4.1.17. rtpPacketOrder . . . . . . . . . . . . . . . . . . . . 19
       4.1.18. rtpSequenceError . . . . . . . . . . . . . . . . . . . 19
       4.1.19. perfRoundTripNetworkDelay  . . . . . . . . . . . . . . 19
     4.2.  User and Application Layer . . . . . . . . . . . . . . . . 20
       4.2.1.  perfSessionSetupDelay  . . . . . . . . . . . . . . . . 20
     4.3.  RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 20
       4.3.1.  rtpProtocolVersion . . . . . . . . . . . . . . . . . . 20
       4.3.2.  rtpSSRC  . . . . . . . . . . . . . . . . . . . . . . . 21
       4.3.3.  rtpPayloadType . . . . . . . . . . . . . . . . . . . . 22
       4.3.4.  rtpMediaType . . . . . . . . . . . . . . . . . . . . . 23
       4.3.5.  rtpMediaSubType  . . . . . . . . . . . . . . . . . . . 23
       4.3.6.  RTP Payload  . . . . . . . . . . . . . . . . . . . . . 24
       4.3.7.  rtpMediaType . . . . . . . . . . . . . . . . . . . . . 26



Akhter & Scholz         Expires January 31, 2013                [Page 2]

Internet-Draft                IPFIX PerfMon                    July 2012


       4.3.8.  rtpMediaSubType  . . . . . . . . . . . . . . . . . . . 26
       4.3.9.  rtpDelayType . . . . . . . . . . . . . . . . . . . . . 26
       4.3.10. rtpDelayOneWay . . . . . . . . . . . . . . . . . . . . 26
       4.3.11. rtpIsSRTP  . . . . . . . . . . . . . . . . . . . . . . 27
       4.3.12. rtpTimestamp . . . . . . . . . . . . . . . . . . . . . 27
       4.3.13. rtpCodecChange . . . . . . . . . . . . . . . . . . . . 27
       4.3.14. rtpMarkerBit . . . . . . . . . . . . . . . . . . . . . 27
       4.3.15. rtpComfortNoise  . . . . . . . . . . . . . . . . . . . 27
       4.3.16. rtpDSCPChange  . . . . . . . . . . . . . . . . . . . . 27
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 27
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 27
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 27
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 27
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 28
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29



































Akhter & Scholz         Expires January 31, 2013                [Page 3]

Internet-Draft                IPFIX PerfMon                    July 2012


1.  Introduction

   Today's networks support a multitude of highly demanding and
   sensitive network applications.  Network issues are readily apparent
   by the users of these applications due to the sensitivity of these
   applications to impaired network conditions.  Examples of these
   network applications include applications making use of IP based
   audio, video, database transactions, virtual desktop interface (VDI),
   online gaming, cloud services and many more.  In some cases, the
   impaired application translates directly to loss of revenue.  In
   other cases, there may be regulatory or contractual service level
   agreements that motivate the network operator.  Due to the
   sensitivity of these types of applications to impaired service it
   leaves a poor impression of the service on the user-- regardless of
   the actual performance of the network itself.  In the case of an
   actual problem within the network service, monitoring the performance
   may yield a early indicator of a much more serious problem.

   Due to the demanding and sensitive nature of these applications,
   network operators have tried to engineer their networks towards
   wringing better and differentiated performance.  However, that same
   differentiated design prevents network operators from extrapolating
   observational data from one application to another, or from one set
   of synthetic (active test) test traffic to actual application
   performance.  This gap highlights the importance of generic
   measurements as well as the reliance on user traffic measurements--
   rather than synthetic tests.

   Performance measurements on user data provide greater visibility not
   only into the quality of experience of the end users but also
   visibility into network health.  With regards to network health, as
   flow performance is being measured, there will be visibility into the
   end to end performance which means that not only visibility into
   local network health, but also viability into remote network health.
   If these measurements are made at multiple points within the network
   (or between the network and end device) then there is not only
   identification that there might be an issue, but a span of area can
   be established where the issue might be.  The resolution of the fault
   increases with the number of measurement points along the flow path.

   IP based applications, esp. those with real-time requirements, may
   suffer temporarily from impairments such as bandwidth bottlenecks or
   packet loss.  Performance measurement with average values is not able
   to record and highlight these issues.  Due to this the measurement
   interval must be configurable to a short time slice in order to
   indicate such temporary impairments.  Aggregation of measurements
   shall be possible to aggregate multiple measurements of the same
   application stream or multiple streams of the same type but



Akhter & Scholz         Expires January 31, 2013                [Page 4]

Internet-Draft                IPFIX PerfMon                    July 2012


   potentially generated by different users.

   The IP Flow Information Export Protocol (IPFIX) [RFC5101] provides
   new levels of flexibility in reporting from measurement points across
   the life cycle of a network based application.  IPFIX can provide
   granular results in terms of flow specificity as well as time
   granularity.  At the same time, IPFIX allows for summarization of
   data along different types of boundaries for operators that are
   unconcerned about specific sessions but about health of a service or
   a portion of the network.  This document details the expression of
   IPFIX Information Elements whose calculation is defined in an
   accompanying document.

   As this document covers the reporting of these metrics via IPFIX,
   consideration is taken with mapping the metric's capabilities and
   context with the IPFIX information and data representation model.
   The guidelines outlined in [I-D.trammell-ipfix-ie-doctors] are used
   to ensure proper IPFIX information element definition.

   There has been related work in this area such as [RFC2321].
   [I-D.huici-ipfix-sipfix], and [VoIP-monitor].


2.  Terminology

   Terms used in this document that are defined in the Terminology
   section of the IPFIX Protocol [RFC5101] document are to be
   interpreted as defined there.

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

   In addition, the information element definitions use the following
   terms:

   Name:  Name of the information element per the IPFIX rules defined in
      Section 2.3 of [RFC5102]

   Description:  Short description of what the information element is
      trying to convey.

   Observation Point:  Where the measurement is meant to be performed.
      Either at an intermediate point (for example, a router) or end
      system.






Akhter & Scholz         Expires January 31, 2013                [Page 5]

Internet-Draft                IPFIX PerfMon                    July 2012


   Element Data Type:  The IPFIX informationElementDataType as defined
      in Section 3.1 of [RFC5610]

   Element Semantics:  The IPFIX informationElementSemantics as defined
      in section Section 3.6 of [RFC5610]

   Element Units:  The IPFIX informationElementUnits as defined in
      section Section 3.7 of [RFC5610]

   Element Range Begin:  The IPFIX informationElementRangeBegin as
      defined in section Section 3.7 of [RFC5610]

   Element Range End:  The IPFIX informationElementRangeEnd as defined
      in section Section 3.7 of [RFC5610]

   Element Id:  The IPFIX global unique element ID as defined in Section
      3.2 of [RFC5101]

   Status:  The status of the specification of this IPFIX Information
      Element.


3.  General Usage

3.1.  Quality of Service (QoS) Monitoring

   For QoS monitoring, it is important to be able to capture the
   application context.  For example, in the case of interactive audio
   flows, the codec and the fact that the application is interactive
   should be captured.  The codec type can be used to determine loss
   thresholds affecting end user quality and the interactive nature
   would suggest thresholds over one way delay.  The IPFIX reporting
   would need to keep this information organized together for operator
   to be able to perform correlated analysis.

3.2.  Fault Isolation and Troubleshooting

   It has been generally easier to troubleshoot and fix problems that
   are binary in nature: it either works or does not work.  The host is
   pingable or not pingable.  However, the much more difficult to
   resolve issues that are transitory in nature, move from location to
   location, more complicated that simple ICMP reachability and many
   times unverifiable reports by the users themselves.  It is these
   intermittent and seemingly inconsistent network impairments that
   performance metrics can be extremely helpful with.  Just the basic
   timely detection that there is a problem (or an impending problem)
   can give the provider the confidence that there is a real problem
   that needs to be resolved.  The next step would be to assist the



Akhter & Scholz         Expires January 31, 2013                [Page 6]

Internet-Draft                IPFIX PerfMon                    July 2012


   operator in a speedy resolution by providing information regarding
   the network location and nature of the problem.

   Transient problems which affect a user only for a short time of this
   session can be made visible with measurements taken in short fixed
   time slices, e.g. every 10 seconds.  While a traditional measurement
   on a per session basis may not show an intermittent impairment (e.g.
   packet loss) the short measurement interval highlights these.


4.  New Information Elements

   The information elements are organized into two main groups:

   Transport Layer:  Metrics that might be calculated from observations
      at higher layers but essentially provide information about the
      network transport of user date.  For example, the metrics related
      to packet loss, latency and jitter would be defined here.

   RTP Header:  Information Elements that describe the RTP stream
      properties based on RTP header information but not the RTP payload
      itself.

   RTP Payload:  Information Elements that describe the RTP payload.
      For example, packet count and media type.

   User and Application Layer:  Metrics that are might be affected by
      the network indirectly, but are ultimately related to user, end-
      system and session states.  For example, session setup time,
      transaction rate and session duration would be defined here.

4.1.  Transport Layer

4.1.1.  perfObservationType

   Name:  perfObservationType

   Description:  The observation type is analog to sipObservationType
      defined in [trammel sip-msg].  It defines the place of the
      metering process in the network path.

   Observation Point:  The observation can be made anywhere along the
      media path or on the endpoints themselves.  The observation is
      only relevant in a unidirectional sense.







Akhter & Scholz         Expires January 31, 2013                [Page 7]

Internet-Draft                IPFIX PerfMon                    July 2012


   Element Data Type:  unsigned8

   Element Semantics:  identifier

   Element Units:  n/a

   Element Range Begin:  0

   Element Range End:  0xFF

   Element Id:  TBDperfObservationType

   Status:  current

   Use and Applications

      0: unknown: The Metering Process does not specify the observation
         type

      1: receiver: The Metering Process is, or is co-located with, the
         receiver of the RTP stream.

      2: sender: The Metering Process is, or is co-located with, the
         sender of the RTP stream.

      3: passive: The Metering Process passively observed the RTP
         stream.

      4: rtcp: The Metering Process obtains the data conveyed in the
         IPFIX message for one or more RTCP reports.

   Calculation Method:

   Units of Measurement:  n/a

   Measurement Timing

4.1.2.  perfIntervalStartMilliseconds

   Name:  perfIntervalStartMilliseconds

   Description:  Start time of the monitoring interval in milliseconds
      since 0000 UTC Jan 1, 1970.  The time is taken from the local
      clock which SHOULD be NTP synchronized.  If a flow only covers
      part of the monitoring interval (for example, the flow started
      after the interval start time), start time MUST be set to the
      start time of the monitoring interval.




Akhter & Scholz         Expires January 31, 2013                [Page 8]

Internet-Draft                IPFIX PerfMon                    July 2012


   Observation Point:

   Element Data Type:  dateTimeMilliseconds

   Element Semantics:  identifier

   Element Units:  n/a

   Element Range Begin:  0

   Element Range End:  ???

   Element Id:  TBDperfIntervalStartMilliseconds

   Status:  current

   Use and Applications

   Calculation Method:

   Units of Measurement:  n/a

   Measurement Timing

4.1.3.  perfIntervalEndMilliseconds

   Name:  perfIntervalEndMilliseconds

   Description:  End time of the flow's monitoring interval in
      milliseconds since 0000 UTC Jan 1, 1970.  The time is taken from
      the local clock which SHOULD be NTP synchronized.  If the flow
      covers part of the monitoring interval (for example, the flow
      ended before the interval end time), the
      perfIntervalEndMilliseconds MUST be set to the end of observation
      interval.

   Observation Point:

   Element Data Type:  datetimeMilliseconds

   Element Semantics:  identifier

   Element Units:  n/a

   Element Range Begin:  0






Akhter & Scholz         Expires January 31, 2013                [Page 9]

Internet-Draft                IPFIX PerfMon                    July 2012


   Element Range End:  0xFF

   Element Id:  TBDperfObservationType

   Status:  current

   Use and Applications

      0: unknown: The Metering Process does not specify the observation
         type

      1: receiver: The Metering Process is, or is co-located with, the
         receiver of the RTP stream.

      2: sender: The Metering Process is, or is co-located with, the
         sender of the RTP stream.

      3: passive: The Metering Process passively observed the RTP
         stream.

      4: rtcp: TBD

   Calculation Method:

   Units of Measurement:  n/a

   Measurement Timing

4.1.4.  perfSampleOffsetMilliseconds

   Name:  perfSampleOffsetMilliseconds

   Description:  Offset of the observation interval contained in this
      flow record.  The value is measured in milliseconds and contains
      the offset of the beginning of the flow record from the beginning
      of the RTP stream.

   Observation Point:

   Element Data Type:  unsigned32

   Element Semantics:  identifier

   Element Units:  milliseconds







Akhter & Scholz         Expires January 31, 2013               [Page 10]

Internet-Draft                IPFIX PerfMon                    July 2012


   Element Range Begin:  0

   Element Range End:  0xFFFFFFFF

   Element Id:  TBDperfSampleOffsetMilliseconds

   Status:  current

   Use and Applications

   Calculation Method:

   Measurement Timing

4.1.5.  perfSampleTimeMilliseconds

   Name:  perfSampleTimeMilliseconds

   Description:  An IPFIX observer may generate and export a flow record
      for the entire duration of an RTP stream or for a specific part,
      e.g. a fixed time slice of 10 seconds.  In case a single flow
      record is created the rtpSampleTime equals the RTP stream duration
      in milliseconds.  In either case the rtpStreamState IE should be
      set to true if this flow record describes an ended RTP stream.

   Observation Point:

   Element Data Type:  unsigned32

   Element Semantics:  DeltaCounter

   Element Units:  milliseconds

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFF

   Element Id:  TBDperfSampleTimeMilliseconds

   Status:  current

   Use and Applications

   Calculation Method:







Akhter & Scholz         Expires January 31, 2013               [Page 11]

Internet-Draft                IPFIX PerfMon                    July 2012


   Units of Measurement:  milliseconds

   Measurement Timing

4.1.6.  perfStreamState

   Name:  perfStreamState

   Description:  Using the rtpSampleOffset and rtpSampleTime IEs flow
      entries may be generated which describe only part of an RTP
      stream.  This IE is used to describe the state of the observed
      stream, e.g. to indicate the reception of the last flow record
      belonging to a single RTP stream.

   Observation Point:

   Element Data Type:  unsigned8

   Element Semantics:  identifier

   Element Units:  n/a

   Element Range Begin:  0

   Element Range End:  0xFF

   Element Id:  TBDperfObservationType

   Status:  current

   Use and Applications

      0: undefined: The state of the stream is not known.

      1: running: The Metering Process expects more RTP packets or has
         already received packets for this RTP stream which are outside
         the scope of this flow record.

      2: ended: The Metering Process determined that the RTP stream
         ended.  Information sources could be signaling information or
         the fact that no RTP media has been received for a longer
         period of time.

      3: no packets: The Metering Process has not received any RTP
         packets for this RTP stream in the observation interval but the
         stream has not ended.  A VoIP endpoint may have requested the
         media stream to be suspended, i.e. put 'on hold' (tbd:reference
         to sendonly ..)



Akhter & Scholz         Expires January 31, 2013               [Page 12]

Internet-Draft                IPFIX PerfMon                    July 2012


   Calculation Method:

   Units of Measurement:  n/a

   Measurement Timing

4.1.7.  perfPacketLoss

   Name:  perfPacketLoss

   Description:  The packet loss metric reports the number of individual
      packets that were lost in the reporting interval.

   Observation Point:  The observation can be made anywhere along the
      media path or on the endpoints them selves.  The observation is
      only relevant in a unidirectional sense.

   Element Data Type:  unsigned32

   Element Semantics:  deltaCounter

   Element Units:  packets

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfPacketLoss

   Status:  current

4.1.8.  perfPacketExpected

   Name:  perfPacketExpected

   Description:  The number of packets there were expected within a
      monitoring interval.

   Observation Point:  The observation can be made anywhere along the
      media path or on the endpoints them selves.  The observation is
      only relevant in a unidirectional sense.

   Element Data Type:  unsigned32

   Element Semantics:  deltaCounter






Akhter & Scholz         Expires January 31, 2013               [Page 13]

Internet-Draft                IPFIX PerfMon                    July 2012


   Element Units:  packets

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfPacketExpected

   Status:  current

4.1.9.  perfPacketLossRate

   Name:  perfPacketLossRate

   Description:  Percentage of number of packets lost out of the total
      set of packets sent.

   Observation Point:  The observation can be made anywhere along the
      media path or on the endpoints them selves.  The observation is
      only relevant in a unidirectional sense.

   Element Data Type:  unsigned16

   Element Semantics:  quantity

   Element Units:  float16 (IPFIX has not defined float16 yet)

   Element Range Begin:  0

   Element Range End:  0x64

   Element Id:  TBDperfPacketLossRate

   Status:  current

4.1.10.  perfPacketLossEvent

   Name:  perfPacketLossEvent

   Description:  The packet loss event metric reports the number of
      continuous sets of packets that were lost in the reporting
      interval.

   Observation Point:  The observation can be made anywhere along the
      media path or on the endpoints them selves.  The observation is
      only relevant in a unidirectional sense.





Akhter & Scholz         Expires January 31, 2013               [Page 14]

Internet-Draft                IPFIX PerfMon                    July 2012


   Element Data Type:  unsigned32

   Element Semantics:  deltaCounter

   Element Units:  event

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfPacketExpected

   Status:  current

4.1.11.  perfPacketInterArrivalJitterAvg

   Name:  perfPacketInterArrivalJitterAvg

   Description:  This metric measures the absolute deviation of the
      difference in packet spacing at the measurement point compared to
      the packet spacing at the sender.

   Observation Point:  The observation can be made anywhere along the
      media path or on the receiver.  The observation is only relevant
      in a unidirectional sense.

   Element Data Type:  unsigned32

   Element Semantics:  quantity

   Element Units:  microseconds

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfPacketInterArrivalJitterAvg

   Status:  current

4.1.12.  perfPacketInterArrivalJitterMin

   Name:  perfPacketInterArrivalJitterMin

   Description:  This metric measures the minimum value the calculation
      used for perfPacketInterArrivalJitterAvg within the monitoring
      interval.




Akhter & Scholz         Expires January 31, 2013               [Page 15]

Internet-Draft                IPFIX PerfMon                    July 2012


   Observation Point:  The observation can be made anywhere along the
      media path or on the receiver.  The observation is only relevant
      in a unidirectional sense.

   Element Data Type:  unsigned32

   Element Semantics:  quantity

   Element Units:  microseconds

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfPacketInterArrivalJitterMin

   Status:  current

4.1.13.  perfPacketInterArrivalJitterMax

   Name:  perfPacketInterArrivalJitterMax

   Description:  This metric measures the maximum value the calculation
      used for perfPacketInterArrivalJitterAvg within the monitoring
      interval.

   Observation Point:  The observation can be made anywhere along the
      media path or on the receiver.  The observation is only relevant
      in a unidirectional sense.

   Element Data Type:  unsigned32

   Element Semantics:  quantity

   Element Units:  microseconds

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfPacketInterArrivalJitterMax

   Status:  current








Akhter & Scholz         Expires January 31, 2013               [Page 16]

Internet-Draft                IPFIX PerfMon                    July 2012


4.1.14.  rtpPacketizationTime

   Name:  rtpPacketizationTime

   Description:  The RTP audio packetization time defines the amount of
      audio contained in the individual RTP packet.  This packetization
      is typically fixed for the duration of an RTP stream but may be
      changed.  The allowed values depend on the codec.  Values
      typically observed are 10, 20 or 30ms.

      Depending on the codec the amount of data contained in each RTP
      packet can be derived from RTP time stamp information or RTP
      payload size.

      If the packetization time changes during an IPFIX monitoring
      interval this value should indicate the most common value
      monitored.  Optionally the rtpPacketizationChange Information
      Element may be updated accordingly.

   Observation Point:  The observation can be made anywhere along the
      media path or on the receiver.  The observation is only relevant
      in a unidirectional sense.

   Element Data Type:  unsigned8

   Element Semantics:  quantity

   Element Units:  milliseconds

   Element Range Begin:  0

   Element Range End:  0xFF

   Element Id:  TBDrtpPacketizationTime

   Status:  current

4.1.15.  rtpPacketizationChange

   Name:  rtpPacketizationChange

   Description:  Each time the packetization time of the observed RTP
      stream changes during the monitoring interval this IE is
      incremented.







Akhter & Scholz         Expires January 31, 2013               [Page 17]

Internet-Draft                IPFIX PerfMon                    July 2012


   Observation Point:  The observation can be made anywhere along the
      media path or on the receiver.  The observation is only relevant
      in a unidirectional sense.

   Element Data Type:  unsigned32

   Element Semantics:  deltaCounter

   Element Units:  n/a

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFF

   Element Id:  TBDrtpPacketizationChange

   Status:  current

4.1.16.  perfDuplicates

   Name:  perfDuplicates

   Description:  Packets belonging to an observed stream or session may
      be duplicated.  The reason or source of duplication (e.g. the
      generator or entities on the network path) is out of scope of this
      IE.  This IE describes the number of protocol specific duplicate
      packets observed in the monitoring interval.

   Observation Point:  anywhere

   Element Data Type:  unsigned32

   Element Semantics:  deltaCounter

   Element Units:  packets

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfDuplicates

   Status:  current

   Use and Applications






Akhter & Scholz         Expires January 31, 2013               [Page 18]

Internet-Draft                IPFIX PerfMon                    July 2012


   Calculation Method:  The calculation method for duplicate packets
      depends on the transport and application protocol used.
      Duplicates on the application layer SHALL be counted if possible.

      For [RFC3550] style RTP streams the RTP sequence numbers MUST be
      used to identify duplicate packets.  If a packet with the same
      sequence number is observed twice or more in the monitoring
      interval it is counted as duplicate.  The perfDuplicates IE
      describes the number of duplicate packets received, not counting
      the first packet with each sequence number.

   Units of Measurement:  packets

   Measurement Timing  n/a

4.1.17.  rtpPacketOrder

4.1.18.  rtpSequenceError

4.1.19.  perfRoundTripNetworkDelay

   Name:  perfRoundTripNetworkDelay

   Description:  This metric measures the network round trip time
      between end stations for a flow.

   Observation Point:  The observation can be made anywhere along the
      flow path as long as the bidirectional network delay is accounted
      for.

   Element Data Type:  unsigned32

   Element Semantics:  quantity

   Element Units:  microseconds

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfRoundTripNetworkDelay

   Status:  current








Akhter & Scholz         Expires January 31, 2013               [Page 19]

Internet-Draft                IPFIX PerfMon                    July 2012


4.2.  User and Application Layer

4.2.1.  perfSessionSetupDelay

   Name:  perfSessionSetupDelay

   Description:  The Session Setup Delay metric reports the time taken
      from a request being initiated by a host/endpoint to the response
      (or request indicator) to the request being observed.  This metric
      is defined in [RFC4710], however the units have been updated to
      microseconds.

   Observation Point:  This metric needs to be calculated where both
      request and response can be observed.  This could be at network
      choke points, application proxies, or within the end systems
      themselves.

   Element Data Type:  unsigned32

   Element Semantics:  quantity

   Element Units:  microseconds

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDperfSessionSetupDelay

   Status:  current

4.3.  RTP Header

4.3.1.  rtpProtocolVersion

   Name:  rtpProtocolVersion

   Description:  Value of the RTP version taken from the RTP header.
      For [RFC3550] RTP packets this will typically be set to 2.

   Observation Point:  anywhere

   Element Data Type:  unsigned8

   Element Semantics:  identifier






Akhter & Scholz         Expires January 31, 2013               [Page 20]

Internet-Draft                IPFIX PerfMon                    July 2012


   Element Units:  none

   Element Range Begin:  0

   Element Range End:  0x02

   Element Id:  TBDrtpProtocolVersion

   Status:  current

   Use and Applications  The RTP protocol version is taken directly from
      the RTP header information.  It can be used to identify RTP
      packets and differ between different RTP versions once they become
      available.

   Calculation Method:  The value is obtained from the RTP header.  For
      [RFC3550] RTP this two bit field must always be set to two (2).
      In case different values are observed in a single monitoring
      interval the IE shall carry the value identified in the first RTP
      packet of the monitoring interval.

   Units of Measurement:  none

   Measurement Timing  does not apply.

4.3.2.  rtpSSRC

   Name:  rtpSSRC

   Description:  Value of the synchronization source (SSRC) field in the
      RTP header of the flow.  This field is defined in [RFC3550].

   Observation Point:  This metric can be gleaned from the RTP packets
      directly, so the observation point can be either on the any RTP
      endpoints or on the flow path in between the endpoints.  It is
      possible for the SSRC to change for a media flow without notice.
      In these cases the IE would represent the value seen in the
      packet-- the new SSRC and this would be treated as a new 'flow'
      per configured flow record definitions.

   Element Data Type:  unsigned32

   Element Semantics:  identifier

   Element Units:  none






Akhter & Scholz         Expires January 31, 2013               [Page 21]

Internet-Draft                IPFIX PerfMon                    July 2012


   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDrtpSSRC

   Status:  current

   Use and Applications  The RTP SSRC value denotes a specific media
      stream.  As such when trying to differentiate media stream
      problems between session participants the SSRC field is needed.

   Calculation Method:  Copy from RTP header's SSRC field as defined in
      [RFC3550].  In the case of a non-RTP flow, or the time period in
      which the flow has not been verified to be a RTP flow the value
      0xFFFFFFFE MUST be reported.

   Units of Measurement:  identifier

   Measurement Timing  It is possible that the SSRC may have be
      renegotiated mid-session due to collisions with other RTP senders.

4.3.3.  rtpPayloadType

   Name:  rtpPayloadType

   Description:  The value of the RTP Payload Type Field as observed in
      the RTP header of the flow.  This field is defined in [RFC3550]

   Observation Point:  This metric can be gleaned from the RTP packets
      directly, so the observation point needs to on the flow path or
      within the endpoints.

   Element Data Type:  unsigned8

   Element Semantics:  identifier

   Element Units:  none

   Element Range Begin:  0

   Element Range End:  0xFF

   Element Id:  TBDrtpPayloadType







Akhter & Scholz         Expires January 31, 2013               [Page 22]

Internet-Draft                IPFIX PerfMon                    July 2012


   Status:  current

4.3.4.  rtpMediaType

   Name:  rtpMediaType

   Description:  The rtpMediaType field carries the verbatim media type
      name (e.g.  Audio) as defined by [RFC4855].

   Observation Point:  anywhere

   Element Data Type:  string

   Element Semantics:  tbd

   Element Units:  n/a

   Element Range Begin:  n/a

   Element Range End:  n/a

   Element Id:  TBDrtpMediaType

   Status:  current

4.3.5.  rtpMediaSubType

   Name:  rtpMediaSubType

   Description:  The rtpMediaSubType field carries the verbatim media
      type name (e.g.  PCMA) as defined by [RFC4855].

   Observation Point:  anywhere

   Element Data Type:  string

   Element Semantics:  tbd

   Element Units:  n/a

   Element Range Begin:  n/a

   Element Range End:  n/a

   Element Id:  TBDrtpMediaSubType






Akhter & Scholz         Expires January 31, 2013               [Page 23]

Internet-Draft                IPFIX PerfMon                    July 2012


   Status:  current

4.3.6.  RTP Payload

   This section defines additional Information Elements which describe
   RTP stream payload and characteristics beyond the transport
   information.  Complicated metrics may be subject to different
   measurement methods.  In order to prevent data from being unusable
   due to incompatible formats or measurement methods most Information
   Elements are counter values which allow calculation of metrics on
   mediator or collector systems.  Additionally this allows matching
   flow records to be aggregated by addition, e.g. addition of the
   rtpPacketCount values of multiple observation intervals.

4.3.6.1.  rtpPacketCount

   Name:  rtpPacketCount

   Description:  Number of RTP packets covered in this flow record.
      This includes observed duplicate packets.

   Observation Point:  anywhere

   Element Data Type:  unsigned32

   Element Semantics:  deltaCounter

   Element Units:  packets

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDrtpPacketCount

   Status:  current

   Use and Applications  The packet count may be used in conjunction
      with the rtpPacketCountLoss and rtpPacketCountDiscard information
      elements to calculate a packet loss rate per monitoring interval.
      The benefit of transporting absolute numbers versus percentiles is
      that an IPFIX mediator or collector may merge multiple IPFIX
      records of the same or different RTP streams into a single record
      for aggregation purposes.







Akhter & Scholz         Expires January 31, 2013               [Page 24]

Internet-Draft                IPFIX PerfMon                    July 2012


   Calculation Method:  The IPFIX observer counts all packets belonging
      to the respective flow.  Lost packets as identified by skipped RTP
      sequence numbers MUST not be counted.  Duplicate packets MUST be
      counted.  The packet order is not observed and does not impact the
      packet count.

   Units of Measurement:  packets

   Measurement Timing

4.3.6.2.  rtpPacketCountLoss

   Name:  rtpPacketCountLoss

   Description:  Number of RTP packets lost in the duration covered by
      this flow record.  The number of lost packets SHOULD be calculated
      using the RTP sequence numbers.

   Observation Point:  anywhere

   Element Data Type:  unsigned32

   Element Semantics:  deltaCounter

   Element Units:  packets

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDrtpPacketCountLoss

   Status:  current

   Use and Applications

   Calculation Method:  The IPFIX observer tracks the RTP sequence
      numbers of each RTP stream and at the end of the monitoring
      interval counts the number of packets not received based on the
      missing sequence numbers.

   Units of Measurement:  packets

   Measurement Timing







Akhter & Scholz         Expires January 31, 2013               [Page 25]

Internet-Draft                IPFIX PerfMon                    July 2012


4.3.6.3.  rtpPacketCountDiscard

   Name:  rtpPacketCountDiscard

   Description:  Passive monitoring equipment shall assume a fixed 40
      millisecond jitter buffer (TODO: add reference to TM Forum/ITU).
      A packet observed later than the expected packet inter-arrival
      time plus the 40ms is assumed to be received by the RTP receiver
      too late to be played out.  Even though the packet may be received
      by the RTP receiver it will be discarded which has the same effect
      as packet loss.

   Observation Point:  anywhere

   Element Data Type:  unsigned32

   Element Semantics:  deltaCounter

   Element Units:  packets

   Element Range Begin:  0

   Element Range End:  0xFFFFFFFE

   Element Id:  TBDrtpPacketCountDiscard

   Status:  current

   Use and Applications

   Calculation Method:  The IPFIX observer implements a 40ms jitter
      buffer per RTP stream observing sequence numbers as an RTP
      endpoint would do.  Packets received 40ms after their scheduled
      playout time are considered discarded.  Lost packets MUST not be
      counted as discarded.

   Units of Measurement:  packets

   Measurement Timing

4.3.7.  rtpMediaType

4.3.8.  rtpMediaSubType

4.3.9.  rtpDelayType

4.3.10.  rtpDelayOneWay




Akhter & Scholz         Expires January 31, 2013               [Page 26]

Internet-Draft                IPFIX PerfMon                    July 2012


4.3.11.  rtpIsSRTP

4.3.12.  rtpTimestamp

4.3.13.  rtpCodecChange

4.3.14.  rtpMarkerBit

4.3.15.  rtpComfortNoise

4.3.16.  rtpDSCPChange


5.  Security Considerations

   The recommendations in this document do not introduce any additional
   security issues to those already mentioned in [RFC5101] and [RFC5477]


6.  IANA Considerations

   This document requires an elements assignment to be made by IANA.


7.  Acknowledgements

   The authors would like to thank Shingo Kashima, Jan Novak and Al
   Morton for their invaluable review and comments.  Thank-you.


8.  References

8.1.  Normative References

   [RFC5101]  Claise, B., "Specification of the IP Flow Information
              Export (IPFIX) Protocol for the Exchange of IP Traffic
              Flow Information", RFC 5101, January 2008.

   [RFC5610]  Boschi, E., Trammell, B., Mark, L., and T. Zseby,
              "Exporting Type Information for IP Flow Information Export
              (IPFIX) Information Elements", RFC 5610, July 2009.

   [RFC4710]  Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time
              Application Quality-of-Service Monitoring (RAQMON)
              Framework", RFC 4710, October 2006.

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



Akhter & Scholz         Expires January 31, 2013               [Page 27]

Internet-Draft                IPFIX PerfMon                    July 2012


              RFC 5102, January 2008.

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

   [RFC3497]  Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP
              Payload Format for Society of Motion Picture and
              Television Engineers (SMPTE) 292M Video", RFC 3497,
              March 2003.

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

   [RFC4855]  Casner, S., "Media Type Registration of RTP Payload
              Formats", RFC 4855, February 2007.

   [RFC6076]  Malas, D. and A. Morton, "Basic Telephony SIP End-to-End
              Performance Metrics", RFC 6076, January 2011.

   [iana-ipfix-assignments]
              Internet Assigned Numbers Authority, "IP Flow Information
              Export Information Elements
              (http://www.iana.org/assignments/ipfix/ipfix.xml)".

8.2.  Informative References

   [I-D.trammell-ipfix-ie-doctors]
              Trammell, B. and B. Claise, "Guidelines for Authors and
              Reviewers of IPFIX Information Elements",
              draft-trammell-ipfix-ie-doctors-03 (work in progress),
              October 2011.

   [RFC2508]  Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
              Headers for Low-Speed Serial Links", RFC 2508,
              February 1999.

   [RFC3711]  Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K.
              Norrman, "The Secure Real-time Transport Protocol (SRTP)",
              RFC 3711, March 2004.

   [RFC2250]  Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar,
              "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250,
              January 1998.

   [RFC2890]  Dommety, G., "Key and Sequence Number Extensions to GRE",
              RFC 2890, September 2000.



Akhter & Scholz         Expires January 31, 2013               [Page 28]

Internet-Draft                IPFIX PerfMon                    July 2012


   [RFC4303]  Kent, S., "IP Encapsulating Security Payload (ESP)",
              RFC 4303, December 2005.

   [RFC5761]  Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
              Control Packets on a Single Port", RFC 5761, April 2010.

   [I-D.huici-ipfix-sipfix]
              Huici, F., Niccolini, S., and S. Anderson, "SIPFIX: Use
              Cases and Problem Statement for VoIP Monitoring and
              Exporting", draft-huici-ipfix-sipfix-00 (work in
              progress), June 2009.

   [RFC2321]  Bressen, A., "RITA -- The Reliable Internetwork
              Troubleshooting Agent", RFC 2321, April 1998.

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

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

   [VoIP-monitor]
              L. Chang-Yong, H. Kim, K. Ko, J. Jim, and H. Jeong, "A
              VoIP Traffic Monitoring System based on NetFlow v9,
              International Journal of Advanced Science and Technology,
              vol. 4, Mar. 2009".


Authors' Addresses

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

   Email: aakhter@cisco.com













Akhter & Scholz         Expires January 31, 2013               [Page 29]

Internet-Draft                IPFIX PerfMon                    July 2012


   Hendrik Scholz
   VOIPFUTURE GmbH
   Wendenstrasse 4
   Hamburg  20097
   Germany

   Phone: +49 40 688 900 100
   Email: hscholz@voipfuture.com
   URI:   http://www.voipfuture.com/










































Akhter & Scholz         Expires January 31, 2013               [Page 30]