< draft-akhter-opsawg-perfmon-ipfix-02.txt   draft-akhter-opsawg-perfmon-ipfix-03.txt >
Network Working Group A. Akhter Network Working Group A. Akhter
Internet-Draft Cisco Systems Internet-Draft Cisco Systems
Intended status: Standards Track March 27, 2012 Intended status: Standards Track H. Scholz
Expires: September 28, 2012 Expires: January 31, 2013 VOIPFUTURE GmbH
July 30, 2012
IPFIX Information Elements for Flow Performance Measurement IPFIX Information Elements for RTP Flow Performance Measurement
draft-akhter-opsawg-perfmon-ipfix-02.txt draft-akhter-opsawg-perfmon-ipfix-03.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. RTP based applications. This performance data provides information
This performance data provides information essential in validating essential in validating service level agreements, fault isolation as
service level agreements, fault isolation as well as early warnings well as early warnings of greater problems. This document describes
of greater problems. This document describes IPFIX Information IPFIX Information Elements related to RTP performance measurement of
Elements related to performance measurement of network based network based applications. In addition, to the performance
applications. In addition, to the performance information several information several non-metric information elements are also included
non-metric information elements are also included to provide greater to provide greater context to the reports. The measurements use
context to the reports. The measurements use audio/video audio/video applications as a base but are not restricted to these
applications as a base but are not restricted to these class of class of applications. These new IPFIX Information Elements can
applications. describe the entire duration of an RTP stream or a smaller time slice
of it.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 September 28, 2012. This Internet-Draft will expire on January 31, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5
3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 6
3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 5 3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 6
3.2. Service Level Agreemnt (SLA) Validation . . . . . . . . . 5 3.2. Fault Isolation and Troubleshooting . . . . . . . . . . . 6
3.3. Fault Isolation and Troubleshooting . . . . . . . . . . . 6 4. New Information Elements . . . . . . . . . . . . . . . . . . . 7
4. New Information Elements . . . . . . . . . . . . . . . . . . . 6 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 7
4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. perfObservationType . . . . . . . . . . . . . . . . . 7
4.1.1. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 6 4.1.2. perfIntervalStartMilliseconds . . . . . . . . . . . . 8
4.1.2. perfPacketExpected . . . . . . . . . . . . . . . . . . 7 4.1.3. perfIntervalEndMilliseconds . . . . . . . . . . . . . 9
4.1.3. perfPacketLossRate . . . . . . . . . . . . . . . . . . 8 4.1.4. perfSampleOffsetMilliseconds . . . . . . . . . . . . . 10
4.1.4. perfPacketLossEvent . . . . . . . . . . . . . . . . . 8 4.1.5. perfSampleTimeMilliseconds . . . . . . . . . . . . . . 11
4.1.5. perfPacketInterArrivalJitterAvg . . . . . . . . . . . 9 4.1.6. perfStreamState . . . . . . . . . . . . . . . . . . . 12
4.1.6. perfPacketInterArrivalJitterMin . . . . . . . . . . . 9 4.1.7. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 13
4.1.7. perfPacketInterArrivalJitterMax . . . . . . . . . . . 10 4.1.8. perfPacketExpected . . . . . . . . . . . . . . . . . . 13
4.1.8. perfRoundTripNetworkDelay . . . . . . . . . . . . . . 10 4.1.9. perfPacketLossRate . . . . . . . . . . . . . . . . . . 14
4.2. User and Application Layer . . . . . . . . . . . . . . . . 11 4.1.10. perfPacketLossEvent . . . . . . . . . . . . . . . . . 14
4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 11 4.1.11. perfPacketInterArrivalJitterAvg . . . . . . . . . . . 15
4.3. Contextual Elements . . . . . . . . . . . . . . . . . . . 12 4.1.12. perfPacketInterArrivalJitterMin . . . . . . . . . . . 15
4.3.1. mediaRTPSSRC . . . . . . . . . . . . . . . . . . . . . 12 4.1.13. perfPacketInterArrivalJitterMax . . . . . . . . . . . 16
4.3.2. mediaRTPPayloadType . . . . . . . . . . . . . . . . . 12 4.1.14. rtpPacketizationTime . . . . . . . . . . . . . . . . . 17
4.3.3. mediaCodec . . . . . . . . . . . . . . . . . . . . . . 13 4.1.15. rtpPacketizationChange . . . . . . . . . . . . . . . . 17
5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 4.1.16. perfDuplicates . . . . . . . . . . . . . . . . . . . . 18
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 4.1.17. rtpPacketOrder . . . . . . . . . . . . . . . . . . . . 19
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 4.1.18. rtpSequenceError . . . . . . . . . . . . . . . . . . . 19
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 4.1.19. perfRoundTripNetworkDelay . . . . . . . . . . . . . . 19
8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 4.2. User and Application Layer . . . . . . . . . . . . . . . . 20
8.2. Informative References . . . . . . . . . . . . . . . . . . 14 4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 20
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 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
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
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 3, line 30 skipping to change at page 4, line 30
actual problem within the network service, monitoring the performance actual problem within the network service, monitoring the performance
may yield a early indicator of a much more serious problem. may yield a early indicator of a much more serious problem.
Due to the demanding and sensitive nature of these applications, Due to the demanding and sensitive nature of these applications,
network operators have tried to engineer their networks towards network operators have tried to engineer their networks towards
wringing better and differentiated performance. However, that same wringing better and differentiated performance. However, that same
differentiated design prevents network operators from extrapolating differentiated design prevents network operators from extrapolating
observational data from one application to another, or from one set observational data from one application to another, or from one set
of synthetic (active test) test traffic to actual application of synthetic (active test) test traffic to actual application
performance. This gap highlights the importance of generic performance. This gap highlights the importance of generic
measurements as well as the reliance on user traffic measurents-- measurements as well as the reliance on user traffic measurements--
rather than synthetic tests. rather than synthetic tests.
Performance measurements on user data provide greater visibility not Performance measurements on user data provide greater visibility not
only into the quality of experience of the end users but also only into the quality of experience of the end users but also
visibility into network health. With regards to network health, as visibility into network health. With regards to network health, as
flow performance is being measured, there will be visibility into the flow performance is being measured, there will be visibility into the
end to end performance which means that not only visibility into end to end performance which means that not only visibility into
local network health, but also viability into remote network health. local network health, but also viability into remote network health.
If these measurements are made at multiple points within the network If these measurements are made at multiple points within the network
(or between the network and end device) then there is not only (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 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 be established where the issue might be. The resolution of the fault
increases with the number of measurement points along the flow path. 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
potentially generated by different users.
The IP Flow Information Export Protocol (IPFIX) [RFC5101] provides The IP Flow Information Export Protocol (IPFIX) [RFC5101] provides
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. This documet details the expresison of a portion of the network. This document details the expression of
IPFIX Information Elements whose calculation is defined in an IPFIX Information Elements whose calculation is defined in an
accompanying document. accompanying document.
As this document covers the reporting of these metrics via IPFIX, As this document covers the reporting of these metrics via IPFIX,
consideration is taken with mapping the metric's capabilities and consideration is taken with mapping the metric's capabilities and
context with the IPFIX information and data representation model. context with the IPFIX information and data representation model.
The guidelines outlined in [I-D.trammell-ipfix-ie-doctors] are used The guidelines outlined in [I-D.trammell-ipfix-ie-doctors] are used
to ensure proper IPFIX information element definition. to ensure proper IPFIX information element definition.
There has been related work in this area such as [RFC2321]. There has been related work in this area such as [RFC2321].
[I-D.huici-ipfix-sipfix], and [VoIP-monitor]. This document is also [I-D.huici-ipfix-sipfix], and [VoIP-monitor].
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 4, line 41 skipping to change at page 6, line 5
Name: Name of the information element per the IPFIX rules defined in Name: Name of the information element per the IPFIX rules defined in
Section 2.3 of [RFC5102] Section 2.3 of [RFC5102]
Description: Short description of what the information element is Description: Short description of what the information element is
trying to convey. trying to convey.
Observation Point: Where the measurement is meant to be performed. Observation Point: Where the measurement is meant to be performed.
Either at an intermediate point (for example, a router) or end Either at an intermediate point (for example, a router) or end
system. system.
Element Data Type: The IPFIX informationElementDataTypeas defined in Element Data Type: The IPFIX informationElementDataType as defined
Section 3.1 of [RFC5610] in Section 3.1 of [RFC5610]
Element Semantics: The IPFIX informationElementSemantics as defined Element Semantics: The IPFIX informationElementSemantics as defined
in section Section 3.6 of [RFC5610] in section Section 3.6 of [RFC5610]
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]
skipping to change at page 5, line 21 skipping to change at page 6, line 30
Element Id: The IPFIX global unique element ID as defined 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.
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 For QoS monitoring, it is important to be able to capture the
satisfaction with the network service. While there are many application context. For example, in the case of interactive audio
components of the satisfaction such as pricing, packaging, offering,
etc., a major component of satisfaction is delivering a consistent
service. The user builds trust on this consistency of the network
service and is then to be able to run network applications-- which is
of course the end goal. Without the ability to deliver a consistent
service for end user network applications network operator will be
left dealing with price sensitive disgruntled users with very low
expectations (if they don't have choice of operator) or abandonment
(if they have choice).
For QoS monitoring, it is importnat to be able to capture the
applicaiton context. For example, in the case of interactive audio
flows, the codec and the fact that the application is interactive flows, the codec and the fact that the application is interactive
shoudl be captured. The codec type can be used to determine loss should be captured. The codec type can be used to determine loss
thresholds affecting end user quality and the interactive nature thresholds affecting end user quality and the interactive nature
would suggest threshodlds over one way delay. The IPFIX reporting would suggest thresholds over one way delay. The IPFIX reporting
would need to keep this information organized together for opeartor would need to keep this information organized together for operator
to be able to perform correlated analysis. to be able to perform correlated analysis.
3.2. Service Level Agreemnt (SLA) Validation 3.2. Fault Isolation and Troubleshooting
Similar to QoS and QoE validation, there might be contractual or
regulatory requirements that need to be met by the network operator.
Monitoring the performance of the flows allows the application
operator, network operator as well as the end user to validate of the
target service is being delivered. While there is quite a diversity
in the codification of network SLAs they may eventually involve some
measurement of network uptime, end to end latency, end to end jitter
and perhaps service response time. In the case violation of the SLA,
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
SLA.
3.3. Fault Isolation and Troubleshooting
It has been generally easier to troubleshoot 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
intermittent and seemingly inconsistent 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 provider 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 would 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 location and nature of the problem. 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 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.
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 User and Application Layer: Metrics that are might be affected by
the network indirectly, but are ultimately related to user, end- the network indirectly, but are ultimately related to user, end-
system and session states. For example, session setup time, system and session states. For example, session setup time,
transaction rate and session duration would be defined here. transaction rate and session duration would be defined here.
Contextual Elements Information elements that provide further
context to the metrics. For example, media type, codec type, and
type of application would be defined here.
4.1. Transport Layer 4.1. Transport Layer
4.1.1. perfPacketLoss 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.
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.
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
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
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:
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 ..)
Calculation Method:
Units of Measurement: n/a
Measurement Timing
4.1.7. perfPacketLoss
Name: perfPacketLoss Name: perfPacketLoss
Description: The packet loss metric reports the number of individual Description: The packet loss metric reports the number of individual
packets that were lost in the reporting interval. packets that were lost in the reporting interval.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
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
skipping to change at page 7, line 25 skipping to change at page 13, line 36
Element Units: packets Element Units: packets
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDperfPacketLoss Element Id: TBDperfPacketLoss
Status: current Status: current
4.1.2. perfPacketExpected 4.1.8. 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
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: packets
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
4.1.3. perfPacketLossRate 4.1.9. 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
set of packets sent. set of packets sent.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
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: unsigned16 Element Data Type: unsigned16
Element Semantics: quantity Element Semantics: quantity
Element Units: none Element Units: float16 (IPFIX has not defined float16 yet)
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFE Element Range End: 0x64
Element Id: TBDperfPacketLossRate Element Id: TBDperfPacketLossRate
Status: current Status: current
4.1.4. perfPacketLossEvent 4.1.10. perfPacketLossEvent
Name: perfPacketLossEvent Name: perfPacketLossEvent
Description: The packet loss event metric reports the number of Description: The packet loss event metric reports the number of
continuous sets of packets that were lost in the reporting continuous sets of packets that were lost in the reporting
interval. interval.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
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: event
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
4.1.5. perfPacketInterArrivalJitterAvg 4.1.11. perfPacketInterArrivalJitterAvg
Name: perfPacketInterArrivalJitterAvg Name: perfPacketInterArrivalJitterAvg
Description: This metric measures the absolute deviation of the Description: This metric measures the absolute deviation of the
difference in packet spacing at the measurement point compared to difference in packet spacing at the measurement point compared to
the packet spacing at the sender. the packet spacing at the sender.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
media path or on the receiver. The observation is only relevant media path or on the receiver. The observation is only relevant
in a unidirectional sense. in a unidirectional sense.
skipping to change at page 9, line 36 skipping to change at page 15, line 45
Element Units: microseconds Element Units: microseconds
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDperfPacketInterArrivalJitterAvg Element Id: TBDperfPacketInterArrivalJitterAvg
Status: current Status: current
4.1.6. perfPacketInterArrivalJitterMin 4.1.12. perfPacketInterArrivalJitterMin
Name: perfPacketInterArrivalJitterMin Name: perfPacketInterArrivalJitterMin
Description: This metric measures the minimum value the calculation Description: This metric measures the minimum value the calculation
used for perfPacketInterArrivalJitterAvg within the monitoring used for perfPacketInterArrivalJitterAvg within the monitoring
interval. interval.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
media path or on the receiver. The observation is only relevant media path or on the receiver. The observation is only relevant
in a unidirectional sense. in a unidirectional sense.
skipping to change at page 10, line 4 skipping to change at page 16, line 10
Description: This metric measures the minimum value the calculation Description: This metric measures the minimum value the calculation
used for perfPacketInterArrivalJitterAvg within the monitoring used for perfPacketInterArrivalJitterAvg within the monitoring
interval. interval.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
media path or on the receiver. The observation is only relevant media path or on the receiver. The observation is only relevant
in a unidirectional sense. in a unidirectional sense.
Element Data Type: unsigned32 Element Data Type: unsigned32
Element Semantics: quantity Element Semantics: quantity
Element Units: microseconds Element Units: microseconds
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDperfPacketInterArrivalJitterMin Element Id: TBDperfPacketInterArrivalJitterMin
Status: current Status: current
4.1.7. perfPacketInterArrivalJitterMax 4.1.13. perfPacketInterArrivalJitterMax
Name: perfPacketInterArrivalJitterMax Name: perfPacketInterArrivalJitterMax
Description: This metric measures the maximum value the calculation Description: This metric measures the maximum value the calculation
used for perfPacketInterArrivalJitterAvg within the monitoring used for perfPacketInterArrivalJitterAvg within the monitoring
interval. interval.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
media path or on the receiver. The observation is only relevant media path or on the receiver. The observation is only relevant
in a unidirectional sense. in a unidirectional sense.
skipping to change at page 10, line 42 skipping to change at page 17, line 5
Element Units: microseconds Element Units: microseconds
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDperfPacketInterArrivalJitterMax Element Id: TBDperfPacketInterArrivalJitterMax
Status: current Status: current
4.1.8. perfRoundTripNetworkDelay 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.
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
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 Name: perfRoundTripNetworkDelay
Description: This metric measures the network round trip time Description: This metric measures the network round trip time
between end stations for a flow. between end stations for a flow.
Observation Point: The observation can be made anywhere along the Observation Point: The observation can be made anywhere along the
flow path as long as the bidirectional network delay is accounted flow path as long as the bidirectional network delay is accounted
for. for.
skipping to change at page 12, line 4 skipping to change at page 20, line 31
Element Data Type: unsigned32 Element Data Type: unsigned32
Element Semantics: quantity Element Semantics: quantity
Element Units: microseconds Element Units: microseconds
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDperfSessionSetupDelay Element Id: TBDperfSessionSetupDelay
Status: current Status: current
4.3. Contextual Elements 4.3. RTP Header
4.3.1. mediaRTPSSRC 4.3.1. rtpProtocolVersion
Name: mediaRTPSSRC 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
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 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 can be either on the any RTP
within the endpoints. 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 Data Type: unsigned32
Element Semantics: identifier Element Semantics: identifier
Element Units: octets Element Units: none
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFFFFFFFE Element Range End: 0xFFFFFFFE
Element Id: TBDmediaRTPSSRC Element Id: TBDrtpSSRC
Status: current Status: current
4.3.2. mediaRTPPayloadType 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.
Name: mediaRTPPayloadType 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.
Description: The value of the RTP Payload Type Field as seen in the Units of Measurement: identifier
RTP header of the flow. This field is defined in [RFC3550]
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 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: unsigned8 Element Data Type: unsigned8
Element Semantics: identifier Element Semantics: identifier
Element Units: octets
Element Units: none
Element Range Begin: 0 Element Range Begin: 0
Element Range End: 0xFF Element Range End: 0xFF
Element Id: TBDmediaRTPPayloadType Element Id: TBDrtpPayloadType
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 Status: current
4.3.3. mediaCodec 4.3.5. rtpMediaSubType
Name: mediaCodec Name: rtpMediaSubType
Description: The media codec used in the flow. Description: The rtpMediaSubType field carries the verbatim media
type name (e.g. PCMA) as defined by [RFC4855].
Observation Point: The ideal location of this metric is on the media Observation Point: anywhere
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 Data Type: string
Element Semantics: identifier Element Semantics: tbd
Element Units: octets Element Units: n/a
Element Id: TBDmediaCodec Element Range Begin: n/a
Element Range End: n/a
Element Id: TBDrtpMediaSubType
Status: current 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.
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
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
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 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
This document requires an elements assignment to be made by IANA. This document requires an elements assignment to be made by IANA.
7. Acknowledgements 7. Acknowledgements
The authors would like to thank Shingo Kashima for their invaluable The authors would like to thank Shingo Kashima, Jan Novak and Al
review and comments. Thank-you. Morton for their invaluable review and comments. Thank-you.
8. References 8. References
8.1. Normative References 8.1. Normative References
[RFC5101] Claise, B., "Specification of the IP Flow Information [RFC5101] Claise, B., "Specification of the IP Flow Information
Export (IPFIX) Protocol for the Exchange of IP Traffic Export (IPFIX) Protocol for the Exchange of IP Traffic
Flow Information", RFC 5101, January 2008. Flow Information", RFC 5101, January 2008.
[RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby,
skipping to change at page 14, line 38 skipping to change at page 28, line 19
[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.
[RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
"Session Traversal Utilities for NAT (STUN)", RFC 5389, "Session Traversal Utilities for NAT (STUN)", RFC 5389,
October 2008. October 2008.
[I-D.ietf-pmol-sip-perf-metrics] [RFC4855] Casner, S., "Media Type Registration of RTP Payload
Malas, D. and A. Morton, "Basic Telephony SIP End-to-End Formats", RFC 4855, February 2007.
Performance Metrics", draft-ietf-pmol-sip-perf-metrics-07
(work in progress), September 2010. [RFC6076] Malas, D. and A. Morton, "Basic Telephony SIP End-to-End
Performance Metrics", RFC 6076, January 2011.
[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)".
8.2. Informative References 8.2. Informative References
[I-D.ietf-pmol-metrics-framework]
Clark, A. and B. Claise, "Guidelines for Considering New
Performance Metric Development",
draft-ietf-pmol-metrics-framework-12 (work in progress),
July 2011.
[I-D.trammell-ipfix-ie-doctors] [I-D.trammell-ipfix-ie-doctors]
Trammell, B. and B. Claise, "Guidelines for Authors and Trammell, B. and B. Claise, "Guidelines for Authors and
Reviewers of IPFIX Information Elements", Reviewers of IPFIX Information Elements",
draft-trammell-ipfix-ie-doctors-03 (work in progress), draft-trammell-ipfix-ie-doctors-03 (work in progress),
October 2011. October 2011.
[RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP
Headers for Low-Speed Serial Links", RFC 2508, Headers for Low-Speed Serial Links", RFC 2508,
February 1999. February 1999.
skipping to change at page 15, line 40 skipping to change at page 29, line 17
[RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and
Control Packets on a Single Port", RFC 5761, April 2010. Control Packets on a Single Port", RFC 5761, April 2010.
[I-D.huici-ipfix-sipfix] [I-D.huici-ipfix-sipfix]
Huici, F., Niccolini, S., and S. Anderson, "SIPFIX: Use Huici, F., Niccolini, S., and S. Anderson, "SIPFIX: Use
Cases and Problem Statement for VoIP Monitoring and Cases and Problem Statement for VoIP Monitoring and
Exporting", draft-huici-ipfix-sipfix-00 (work in Exporting", draft-huici-ipfix-sipfix-00 (work in
progress), June 2009. progress), June 2009.
[nProbe] "nProbe - NetFlow/IPFIX Network Probe
(http://www.ntop.org/nProbe.html)".
[RFC2321] Bressen, A., "RITA -- The Reliable Internetwork [RFC2321] Bressen, A., "RITA -- The Reliable Internetwork
Troubleshooting Agent", RFC 2321, April 1998. Troubleshooting Agent", RFC 2321, April 1998.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G.
Carle, "Information Model for Packet Sampling Exports", Carle, "Information Model for Packet Sampling Exports",
RFC 5477, March 2009. RFC 5477, March 2009.
[VoIP-monitor] [VoIP-monitor]
L. Chang-Yong, H. Kim, K. Ko, J. Jim, and H. Jeong, "A L. Chang-Yong, H. Kim, K. Ko, J. Jim, and H. Jeong, "A
VoIP Traffic Monitoring System based on NetFlow v9, VoIP Traffic Monitoring System based on NetFlow v9,
International Journal of Advanced Science and Technology, International Journal of Advanced Science and Technology,
vol. 4, Mar. 2009". vol. 4, Mar. 2009".
Author's Address Authors' Addresses
Aamer Akhter Aamer Akhter
Cisco Systems, Inc. Cisco Systems, Inc.
7025 Kit Creek Road 7025 Kit Creek Road
RTP, NC 27709 RTP, NC 27709
USA USA
Email: aakhter@cisco.com Email: aakhter@cisco.com
Hendrik Scholz
VOIPFUTURE GmbH
Wendenstrasse 4
Hamburg 20097
Germany
Phone: +49 40 688 900 100
Email: hscholz@voipfuture.com
URI: http://www.voipfuture.com/
 End of changes. 60 change blocks. 
141 lines changed or deleted 735 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/