Network Working Group A. Akhter Internet-Draft Cisco Systems Intended status: Standards Track H. Scholz Expires: January 31, 2013 VOIPFUTURE GmbH July 30, 2012 IPFIX Information Elements for RTP Flow Performance Measurement draft-akhter-opsawg-perfmon-ipfix-03.txt Abstract There is a need to be able to quantify and report the performance of RTP based applications. This performance data provides information essential in validating service level agreements, fault isolation as well as early warnings of greater problems. This document describes IPFIX Information Elements related to RTP performance measurement of network based applications. In addition, to the performance information several non-metric information elements are also included to provide greater context to the reports. The measurements use audio/video applications as a base but are not restricted to these class of applications. These new IPFIX Information Elements can describe the entire duration of an RTP stream or a smaller time slice of it. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on January 31, 2013. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Akhter & Scholz Expires January 31, 2013 [Page 1] Internet-Draft IPFIX PerfMon July 2012 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 6 3.2. Fault Isolation and Troubleshooting . . . . . . . . . . . 6 4. New Information Elements . . . . . . . . . . . . . . . . . . . 7 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 7 4.1.1. perfObservationType . . . . . . . . . . . . . . . . . 7 4.1.2. perfIntervalStartMilliseconds . . . . . . . . . . . . 8 4.1.3. perfIntervalEndMilliseconds . . . . . . . . . . . . . 9 4.1.4. perfSampleOffsetMilliseconds . . . . . . . . . . . . . 10 4.1.5. perfSampleTimeMilliseconds . . . . . . . . . . . . . . 11 4.1.6. perfStreamState . . . . . . . . . . . . . . . . . . . 12 4.1.7. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 13 4.1.8. perfPacketExpected . . . . . . . . . . . . . . . . . . 13 4.1.9. perfPacketLossRate . . . . . . . . . . . . . . . . . . 14 4.1.10. perfPacketLossEvent . . . . . . . . . . . . . . . . . 14 4.1.11. perfPacketInterArrivalJitterAvg . . . . . . . . . . . 15 4.1.12. perfPacketInterArrivalJitterMin . . . . . . . . . . . 15 4.1.13. perfPacketInterArrivalJitterMax . . . . . . . . . . . 16 4.1.14. rtpPacketizationTime . . . . . . . . . . . . . . . . . 17 4.1.15. rtpPacketizationChange . . . . . . . . . . . . . . . . 17 4.1.16. perfDuplicates . . . . . . . . . . . . . . . . . . . . 18 4.1.17. rtpPacketOrder . . . . . . . . . . . . . . . . . . . . 19 4.1.18. rtpSequenceError . . . . . . . . . . . . . . . . . . . 19 4.1.19. perfRoundTripNetworkDelay . . . . . . . . . . . . . . 19 4.2. User and Application Layer . . . . . . . . . . . . . . . . 20 4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 20 4.3. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.1. rtpProtocolVersion . . . . . . . . . . . . . . . . . . 20 4.3.2. rtpSSRC . . . . . . . . . . . . . . . . . . . . . . . 21 4.3.3. rtpPayloadType . . . . . . . . . . . . . . . . . . . . 22 4.3.4. rtpMediaType . . . . . . . . . . . . . . . . . . . . . 23 4.3.5. rtpMediaSubType . . . . . . . . . . . . . . . . . . . 23 4.3.6. RTP Payload . . . . . . . . . . . . . . . . . . . . . 24 4.3.7. rtpMediaType . . . . . . . . . . . . . . . . . . . . . 26 Akhter & Scholz Expires January 31, 2013 [Page 2] Internet-Draft IPFIX PerfMon July 2012 4.3.8. rtpMediaSubType . . . . . . . . . . . . . . . . . . . 26 4.3.9. rtpDelayType . . . . . . . . . . . . . . . . . . . . . 26 4.3.10. rtpDelayOneWay . . . . . . . . . . . . . . . . . . . . 26 4.3.11. rtpIsSRTP . . . . . . . . . . . . . . . . . . . . . . 27 4.3.12. rtpTimestamp . . . . . . . . . . . . . . . . . . . . . 27 4.3.13. rtpCodecChange . . . . . . . . . . . . . . . . . . . . 27 4.3.14. rtpMarkerBit . . . . . . . . . . . . . . . . . . . . . 27 4.3.15. rtpComfortNoise . . . . . . . . . . . . . . . . . . . 27 4.3.16. rtpDSCPChange . . . . . . . . . . . . . . . . . . . . 27 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 Akhter & Scholz Expires January 31, 2013 [Page 3] Internet-Draft IPFIX PerfMon July 2012 1. Introduction Today's networks support a multitude of highly demanding and sensitive network applications. Network issues are readily apparent by the users of these applications due to the sensitivity of these applications to impaired network conditions. Examples of these network applications include applications making use of IP based audio, video, database transactions, virtual desktop interface (VDI), online gaming, cloud services and many more. In some cases, the impaired application translates directly to loss of revenue. In other cases, there may be regulatory or contractual service level agreements that motivate the network operator. Due to the sensitivity of these types of applications to impaired service it leaves a poor impression of the service on the user-- regardless of the actual performance of the network itself. In the case of an actual problem within the network service, monitoring the performance may yield a early indicator of a much more serious problem. Due to the demanding and sensitive nature of these applications, network operators have tried to engineer their networks towards wringing better and differentiated performance. However, that same differentiated design prevents network operators from extrapolating observational data from one application to another, or from one set of synthetic (active test) test traffic to actual application performance. This gap highlights the importance of generic measurements as well as the reliance on user traffic measurements-- rather than synthetic tests. Performance measurements on user data provide greater visibility not only into the quality of experience of the end users but also visibility into network health. With regards to network health, as flow performance is being measured, there will be visibility into the end to end performance which means that not only visibility into local network health, but also viability into remote network health. If these measurements are made at multiple points within the network (or between the network and end device) then there is not only identification that there might be an issue, but a span of area can be established where the issue might be. The resolution of the fault increases with the number of measurement points along the flow path. IP based applications, esp. those with real-time requirements, may suffer temporarily from impairments such as bandwidth bottlenecks or packet loss. Performance measurement with average values is not able to record and highlight these issues. Due to this the measurement interval must be configurable to a short time slice in order to indicate such temporary impairments. Aggregation of measurements shall be possible to aggregate multiple measurements of the same application stream or multiple streams of the same type but Akhter & Scholz Expires January 31, 2013 [Page 4] Internet-Draft IPFIX PerfMon July 2012 potentially generated by different users. The IP Flow Information Export Protocol (IPFIX) [RFC5101] provides new levels of flexibility in reporting from measurement points across the life cycle of a network based application. IPFIX can provide granular results in terms of flow specificity as well as time granularity. At the same time, IPFIX allows for summarization of data along different types of boundaries for operators that are unconcerned about specific sessions but about health of a service or a portion of the network. This document details the expression of IPFIX Information Elements whose calculation is defined in an accompanying document. As this document covers the reporting of these metrics via IPFIX, consideration is taken with mapping the metric's capabilities and context with the IPFIX information and data representation model. The guidelines outlined in [I-D.trammell-ipfix-ie-doctors] are used to ensure proper IPFIX information element definition. There has been related work in this area such as [RFC2321]. [I-D.huici-ipfix-sipfix], and [VoIP-monitor]. 2. Terminology Terms used in this document that are defined in the Terminology section of the IPFIX Protocol [RFC5101] document are to be interpreted as defined there. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. In addition, the information element definitions use the following terms: Name: Name of the information element per the IPFIX rules defined in Section 2.3 of [RFC5102] Description: Short description of what the information element is trying to convey. Observation Point: Where the measurement is meant to be performed. Either at an intermediate point (for example, a router) or end system. Akhter & Scholz Expires January 31, 2013 [Page 5] Internet-Draft IPFIX PerfMon July 2012 Element Data Type: The IPFIX informationElementDataType as defined in Section 3.1 of [RFC5610] Element Semantics: The IPFIX informationElementSemantics as defined in section Section 3.6 of [RFC5610] Element Units: The IPFIX informationElementUnits as defined in section Section 3.7 of [RFC5610] Element Range Begin: The IPFIX informationElementRangeBegin as defined in section Section 3.7 of [RFC5610] Element Range End: The IPFIX informationElementRangeEnd as defined in section Section 3.7 of [RFC5610] Element Id: The IPFIX global unique element ID as defined in Section 3.2 of [RFC5101] Status: The status of the specification of this IPFIX Information Element. 3. General Usage 3.1. Quality of Service (QoS) Monitoring For QoS monitoring, it is important to be able to capture the application context. For example, in the case of interactive audio flows, the codec and the fact that the application is interactive should be captured. The codec type can be used to determine loss thresholds affecting end user quality and the interactive nature would suggest thresholds over one way delay. The IPFIX reporting would need to keep this information organized together for operator to be able to perform correlated analysis. 3.2. Fault Isolation and Troubleshooting It has been generally easier to troubleshoot and fix problems that are binary in nature: it either works or does not work. The host is pingable or not pingable. However, the much more difficult to resolve issues that are transitory in nature, move from location to location, more complicated that simple ICMP reachability and many times unverifiable reports by the users themselves. It is these intermittent and seemingly inconsistent network impairments that performance metrics can be extremely helpful with. Just the basic timely detection that there is a problem (or an impending problem) can give the provider the confidence that there is a real problem that needs to be resolved. The next step would be to assist the Akhter & Scholz Expires January 31, 2013 [Page 6] Internet-Draft IPFIX PerfMon July 2012 operator in a speedy resolution by providing information regarding the network location and nature of the problem. Transient problems which affect a user only for a short time of this session can be made visible with measurements taken in short fixed time slices, e.g. every 10 seconds. While a traditional measurement on a per session basis may not show an intermittent impairment (e.g. packet loss) the short measurement interval highlights these. 4. New Information Elements The information elements are organized into two main groups: Transport Layer: Metrics that might be calculated from observations at higher layers but essentially provide information about the network transport of user date. For example, the metrics related to packet loss, latency and jitter would be defined here. RTP Header: Information Elements that describe the RTP stream properties based on RTP header information but not the RTP payload itself. RTP Payload: Information Elements that describe the RTP payload. For example, packet count and media type. User and Application Layer: Metrics that are might be affected by the network indirectly, but are ultimately related to user, end- system and session states. For example, session setup time, transaction rate and session duration would be defined here. 4.1. Transport Layer 4.1.1. perfObservationType Name: perfObservationType Description: The observation type is analog to sipObservationType defined in [trammel sip-msg]. It defines the place of the metering process in the network path. Observation Point: The observation can be made anywhere along the media path or on the endpoints themselves. The observation is only relevant in a unidirectional sense. Akhter & Scholz Expires January 31, 2013 [Page 7] Internet-Draft IPFIX PerfMon July 2012 Element Data Type: unsigned8 Element Semantics: identifier Element Units: n/a Element Range Begin: 0 Element Range End: 0xFF Element Id: TBDperfObservationType Status: current Use and Applications 0: unknown: The Metering Process does not specify the observation type 1: receiver: The Metering Process is, or is co-located with, the receiver of the RTP stream. 2: sender: The Metering Process is, or is co-located with, the sender of the RTP stream. 3: passive: The Metering Process passively observed the RTP stream. 4: rtcp: The Metering Process obtains the data conveyed in the IPFIX message for one or more RTCP reports. Calculation Method: Units of Measurement: n/a Measurement Timing 4.1.2. perfIntervalStartMilliseconds Name: perfIntervalStartMilliseconds Description: Start time of the monitoring interval in milliseconds since 0000 UTC Jan 1, 1970. The time is taken from the local clock which SHOULD be NTP synchronized. If a flow only covers part of the monitoring interval (for example, the flow started after the interval start time), start time MUST be set to the start time of the monitoring interval. Akhter & Scholz Expires January 31, 2013 [Page 8] Internet-Draft IPFIX PerfMon July 2012 Observation Point: Element Data Type: dateTimeMilliseconds Element Semantics: identifier Element Units: n/a Element Range Begin: 0 Element Range End: ??? Element Id: TBDperfIntervalStartMilliseconds Status: current Use and Applications Calculation Method: Units of Measurement: n/a Measurement Timing 4.1.3. perfIntervalEndMilliseconds Name: perfIntervalEndMilliseconds Description: End time of the flow's monitoring interval in milliseconds since 0000 UTC Jan 1, 1970. The time is taken from the local clock which SHOULD be NTP synchronized. If the flow covers part of the monitoring interval (for example, the flow ended before the interval end time), the perfIntervalEndMilliseconds MUST be set to the end of observation interval. Observation Point: Element Data Type: datetimeMilliseconds Element Semantics: identifier Element Units: n/a Element Range Begin: 0 Akhter & Scholz Expires January 31, 2013 [Page 9] Internet-Draft IPFIX PerfMon July 2012 Element Range End: 0xFF Element Id: TBDperfObservationType Status: current Use and Applications 0: unknown: The Metering Process does not specify the observation type 1: receiver: The Metering Process is, or is co-located with, the receiver of the RTP stream. 2: sender: The Metering Process is, or is co-located with, the sender of the RTP stream. 3: passive: The Metering Process passively observed the RTP stream. 4: rtcp: TBD Calculation Method: Units of Measurement: n/a Measurement Timing 4.1.4. perfSampleOffsetMilliseconds Name: perfSampleOffsetMilliseconds Description: Offset of the observation interval contained in this flow record. The value is measured in milliseconds and contains the offset of the beginning of the flow record from the beginning of the RTP stream. Observation Point: Element Data Type: unsigned32 Element Semantics: identifier Element Units: milliseconds Akhter & Scholz Expires January 31, 2013 [Page 10] Internet-Draft IPFIX PerfMon July 2012 Element Range Begin: 0 Element Range End: 0xFFFFFFFF Element Id: TBDperfSampleOffsetMilliseconds Status: current Use and Applications Calculation Method: Measurement Timing 4.1.5. perfSampleTimeMilliseconds Name: perfSampleTimeMilliseconds Description: An IPFIX observer may generate and export a flow record for the entire duration of an RTP stream or for a specific part, e.g. a fixed time slice of 10 seconds. In case a single flow record is created the rtpSampleTime equals the RTP stream duration in milliseconds. In either case the rtpStreamState IE should be set to true if this flow record describes an ended RTP stream. Observation Point: Element Data Type: unsigned32 Element Semantics: DeltaCounter Element Units: milliseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFF Element Id: TBDperfSampleTimeMilliseconds Status: current Use and Applications Calculation Method: Akhter & Scholz Expires January 31, 2013 [Page 11] Internet-Draft IPFIX PerfMon July 2012 Units of Measurement: milliseconds Measurement Timing 4.1.6. perfStreamState Name: perfStreamState Description: Using the rtpSampleOffset and rtpSampleTime IEs flow entries may be generated which describe only part of an RTP stream. This IE is used to describe the state of the observed stream, e.g. to indicate the reception of the last flow record belonging to a single RTP stream. Observation Point: Element Data Type: unsigned8 Element Semantics: identifier Element Units: n/a Element Range Begin: 0 Element Range End: 0xFF Element Id: TBDperfObservationType Status: current Use and Applications 0: undefined: The state of the stream is not known. 1: running: The Metering Process expects more RTP packets or has already received packets for this RTP stream which are outside the scope of this flow record. 2: ended: The Metering Process determined that the RTP stream ended. Information sources could be signaling information or the fact that no RTP media has been received for a longer period of time. 3: no packets: The Metering Process has not received any RTP packets for this RTP stream in the observation interval but the stream has not ended. A VoIP endpoint may have requested the media stream to be suspended, i.e. put 'on hold' (tbd:reference to sendonly ..) Akhter & Scholz Expires January 31, 2013 [Page 12] Internet-Draft IPFIX PerfMon July 2012 Calculation Method: Units of Measurement: n/a Measurement Timing 4.1.7. perfPacketLoss Name: perfPacketLoss Description: The packet loss metric reports the number of individual packets that were lost in the reporting interval. Observation Point: The observation can be made anywhere along the media path or on the endpoints them selves. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: deltaCounter Element Units: packets Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketLoss Status: current 4.1.8. perfPacketExpected Name: perfPacketExpected Description: The number of packets there were expected within a monitoring interval. Observation Point: The observation can be made anywhere along the media path or on the endpoints them selves. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: deltaCounter Akhter & Scholz Expires January 31, 2013 [Page 13] Internet-Draft IPFIX PerfMon July 2012 Element Units: packets Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketExpected Status: current 4.1.9. perfPacketLossRate Name: perfPacketLossRate Description: Percentage of number of packets lost out of the total set of packets sent. Observation Point: The observation can be made anywhere along the media path or on the endpoints them selves. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned16 Element Semantics: quantity Element Units: float16 (IPFIX has not defined float16 yet) Element Range Begin: 0 Element Range End: 0x64 Element Id: TBDperfPacketLossRate Status: current 4.1.10. perfPacketLossEvent Name: perfPacketLossEvent Description: The packet loss event metric reports the number of continuous sets of packets that were lost in the reporting interval. Observation Point: The observation can be made anywhere along the media path or on the endpoints them selves. The observation is only relevant in a unidirectional sense. Akhter & Scholz Expires January 31, 2013 [Page 14] Internet-Draft IPFIX PerfMon July 2012 Element Data Type: unsigned32 Element Semantics: deltaCounter Element Units: event Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketExpected Status: current 4.1.11. perfPacketInterArrivalJitterAvg Name: perfPacketInterArrivalJitterAvg Description: This metric measures the absolute deviation of the difference in packet spacing at the measurement point compared to the packet spacing at the sender. Observation Point: The observation can be made anywhere along the media path or on the receiver. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: quantity Element Units: microseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketInterArrivalJitterAvg Status: current 4.1.12. perfPacketInterArrivalJitterMin Name: perfPacketInterArrivalJitterMin Description: This metric measures the minimum value the calculation used for perfPacketInterArrivalJitterAvg within the monitoring interval. Akhter & Scholz Expires January 31, 2013 [Page 15] Internet-Draft IPFIX PerfMon July 2012 Observation Point: The observation can be made anywhere along the media path or on the receiver. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: quantity Element Units: microseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketInterArrivalJitterMin Status: current 4.1.13. perfPacketInterArrivalJitterMax Name: perfPacketInterArrivalJitterMax Description: This metric measures the maximum value the calculation used for perfPacketInterArrivalJitterAvg within the monitoring interval. Observation Point: The observation can be made anywhere along the media path or on the receiver. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: quantity Element Units: microseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketInterArrivalJitterMax Status: current Akhter & Scholz Expires January 31, 2013 [Page 16] Internet-Draft IPFIX PerfMon July 2012 4.1.14. rtpPacketizationTime Name: rtpPacketizationTime Description: The RTP audio packetization time defines the amount of audio contained in the individual RTP packet. This packetization is typically fixed for the duration of an RTP stream but may be changed. The allowed values depend on the codec. Values typically observed are 10, 20 or 30ms. Depending on the codec the amount of data contained in each RTP packet can be derived from RTP time stamp information or RTP payload size. If the packetization time changes during an IPFIX monitoring interval this value should indicate the most common value monitored. Optionally the rtpPacketizationChange Information Element may be updated accordingly. Observation Point: The observation can be made anywhere along the media path or on the receiver. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned8 Element Semantics: quantity Element Units: milliseconds Element Range Begin: 0 Element Range End: 0xFF Element Id: TBDrtpPacketizationTime Status: current 4.1.15. rtpPacketizationChange Name: rtpPacketizationChange Description: Each time the packetization time of the observed RTP stream changes during the monitoring interval this IE is incremented. Akhter & Scholz Expires January 31, 2013 [Page 17] Internet-Draft IPFIX PerfMon July 2012 Observation Point: The observation can be made anywhere along the media path or on the receiver. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: deltaCounter Element Units: n/a Element Range Begin: 0 Element Range End: 0xFFFFFFFF Element Id: TBDrtpPacketizationChange Status: current 4.1.16. perfDuplicates Name: perfDuplicates Description: Packets belonging to an observed stream or session may be duplicated. The reason or source of duplication (e.g. the generator or entities on the network path) is out of scope of this IE. This IE describes the number of protocol specific duplicate packets observed in the monitoring interval. Observation Point: anywhere Element Data Type: unsigned32 Element Semantics: deltaCounter Element Units: packets Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfDuplicates Status: current Use and Applications Akhter & Scholz Expires January 31, 2013 [Page 18] Internet-Draft IPFIX PerfMon July 2012 Calculation Method: The calculation method for duplicate packets depends on the transport and application protocol used. Duplicates on the application layer SHALL be counted if possible. For [RFC3550] style RTP streams the RTP sequence numbers MUST be used to identify duplicate packets. If a packet with the same sequence number is observed twice or more in the monitoring interval it is counted as duplicate. The perfDuplicates IE describes the number of duplicate packets received, not counting the first packet with each sequence number. Units of Measurement: packets Measurement Timing n/a 4.1.17. rtpPacketOrder 4.1.18. rtpSequenceError 4.1.19. perfRoundTripNetworkDelay Name: perfRoundTripNetworkDelay Description: This metric measures the network round trip time between end stations for a flow. Observation Point: The observation can be made anywhere along the flow path as long as the bidirectional network delay is accounted for. Element Data Type: unsigned32 Element Semantics: quantity Element Units: microseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfRoundTripNetworkDelay Status: current Akhter & Scholz Expires January 31, 2013 [Page 19] Internet-Draft IPFIX PerfMon July 2012 4.2. User and Application Layer 4.2.1. perfSessionSetupDelay Name: perfSessionSetupDelay Description: The Session Setup Delay metric reports the time taken from a request being initiated by a host/endpoint to the response (or request indicator) to the request being observed. This metric is defined in [RFC4710], however the units have been updated to microseconds. Observation Point: This metric needs to be calculated where both request and response can be observed. This could be at network choke points, application proxies, or within the end systems themselves. Element Data Type: unsigned32 Element Semantics: quantity Element Units: microseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfSessionSetupDelay Status: current 4.3. RTP Header 4.3.1. rtpProtocolVersion Name: rtpProtocolVersion Description: Value of the RTP version taken from the RTP header. For [RFC3550] RTP packets this will typically be set to 2. Observation Point: anywhere Element Data Type: unsigned8 Element Semantics: identifier Akhter & Scholz Expires January 31, 2013 [Page 20] Internet-Draft IPFIX PerfMon July 2012 Element Units: none Element Range Begin: 0 Element Range End: 0x02 Element Id: TBDrtpProtocolVersion Status: current Use and Applications The RTP protocol version is taken directly from the RTP header information. It can be used to identify RTP packets and differ between different RTP versions once they become available. Calculation Method: The value is obtained from the RTP header. For [RFC3550] RTP this two bit field must always be set to two (2). In case different values are observed in a single monitoring interval the IE shall carry the value identified in the first RTP packet of the monitoring interval. Units of Measurement: none Measurement Timing does not apply. 4.3.2. rtpSSRC Name: rtpSSRC Description: Value of the synchronization source (SSRC) field in the RTP header of the flow. This field is defined in [RFC3550]. Observation Point: This metric can be gleaned from the RTP packets directly, so the observation point can be either on the any RTP endpoints or on the flow path in between the endpoints. It is possible for the SSRC to change for a media flow without notice. In these cases the IE would represent the value seen in the packet-- the new SSRC and this would be treated as a new 'flow' per configured flow record definitions. Element Data Type: unsigned32 Element Semantics: identifier Element Units: none Akhter & Scholz Expires January 31, 2013 [Page 21] Internet-Draft IPFIX PerfMon July 2012 Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDrtpSSRC Status: current Use and Applications The RTP SSRC value denotes a specific media stream. As such when trying to differentiate media stream problems between session participants the SSRC field is needed. Calculation Method: Copy from RTP header's SSRC field as defined in [RFC3550]. In the case of a non-RTP flow, or the time period in which the flow has not been verified to be a RTP flow the value 0xFFFFFFFE MUST be reported. Units of Measurement: identifier Measurement Timing It is possible that the SSRC may have be renegotiated mid-session due to collisions with other RTP senders. 4.3.3. rtpPayloadType Name: rtpPayloadType Description: The value of the RTP Payload Type Field as observed in the RTP header of the flow. This field is defined in [RFC3550] Observation Point: This metric can be gleaned from the RTP packets directly, so the observation point needs to on the flow path or within the endpoints. Element Data Type: unsigned8 Element Semantics: identifier Element Units: none Element Range Begin: 0 Element Range End: 0xFF Element Id: TBDrtpPayloadType Akhter & Scholz Expires January 31, 2013 [Page 22] Internet-Draft IPFIX PerfMon July 2012 Status: current 4.3.4. rtpMediaType Name: rtpMediaType Description: The rtpMediaType field carries the verbatim media type name (e.g. Audio) as defined by [RFC4855]. Observation Point: anywhere Element Data Type: string Element Semantics: tbd Element Units: n/a Element Range Begin: n/a Element Range End: n/a Element Id: TBDrtpMediaType Status: current 4.3.5. rtpMediaSubType Name: rtpMediaSubType Description: The rtpMediaSubType field carries the verbatim media type name (e.g. PCMA) as defined by [RFC4855]. Observation Point: anywhere Element Data Type: string Element Semantics: tbd Element Units: n/a Element Range Begin: n/a Element Range End: n/a Element Id: TBDrtpMediaSubType Akhter & Scholz Expires January 31, 2013 [Page 23] Internet-Draft IPFIX PerfMon July 2012 Status: current 4.3.6. RTP Payload This section defines additional Information Elements which describe RTP stream payload and characteristics beyond the transport information. Complicated metrics may be subject to different measurement methods. In order to prevent data from being unusable due to incompatible formats or measurement methods most Information Elements are counter values which allow calculation of metrics on mediator or collector systems. Additionally this allows matching flow records to be aggregated by addition, e.g. addition of the rtpPacketCount values of multiple observation intervals. 4.3.6.1. rtpPacketCount Name: rtpPacketCount Description: Number of RTP packets covered in this flow record. This includes observed duplicate packets. Observation Point: anywhere Element Data Type: unsigned32 Element Semantics: deltaCounter Element Units: packets Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDrtpPacketCount Status: current Use and Applications The packet count may be used in conjunction with the rtpPacketCountLoss and rtpPacketCountDiscard information elements to calculate a packet loss rate per monitoring interval. The benefit of transporting absolute numbers versus percentiles is that an IPFIX mediator or collector may merge multiple IPFIX records of the same or different RTP streams into a single record for aggregation purposes. Akhter & Scholz Expires January 31, 2013 [Page 24] Internet-Draft IPFIX PerfMon July 2012 Calculation Method: The IPFIX observer counts all packets belonging to the respective flow. Lost packets as identified by skipped RTP sequence numbers MUST not be counted. Duplicate packets MUST be counted. The packet order is not observed and does not impact the packet count. Units of Measurement: packets Measurement Timing 4.3.6.2. rtpPacketCountLoss Name: rtpPacketCountLoss Description: Number of RTP packets lost in the duration covered by this flow record. The number of lost packets SHOULD be calculated using the RTP sequence numbers. Observation Point: anywhere Element Data Type: unsigned32 Element Semantics: deltaCounter Element Units: packets Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDrtpPacketCountLoss Status: current Use and Applications Calculation Method: The IPFIX observer tracks the RTP sequence numbers of each RTP stream and at the end of the monitoring interval counts the number of packets not received based on the missing sequence numbers. Units of Measurement: packets Measurement Timing Akhter & Scholz Expires January 31, 2013 [Page 25] Internet-Draft IPFIX PerfMon July 2012 4.3.6.3. rtpPacketCountDiscard Name: rtpPacketCountDiscard Description: Passive monitoring equipment shall assume a fixed 40 millisecond jitter buffer (TODO: add reference to TM Forum/ITU). A packet observed later than the expected packet inter-arrival time plus the 40ms is assumed to be received by the RTP receiver too late to be played out. Even though the packet may be received by the RTP receiver it will be discarded which has the same effect as packet loss. Observation Point: anywhere Element Data Type: unsigned32 Element Semantics: deltaCounter Element Units: packets Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDrtpPacketCountDiscard Status: current Use and Applications Calculation Method: The IPFIX observer implements a 40ms jitter buffer per RTP stream observing sequence numbers as an RTP endpoint would do. Packets received 40ms after their scheduled playout time are considered discarded. Lost packets MUST not be counted as discarded. Units of Measurement: packets Measurement Timing 4.3.7. rtpMediaType 4.3.8. rtpMediaSubType 4.3.9. rtpDelayType 4.3.10. rtpDelayOneWay Akhter & Scholz Expires January 31, 2013 [Page 26] Internet-Draft IPFIX PerfMon July 2012 4.3.11. rtpIsSRTP 4.3.12. rtpTimestamp 4.3.13. rtpCodecChange 4.3.14. rtpMarkerBit 4.3.15. rtpComfortNoise 4.3.16. rtpDSCPChange 5. Security Considerations The recommendations in this document do not introduce any additional security issues to those already mentioned in [RFC5101] and [RFC5477] 6. IANA Considerations This document requires an elements assignment to be made by IANA. 7. Acknowledgements The authors would like to thank Shingo Kashima, Jan Novak and Al Morton for their invaluable review and comments. Thank-you. 8. References 8.1. Normative References [RFC5101] Claise, B., "Specification of the IP Flow Information Export (IPFIX) Protocol for the Exchange of IP Traffic Flow Information", RFC 5101, January 2008. [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, "Exporting Type Information for IP Flow Information Export (IPFIX) Information Elements", RFC 5610, July 2009. [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time Application Quality-of-Service Monitoring (RAQMON) Framework", RFC 4710, October 2006. [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. Meyer, "Information Model for IP Flow Information Export", Akhter & Scholz Expires January 31, 2013 [Page 27] Internet-Draft IPFIX PerfMon July 2012 RFC 5102, January 2008. [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", STD 64, RFC 3550, July 2003. [RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP Payload Format for Society of Motion Picture and Television Engineers (SMPTE) 292M Video", RFC 3497, March 2003. [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, "Session Traversal Utilities for NAT (STUN)", RFC 5389, October 2008. [RFC4855] Casner, S., "Media Type Registration of RTP Payload Formats", RFC 4855, February 2007. [RFC6076] Malas, D. and A. Morton, "Basic Telephony SIP End-to-End Performance Metrics", RFC 6076, January 2011. [iana-ipfix-assignments] Internet Assigned Numbers Authority, "IP Flow Information Export Information Elements (http://www.iana.org/assignments/ipfix/ipfix.xml)". 8.2. Informative References [I-D.trammell-ipfix-ie-doctors] Trammell, B. and B. Claise, "Guidelines for Authors and Reviewers of IPFIX Information Elements", draft-trammell-ipfix-ie-doctors-03 (work in progress), October 2011. [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP Headers for Low-Speed Serial Links", RFC 2508, February 1999. [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. Norrman, "The Secure Real-time Transport Protocol (SRTP)", RFC 3711, March 2004. [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. Akhter & Scholz Expires January 31, 2013 [Page 28] Internet-Draft IPFIX PerfMon July 2012 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005. [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and Control Packets on a Single Port", RFC 5761, April 2010. [I-D.huici-ipfix-sipfix] Huici, F., Niccolini, S., and S. Anderson, "SIPFIX: Use Cases and Problem Statement for VoIP Monitoring and Exporting", draft-huici-ipfix-sipfix-00 (work in progress), June 2009. [RFC2321] Bressen, A., "RITA -- The Reliable Internetwork Troubleshooting Agent", RFC 2321, April 1998. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. Carle, "Information Model for Packet Sampling Exports", RFC 5477, March 2009. [VoIP-monitor] L. Chang-Yong, H. Kim, K. Ko, J. Jim, and H. Jeong, "A VoIP Traffic Monitoring System based on NetFlow v9, International Journal of Advanced Science and Technology, vol. 4, Mar. 2009". Authors' Addresses Aamer Akhter Cisco Systems, Inc. 7025 Kit Creek Road RTP, NC 27709 USA Email: aakhter@cisco.com Akhter & Scholz Expires January 31, 2013 [Page 29] Internet-Draft IPFIX PerfMon July 2012 Hendrik Scholz VOIPFUTURE GmbH Wendenstrasse 4 Hamburg 20097 Germany Phone: +49 40 688 900 100 Email: hscholz@voipfuture.com URI: http://www.voipfuture.com/ Akhter & Scholz Expires January 31, 2013 [Page 30]