< draft-akhter-ipfix-perfmon-00.txt   draft-akhter-ipfix-perfmon-01.txt >
IPFIX Working Group A. Akhter IPFIX Working Group A. Akhter
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track October 17, 2010 Intended status: Standards Track October 25, 2010
Expires: April 20, 2011 Expires: April 28, 2011
Information Elements for Flow Performance Measurement Information Elements for Flow Performance Measurement
draft-akhter-ipfix-perfmon-00.txt draft-akhter-ipfix-perfmon-01.txt
Abstract Abstract
There is a need to be able to quantify and report the performance of There is a need to be able to quantify and report the performance of
network applications and the network service in handling user data. network applications and the network service in handling user data.
This performance data provides information essential in validating This performance data provides information essential in validating
service level agreements, fault isolation as well as early warnings service level agreements, fault isolation as well as early warnings
of greater problems. This document describes IPFIX Information of greater problems. This document describes IPFIX Information
Elements related to performance measurement of network based Elements related to performance measurement of network based
applications. In addition, to the performance information several applications. In addition, to the performance information several
skipping to change at page 1, line 40 skipping to change at page 1, line 40
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 April 20, 2011. This Internet-Draft will expire on April 28, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 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
skipping to change at page 2, line 17 skipping to change at page 2, line 17
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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 5
3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 5 3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 5
3.2. Service Level Agreemnt (SLA) Validation . . . . . . . . . 5 3.2. Service Level Agreemnt (SLA) Validation . . . . . . . . . 6
3.3. Fault Isolation and Troubleshooting . . . . . . . . . . . 6 3.3. Fault Isolation and Troubleshooting . . . . . . . . . . . 6
4. New Information Elements . . . . . . . . . . . . . . . . . . . 6 4. New Information Elements . . . . . . . . . . . . . . . . . . . 6
4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 6 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 7
4.1.1. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 6 4.1.1. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 7
4.1.2. perfPacketExpected . . . . . . . . . . . . . . . . . . 8 4.1.2. perfPacketExpected . . . . . . . . . . . . . . . . . . 9
4.1.3. perfPacketLossRate . . . . . . . . . . . . . . . . . . 9 4.1.3. perfPacketLossRate . . . . . . . . . . . . . . . . . . 10
4.2. User and Application Layer . . . . . . . . . . . . . . . . 10 4.1.4. perfPacketLossEvent . . . . . . . . . . . . . . . . . 11
4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 10 4.1.5. perfPacketInterArrivalJitterAvg . . . . . . . . . . . 12
4.3. Contextual Elements . . . . . . . . . . . . . . . . . . . 11 4.1.6. perfPacketInterArrivalJitterMin . . . . . . . . . . . 14
4.3.1. mediaRTPSSRC . . . . . . . . . . . . . . . . . . . . . 11 4.1.7. perfPacketInterArrivalJitterMax . . . . . . . . . . . 15
4.3.2. mediaRTPPayloadType . . . . . . . . . . . . . . . . . 12 4.2. User and Application Layer . . . . . . . . . . . . . . . . 16
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.3. Contextual Elements . . . . . . . . . . . . . . . . . . . 17
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.3.1. mediaRTPSSRC . . . . . . . . . . . . . . . . . . . . . 17
7.1. Normative References . . . . . . . . . . . . . . . . . . . 14 4.3.2. mediaRTPPayloadType . . . . . . . . . . . . . . . . . 18
7.2. Informative References . . . . . . . . . . . . . . . . . . 14 4.3.3. mediaCodec . . . . . . . . . . . . . . . . . . . . . . 19
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
7.1. Normative References . . . . . . . . . . . . . . . . . . . 20
7.2. Informative References . . . . . . . . . . . . . . . . . . 21
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22
1. Introduction 1. Introduction
Today's networks support a multitude of highly demanding and Today's networks support a multitude of highly demanding and
sensitive network applications. Network issues are readily apparent sensitive network applications. Network issues are readily apparent
by the users of these applications due to the sensitivity of these by the users of these applications due to the sensitivity of these
applications to impaired network conditions. Examples of these applications to impaired network conditions. Examples of these
network applications include applications making use of IP based network applications include applications making use of IP based
audio, video, database transactions, virtual desktop interface (VDI), audio, video, database transactions, virtual desktop interface (VDI),
online gaming, cloud services and many more. In some cases the online gaming, cloud services and many more. In some cases the
skipping to change at page 4, line 5 skipping to change at page 4, line 5
new levels of flexibility in reporting from measurement points across new levels of flexibility in reporting from measurement points across
the life cycle of a network based application. IPFIX can provide the life cycle of a network based application. IPFIX can provide
granular results in terms of flow specificity as well as time granular results in terms of flow specificity as well as time
granularity. At the same time, IPFIX allows for summarization of granularity. At the same time, IPFIX allows for summarization of
data along different types of boundaries for operators that are data along different types of boundaries for operators that are
unconcerned about specific sessions but about health of a service or unconcerned about specific sessions but about health of a service or
a portion of the network. a portion of the network.
Where possible, an attempt has been made to make use of existing Where possible, an attempt has been made to make use of existing
definitions of metrics ([RFC4710]) and if needed, clarify and expand definitions of metrics ([RFC4710]) and if needed, clarify and expand
on them to widen their usage with additional applications. As this on them to widen their usage with additional applications. The
document also covers the reporting of these metrics via IPFIX, methodology described in [I-D.ietf-pmol-sip-perf-metrics] is used to
consideration is taken with mapping the metric's capabilities and describe the methodology of measurement. As this document also
context with the IPFIX information and data representation model. 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]. This document is also
an attempt to generalize as well as standardize the reporting formats
and measurement methodology.
2. Terminology 2. Terminology
Terms used in this document that are defined in the Terminology Terms used in this document that are defined in the Terminology
section of the IPFIX Protocol [RFC5101] document are to be section of the IPFIX Protocol [RFC5101] document are to be
interpreted as defined there. interpreted as defined there.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
skipping to change at page 5, line 5 skipping to change at page 5, line 14
Element Units: The IPFIX informationElementUnits as defined in Element Units: The IPFIX informationElementUnits as defined in
section Section 3.7 of [RFC5610] section Section 3.7 of [RFC5610]
Element Range Begin: The IPFIX informationElementRangeBegin as Element Range Begin: The IPFIX informationElementRangeBegin as
defined in section Section 3.7 of [RFC5610] defined in section Section 3.7 of [RFC5610]
Element Range End: The IPFIX informationElementRangeEnd as defined Element Range End: The IPFIX informationElementRangeEnd as defined
in section Section 3.7 of [RFC5610] in section Section 3.7 of [RFC5610]
Element Id: The IPFIX global unique element ID as defind in Section Element Id: The IPFIX global unique element ID as defined in Section
3.2 of [RFC5101] 3.2 of [RFC5101]
Status: The status of the specification of this IPFIX Information Status: The status of the specification of this IPFIX Information
Element. Element.
Use and Applications An explanation of how this particular Use and Applications An explanation of how this particular
information element would be used. information element would be used.
Calculation Method: In the case of metrics, this section describes Calculation Method: In the case of metrics, this section describes
how the metric is calculated, as well as any special conditions. how the metric is calculated, as well as any special conditions.
skipping to change at page 5, line 30 skipping to change at page 5, line 39
Measurement Timing: Discussion on the acceptable range of timing and Measurement Timing: Discussion on the acceptable range of timing and
sampling intervals. sampling intervals.
3. General Usage 3. General Usage
3.1. Quality of Service (QoS) Monitoring 3.1. Quality of Service (QoS) Monitoring
The network operator needs to be able to gauge the end user's The network operator needs to be able to gauge the end user's
satisfaction with the network service. While there are many satisfaction with the network service. While there are many
components of the satifaction such as pricing, packaging, offering, components of the satisfaction such as pricing, packaging, offering,
etc., a major compoenent of satisfaction is delivering a consistant etc., a major component of satisfaction is delivering a consistent
service. The user builds trust on this consistancy of the network service. The user builds trust on this consistency of the network
service and is then to be able to run network applications-- which is service and is then to be able to run network applications-- which is
of course the the end goal. Without the ability to deliver a of course the end goal. Without the ability to deliver a consistent
consistant service for end user network applications network operator service for end user network applications network operator will be
will be left dealing with price sensitive disgruntled users with very left dealing with price sensitive disgruntled users with very low
low expectations (if they don't have choice of operator) or expectations (if they don't have choice of operator) or abandonment
abandonment (if they have choice). (if they have choice).
3.2. Service Level Agreemnt (SLA) Validation 3.2. Service Level Agreemnt (SLA) Validation
Similar to QoS and QoE validation, there might be contractual or Similar to QoS and QoE validation, there might be contractual or
regulatory requirements that need to be met by the network operator. regulatory requirements that need to be met by the network operator.
Monitoring the performance of the flows allows the application Monitoring the performance of the flows allows the application
operator, network operator as well as the end user to validate of the operator, network operator as well as the end user to validate of the
target service is being deliverd. While there is quite a diverstiy target service is being delivered. While there is quite a diversity
in the codification of network SLAs they may eventually involve some in the codification of network SLAs they may eventually involve some
measurement of network uptime, end to end latency, end to end jitter measurement of network uptime, end to end latency, end to end jitter
and perhaps service response time. In the case violation of the SLA, and perhaps service response time. In the case violation of the SLA,
the start and end times, nature and network scope of the violation the start and end times, nature and network scope of the violation
needs to be captured to allow for the most accurate settling of the needs to be captured to allow for the most accurate settling of the
SLA. SLA.
3.3. Fault Isolation and Troubleshooting 3.3. Fault Isolation and Troubleshooting
It has been generally easier to troubelshoot and fix problems that 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 are binary in nature: it either works or does not work. The host is
pingable or not pingable. However, the much more difficult to pingable or not pingable. However, the much more difficult to
resolve issues that are transitory in nature, move from location to resolve issues that are transitory in nature, move from location to
location, more complicated that simple ICMP reachability and many location, more complicated that simple ICMP reachability and many
times unverifiable reports by the users themselves. It is these times unverifiable reports by the users themselves. It is these
intermittant and seemingly inconsistant network impairments that intermittent and seemingly inconsistent network impairments that
performance metrics can be extremely helpful with. Just the basic performance metrics can be extremely helpful with. Just the basic
timely detection that there is a problem (or an impending problem) timely detection that there is a problem (or an impending problem)
can give the providor the confidence that there is a real problem can give the provider the confidence that there is a real problem
that needs to be resolved. The next step woudl be to assist the that needs to be resolved. The next step would be to assist the
operator in a speedy resolution by providing information regarding operator in a speedy resolution by providing information regarding
the network locaton and nature of the problem. the network location and nature of the problem.
4. New Information Elements 4. New Information Elements
The information elements are organized into two main groups: The information elements are organized into two main groups:
Transport Layer: Metrics that might be calculated from observations Transport Layer: Metrics that might be calculated from observations
at higher layers but essentially provide information about the at higher layers but essentially provide information about the
network transport of user date. For example, the metrics related network transport of user date. For example, the metrics related
to packet loss, latency and jitter would be defined here. to packet loss, latency and jitter would be defined here.
skipping to change at page 7, line 27 skipping to change at page 7, line 40
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDperfPacketLoss Element Id: TBDperfPacketLoss
Status: current Status: current
Use and Applications The packet loss metric can be used to determine Use and Applications The packet loss metric can be used to determine
if there is a network impairment that is causing packet loss if there is a network impairment that is causing packet loss
upstream of the measurement point. When there are observation upstream of the measurement point. When there are observation
points on either side of the impairment location it is possible to points on either side of the impairment location it is possible to
locate the impairment. With the location information teh operator locate the impairment. With the location information the operator
can is able to perform quicker fault-isolation as well as shorten can is able to perform quicker fault-isolation as well as shorten
time to resolution. time to resolution.
Calculation Method: This metric requires that each IP packet be Calculation Method: This metric requires that each IP packet be
individually marked with a monotonically incrementing sequence individually marked with a monotonically incrementing sequence
number. A number of encapsulations support this type of number. A number of encapsulations support this type of
sequencing: IPSec ESP [RFC4303], GRE [RFC2890] and RTP [RFC3550]. sequencing: IPSec ESP [RFC4303], GRE [RFC2890] and RTP [RFC3550].
And an analyis of the sequence number field can yeild the lost An analysis of the sequence number field can yield the lost number
number of packets. In certain cases, there might be an element of of packets. In certain cases, there might be an element of
discovery and synchronization of the flow it self before the discovery and synchronization of the flow itself before the
measurement can be made. An example of this can be found for RTP measurement can be made. An example of this can be found for RTP
flows running on ephemeral UDP port numbers. In these cases, flows running on ephemeral UDP port numbers. In these cases,
reporting 0 as packet loss would be misleading and the value reporting 0 as packet loss would be misleading and the value
0xFFFFFFFF must be used in cases where the packet loss value can 0xFFFFFFFF MUST be used in cases where the packet loss value
not be determined. In the case of a monitor interval where cannot be determined. In the case of a monitor interval where
synchronization was acheived mid-interval, the loss packet counter synchronization was achieved mid-interval, the loss packet counter
MAY be used to represent remainder of the interval. As this MAY be used to represent the remainder of the interval. As this
metric is a deltaCounter the number of loss packets only represent metric is a deltaCounter, the number of loss packets only
the observation within the reporting interval. Due to the represent the observation within the reporting interval. Due to
dependency on the arrival of a packet with a sequcnce number to the dependency on the arrival of a packet with a sequence number
calculate loss, the loss calculation may be indefenitely delayed to calculate loss, the loss calculation may be indefinitely
if no more packets arrive at all. For the case of RTP, in delayed if no more packets arrive at all. For the case of RTP, in
addition to the 16 bit sequence number field in RFC3550, there is addition to the 16 bit sequence number field in RFC3550, there is
also the additional 16-bit high-order sequence number field (for a also the additional 16-bit high-order sequence number field (for a
total of 32-bit seq number space) that is used in RFC3497 total of 32-bit seq number space) that is used in RFC3497
[RFC3497]. RFC3497 traffic runs at a very high rate and the 32- [RFC3497]. RFC3497 traffic runs at a very high rate and the 32-
bit field allow for additional time for wrapping (21 seconds). bit field allow for additional time for wrapping (21 seconds).
So, a loss span of greater than 21 seconds measured only by the So, a loss span of greater than 21 seconds measured only by the
16-bit field will lead to inaccurate reporting. In the case of 16-bit field will lead to inaccurate reporting. In the case of
secure RTP [RFC3711], the relevant portion of the RTP header is in secure RTP [RFC3711], the relevant portion of the RTP header is in
the clear and lost packet counting can still be performed. It is the clear and lost packet counting can still be performed. It is
important to note that the sequence number space is unique per RTP important to note that the sequence number space is unique per RTP
SSRC. Therefore it is important to track the high sequence number SSRC. Therefore it is important to track the high sequence number
seen on a per SSRC-5-tuple basis. There may be multiple SSRCs in seen on a per SSRC-5-tuple basis. There may be multiple SSRCs in
a single 5-tuple. Certain applications inject non-RTP traffic a single 5-tuple. Certain applications inject non-RTP traffic
into the same 5-tuple as the media stream. RTCP packets may be into the same 5-tuple as the media stream. RTCP packets may be
seen in the same 5-tuple as the RTP stream [RFC5761], and STUN seen in the same 5-tuple as the RTP stream [RFC5761], and STUN
[RFC3489] packets may also be seen. The loss detection should [RFC5389] packets may also be seen. The loss detection should
ignore these packets. ignore these packets. There may be spans within the network where
header compression schemes such as [RFC2508] are used. In cases
where the measurement device is terminating the compression, and
the measurement implementation does not support calculation of the
metric the value 0xFFFFFFFF MUST be reported. In other cases the
measurement point may be at a midpoint of the header compression
network span. Depending on the mechanics of header compression,
sequencing information may be present and it is possible to
calculate the metric. In such cases the implementation SHOULD
perform the calculation and report the metric.
Units of Measurement: packets Units of Measurement: packets
Measurment Timing To be able to calculate this metric a continous Measurment Timing To be able to calculate this metric a continuous
set of the flow's packets (as each woudl have an incrementing set of the flow's packets (as each would have an incrementing
sequence number) needs to be monitored. Therefore, per-packet sequence number) needs to be monitored. Therefore, per-packet
sampling would prevent this metric from being calculated. sampling would prevent this metric from being calculated.
However, there are other sampling methodoligies that might be However, there are other sampling methodologies that might be
usabel. It is possible to generate sampled metrics by sampling usable. It is possible to generate sampled metrics by sampling
spans of continous packets, however a portion of the span may have spans of continuous packets, however a portion of the span may
to be utilized for resynchronization of the sequence number. have to be utilized for resynchronization of the sequence number.
Another form of acceptable sampling would be at the flow level. Another form of acceptable sampling would be at the flow level.
4.1.2. perfPacketExpected 4.1.2. perfPacketExpected
Name: perfPacketExpected Name: perfPacketExpected
Description: The number of packets there were expected within a Description: The number of packets there were expected within a
monitoring interval. monitoring interval.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
skipping to change at page 9, line 4 skipping to change at page 9, line 23
media path or on the endpoints them selves. The observation is media path or on the endpoints them selves. The observation is
only relevant in a unidirectional sense. only relevant in a unidirectional sense.
Element Data Type: unsigned32 Element Data Type: unsigned32
Element Semantics: deltaCounter Element Semantics: deltaCounter
Element Units: none Element Units: none
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDperfPacketExpected Element Id: TBDperfPacketExpected
Status: current Status: current
Use and Applications The perfPacketExpected is a mid-calculation Use and Applications The perfPacketExpected is a mid-calculation
metric used in the calculation of perfPacketLossRate. metric used in the calculation of perfPacketLossRate.
Calculation Method: The subtraction of the last sequence number from Calculation Method: The subtraction of the last sequence number from
the first sequence numebr in monitoirng interval yeilds the the first sequence number in monitoring interval yields the
expected count. As discussed with perfPacketLost, there might be expected count. As discussed with perfPacketLost, there might be
a delay due to synchronization with the flows's sequnce numbers a delay due to synchronization with the flow's sequence numbers
and in such times the value of the metric should be set to and in such times the value of the metric should be set to
0xFFFFFFFE. Care has to be taken to account for cases where the 0xFFFFFFFE. Care has to be taken to account for cases where the
packet's sequence number field wraps. For RTP the expected count packet's sequence number field wraps. For RTP, the expected count
calculation formula can be found in Appendix A.3 of [RFC3550] calculation formula can be found in Appendix A.3 of [RFC3550].
Refer to the perfPacketLoss metric regarding considerations for
header compression. The value 0xFFFF is used to represent cases
where the metric could not be calculated.
Units of Measurement: packets Units of Measurement: packets
Measurment Timing Same considerations as perfPacketLoss Measurment Timing Same considerations as perfPacketLoss
4.1.3. perfPacketLossRate 4.1.3. perfPacketLossRate
Name: perfPacketLossRate Name: perfPacketLossRate
Description: Percentage of number of packets lost out of the total Description: Percentage of number of packets lost out of the total
skipping to change at page 10, line 4 skipping to change at page 10, line 27
Element Semantics: quantity Element Semantics: quantity
Element Units: none Element Units: none
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFE Element Range End: 0xFFFE
Element Id: TBDperfPacketLossRate Element Id: TBDperfPacketLossRate
Status: current Status: current
Use and Applications The perfPacketLossRate metric can be used to Use and Applications The perfPacketLossRate metric can be used to
normalize the perfPacketLoss metric to handle cases where normalize the perfPacketLoss metric to handle cases where
different flows are running at different packet per second (pps) different flows are running at different packet per second (PPS)
rates. Due to the normalization, comparisons can now be made rates. Due to the normalization, comparisons can now be made
against thresholds (for creating alerts, etc.). In addition, the against thresholds (for creating alerts, etc.). In addition, the
percentage form of the metric allows for comparisons against other percentage form of the metric allows for comparisons against other
flows at the same observation point to determine if there is an flows at the same observation point to determine if there is an
equal bias for drops between the flows. Otherwise, the equal bias for drops between the flows. Otherwise, the
perfoPacketLossRate is used in same way as perfPacketLoss. perfoPacketLossRate is used in same way as perfPacketLoss.
Calculation Method: The number of lost packets divided by the number Calculation Method: The number of lost packets divided by the number
of expected packets in an interval period multiplied by 100. In of expected packets in an interval period multiplied by 100. In
cases where perfPacketLoss is unknown (for example due to cases where perfPacketLoss is unknown (for example due to
synchronization issues), the perfPacketLossRate woudl also be synchronization issues), the perfPacketLossRate would also be
unknown. In such cases perfPacketLossRate MUST be set to 0xFFFF. unknown. In such cases perfPacketLossRate MUST be set to 0xFFFF.
If there are multiple flows whose loss rate is being aggregated, If there are multiple flows whose loss rate is being aggregated,
then the average of the individual flows is used. then the average of the individual flows is used. Refer to the
perfPacketLoss metric regarding considerations for header
compression. The value 0xFFFF is used to represent cases where
the metric could not be calculated.
Units of Measurement: percentage Units of Measurement: percentage
Measurment Timing Same notes as perfPacketLossRate Measurment Timing Same notes as perfPacketLossRate
4.1.4. 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.
Element Data Type: unsigned32
Element Semantics: deltaCounter
Element Units: packets
Element Range Begin: 0
Element Range End: 0xFFFFFFFE
Element Id: TBDperfPacketLossEvent
Status: current
Use and Applications The perfPacketLossEvent metric can provide loss
information for protocols that do not implement per packet
sequencing. Similarly to the perfPacketLoss metric, the packet
loss event metric can be used to determine if there is a network
impairment that is causing packet loss upstream of the measurement
point. In cases where both the perfPacketLoss and
perfPacketLossEvent metric are available, the ratio between the
packet loss and packet event count can provide the average loss
length. The average loss length provides additional information
regarding the cause of the loss. For example, a dirty fiber
connection might have a low average loss length, while a routing
protocol convergence will have a high loss length.
Calculation Method: This data value is a simplified version of the
Lost Packets metric. Whereas Lost Packets counts individual
packet loss, the 'loss event count' metric counts sets of packets
that are lost. For example, in the case of a sequence of packets:
1,3,6,7,10 the packets marked 2,4,5,8 and 9 are lost. So, a total
of 5 packets are lost. This same sequence translates to 3 loss
events: (2), (4,5) and (8,9). In the case of RTP, the sequence
number in the RTP header can be used to identify loss events.
Certain protocols such as TCP and UDP+MPEG2-TS encapsulation in IP
have sequencing information, but the sequence field is incremented
by individual IP packets. As a side note, in the case of UDP+
MPEG2-TS encapsulation the simple use of RTP+MPEG2-TS via
[RFC2250] results in the avaliability of the more granular
perfPacketLoss metrics. In these cases, the perfPacketLoss metric
cannot be calculated but the perfPacketLossEvent can be calculated
and can provide detection of loss. The value 0xFFFFFFFF is used
to represent non-applicable cases such as lack of sequence number
synchronization. Many of the same considerations as for
perfPacketLoss apply to perfPacketLoss event. Please refer to the
Calculation Method section of the perfPacketLoss.
Units of Measurement: event counts
Measurment Timing Please refer to the measurement timing section of
perfPacketLoss.
4.1.5. 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
Use and Applications The inter arrival jitter data value can be used
be network operator to determine the network's impact to the
spacing in between a media stream's packets as they traverse the
network. For example, in the case of media applications, the
receiving end system is expecting these packets to come in at a
particular periodicity and large deviations may result in de-
jitter buffers adding excessive delay, or the media packets being
discarded. When the data is reported from multiple intermediate
nodes, the area of the network that is having a detrimental
contribution can be identified. On a non-media application level,
the inter arrival jitter metrics can be used for early indication
queuing contention within the network (which could lead to packet
loss).
Calculation Method: The inter arrival jitter value makes use of the
association of sending time with an IP packets and comparison of
the arrival time on the monitoring point. In certain protocols, a
representation of sending time is encoded into the header itself.
For example, in the case of RTP packets, the RTP header's
timestamps field represents encoder clock ticks-- which are
representations of time. Similarly, in the case of TCP options
encode absolute timestamps values. For RTP the calculation method
can be found in Appendix A of [RFC3550]. It should be noted that
the RFC3550 calculation is on the last 16 packets measured. The
most recent value calculated SHOULD be reported at the end of the
monitoring interval. The range of the jitter values during the
monitoring interval can be reported using
perfPacketInterArrivalJitterMin and
perfPacketInterArrivalJitterMax. Similarly to the perfPacketLoss
case there may be periods of time where the jitter value cannot be
calculated. In these cases, the 0xFFFFFFFF value should be used
to convey the lack of availability of the metric. As mentioned
earlier, the RTP header timestamps is actually a 'sample-stamp'
(ie clicks) from the encoder's clock. The frequency of the clock
is dependent on the codec. Some codecs (eg AAC-LD) support
multiple possible frequencies one of which is then selected for
the media-stream. The mapping to clock rate can be performed via
mapping from the static RTP payload type (RTP-PT), but newer
codecs are make use of the dynamic payload type range and the
RTP-PT (in the dynamic case) cannot be used to determine the clock
frequency. There are various methods by which the clock frequency
(deep packet inspection of the signalling, manual configuration,
etc.) can be associated to the calculation method. The frequency
should be locked in the metering layer to a unique combination of
the IP source, IP destination, IP protocol layer-4 ports, RTP-PT
and SSRC. By strict RFC3550 definition, the SSRC is set to a
specific encoder clock and it is the SSRC that should be tracked
rather than payload type. However, in recent discussions it has
been noted that there are RTP implementations that might change
the encoder clock frequency while maintaining the SSRC value. An
encoder frequency change will be accompanied by a different
RTP-PT.
Units of Measurement: microseconds
Measurment Timing Please refer to the measurement timing section of
perfPacketLoss.
4.1.6. perfPacketInterArrivalJitterMin
Name: perfPacketInterArrivalJitterMin
Description: This metric measures the minimum 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: TBDperfPacketInterArrivalJitterMin
Status: current
Use and Applications Please refer to the 'Use and Applications'
section of perfPacketInterArrivalJitterAvg. This specific metric,
along with perfPacketInterArrivalJitterMax, is to capture the
range of measurements observed within a monitoring interval as the
average function may hide extremes.
Calculation Method: Please see the perfPacketInterArrivalJitterAvg
section for general calculation section. The average calculation
is evaluated on a running basis over the last 16 packets and the
entire monitoring interval is not covered. In this metric, the
minimum value is taken over the entire monitoring interval.
Units of Measurement: microseconds
Measurment Timing Please refer to the measurement timing section of
perfPacketLoss.
4.1.7. 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
Use and Applications Please refer to the 'Use and Applications'
section of perfPacketInterArrivalJitterAvg. This specific metric,
along with perfPacketInterArrivalJitterMin, is to capture the
range of measurements observed within a monitoring interval as the
average function may hide extremes.
Calculation Method: Please see the perfPacketInterArrivalJitterAvg
section for general calculation section. The average calculation
is evaluated on a running basis over the last 16 packets and the
entire monitoring interval is not covered. In this metric, the
maximum value is taken over the entire monitoring interval.
Units of Measurement: microseconds
Measurment Timing Please refer to the measurement timing section of
perfPacketLoss.
4.2. User and Application Layer 4.2. User and Application Layer
4.2.1. perfSessionSetupDelay 4.2.1. perfSessionSetupDelay
Name: perfSessionSetupDelay Name: perfSessionSetupDelay
Description: The Session Setup Delay metric reports the time taken Description: The Session Setup Delay metric reports the time taken
from a request being initiated by a host/endpoint to the response from a request being initiated by a host/endpoint to the response
(or request indicator) to the request being observed. This metric (or request indicator) to the request being observed. This metric
is defined in [RFC4710], however the units have been updated to is defined in [RFC4710], however the units have been updated to
skipping to change at page 12, line 4 skipping to change at page 17, line 28
for perfSessionSetupDelay values calculated in the most recent for perfSessionSetupDelay values calculated in the most recent
interval SHOULD be used. The intention with this behavior is to interval SHOULD be used. The intention with this behavior is to
acknowledge that the value has not bee calculated, and when it has acknowledge that the value has not bee calculated, and when it has
provide the freshest values available. provide the freshest values available.
4.3. Contextual Elements 4.3. Contextual Elements
4.3.1. mediaRTPSSRC 4.3.1. mediaRTPSSRC
Name: mediaRTPSSRC Name: mediaRTPSSRC
Description: Value of the syncronization source (SSRC) field in the
Description: Value of the synchronization source (SSRC) field in the
RTP header of the flow. This field is defined in [RFC3550] RTP header of the flow. This field is defined in [RFC3550]
Observation Point: This metric can be gleaned from the RTP packets Observation Point: This metric can be gleaned from the RTP packets
directly, so the observation point needs to on the flow path or directly, so the observation point needs to on the flow path or
within the endpoints. within the endpoints.
Element Data Type: unsigned32 Element Data Type: unsigned32
Element Semantics: identifier Element Semantics: identifier
skipping to change at page 12, line 24 skipping to change at page 18, line 4
Element Units: octets Element Units: octets
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDmediaRTPSSRC Element Id: TBDmediaRTPSSRC
Status: current Status: current
Use and Applications The RTP SSRC value denotes a specific media Use and Applications The RTP SSRC value denotes a specific media
stream. As such when trying to differentiate media stream stream. As such when trying to differentiate media stream
problems between session participants the SSRC field is needed. problems between session participants the SSRC field is needed.
Calculation Method: Copy from RTP header's SSRC field as defined in 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 [RFC3550]. In the case of a non-RTP flow, or the time period in
which the flow has not been verfied to be a RTP flow the value which the flow has not been verified to be a RTP flow the value
0xFFFFFFFE MUST be reported. 0xFFFFFFFE MUST be reported.
Units of Measurement: identifer Units of Measurement: identifier
Measurment Timing It is possible that the SSRC may have be Measurment Timing It is possible that the SSRC may have be
renegotiated mid-session due to collisions with other RTP senders. renegotiated mid-session due to collisions with other RTP senders.
4.3.2. mediaRTPPayloadType 4.3.2. mediaRTPPayloadType
Name: mediaRTPPayloadType Name: mediaRTPPayloadType
Description: The value of the RTP Payload Type Field as seen in the Description: The value of the RTP Payload Type Field as seen in the
RTP header of the flow. This field is defind in [RFC3550] RTP header of the flow. This field is defined in [RFC3550]
Observation Point: This metric can be gleaned from the RTP packets Observation Point: This metric can be gleaned from the RTP packets
directly, so the observation point needs to on the flow path or directly, so the observation point needs to on the flow path or
within the endpoints. within the endpoints.
Element Data Type: unsigned16 Element Data Type: unsigned16
Element Semantics: identifier Element Semantics: identifier
Element Units: octets Element Units: octets
skipping to change at page 13, line 21 skipping to change at page 18, line 45
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFF Element Range End: 0xFF
Element Id: TBDmediaRTPPayloadType Element Id: TBDmediaRTPPayloadType
Status: current Status: current
Use and Applications The RTP PT conveys the payload format and media Use and Applications The RTP PT conveys the payload format and media
encoding used in the RTP payload. For simple cases, where the RTP encoding used in the RTP payload. For simple cases, where the RTP
PT is from the statically defiend range this can lead to an PT is from the statically defined range this can lead to an
understanding of type of media codec used. With the knowledge of understanding of type of media codec used. With the knowledge of
the codec being used the degree of media impairment (given loss the codec being used the degree of media impairment (given loss
values and jitter) can be estimated better. However, for more values and jitter) can be estimated better. However, for more
recent codecs, the RTP dynamic range is used. In these cases the recent codecs, the RTP dynamic range is used. In these cases the
RTP payload values are dynamically negotiated. In the case of a RTP payload values are dynamically negotiated. In the case of a
non-RTP flow, or the time period in which the flow has not been non-RTP flow, or the time period in which the flow has not been
verfied to be a RTP flow, the value 0xFFFF MUST be reported. verified to be a RTP flow, the value 0xFFFF MUST be reported.
Calculation Method: Copy from RTP header's RTP-PT field as defined Calculation Method: Copy from RTP header's RTP-PT field as defined
in [RFC3550] in [RFC3550]
Units of Measurement: identifer Units of Measurement: identifier
Measurment Timing
4.3.3. mediaCodec
Name: mediaCodec
Description: The media codec used in the flow.
Observation Point: The ideal location of this metric is on the media
generators and consumers. However, given application inspection
or static configuration it is possible that intermediate nodes are
able to generate codec information.
Element Data Type: string
Element Semantics: identifier
Element Units: octets
Element Id: TBDmediaCodec
Status: current
Use and Applications The media codec value conveys the name of the
codec used to encode the media in the flow being monitored.
Simply reporting loss and jitter measurements are useful for
detection of network problems. However, judging the degree of the
impact on the audio/video experience needs additional information.
The most basic information is the codec being used which when
coupled with per-codec knowledge of sensitivity to the transport
metrics a better idea of the experience can be gained.
Calculation Method: The valid values for the mediaCodec are listed
on the IANA media-types registry. Analysis of the RTP payload
type may lead to the determination of the media codec. However,
with the use of the RTP dynamic payload type range the media
information is not encoded into the data packet. For these cases,
intermediate nodes may need to perform inspection of the
signalling (SIP, H.323, RTSP, etc.). In cases where the
mediaCodec cannot be determined, the value 'unknown' MUST be used.
Units of Measurement: identifier
Measurment Timing Measurment Timing
5. Security Considerations 5. Security Considerations
The recommendations in this document do not introduce any additional The recommendations in this document do not introduce any additional
security issues to those already mentioned in [RFC5101] and [RFC5477] security issues to those already mentioned in [RFC5101] and [RFC5477]
6. IANA Considerations 6. IANA Considerations
skipping to change at page 14, line 31 skipping to change at page 20, line 47
[RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V.
Jacobson, "RTP: A Transport Protocol for Real-Time Jacobson, "RTP: A Transport Protocol for Real-Time
Applications", STD 64, RFC 3550, July 2003. Applications", STD 64, RFC 3550, July 2003.
[RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP [RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP
Payload Format for Society of Motion Picture and Payload Format for Society of Motion Picture and
Television Engineers (SMPTE) 292M Video", RFC 3497, Television Engineers (SMPTE) 292M Video", RFC 3497,
March 2003. March 2003.
[RFC3489] Rosenberg, J., Weinberger, J., Huitema, C., and R. Mahy, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"STUN - Simple Traversal of User Datagram Protocol (UDP) "Session Traversal Utilities for NAT (STUN)", RFC 5389,
Through Network Address Translators (NATs)", RFC 3489, October 2008.
March 2003.
[I-D.ietf-pmol-sip-perf-metrics] [I-D.ietf-pmol-sip-perf-metrics]
Malas, D. and A. Morton, "Basic Telephony SIP End-to-End Malas, D. and A. Morton, "Basic Telephony SIP End-to-End
Performance Metrics", draft-ietf-pmol-sip-perf-metrics-07 Performance Metrics", draft-ietf-pmol-sip-perf-metrics-07
(work in progress), September 2010. (work in progress), September 2010.
[iana-ipfix-assignments] [iana-ipfix-assignments]
Internet Assigned Numbers Authority, "IP Flow Information Internet Assigned Numbers Authority, "IP Flow Information
Export Information Elements Export Information Elements
(http://www.iana.org/assignments/ipfix/ipfix.xml)". (http://www.iana.org/assignments/ipfix/ipfix.xml)".
 End of changes. 39 change blocks. 
80 lines changed or deleted 386 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/