Network Working Group A. Akhter Internet-Draft Cisco Systems Intended status: Standards Track March 27, 2012 Expires: September 28, 2012 IPFIX Information Elements for Flow Performance Measurement draft-akhter-opsawg-perfmon-ipfix-02.txt Abstract There is a need to be able to quantify and report the performance of network applications and the network service in handling user data. 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 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. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on September 28, 2012. 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 Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of Akhter Expires September 28, 2012 [Page 1] Internet-Draft IPFIX PerfMon March 2012 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 5 3.2. Service Level Agreemnt (SLA) Validation . . . . . . . . . 5 3.3. Fault Isolation and Troubleshooting . . . . . . . . . . . 6 4. New Information Elements . . . . . . . . . . . . . . . . . . . 6 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 6 4.1.1. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 6 4.1.2. perfPacketExpected . . . . . . . . . . . . . . . . . . 7 4.1.3. perfPacketLossRate . . . . . . . . . . . . . . . . . . 8 4.1.4. perfPacketLossEvent . . . . . . . . . . . . . . . . . 8 4.1.5. perfPacketInterArrivalJitterAvg . . . . . . . . . . . 9 4.1.6. perfPacketInterArrivalJitterMin . . . . . . . . . . . 9 4.1.7. perfPacketInterArrivalJitterMax . . . . . . . . . . . 10 4.1.8. perfRoundTripNetworkDelay . . . . . . . . . . . . . . 10 4.2. User and Application Layer . . . . . . . . . . . . . . . . 11 4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 11 4.3. Contextual Elements . . . . . . . . . . . . . . . . . . . 12 4.3.1. mediaRTPSSRC . . . . . . . . . . . . . . . . . . . . . 12 4.3.2. mediaRTPPayloadType . . . . . . . . . . . . . . . . . 12 4.3.3. mediaCodec . . . . . . . . . . . . . . . . . . . . . . 13 5. Security Considerations . . . . . . . . . . . . . . . . . . . 13 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 16 Akhter Expires September 28, 2012 [Page 2] Internet-Draft IPFIX PerfMon March 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 measurents-- 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. 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 documet details the expresison of Akhter Expires September 28, 2012 [Page 3] Internet-Draft IPFIX PerfMon March 2012 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]. This document is also an attempt to generalize as well as standardize the reporting formats and measurement methodology. 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. Element Data Type: The IPFIX informationElementDataTypeas 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] Akhter Expires September 28, 2012 [Page 4] Internet-Draft IPFIX PerfMon March 2012 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 The network operator needs to be able to gauge the end user's satisfaction with the network service. While there are many 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 shoudl be captured. The codec type can be used to determine loss thresholds affecting end user quality and the interactive nature would suggest threshodlds over one way delay. The IPFIX reporting would need to keep this information organized together for opeartor to be able to perform correlated analysis. 3.2. Service Level Agreemnt (SLA) Validation 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, Akhter Expires September 28, 2012 [Page 5] Internet-Draft IPFIX PerfMon March 2012 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 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 operator in a speedy resolution by providing information regarding the network location and nature of the problem. 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. 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. 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.1. perfPacketLoss Name: perfPacketLoss Akhter Expires September 28, 2012 [Page 6] Internet-Draft IPFIX PerfMon March 2012 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.2. 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 Element Units: none Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketExpected Status: current Akhter Expires September 28, 2012 [Page 7] Internet-Draft IPFIX PerfMon March 2012 4.1.3. 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: none Element Range Begin: 0 Element Range End: 0xFFFE Element Id: TBDperfPacketLossRate Status: current 4.1.4. perfPacketLossEvent Name: perfPacketLossEvent Description: The packet loss event metric reports the number of continuous sets of packets that were lost in the reporting interval. Observation Point: The observation can be made anywhere along the media path or on the endpoints them selves. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: deltaCounter Element Units: none Element Range Begin: 0 Akhter Expires September 28, 2012 [Page 8] Internet-Draft IPFIX PerfMon March 2012 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketExpected Status: current 4.1.5. perfPacketInterArrivalJitterAvg Name: perfPacketInterArrivalJitterAvg Description: This metric measures the absolute deviation of the difference in packet spacing at the measurement point compared to the packet spacing at the sender. Observation Point: The observation can be made anywhere along the media path or on the receiver. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: quantity Element Units: microseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketInterArrivalJitterAvg Status: current 4.1.6. perfPacketInterArrivalJitterMin Name: perfPacketInterArrivalJitterMin Description: This metric measures the minimum value the calculation used for perfPacketInterArrivalJitterAvg within the monitoring interval. Observation Point: The observation can be made anywhere along the media path or on the receiver. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Akhter Expires September 28, 2012 [Page 9] Internet-Draft IPFIX PerfMon March 2012 Element Semantics: quantity Element Units: microseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketInterArrivalJitterMin Status: current 4.1.7. perfPacketInterArrivalJitterMax Name: perfPacketInterArrivalJitterMax Description: This metric measures the maximum value the calculation used for perfPacketInterArrivalJitterAvg within the monitoring interval. Observation Point: The observation can be made anywhere along the media path or on the receiver. The observation is only relevant in a unidirectional sense. Element Data Type: unsigned32 Element Semantics: quantity Element Units: microseconds Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDperfPacketInterArrivalJitterMax Status: current 4.1.8. perfRoundTripNetworkDelay Name: perfRoundTripNetworkDelay Description: This metric measures the network round trip time between end stations for a flow. Akhter Expires September 28, 2012 [Page 10] Internet-Draft IPFIX PerfMon March 2012 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 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 Akhter Expires September 28, 2012 [Page 11] Internet-Draft IPFIX PerfMon March 2012 Element Id: TBDperfSessionSetupDelay Status: current 4.3. Contextual Elements 4.3.1. mediaRTPSSRC Name: mediaRTPSSRC 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 needs to on the flow path or within the endpoints. Element Data Type: unsigned32 Element Semantics: identifier Element Units: octets Element Range Begin: 0 Element Range End: 0xFFFFFFFE Element Id: TBDmediaRTPSSRC Status: current 4.3.2. mediaRTPPayloadType Name: mediaRTPPayloadType Description: The value of the RTP Payload Type Field as seen 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 Akhter Expires September 28, 2012 [Page 12] Internet-Draft IPFIX PerfMon March 2012 Element Units: octets Element Range Begin: 0 Element Range End: 0xFF Element Id: TBDmediaRTPPayloadType Status: current 4.3.3. mediaCodec Name: mediaCodec Description: The media codec used in the flow. Observation Point: The ideal location of this metric is on the media generators and consumers. However, given application inspection or static configuration it is possible that intermediate nodes are able to generate codec information. Element Data Type: string Element Semantics: identifier Element Units: octets Element Id: TBDmediaCodec Status: current 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 for their invaluable review and comments. Thank-you. Akhter Expires September 28, 2012 [Page 13] Internet-Draft IPFIX PerfMon March 2012 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", 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. [I-D.ietf-pmol-sip-perf-metrics] Malas, D. and A. Morton, "Basic Telephony SIP End-to-End Performance Metrics", draft-ietf-pmol-sip-perf-metrics-07 (work in progress), September 2010. [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.ietf-pmol-metrics-framework] Clark, A. and B. Claise, "Guidelines for Considering New Performance Metric Development", Akhter Expires September 28, 2012 [Page 14] Internet-Draft IPFIX PerfMon March 2012 draft-ietf-pmol-metrics-framework-12 (work in progress), July 2011. [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. [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. [nProbe] "nProbe - NetFlow/IPFIX Network Probe (http://www.ntop.org/nProbe.html)". [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. Akhter Expires September 28, 2012 [Page 15] Internet-Draft IPFIX PerfMon March 2012 [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". Author's Address Aamer Akhter Cisco Systems, Inc. 7025 Kit Creek Road RTP, NC 27709 USA Email: aakhter@cisco.com Akhter Expires September 28, 2012 [Page 16]