idnits 2.17.1 draft-akhter-opsawg-perfmon-ipfix-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 815 has weird spacing: '... Timing n/a...' == Line 914 has weird spacing: '... Timing does ...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: 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. -- The document date (July 30, 2012) is 4285 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC3497' is defined on line 1212, but no explicit reference was found in the text == Unused Reference: 'RFC5389' is defined on line 1217, but no explicit reference was found in the text == Unused Reference: 'RFC6076' is defined on line 1224, but no explicit reference was found in the text == Unused Reference: 'RFC2508' is defined on line 1240, but no explicit reference was found in the text == Unused Reference: 'RFC3711' is defined on line 1244, but no explicit reference was found in the text == Unused Reference: 'RFC2250' is defined on line 1248, but no explicit reference was found in the text == Unused Reference: 'RFC2890' is defined on line 1252, but no explicit reference was found in the text == Unused Reference: 'RFC4303' is defined on line 1255, but no explicit reference was found in the text == Unused Reference: 'RFC5761' is defined on line 1258, but no explicit reference was found in the text ** Obsolete normative reference: RFC 5101 (Obsoleted by RFC 7011) ** Obsolete normative reference: RFC 5102 (Obsoleted by RFC 7012) ** Obsolete normative reference: RFC 5389 (Obsoleted by RFC 8489) Summary: 3 errors (**), 0 flaws (~~), 14 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Akhter 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track H. Scholz 5 Expires: January 31, 2013 VOIPFUTURE GmbH 6 July 30, 2012 8 IPFIX Information Elements for RTP Flow Performance Measurement 9 draft-akhter-opsawg-perfmon-ipfix-03.txt 11 Abstract 13 There is a need to be able to quantify and report the performance of 14 RTP based applications. This performance data provides information 15 essential in validating service level agreements, fault isolation as 16 well as early warnings of greater problems. This document describes 17 IPFIX Information Elements related to RTP performance measurement of 18 network based applications. In addition, to the performance 19 information several non-metric information elements are also included 20 to provide greater context to the reports. The measurements use 21 audio/video applications as a base but are not restricted to these 22 class of applications. These new IPFIX Information Elements can 23 describe the entire duration of an RTP stream or a smaller time slice 24 of it. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on January 31, 2013. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 62 3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 6 63 3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 6 64 3.2. Fault Isolation and Troubleshooting . . . . . . . . . . . 6 65 4. New Information Elements . . . . . . . . . . . . . . . . . . . 7 66 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 7 67 4.1.1. perfObservationType . . . . . . . . . . . . . . . . . 7 68 4.1.2. perfIntervalStartMilliseconds . . . . . . . . . . . . 8 69 4.1.3. perfIntervalEndMilliseconds . . . . . . . . . . . . . 9 70 4.1.4. perfSampleOffsetMilliseconds . . . . . . . . . . . . . 10 71 4.1.5. perfSampleTimeMilliseconds . . . . . . . . . . . . . . 11 72 4.1.6. perfStreamState . . . . . . . . . . . . . . . . . . . 12 73 4.1.7. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 13 74 4.1.8. perfPacketExpected . . . . . . . . . . . . . . . . . . 13 75 4.1.9. perfPacketLossRate . . . . . . . . . . . . . . . . . . 14 76 4.1.10. perfPacketLossEvent . . . . . . . . . . . . . . . . . 14 77 4.1.11. perfPacketInterArrivalJitterAvg . . . . . . . . . . . 15 78 4.1.12. perfPacketInterArrivalJitterMin . . . . . . . . . . . 15 79 4.1.13. perfPacketInterArrivalJitterMax . . . . . . . . . . . 16 80 4.1.14. rtpPacketizationTime . . . . . . . . . . . . . . . . . 17 81 4.1.15. rtpPacketizationChange . . . . . . . . . . . . . . . . 17 82 4.1.16. perfDuplicates . . . . . . . . . . . . . . . . . . . . 18 83 4.1.17. rtpPacketOrder . . . . . . . . . . . . . . . . . . . . 19 84 4.1.18. rtpSequenceError . . . . . . . . . . . . . . . . . . . 19 85 4.1.19. perfRoundTripNetworkDelay . . . . . . . . . . . . . . 19 86 4.2. User and Application Layer . . . . . . . . . . . . . . . . 20 87 4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 20 88 4.3. RTP Header . . . . . . . . . . . . . . . . . . . . . . . . 20 89 4.3.1. rtpProtocolVersion . . . . . . . . . . . . . . . . . . 20 90 4.3.2. rtpSSRC . . . . . . . . . . . . . . . . . . . . . . . 21 91 4.3.3. rtpPayloadType . . . . . . . . . . . . . . . . . . . . 22 92 4.3.4. rtpMediaType . . . . . . . . . . . . . . . . . . . . . 23 93 4.3.5. rtpMediaSubType . . . . . . . . . . . . . . . . . . . 23 94 4.3.6. RTP Payload . . . . . . . . . . . . . . . . . . . . . 24 95 4.3.7. rtpMediaType . . . . . . . . . . . . . . . . . . . . . 26 96 4.3.8. rtpMediaSubType . . . . . . . . . . . . . . . . . . . 26 97 4.3.9. rtpDelayType . . . . . . . . . . . . . . . . . . . . . 26 98 4.3.10. rtpDelayOneWay . . . . . . . . . . . . . . . . . . . . 26 99 4.3.11. rtpIsSRTP . . . . . . . . . . . . . . . . . . . . . . 27 100 4.3.12. rtpTimestamp . . . . . . . . . . . . . . . . . . . . . 27 101 4.3.13. rtpCodecChange . . . . . . . . . . . . . . . . . . . . 27 102 4.3.14. rtpMarkerBit . . . . . . . . . . . . . . . . . . . . . 27 103 4.3.15. rtpComfortNoise . . . . . . . . . . . . . . . . . . . 27 104 4.3.16. rtpDSCPChange . . . . . . . . . . . . . . . . . . . . 27 105 5. Security Considerations . . . . . . . . . . . . . . . . . . . 27 106 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 107 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 108 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 109 8.1. Normative References . . . . . . . . . . . . . . . . . . . 27 110 8.2. Informative References . . . . . . . . . . . . . . . . . . 28 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 113 1. Introduction 115 Today's networks support a multitude of highly demanding and 116 sensitive network applications. Network issues are readily apparent 117 by the users of these applications due to the sensitivity of these 118 applications to impaired network conditions. Examples of these 119 network applications include applications making use of IP based 120 audio, video, database transactions, virtual desktop interface (VDI), 121 online gaming, cloud services and many more. In some cases, the 122 impaired application translates directly to loss of revenue. In 123 other cases, there may be regulatory or contractual service level 124 agreements that motivate the network operator. Due to the 125 sensitivity of these types of applications to impaired service it 126 leaves a poor impression of the service on the user-- regardless of 127 the actual performance of the network itself. In the case of an 128 actual problem within the network service, monitoring the performance 129 may yield a early indicator of a much more serious problem. 131 Due to the demanding and sensitive nature of these applications, 132 network operators have tried to engineer their networks towards 133 wringing better and differentiated performance. However, that same 134 differentiated design prevents network operators from extrapolating 135 observational data from one application to another, or from one set 136 of synthetic (active test) test traffic to actual application 137 performance. This gap highlights the importance of generic 138 measurements as well as the reliance on user traffic measurements-- 139 rather than synthetic tests. 141 Performance measurements on user data provide greater visibility not 142 only into the quality of experience of the end users but also 143 visibility into network health. With regards to network health, as 144 flow performance is being measured, there will be visibility into the 145 end to end performance which means that not only visibility into 146 local network health, but also viability into remote network health. 147 If these measurements are made at multiple points within the network 148 (or between the network and end device) then there is not only 149 identification that there might be an issue, but a span of area can 150 be established where the issue might be. The resolution of the fault 151 increases with the number of measurement points along the flow path. 153 IP based applications, esp. those with real-time requirements, may 154 suffer temporarily from impairments such as bandwidth bottlenecks or 155 packet loss. Performance measurement with average values is not able 156 to record and highlight these issues. Due to this the measurement 157 interval must be configurable to a short time slice in order to 158 indicate such temporary impairments. Aggregation of measurements 159 shall be possible to aggregate multiple measurements of the same 160 application stream or multiple streams of the same type but 161 potentially generated by different users. 163 The IP Flow Information Export Protocol (IPFIX) [RFC5101] provides 164 new levels of flexibility in reporting from measurement points across 165 the life cycle of a network based application. IPFIX can provide 166 granular results in terms of flow specificity as well as time 167 granularity. At the same time, IPFIX allows for summarization of 168 data along different types of boundaries for operators that are 169 unconcerned about specific sessions but about health of a service or 170 a portion of the network. This document details the expression of 171 IPFIX Information Elements whose calculation is defined in an 172 accompanying document. 174 As this document covers the reporting of these metrics via IPFIX, 175 consideration is taken with mapping the metric's capabilities and 176 context with the IPFIX information and data representation model. 177 The guidelines outlined in [I-D.trammell-ipfix-ie-doctors] are used 178 to ensure proper IPFIX information element definition. 180 There has been related work in this area such as [RFC2321]. 181 [I-D.huici-ipfix-sipfix], and [VoIP-monitor]. 183 2. Terminology 185 Terms used in this document that are defined in the Terminology 186 section of the IPFIX Protocol [RFC5101] document are to be 187 interpreted as defined there. 189 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 190 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 191 document are to be interpreted as described in RFC 2119 [RFC2119]. 193 In addition, the information element definitions use the following 194 terms: 196 Name: Name of the information element per the IPFIX rules defined in 197 Section 2.3 of [RFC5102] 199 Description: Short description of what the information element is 200 trying to convey. 202 Observation Point: Where the measurement is meant to be performed. 203 Either at an intermediate point (for example, a router) or end 204 system. 206 Element Data Type: The IPFIX informationElementDataType as defined 207 in Section 3.1 of [RFC5610] 209 Element Semantics: The IPFIX informationElementSemantics as defined 210 in section Section 3.6 of [RFC5610] 212 Element Units: The IPFIX informationElementUnits as defined in 213 section Section 3.7 of [RFC5610] 215 Element Range Begin: The IPFIX informationElementRangeBegin as 216 defined in section Section 3.7 of [RFC5610] 218 Element Range End: The IPFIX informationElementRangeEnd as defined 219 in section Section 3.7 of [RFC5610] 221 Element Id: The IPFIX global unique element ID as defined in Section 222 3.2 of [RFC5101] 224 Status: The status of the specification of this IPFIX Information 225 Element. 227 3. General Usage 229 3.1. Quality of Service (QoS) Monitoring 231 For QoS monitoring, it is important to be able to capture the 232 application context. For example, in the case of interactive audio 233 flows, the codec and the fact that the application is interactive 234 should be captured. The codec type can be used to determine loss 235 thresholds affecting end user quality and the interactive nature 236 would suggest thresholds over one way delay. The IPFIX reporting 237 would need to keep this information organized together for operator 238 to be able to perform correlated analysis. 240 3.2. Fault Isolation and Troubleshooting 242 It has been generally easier to troubleshoot and fix problems that 243 are binary in nature: it either works or does not work. The host is 244 pingable or not pingable. However, the much more difficult to 245 resolve issues that are transitory in nature, move from location to 246 location, more complicated that simple ICMP reachability and many 247 times unverifiable reports by the users themselves. It is these 248 intermittent and seemingly inconsistent network impairments that 249 performance metrics can be extremely helpful with. Just the basic 250 timely detection that there is a problem (or an impending problem) 251 can give the provider the confidence that there is a real problem 252 that needs to be resolved. The next step would be to assist the 253 operator in a speedy resolution by providing information regarding 254 the network location and nature of the problem. 256 Transient problems which affect a user only for a short time of this 257 session can be made visible with measurements taken in short fixed 258 time slices, e.g. every 10 seconds. While a traditional measurement 259 on a per session basis may not show an intermittent impairment (e.g. 260 packet loss) the short measurement interval highlights these. 262 4. New Information Elements 264 The information elements are organized into two main groups: 266 Transport Layer: Metrics that might be calculated from observations 267 at higher layers but essentially provide information about the 268 network transport of user date. For example, the metrics related 269 to packet loss, latency and jitter would be defined here. 271 RTP Header: Information Elements that describe the RTP stream 272 properties based on RTP header information but not the RTP payload 273 itself. 275 RTP Payload: Information Elements that describe the RTP payload. 276 For example, packet count and media type. 278 User and Application Layer: Metrics that are might be affected by 279 the network indirectly, but are ultimately related to user, end- 280 system and session states. For example, session setup time, 281 transaction rate and session duration would be defined here. 283 4.1. Transport Layer 285 4.1.1. perfObservationType 287 Name: perfObservationType 289 Description: The observation type is analog to sipObservationType 290 defined in [trammel sip-msg]. It defines the place of the 291 metering process in the network path. 293 Observation Point: The observation can be made anywhere along the 294 media path or on the endpoints themselves. The observation is 295 only relevant in a unidirectional sense. 297 Element Data Type: unsigned8 299 Element Semantics: identifier 301 Element Units: n/a 303 Element Range Begin: 0 305 Element Range End: 0xFF 307 Element Id: TBDperfObservationType 309 Status: current 311 Use and Applications 313 0: unknown: The Metering Process does not specify the observation 314 type 316 1: receiver: The Metering Process is, or is co-located with, the 317 receiver of the RTP stream. 319 2: sender: The Metering Process is, or is co-located with, the 320 sender of the RTP stream. 322 3: passive: The Metering Process passively observed the RTP 323 stream. 325 4: rtcp: The Metering Process obtains the data conveyed in the 326 IPFIX message for one or more RTCP reports. 328 Calculation Method: 330 Units of Measurement: n/a 332 Measurement Timing 334 4.1.2. perfIntervalStartMilliseconds 336 Name: perfIntervalStartMilliseconds 338 Description: Start time of the monitoring interval in milliseconds 339 since 0000 UTC Jan 1, 1970. The time is taken from the local 340 clock which SHOULD be NTP synchronized. If a flow only covers 341 part of the monitoring interval (for example, the flow started 342 after the interval start time), start time MUST be set to the 343 start time of the monitoring interval. 345 Observation Point: 347 Element Data Type: dateTimeMilliseconds 349 Element Semantics: identifier 351 Element Units: n/a 353 Element Range Begin: 0 355 Element Range End: ??? 357 Element Id: TBDperfIntervalStartMilliseconds 359 Status: current 361 Use and Applications 363 Calculation Method: 365 Units of Measurement: n/a 367 Measurement Timing 369 4.1.3. perfIntervalEndMilliseconds 371 Name: perfIntervalEndMilliseconds 373 Description: End time of the flow's monitoring interval in 374 milliseconds since 0000 UTC Jan 1, 1970. The time is taken from 375 the local clock which SHOULD be NTP synchronized. If the flow 376 covers part of the monitoring interval (for example, the flow 377 ended before the interval end time), the 378 perfIntervalEndMilliseconds MUST be set to the end of observation 379 interval. 381 Observation Point: 383 Element Data Type: datetimeMilliseconds 385 Element Semantics: identifier 387 Element Units: n/a 389 Element Range Begin: 0 390 Element Range End: 0xFF 392 Element Id: TBDperfObservationType 394 Status: current 396 Use and Applications 398 0: unknown: The Metering Process does not specify the observation 399 type 401 1: receiver: The Metering Process is, or is co-located with, the 402 receiver of the RTP stream. 404 2: sender: The Metering Process is, or is co-located with, the 405 sender of the RTP stream. 407 3: passive: The Metering Process passively observed the RTP 408 stream. 410 4: rtcp: TBD 412 Calculation Method: 414 Units of Measurement: n/a 416 Measurement Timing 418 4.1.4. perfSampleOffsetMilliseconds 420 Name: perfSampleOffsetMilliseconds 422 Description: Offset of the observation interval contained in this 423 flow record. The value is measured in milliseconds and contains 424 the offset of the beginning of the flow record from the beginning 425 of the RTP stream. 427 Observation Point: 429 Element Data Type: unsigned32 431 Element Semantics: identifier 433 Element Units: milliseconds 434 Element Range Begin: 0 436 Element Range End: 0xFFFFFFFF 438 Element Id: TBDperfSampleOffsetMilliseconds 440 Status: current 442 Use and Applications 444 Calculation Method: 446 Measurement Timing 448 4.1.5. perfSampleTimeMilliseconds 450 Name: perfSampleTimeMilliseconds 452 Description: An IPFIX observer may generate and export a flow record 453 for the entire duration of an RTP stream or for a specific part, 454 e.g. a fixed time slice of 10 seconds. In case a single flow 455 record is created the rtpSampleTime equals the RTP stream duration 456 in milliseconds. In either case the rtpStreamState IE should be 457 set to true if this flow record describes an ended RTP stream. 459 Observation Point: 461 Element Data Type: unsigned32 463 Element Semantics: DeltaCounter 465 Element Units: milliseconds 467 Element Range Begin: 0 469 Element Range End: 0xFFFFFFFF 471 Element Id: TBDperfSampleTimeMilliseconds 473 Status: current 475 Use and Applications 477 Calculation Method: 479 Units of Measurement: milliseconds 481 Measurement Timing 483 4.1.6. perfStreamState 485 Name: perfStreamState 487 Description: Using the rtpSampleOffset and rtpSampleTime IEs flow 488 entries may be generated which describe only part of an RTP 489 stream. This IE is used to describe the state of the observed 490 stream, e.g. to indicate the reception of the last flow record 491 belonging to a single RTP stream. 493 Observation Point: 495 Element Data Type: unsigned8 497 Element Semantics: identifier 499 Element Units: n/a 501 Element Range Begin: 0 503 Element Range End: 0xFF 505 Element Id: TBDperfObservationType 507 Status: current 509 Use and Applications 511 0: undefined: The state of the stream is not known. 513 1: running: The Metering Process expects more RTP packets or has 514 already received packets for this RTP stream which are outside 515 the scope of this flow record. 517 2: ended: The Metering Process determined that the RTP stream 518 ended. Information sources could be signaling information or 519 the fact that no RTP media has been received for a longer 520 period of time. 522 3: no packets: The Metering Process has not received any RTP 523 packets for this RTP stream in the observation interval but the 524 stream has not ended. A VoIP endpoint may have requested the 525 media stream to be suspended, i.e. put 'on hold' (tbd:reference 526 to sendonly ..) 528 Calculation Method: 530 Units of Measurement: n/a 532 Measurement Timing 534 4.1.7. perfPacketLoss 536 Name: perfPacketLoss 538 Description: The packet loss metric reports the number of individual 539 packets that were lost in the reporting interval. 541 Observation Point: The observation can be made anywhere along the 542 media path or on the endpoints them selves. The observation is 543 only relevant in a unidirectional sense. 545 Element Data Type: unsigned32 547 Element Semantics: deltaCounter 549 Element Units: packets 551 Element Range Begin: 0 553 Element Range End: 0xFFFFFFFE 555 Element Id: TBDperfPacketLoss 557 Status: current 559 4.1.8. perfPacketExpected 561 Name: perfPacketExpected 563 Description: The number of packets there were expected within a 564 monitoring interval. 566 Observation Point: The observation can be made anywhere along the 567 media path or on the endpoints them selves. The observation is 568 only relevant in a unidirectional sense. 570 Element Data Type: unsigned32 572 Element Semantics: deltaCounter 573 Element Units: packets 575 Element Range Begin: 0 577 Element Range End: 0xFFFFFFFE 579 Element Id: TBDperfPacketExpected 581 Status: current 583 4.1.9. perfPacketLossRate 585 Name: perfPacketLossRate 587 Description: Percentage of number of packets lost out of the total 588 set of packets sent. 590 Observation Point: The observation can be made anywhere along the 591 media path or on the endpoints them selves. The observation is 592 only relevant in a unidirectional sense. 594 Element Data Type: unsigned16 596 Element Semantics: quantity 598 Element Units: float16 (IPFIX has not defined float16 yet) 600 Element Range Begin: 0 602 Element Range End: 0x64 604 Element Id: TBDperfPacketLossRate 606 Status: current 608 4.1.10. perfPacketLossEvent 610 Name: perfPacketLossEvent 612 Description: The packet loss event metric reports the number of 613 continuous sets of packets that were lost in the reporting 614 interval. 616 Observation Point: The observation can be made anywhere along the 617 media path or on the endpoints them selves. The observation is 618 only relevant in a unidirectional sense. 620 Element Data Type: unsigned32 622 Element Semantics: deltaCounter 624 Element Units: event 626 Element Range Begin: 0 628 Element Range End: 0xFFFFFFFE 630 Element Id: TBDperfPacketExpected 632 Status: current 634 4.1.11. perfPacketInterArrivalJitterAvg 636 Name: perfPacketInterArrivalJitterAvg 638 Description: This metric measures the absolute deviation of the 639 difference in packet spacing at the measurement point compared to 640 the packet spacing at the sender. 642 Observation Point: The observation can be made anywhere along the 643 media path or on the receiver. The observation is only relevant 644 in a unidirectional sense. 646 Element Data Type: unsigned32 648 Element Semantics: quantity 650 Element Units: microseconds 652 Element Range Begin: 0 654 Element Range End: 0xFFFFFFFE 656 Element Id: TBDperfPacketInterArrivalJitterAvg 658 Status: current 660 4.1.12. perfPacketInterArrivalJitterMin 662 Name: perfPacketInterArrivalJitterMin 664 Description: This metric measures the minimum value the calculation 665 used for perfPacketInterArrivalJitterAvg within the monitoring 666 interval. 668 Observation Point: The observation can be made anywhere along the 669 media path or on the receiver. The observation is only relevant 670 in a unidirectional sense. 672 Element Data Type: unsigned32 674 Element Semantics: quantity 676 Element Units: microseconds 678 Element Range Begin: 0 680 Element Range End: 0xFFFFFFFE 682 Element Id: TBDperfPacketInterArrivalJitterMin 684 Status: current 686 4.1.13. perfPacketInterArrivalJitterMax 688 Name: perfPacketInterArrivalJitterMax 690 Description: This metric measures the maximum value the calculation 691 used for perfPacketInterArrivalJitterAvg within the monitoring 692 interval. 694 Observation Point: The observation can be made anywhere along the 695 media path or on the receiver. The observation is only relevant 696 in a unidirectional sense. 698 Element Data Type: unsigned32 700 Element Semantics: quantity 702 Element Units: microseconds 704 Element Range Begin: 0 706 Element Range End: 0xFFFFFFFE 708 Element Id: TBDperfPacketInterArrivalJitterMax 710 Status: current 712 4.1.14. rtpPacketizationTime 714 Name: rtpPacketizationTime 716 Description: The RTP audio packetization time defines the amount of 717 audio contained in the individual RTP packet. This packetization 718 is typically fixed for the duration of an RTP stream but may be 719 changed. The allowed values depend on the codec. Values 720 typically observed are 10, 20 or 30ms. 722 Depending on the codec the amount of data contained in each RTP 723 packet can be derived from RTP time stamp information or RTP 724 payload size. 726 If the packetization time changes during an IPFIX monitoring 727 interval this value should indicate the most common value 728 monitored. Optionally the rtpPacketizationChange Information 729 Element may be updated accordingly. 731 Observation Point: The observation can be made anywhere along the 732 media path or on the receiver. The observation is only relevant 733 in a unidirectional sense. 735 Element Data Type: unsigned8 737 Element Semantics: quantity 739 Element Units: milliseconds 741 Element Range Begin: 0 743 Element Range End: 0xFF 745 Element Id: TBDrtpPacketizationTime 747 Status: current 749 4.1.15. rtpPacketizationChange 751 Name: rtpPacketizationChange 753 Description: Each time the packetization time of the observed RTP 754 stream changes during the monitoring interval this IE is 755 incremented. 757 Observation Point: The observation can be made anywhere along the 758 media path or on the receiver. The observation is only relevant 759 in a unidirectional sense. 761 Element Data Type: unsigned32 763 Element Semantics: deltaCounter 765 Element Units: n/a 767 Element Range Begin: 0 769 Element Range End: 0xFFFFFFFF 771 Element Id: TBDrtpPacketizationChange 773 Status: current 775 4.1.16. perfDuplicates 777 Name: perfDuplicates 779 Description: Packets belonging to an observed stream or session may 780 be duplicated. The reason or source of duplication (e.g. the 781 generator or entities on the network path) is out of scope of this 782 IE. This IE describes the number of protocol specific duplicate 783 packets observed in the monitoring interval. 785 Observation Point: anywhere 787 Element Data Type: unsigned32 789 Element Semantics: deltaCounter 791 Element Units: packets 793 Element Range Begin: 0 795 Element Range End: 0xFFFFFFFE 797 Element Id: TBDperfDuplicates 799 Status: current 801 Use and Applications 802 Calculation Method: The calculation method for duplicate packets 803 depends on the transport and application protocol used. 804 Duplicates on the application layer SHALL be counted if possible. 806 For [RFC3550] style RTP streams the RTP sequence numbers MUST be 807 used to identify duplicate packets. If a packet with the same 808 sequence number is observed twice or more in the monitoring 809 interval it is counted as duplicate. The perfDuplicates IE 810 describes the number of duplicate packets received, not counting 811 the first packet with each sequence number. 813 Units of Measurement: packets 815 Measurement Timing n/a 817 4.1.17. rtpPacketOrder 819 4.1.18. rtpSequenceError 821 4.1.19. perfRoundTripNetworkDelay 823 Name: perfRoundTripNetworkDelay 825 Description: This metric measures the network round trip time 826 between end stations for a flow. 828 Observation Point: The observation can be made anywhere along the 829 flow path as long as the bidirectional network delay is accounted 830 for. 832 Element Data Type: unsigned32 834 Element Semantics: quantity 836 Element Units: microseconds 838 Element Range Begin: 0 840 Element Range End: 0xFFFFFFFE 842 Element Id: TBDperfRoundTripNetworkDelay 844 Status: current 846 4.2. User and Application Layer 848 4.2.1. perfSessionSetupDelay 850 Name: perfSessionSetupDelay 852 Description: The Session Setup Delay metric reports the time taken 853 from a request being initiated by a host/endpoint to the response 854 (or request indicator) to the request being observed. This metric 855 is defined in [RFC4710], however the units have been updated to 856 microseconds. 858 Observation Point: This metric needs to be calculated where both 859 request and response can be observed. This could be at network 860 choke points, application proxies, or within the end systems 861 themselves. 863 Element Data Type: unsigned32 865 Element Semantics: quantity 867 Element Units: microseconds 869 Element Range Begin: 0 871 Element Range End: 0xFFFFFFFE 873 Element Id: TBDperfSessionSetupDelay 875 Status: current 877 4.3. RTP Header 879 4.3.1. rtpProtocolVersion 881 Name: rtpProtocolVersion 883 Description: Value of the RTP version taken from the RTP header. 884 For [RFC3550] RTP packets this will typically be set to 2. 886 Observation Point: anywhere 888 Element Data Type: unsigned8 890 Element Semantics: identifier 891 Element Units: none 893 Element Range Begin: 0 895 Element Range End: 0x02 897 Element Id: TBDrtpProtocolVersion 899 Status: current 901 Use and Applications The RTP protocol version is taken directly from 902 the RTP header information. It can be used to identify RTP 903 packets and differ between different RTP versions once they become 904 available. 906 Calculation Method: The value is obtained from the RTP header. For 907 [RFC3550] RTP this two bit field must always be set to two (2). 908 In case different values are observed in a single monitoring 909 interval the IE shall carry the value identified in the first RTP 910 packet of the monitoring interval. 912 Units of Measurement: none 914 Measurement Timing does not apply. 916 4.3.2. rtpSSRC 918 Name: rtpSSRC 920 Description: Value of the synchronization source (SSRC) field in the 921 RTP header of the flow. This field is defined in [RFC3550]. 923 Observation Point: This metric can be gleaned from the RTP packets 924 directly, so the observation point can be either on the any RTP 925 endpoints or on the flow path in between the endpoints. It is 926 possible for the SSRC to change for a media flow without notice. 927 In these cases the IE would represent the value seen in the 928 packet-- the new SSRC and this would be treated as a new 'flow' 929 per configured flow record definitions. 931 Element Data Type: unsigned32 933 Element Semantics: identifier 935 Element Units: none 936 Element Range Begin: 0 938 Element Range End: 0xFFFFFFFE 940 Element Id: TBDrtpSSRC 942 Status: current 944 Use and Applications The RTP SSRC value denotes a specific media 945 stream. As such when trying to differentiate media stream 946 problems between session participants the SSRC field is needed. 948 Calculation Method: Copy from RTP header's SSRC field as defined in 949 [RFC3550]. In the case of a non-RTP flow, or the time period in 950 which the flow has not been verified to be a RTP flow the value 951 0xFFFFFFFE MUST be reported. 953 Units of Measurement: identifier 955 Measurement Timing It is possible that the SSRC may have be 956 renegotiated mid-session due to collisions with other RTP senders. 958 4.3.3. rtpPayloadType 960 Name: rtpPayloadType 962 Description: The value of the RTP Payload Type Field as observed in 963 the RTP header of the flow. This field is defined in [RFC3550] 965 Observation Point: This metric can be gleaned from the RTP packets 966 directly, so the observation point needs to on the flow path or 967 within the endpoints. 969 Element Data Type: unsigned8 971 Element Semantics: identifier 973 Element Units: none 975 Element Range Begin: 0 977 Element Range End: 0xFF 979 Element Id: TBDrtpPayloadType 980 Status: current 982 4.3.4. rtpMediaType 984 Name: rtpMediaType 986 Description: The rtpMediaType field carries the verbatim media type 987 name (e.g. Audio) as defined by [RFC4855]. 989 Observation Point: anywhere 991 Element Data Type: string 993 Element Semantics: tbd 995 Element Units: n/a 997 Element Range Begin: n/a 999 Element Range End: n/a 1001 Element Id: TBDrtpMediaType 1003 Status: current 1005 4.3.5. rtpMediaSubType 1007 Name: rtpMediaSubType 1009 Description: The rtpMediaSubType field carries the verbatim media 1010 type name (e.g. PCMA) as defined by [RFC4855]. 1012 Observation Point: anywhere 1014 Element Data Type: string 1016 Element Semantics: tbd 1018 Element Units: n/a 1020 Element Range Begin: n/a 1022 Element Range End: n/a 1024 Element Id: TBDrtpMediaSubType 1025 Status: current 1027 4.3.6. RTP Payload 1029 This section defines additional Information Elements which describe 1030 RTP stream payload and characteristics beyond the transport 1031 information. Complicated metrics may be subject to different 1032 measurement methods. In order to prevent data from being unusable 1033 due to incompatible formats or measurement methods most Information 1034 Elements are counter values which allow calculation of metrics on 1035 mediator or collector systems. Additionally this allows matching 1036 flow records to be aggregated by addition, e.g. addition of the 1037 rtpPacketCount values of multiple observation intervals. 1039 4.3.6.1. rtpPacketCount 1041 Name: rtpPacketCount 1043 Description: Number of RTP packets covered in this flow record. 1044 This includes observed duplicate packets. 1046 Observation Point: anywhere 1048 Element Data Type: unsigned32 1050 Element Semantics: deltaCounter 1052 Element Units: packets 1054 Element Range Begin: 0 1056 Element Range End: 0xFFFFFFFE 1058 Element Id: TBDrtpPacketCount 1060 Status: current 1062 Use and Applications The packet count may be used in conjunction 1063 with the rtpPacketCountLoss and rtpPacketCountDiscard information 1064 elements to calculate a packet loss rate per monitoring interval. 1065 The benefit of transporting absolute numbers versus percentiles is 1066 that an IPFIX mediator or collector may merge multiple IPFIX 1067 records of the same or different RTP streams into a single record 1068 for aggregation purposes. 1070 Calculation Method: The IPFIX observer counts all packets belonging 1071 to the respective flow. Lost packets as identified by skipped RTP 1072 sequence numbers MUST not be counted. Duplicate packets MUST be 1073 counted. The packet order is not observed and does not impact the 1074 packet count. 1076 Units of Measurement: packets 1078 Measurement Timing 1080 4.3.6.2. rtpPacketCountLoss 1082 Name: rtpPacketCountLoss 1084 Description: Number of RTP packets lost in the duration covered by 1085 this flow record. The number of lost packets SHOULD be calculated 1086 using the RTP sequence numbers. 1088 Observation Point: anywhere 1090 Element Data Type: unsigned32 1092 Element Semantics: deltaCounter 1094 Element Units: packets 1096 Element Range Begin: 0 1098 Element Range End: 0xFFFFFFFE 1100 Element Id: TBDrtpPacketCountLoss 1102 Status: current 1104 Use and Applications 1106 Calculation Method: The IPFIX observer tracks the RTP sequence 1107 numbers of each RTP stream and at the end of the monitoring 1108 interval counts the number of packets not received based on the 1109 missing sequence numbers. 1111 Units of Measurement: packets 1113 Measurement Timing 1115 4.3.6.3. rtpPacketCountDiscard 1117 Name: rtpPacketCountDiscard 1119 Description: Passive monitoring equipment shall assume a fixed 40 1120 millisecond jitter buffer (TODO: add reference to TM Forum/ITU). 1121 A packet observed later than the expected packet inter-arrival 1122 time plus the 40ms is assumed to be received by the RTP receiver 1123 too late to be played out. Even though the packet may be received 1124 by the RTP receiver it will be discarded which has the same effect 1125 as packet loss. 1127 Observation Point: anywhere 1129 Element Data Type: unsigned32 1131 Element Semantics: deltaCounter 1133 Element Units: packets 1135 Element Range Begin: 0 1137 Element Range End: 0xFFFFFFFE 1139 Element Id: TBDrtpPacketCountDiscard 1141 Status: current 1143 Use and Applications 1145 Calculation Method: The IPFIX observer implements a 40ms jitter 1146 buffer per RTP stream observing sequence numbers as an RTP 1147 endpoint would do. Packets received 40ms after their scheduled 1148 playout time are considered discarded. Lost packets MUST not be 1149 counted as discarded. 1151 Units of Measurement: packets 1153 Measurement Timing 1155 4.3.7. rtpMediaType 1157 4.3.8. rtpMediaSubType 1159 4.3.9. rtpDelayType 1161 4.3.10. rtpDelayOneWay 1162 4.3.11. rtpIsSRTP 1164 4.3.12. rtpTimestamp 1166 4.3.13. rtpCodecChange 1168 4.3.14. rtpMarkerBit 1170 4.3.15. rtpComfortNoise 1172 4.3.16. rtpDSCPChange 1174 5. Security Considerations 1176 The recommendations in this document do not introduce any additional 1177 security issues to those already mentioned in [RFC5101] and [RFC5477] 1179 6. IANA Considerations 1181 This document requires an elements assignment to be made by IANA. 1183 7. Acknowledgements 1185 The authors would like to thank Shingo Kashima, Jan Novak and Al 1186 Morton for their invaluable review and comments. Thank-you. 1188 8. References 1190 8.1. Normative References 1192 [RFC5101] Claise, B., "Specification of the IP Flow Information 1193 Export (IPFIX) Protocol for the Exchange of IP Traffic 1194 Flow Information", RFC 5101, January 2008. 1196 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 1197 "Exporting Type Information for IP Flow Information Export 1198 (IPFIX) Information Elements", RFC 5610, July 2009. 1200 [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time 1201 Application Quality-of-Service Monitoring (RAQMON) 1202 Framework", RFC 4710, October 2006. 1204 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 1205 Meyer, "Information Model for IP Flow Information Export", 1206 RFC 5102, January 2008. 1208 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1209 Jacobson, "RTP: A Transport Protocol for Real-Time 1210 Applications", STD 64, RFC 3550, July 2003. 1212 [RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP 1213 Payload Format for Society of Motion Picture and 1214 Television Engineers (SMPTE) 292M Video", RFC 3497, 1215 March 2003. 1217 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 1218 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 1219 October 2008. 1221 [RFC4855] Casner, S., "Media Type Registration of RTP Payload 1222 Formats", RFC 4855, February 2007. 1224 [RFC6076] Malas, D. and A. Morton, "Basic Telephony SIP End-to-End 1225 Performance Metrics", RFC 6076, January 2011. 1227 [iana-ipfix-assignments] 1228 Internet Assigned Numbers Authority, "IP Flow Information 1229 Export Information Elements 1230 (http://www.iana.org/assignments/ipfix/ipfix.xml)". 1232 8.2. Informative References 1234 [I-D.trammell-ipfix-ie-doctors] 1235 Trammell, B. and B. Claise, "Guidelines for Authors and 1236 Reviewers of IPFIX Information Elements", 1237 draft-trammell-ipfix-ie-doctors-03 (work in progress), 1238 October 2011. 1240 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 1241 Headers for Low-Speed Serial Links", RFC 2508, 1242 February 1999. 1244 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 1245 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 1246 RFC 3711, March 2004. 1248 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 1249 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 1250 January 1998. 1252 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 1253 RFC 2890, September 2000. 1255 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 1256 RFC 4303, December 2005. 1258 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 1259 Control Packets on a Single Port", RFC 5761, April 2010. 1261 [I-D.huici-ipfix-sipfix] 1262 Huici, F., Niccolini, S., and S. Anderson, "SIPFIX: Use 1263 Cases and Problem Statement for VoIP Monitoring and 1264 Exporting", draft-huici-ipfix-sipfix-00 (work in 1265 progress), June 2009. 1267 [RFC2321] Bressen, A., "RITA -- The Reliable Internetwork 1268 Troubleshooting Agent", RFC 2321, April 1998. 1270 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1271 Requirement Levels", BCP 14, RFC 2119, March 1997. 1273 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 1274 Carle, "Information Model for Packet Sampling Exports", 1275 RFC 5477, March 2009. 1277 [VoIP-monitor] 1278 L. Chang-Yong, H. Kim, K. Ko, J. Jim, and H. Jeong, "A 1279 VoIP Traffic Monitoring System based on NetFlow v9, 1280 International Journal of Advanced Science and Technology, 1281 vol. 4, Mar. 2009". 1283 Authors' Addresses 1285 Aamer Akhter 1286 Cisco Systems, Inc. 1287 7025 Kit Creek Road 1288 RTP, NC 27709 1289 USA 1291 Email: aakhter@cisco.com 1292 Hendrik Scholz 1293 VOIPFUTURE GmbH 1294 Wendenstrasse 4 1295 Hamburg 20097 1296 Germany 1298 Phone: +49 40 688 900 100 1299 Email: hscholz@voipfuture.com 1300 URI: http://www.voipfuture.com/