idnits 2.17.1 draft-akhter-ipfix-perfmon-01.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 -- The document date (October 25, 2010) is 4930 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: 'I-D.ietf-pmol-metrics-framework' is defined on line 931, 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) == Outdated reference: A later version (-12) exists of draft-ietf-pmol-metrics-framework-05 == Outdated reference: A later version (-03) exists of draft-trammell-ipfix-ie-doctors-00 Summary: 3 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPFIX Working Group A. Akhter 3 Internet-Draft Cisco Systems 4 Intended status: Standards Track October 25, 2010 5 Expires: April 28, 2011 7 Information Elements for Flow Performance Measurement 8 draft-akhter-ipfix-perfmon-01.txt 10 Abstract 12 There is a need to be able to quantify and report the performance of 13 network applications and the network service in handling user data. 14 This performance data provides information essential in validating 15 service level agreements, fault isolation as well as early warnings 16 of greater problems. This document describes IPFIX Information 17 Elements related to performance measurement of network based 18 applications. In addition, to the performance information several 19 non-metric information elements are also included to provide greater 20 context to the reports. The measurements use audio/video 21 applications as a base but are not restricted to these class of 22 applications. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on April 28, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3. General Usage . . . . . . . . . . . . . . . . . . . . . . . . 5 61 3.1. Quality of Service (QoS) Monitoring . . . . . . . . . . . 5 62 3.2. Service Level Agreemnt (SLA) Validation . . . . . . . . . 6 63 3.3. Fault Isolation and Troubleshooting . . . . . . . . . . . 6 64 4. New Information Elements . . . . . . . . . . . . . . . . . . . 6 65 4.1. Transport Layer . . . . . . . . . . . . . . . . . . . . . 7 66 4.1.1. perfPacketLoss . . . . . . . . . . . . . . . . . . . . 7 67 4.1.2. perfPacketExpected . . . . . . . . . . . . . . . . . . 9 68 4.1.3. perfPacketLossRate . . . . . . . . . . . . . . . . . . 10 69 4.1.4. perfPacketLossEvent . . . . . . . . . . . . . . . . . 11 70 4.1.5. perfPacketInterArrivalJitterAvg . . . . . . . . . . . 12 71 4.1.6. perfPacketInterArrivalJitterMin . . . . . . . . . . . 14 72 4.1.7. perfPacketInterArrivalJitterMax . . . . . . . . . . . 15 73 4.2. User and Application Layer . . . . . . . . . . . . . . . . 16 74 4.2.1. perfSessionSetupDelay . . . . . . . . . . . . . . . . 16 75 4.3. Contextual Elements . . . . . . . . . . . . . . . . . . . 17 76 4.3.1. mediaRTPSSRC . . . . . . . . . . . . . . . . . . . . . 17 77 4.3.2. mediaRTPPayloadType . . . . . . . . . . . . . . . . . 18 78 4.3.3. mediaCodec . . . . . . . . . . . . . . . . . . . . . . 19 79 5. Security Considerations . . . . . . . . . . . . . . . . . . . 20 80 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 81 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 82 7.1. Normative References . . . . . . . . . . . . . . . . . . . 20 83 7.2. Informative References . . . . . . . . . . . . . . . . . . 21 84 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 22 86 1. Introduction 88 Today's networks support a multitude of highly demanding and 89 sensitive network applications. Network issues are readily apparent 90 by the users of these applications due to the sensitivity of these 91 applications to impaired network conditions. Examples of these 92 network applications include applications making use of IP based 93 audio, video, database transactions, virtual desktop interface (VDI), 94 online gaming, cloud services and many more. In some cases the 95 impaired application translates directly to loss of revenue. In 96 other cases, there may be regulatory or contractual service level 97 agreements that motivate the network operator. Due to the sensitive 98 of these types of applications to impaired service it leaves a poor 99 impression of the service on the user-- regardless of the actual 100 performance of the network itself. In the case of an actual problem 101 within the network service, monitoring the performance may yield a 102 early indicator of a much more serious problem. 104 Due to the demanding and sensitive nature of these applications, 105 network operators have tried to engineer their networks in an attempt 106 to wring better and differentiated performance. However, that same 107 differentiated design prevents network operators from extrapolating 108 observational data from one application to another, or from one set 109 of synthetic (active test) test traffic to actual application 110 performance. 112 Performance measurements on user data provide greater visibility not 113 only into the quality of experience of the end users but also 114 visibility into network health. With regards to network health, as 115 flow performance is being measured, there will be visibility into the 116 end to end performance which means that not only visibility into 117 local network health, but also viability into remote network health. 118 If these measurements are made at multiple points within the network 119 (or between the network and end device) then there is not only 120 identification that there might be an issue, but a span of area can 121 be established where the issue might be. The resolution of the fault 122 increases with the number of measurement points along the flow path. 124 The IP Flow Information Export Protocol (IPFIX) [RFC5101] provides 125 new levels of flexibility in reporting from measurement points across 126 the life cycle of a network based application. IPFIX can provide 127 granular results in terms of flow specificity as well as time 128 granularity. At the same time, IPFIX allows for summarization of 129 data along different types of boundaries for operators that are 130 unconcerned about specific sessions but about health of a service or 131 a portion of the network. 133 Where possible, an attempt has been made to make use of existing 134 definitions of metrics ([RFC4710]) and if needed, clarify and expand 135 on them to widen their usage with additional applications. The 136 methodology described in [I-D.ietf-pmol-sip-perf-metrics] is used to 137 describe the methodology of measurement. As this document also 138 covers the reporting of these metrics via IPFIX, consideration is 139 taken with mapping the metric's capabilities and context with the 140 IPFIX information and data representation model. The guidelines 141 outlined in [I-D.trammell-ipfix-ie-doctors] are used to ensure proper 142 IPFIX information element definition. 144 There has been related work in this area such as [RFC2321]. 145 [I-D.huici-ipfix-sipfix], and [VoIP-monitor]. This document is also 146 an attempt to generalize as well as standardize the reporting formats 147 and measurement methodology. 149 2. Terminology 151 Terms used in this document that are defined in the Terminology 152 section of the IPFIX Protocol [RFC5101] document are to be 153 interpreted as defined there. 155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 157 document are to be interpreted as described in RFC 2119 [RFC2119]. 159 In addition, the information element definitions use the following 160 terms: 162 Name: Name of the information element per the IPFIX rules defined in 163 Section 2.3 of [RFC5102] 165 Description: Short description of what the information element is 166 trying to convey. 168 Observation Point: Where the measurement is meant to be performed. 169 Either at an intermediate point (for example, a router) or end 170 system. 172 Element Data Type: The IPFIX informationElementDataTypeas defined in 173 Section 3.1 of [RFC5610] 175 Element Semantics: The IPFIX informationElementSemantics as defined 176 in section Section 3.6 of [RFC5610] 178 Element Units: The IPFIX informationElementUnits as defined in 179 section Section 3.7 of [RFC5610] 181 Element Range Begin: The IPFIX informationElementRangeBegin as 182 defined in section Section 3.7 of [RFC5610] 184 Element Range End: The IPFIX informationElementRangeEnd as defined 185 in section Section 3.7 of [RFC5610] 187 Element Id: The IPFIX global unique element ID as defined in Section 188 3.2 of [RFC5101] 190 Status: The status of the specification of this IPFIX Information 191 Element. 193 Use and Applications An explanation of how this particular 194 information element would be used. 196 Calculation Method: In the case of metrics, this section describes 197 how the metric is calculated, as well as any special conditions. 199 Units of Measurement: In the case of metrics, what are the units of 200 measurement. The text here is expected to be wider and more 201 descriptive than in the IPFIX Element Units section. 203 Measurement Timing: Discussion on the acceptable range of timing and 204 sampling intervals. 206 3. General Usage 208 3.1. Quality of Service (QoS) Monitoring 210 The network operator needs to be able to gauge the end user's 211 satisfaction with the network service. While there are many 212 components of the satisfaction such as pricing, packaging, offering, 213 etc., a major component of satisfaction is delivering a consistent 214 service. The user builds trust on this consistency of the network 215 service and is then to be able to run network applications-- which is 216 of course the end goal. Without the ability to deliver a consistent 217 service for end user network applications network operator will be 218 left dealing with price sensitive disgruntled users with very low 219 expectations (if they don't have choice of operator) or abandonment 220 (if they have choice). 222 3.2. Service Level Agreemnt (SLA) Validation 224 Similar to QoS and QoE validation, there might be contractual or 225 regulatory requirements that need to be met by the network operator. 226 Monitoring the performance of the flows allows the application 227 operator, network operator as well as the end user to validate of the 228 target service is being delivered. While there is quite a diversity 229 in the codification of network SLAs they may eventually involve some 230 measurement of network uptime, end to end latency, end to end jitter 231 and perhaps service response time. In the case violation of the SLA, 232 the start and end times, nature and network scope of the violation 233 needs to be captured to allow for the most accurate settling of the 234 SLA. 236 3.3. Fault Isolation and Troubleshooting 238 It has been generally easier to troubleshoot and fix problems that 239 are binary in nature: it either works or does not work. The host is 240 pingable or not pingable. However, the much more difficult to 241 resolve issues that are transitory in nature, move from location to 242 location, more complicated that simple ICMP reachability and many 243 times unverifiable reports by the users themselves. It is these 244 intermittent and seemingly inconsistent network impairments that 245 performance metrics can be extremely helpful with. Just the basic 246 timely detection that there is a problem (or an impending problem) 247 can give the provider the confidence that there is a real problem 248 that needs to be resolved. The next step would be to assist the 249 operator in a speedy resolution by providing information regarding 250 the network location and nature of the problem. 252 4. New Information Elements 254 The information elements are organized into two main groups: 256 Transport Layer: Metrics that might be calculated from observations 257 at higher layers but essentially provide information about the 258 network transport of user date. For example, the metrics related 259 to packet loss, latency and jitter would be defined here. 261 User and Application Layer: Metrics that are might be affected by 262 the network indirectly, but are ultimately related to user, end- 263 system and session states. For example, session setup time, 264 transaction rate and session duration would be defined here. 266 Contextual Elements Information elements that provide further 267 context to the metrics. For example, media type, codec type, and 268 type of application would be defined here. 270 4.1. Transport Layer 272 4.1.1. perfPacketLoss 274 Name: perfPacketLoss 276 Description: The packet loss metric reports the number of individual 277 packets that were lost in the reporting interval. 279 Observation Point: The observation can be made anywhere along the 280 media path or on the endpoints them selves. The observation is 281 only relevant in a unidirectional sense. 283 Element Data Type: unsigned32 285 Element Semantics: deltaCounter 287 Element Units: packets 289 Element Range Begin: 0 291 Element Range End: 0xFFFFFFFE 293 Element Id: TBDperfPacketLoss 295 Status: current 297 Use and Applications The packet loss metric can be used to determine 298 if there is a network impairment that is causing packet loss 299 upstream of the measurement point. When there are observation 300 points on either side of the impairment location it is possible to 301 locate the impairment. With the location information the operator 302 can is able to perform quicker fault-isolation as well as shorten 303 time to resolution. 305 Calculation Method: This metric requires that each IP packet be 306 individually marked with a monotonically incrementing sequence 307 number. A number of encapsulations support this type of 308 sequencing: IPSec ESP [RFC4303], GRE [RFC2890] and RTP [RFC3550]. 309 An analysis of the sequence number field can yield the lost number 310 of packets. In certain cases, there might be an element of 311 discovery and synchronization of the flow itself before the 312 measurement can be made. An example of this can be found for RTP 313 flows running on ephemeral UDP port numbers. In these cases, 314 reporting 0 as packet loss would be misleading and the value 315 0xFFFFFFFF MUST be used in cases where the packet loss value 316 cannot be determined. In the case of a monitor interval where 317 synchronization was achieved mid-interval, the loss packet counter 318 MAY be used to represent the remainder of the interval. As this 319 metric is a deltaCounter, the number of loss packets only 320 represent the observation within the reporting interval. Due to 321 the dependency on the arrival of a packet with a sequence number 322 to calculate loss, the loss calculation may be indefinitely 323 delayed if no more packets arrive at all. For the case of RTP, in 324 addition to the 16 bit sequence number field in RFC3550, there is 325 also the additional 16-bit high-order sequence number field (for a 326 total of 32-bit seq number space) that is used in RFC3497 327 [RFC3497]. RFC3497 traffic runs at a very high rate and the 32- 328 bit field allow for additional time for wrapping (21 seconds). 329 So, a loss span of greater than 21 seconds measured only by the 330 16-bit field will lead to inaccurate reporting. In the case of 331 secure RTP [RFC3711], the relevant portion of the RTP header is in 332 the clear and lost packet counting can still be performed. It is 333 important to note that the sequence number space is unique per RTP 334 SSRC. Therefore it is important to track the high sequence number 335 seen on a per SSRC-5-tuple basis. There may be multiple SSRCs in 336 a single 5-tuple. Certain applications inject non-RTP traffic 337 into the same 5-tuple as the media stream. RTCP packets may be 338 seen in the same 5-tuple as the RTP stream [RFC5761], and STUN 339 [RFC5389] packets may also be seen. The loss detection should 340 ignore these packets. There may be spans within the network where 341 header compression schemes such as [RFC2508] are used. In cases 342 where the measurement device is terminating the compression, and 343 the measurement implementation does not support calculation of the 344 metric the value 0xFFFFFFFF MUST be reported. In other cases the 345 measurement point may be at a midpoint of the header compression 346 network span. Depending on the mechanics of header compression, 347 sequencing information may be present and it is possible to 348 calculate the metric. In such cases the implementation SHOULD 349 perform the calculation and report the metric. 351 Units of Measurement: packets 353 Measurment Timing To be able to calculate this metric a continuous 354 set of the flow's packets (as each would have an incrementing 355 sequence number) needs to be monitored. Therefore, per-packet 356 sampling would prevent this metric from being calculated. 357 However, there are other sampling methodologies that might be 358 usable. It is possible to generate sampled metrics by sampling 359 spans of continuous packets, however a portion of the span may 360 have to be utilized for resynchronization of the sequence number. 361 Another form of acceptable sampling would be at the flow level. 363 4.1.2. perfPacketExpected 365 Name: perfPacketExpected 367 Description: The number of packets there were expected within a 368 monitoring interval. 370 Observation Point: The observation can be made anywhere along the 371 media path or on the endpoints them selves. The observation is 372 only relevant in a unidirectional sense. 374 Element Data Type: unsigned32 376 Element Semantics: deltaCounter 378 Element Units: none 380 Element Range Begin: 0 382 Element Range End: 0xFFFFFFFE 384 Element Id: TBDperfPacketExpected 386 Status: current 388 Use and Applications The perfPacketExpected is a mid-calculation 389 metric used in the calculation of perfPacketLossRate. 391 Calculation Method: The subtraction of the last sequence number from 392 the first sequence number in monitoring interval yields the 393 expected count. As discussed with perfPacketLost, there might be 394 a delay due to synchronization with the flow's sequence numbers 395 and in such times the value of the metric should be set to 396 0xFFFFFFFE. Care has to be taken to account for cases where the 397 packet's sequence number field wraps. For RTP, the expected count 398 calculation formula can be found in Appendix A.3 of [RFC3550]. 399 Refer to the perfPacketLoss metric regarding considerations for 400 header compression. The value 0xFFFF is used to represent cases 401 where the metric could not be calculated. 403 Units of Measurement: packets 405 Measurment Timing Same considerations as perfPacketLoss 407 4.1.3. perfPacketLossRate 409 Name: perfPacketLossRate 411 Description: Percentage of number of packets lost out of the total 412 set of packets sent. 414 Observation Point: The observation can be made anywhere along the 415 media path or on the endpoints them selves. The observation is 416 only relevant in a unidirectional sense. 418 Element Data Type: unsigned16 420 Element Semantics: quantity 422 Element Units: none 424 Element Range Begin: 0 426 Element Range End: 0xFFFE 428 Element Id: TBDperfPacketLossRate 430 Status: current 432 Use and Applications The perfPacketLossRate metric can be used to 433 normalize the perfPacketLoss metric to handle cases where 434 different flows are running at different packet per second (PPS) 435 rates. Due to the normalization, comparisons can now be made 436 against thresholds (for creating alerts, etc.). In addition, the 437 percentage form of the metric allows for comparisons against other 438 flows at the same observation point to determine if there is an 439 equal bias for drops between the flows. Otherwise, the 440 perfoPacketLossRate is used in same way as perfPacketLoss. 442 Calculation Method: The number of lost packets divided by the number 443 of expected packets in an interval period multiplied by 100. In 444 cases where perfPacketLoss is unknown (for example due to 445 synchronization issues), the perfPacketLossRate would also be 446 unknown. In such cases perfPacketLossRate MUST be set to 0xFFFF. 447 If there are multiple flows whose loss rate is being aggregated, 448 then the average of the individual flows is used. Refer to the 449 perfPacketLoss metric regarding considerations for header 450 compression. The value 0xFFFF is used to represent cases where 451 the metric could not be calculated. 453 Units of Measurement: percentage 455 Measurment Timing Same notes as perfPacketLossRate 457 4.1.4. perfPacketLossEvent 459 Name: perfPacketLossEvent 461 Description: The packet loss event metric reports the number of 462 continuous sets of packets that were lost in the reporting 463 interval. 465 Observation Point: The observation can be made anywhere along the 466 media path or on the endpoints them selves. The observation is 467 only relevant in a unidirectional sense. 469 Element Data Type: unsigned32 471 Element Semantics: deltaCounter 473 Element Units: packets 475 Element Range Begin: 0 477 Element Range End: 0xFFFFFFFE 479 Element Id: TBDperfPacketLossEvent 481 Status: current 483 Use and Applications The perfPacketLossEvent metric can provide loss 484 information for protocols that do not implement per packet 485 sequencing. Similarly to the perfPacketLoss metric, the packet 486 loss event metric can be used to determine if there is a network 487 impairment that is causing packet loss upstream of the measurement 488 point. In cases where both the perfPacketLoss and 489 perfPacketLossEvent metric are available, the ratio between the 490 packet loss and packet event count can provide the average loss 491 length. The average loss length provides additional information 492 regarding the cause of the loss. For example, a dirty fiber 493 connection might have a low average loss length, while a routing 494 protocol convergence will have a high loss length. 496 Calculation Method: This data value is a simplified version of the 497 Lost Packets metric. Whereas Lost Packets counts individual 498 packet loss, the 'loss event count' metric counts sets of packets 499 that are lost. For example, in the case of a sequence of packets: 500 1,3,6,7,10 the packets marked 2,4,5,8 and 9 are lost. So, a total 501 of 5 packets are lost. This same sequence translates to 3 loss 502 events: (2), (4,5) and (8,9). In the case of RTP, the sequence 503 number in the RTP header can be used to identify loss events. 504 Certain protocols such as TCP and UDP+MPEG2-TS encapsulation in IP 505 have sequencing information, but the sequence field is incremented 506 by individual IP packets. As a side note, in the case of UDP+ 507 MPEG2-TS encapsulation the simple use of RTP+MPEG2-TS via 508 [RFC2250] results in the avaliability of the more granular 509 perfPacketLoss metrics. In these cases, the perfPacketLoss metric 510 cannot be calculated but the perfPacketLossEvent can be calculated 511 and can provide detection of loss. The value 0xFFFFFFFF is used 512 to represent non-applicable cases such as lack of sequence number 513 synchronization. Many of the same considerations as for 514 perfPacketLoss apply to perfPacketLoss event. Please refer to the 515 Calculation Method section of the perfPacketLoss. 517 Units of Measurement: event counts 519 Measurment Timing Please refer to the measurement timing section of 520 perfPacketLoss. 522 4.1.5. perfPacketInterArrivalJitterAvg 524 Name: perfPacketInterArrivalJitterAvg 526 Description: This metric measures the absolute deviation of the 527 difference in packet spacing at the measurement point compared to 528 the packet spacing at the sender. 530 Observation Point: The observation can be made anywhere along the 531 media path or on the receiver. The observation is only relevant 532 in a unidirectional sense. 534 Element Data Type: unsigned32 536 Element Semantics: quantity 538 Element Units: microseconds 540 Element Range Begin: 0 542 Element Range End: 0xFFFFFFFE 544 Element Id: TBDperfPacketInterArrivalJitterAvg 545 Status: current 547 Use and Applications The inter arrival jitter data value can be used 548 be network operator to determine the network's impact to the 549 spacing in between a media stream's packets as they traverse the 550 network. For example, in the case of media applications, the 551 receiving end system is expecting these packets to come in at a 552 particular periodicity and large deviations may result in de- 553 jitter buffers adding excessive delay, or the media packets being 554 discarded. When the data is reported from multiple intermediate 555 nodes, the area of the network that is having a detrimental 556 contribution can be identified. On a non-media application level, 557 the inter arrival jitter metrics can be used for early indication 558 queuing contention within the network (which could lead to packet 559 loss). 561 Calculation Method: The inter arrival jitter value makes use of the 562 association of sending time with an IP packets and comparison of 563 the arrival time on the monitoring point. In certain protocols, a 564 representation of sending time is encoded into the header itself. 565 For example, in the case of RTP packets, the RTP header's 566 timestamps field represents encoder clock ticks-- which are 567 representations of time. Similarly, in the case of TCP options 568 encode absolute timestamps values. For RTP the calculation method 569 can be found in Appendix A of [RFC3550]. It should be noted that 570 the RFC3550 calculation is on the last 16 packets measured. The 571 most recent value calculated SHOULD be reported at the end of the 572 monitoring interval. The range of the jitter values during the 573 monitoring interval can be reported using 574 perfPacketInterArrivalJitterMin and 575 perfPacketInterArrivalJitterMax. Similarly to the perfPacketLoss 576 case there may be periods of time where the jitter value cannot be 577 calculated. In these cases, the 0xFFFFFFFF value should be used 578 to convey the lack of availability of the metric. As mentioned 579 earlier, the RTP header timestamps is actually a 'sample-stamp' 580 (ie clicks) from the encoder's clock. The frequency of the clock 581 is dependent on the codec. Some codecs (eg AAC-LD) support 582 multiple possible frequencies one of which is then selected for 583 the media-stream. The mapping to clock rate can be performed via 584 mapping from the static RTP payload type (RTP-PT), but newer 585 codecs are make use of the dynamic payload type range and the 586 RTP-PT (in the dynamic case) cannot be used to determine the clock 587 frequency. There are various methods by which the clock frequency 588 (deep packet inspection of the signalling, manual configuration, 589 etc.) can be associated to the calculation method. The frequency 590 should be locked in the metering layer to a unique combination of 591 the IP source, IP destination, IP protocol layer-4 ports, RTP-PT 592 and SSRC. By strict RFC3550 definition, the SSRC is set to a 593 specific encoder clock and it is the SSRC that should be tracked 594 rather than payload type. However, in recent discussions it has 595 been noted that there are RTP implementations that might change 596 the encoder clock frequency while maintaining the SSRC value. An 597 encoder frequency change will be accompanied by a different 598 RTP-PT. 600 Units of Measurement: microseconds 602 Measurment Timing Please refer to the measurement timing section of 603 perfPacketLoss. 605 4.1.6. perfPacketInterArrivalJitterMin 607 Name: perfPacketInterArrivalJitterMin 609 Description: This metric measures the minimum value the calculation 610 used for perfPacketInterArrivalJitterAvg within the monitoring 611 interval. 613 Observation Point: The observation can be made anywhere along the 614 media path or on the receiver. The observation is only relevant 615 in a unidirectional sense. 617 Element Data Type: unsigned32 619 Element Semantics: quantity 621 Element Units: microseconds 623 Element Range Begin: 0 625 Element Range End: 0xFFFFFFFE 627 Element Id: TBDperfPacketInterArrivalJitterMin 629 Status: current 631 Use and Applications Please refer to the 'Use and Applications' 632 section of perfPacketInterArrivalJitterAvg. This specific metric, 633 along with perfPacketInterArrivalJitterMax, is to capture the 634 range of measurements observed within a monitoring interval as the 635 average function may hide extremes. 637 Calculation Method: Please see the perfPacketInterArrivalJitterAvg 638 section for general calculation section. The average calculation 639 is evaluated on a running basis over the last 16 packets and the 640 entire monitoring interval is not covered. In this metric, the 641 minimum value is taken over the entire monitoring interval. 643 Units of Measurement: microseconds 645 Measurment Timing Please refer to the measurement timing section of 646 perfPacketLoss. 648 4.1.7. perfPacketInterArrivalJitterMax 650 Name: perfPacketInterArrivalJitterMax 652 Description: This metric measures the maximum value the calculation 653 used for perfPacketInterArrivalJitterAvg within the monitoring 654 interval. 656 Observation Point: The observation can be made anywhere along the 657 media path or on the receiver. The observation is only relevant 658 in a unidirectional sense. 660 Element Data Type: unsigned32 662 Element Semantics: quantity 664 Element Units: microseconds 666 Element Range Begin: 0 668 Element Range End: 0xFFFFFFFE 670 Element Id: TBDperfPacketInterArrivalJitterMax 672 Status: current 674 Use and Applications Please refer to the 'Use and Applications' 675 section of perfPacketInterArrivalJitterAvg. This specific metric, 676 along with perfPacketInterArrivalJitterMin, is to capture the 677 range of measurements observed within a monitoring interval as the 678 average function may hide extremes. 680 Calculation Method: Please see the perfPacketInterArrivalJitterAvg 681 section for general calculation section. The average calculation 682 is evaluated on a running basis over the last 16 packets and the 683 entire monitoring interval is not covered. In this metric, the 684 maximum value is taken over the entire monitoring interval. 686 Units of Measurement: microseconds 688 Measurment Timing Please refer to the measurement timing section of 689 perfPacketLoss. 691 4.2. User and Application Layer 693 4.2.1. perfSessionSetupDelay 695 Name: perfSessionSetupDelay 697 Description: The Session Setup Delay metric reports the time taken 698 from a request being initiated by a host/endpoint to the response 699 (or request indicator) to the request being observed. This metric 700 is defined in [RFC4710], however the units have been updated to 701 microseconds. 703 Observation Point: This metric needs to be calculated where both 704 request and response can be observed. This could be at network 705 choke points, application proxies, or within the end systems 706 themselves. 708 Element Data Type: unsigned32 710 Element Semantics: quantity 712 Element Units: microseconds 714 Element Range Begin: 0 716 Element Range End: 0xFFFFFFFE 718 Element Id: TBDperfSessionSetupDelay 720 Status: current 722 Use and Applications The session setup delay metric can measure the 723 end user initial wait experience as seen from the network 724 transaction level. The value will not only include the network 725 flight time, but also includes the server response time and may be 726 used to alert the operator in cases where the overall service is 727 overloaded and thus sluggish, or within normal operating values. 729 Calculation Method: Measure distance in time between the first bit 730 of request and the first bit of the response. For the case of 731 SIP, please see Section 4.3.1 of [I-D.ietf-pmol-sip-perf-metrics] 733 Units of Measurement: microseconds 735 Measurment Timing This measurement can be sampled on a session by 736 session basis. It may be advisable to set sample targets on a per 737 source range - to destination basis. Due to the nature of 738 measurement intervals, there may be a period of time (and thus 739 measurement reports) in which the perfSessionSetupDelay value has 740 not been calculated. In these cases the value 0xFFFFFFFE MUST be 741 used and can be interpreted to mean not applicable. For 742 measurement intervals after perfSessionSetupDelay has been 743 calculated and the existing calculated perfSessionSetupDelay value 744 SHOULD be sent if reporting only on that single session. However, 745 if multiple sessions are summarized in the report then the average 746 for perfSessionSetupDelay values calculated in the most recent 747 interval SHOULD be used. The intention with this behavior is to 748 acknowledge that the value has not bee calculated, and when it has 749 provide the freshest values available. 751 4.3. Contextual Elements 753 4.3.1. mediaRTPSSRC 755 Name: mediaRTPSSRC 757 Description: Value of the synchronization source (SSRC) field in the 758 RTP header of the flow. This field is defined in [RFC3550] 760 Observation Point: This metric can be gleaned from the RTP packets 761 directly, so the observation point needs to on the flow path or 762 within the endpoints. 764 Element Data Type: unsigned32 766 Element Semantics: identifier 768 Element Units: octets 770 Element Range Begin: 0 772 Element Range End: 0xFFFFFFFE 774 Element Id: TBDmediaRTPSSRC 776 Status: current 777 Use and Applications The RTP SSRC value denotes a specific media 778 stream. As such when trying to differentiate media stream 779 problems between session participants the SSRC field is needed. 781 Calculation Method: Copy from RTP header's SSRC field as defined in 782 [RFC3550]. In the case of a non-RTP flow, or the time period in 783 which the flow has not been verified to be a RTP flow the value 784 0xFFFFFFFE MUST be reported. 786 Units of Measurement: identifier 788 Measurment Timing It is possible that the SSRC may have be 789 renegotiated mid-session due to collisions with other RTP senders. 791 4.3.2. mediaRTPPayloadType 793 Name: mediaRTPPayloadType 795 Description: The value of the RTP Payload Type Field as seen in the 796 RTP header of the flow. This field is defined in [RFC3550] 798 Observation Point: This metric can be gleaned from the RTP packets 799 directly, so the observation point needs to on the flow path or 800 within the endpoints. 802 Element Data Type: unsigned16 804 Element Semantics: identifier 806 Element Units: octets 808 Element Range Begin: 0 810 Element Range End: 0xFF 812 Element Id: TBDmediaRTPPayloadType 814 Status: current 816 Use and Applications The RTP PT conveys the payload format and media 817 encoding used in the RTP payload. For simple cases, where the RTP 818 PT is from the statically defined range this can lead to an 819 understanding of type of media codec used. With the knowledge of 820 the codec being used the degree of media impairment (given loss 821 values and jitter) can be estimated better. However, for more 822 recent codecs, the RTP dynamic range is used. In these cases the 823 RTP payload values are dynamically negotiated. In the case of a 824 non-RTP flow, or the time period in which the flow has not been 825 verified to be a RTP flow, the value 0xFFFF MUST be reported. 827 Calculation Method: Copy from RTP header's RTP-PT field as defined 828 in [RFC3550] 830 Units of Measurement: identifier 832 Measurment Timing 834 4.3.3. mediaCodec 836 Name: mediaCodec 838 Description: The media codec used in the flow. 840 Observation Point: The ideal location of this metric is on the media 841 generators and consumers. However, given application inspection 842 or static configuration it is possible that intermediate nodes are 843 able to generate codec information. 845 Element Data Type: string 847 Element Semantics: identifier 849 Element Units: octets 851 Element Id: TBDmediaCodec 853 Status: current 855 Use and Applications The media codec value conveys the name of the 856 codec used to encode the media in the flow being monitored. 857 Simply reporting loss and jitter measurements are useful for 858 detection of network problems. However, judging the degree of the 859 impact on the audio/video experience needs additional information. 860 The most basic information is the codec being used which when 861 coupled with per-codec knowledge of sensitivity to the transport 862 metrics a better idea of the experience can be gained. 864 Calculation Method: The valid values for the mediaCodec are listed 865 on the IANA media-types registry. Analysis of the RTP payload 866 type may lead to the determination of the media codec. However, 867 with the use of the RTP dynamic payload type range the media 868 information is not encoded into the data packet. For these cases, 869 intermediate nodes may need to perform inspection of the 870 signalling (SIP, H.323, RTSP, etc.). In cases where the 871 mediaCodec cannot be determined, the value 'unknown' MUST be used. 873 Units of Measurement: identifier 875 Measurment Timing 877 5. Security Considerations 879 The recommendations in this document do not introduce any additional 880 security issues to those already mentioned in [RFC5101] and [RFC5477] 882 6. IANA Considerations 884 This document requires an elements assignment to be made by IANA. 886 7. References 888 7.1. Normative References 890 [RFC5101] Claise, B., "Specification of the IP Flow Information 891 Export (IPFIX) Protocol for the Exchange of IP Traffic 892 Flow Information", RFC 5101, January 2008. 894 [RFC5610] Boschi, E., Trammell, B., Mark, L., and T. Zseby, 895 "Exporting Type Information for IP Flow Information Export 896 (IPFIX) Information Elements", RFC 5610, July 2009. 898 [RFC4710] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real-time 899 Application Quality-of-Service Monitoring (RAQMON) 900 Framework", RFC 4710, October 2006. 902 [RFC5102] Quittek, J., Bryant, S., Claise, B., Aitken, P., and J. 903 Meyer, "Information Model for IP Flow Information Export", 904 RFC 5102, January 2008. 906 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 907 Jacobson, "RTP: A Transport Protocol for Real-Time 908 Applications", STD 64, RFC 3550, July 2003. 910 [RFC3497] Gharai, L., Perkins, C., Goncher, G., and A. Mankin, "RTP 911 Payload Format for Society of Motion Picture and 912 Television Engineers (SMPTE) 292M Video", RFC 3497, 913 March 2003. 915 [RFC5389] Rosenberg, J., Mahy, R., Matthews, P., and D. Wing, 916 "Session Traversal Utilities for NAT (STUN)", RFC 5389, 917 October 2008. 919 [I-D.ietf-pmol-sip-perf-metrics] 920 Malas, D. and A. Morton, "Basic Telephony SIP End-to-End 921 Performance Metrics", draft-ietf-pmol-sip-perf-metrics-07 922 (work in progress), September 2010. 924 [iana-ipfix-assignments] 925 Internet Assigned Numbers Authority, "IP Flow Information 926 Export Information Elements 927 (http://www.iana.org/assignments/ipfix/ipfix.xml)". 929 7.2. Informative References 931 [I-D.ietf-pmol-metrics-framework] 932 Clark, A. and B. Claise, "Guidelines for Considering New 933 Performance Metric Development", 934 draft-ietf-pmol-metrics-framework-05 (work in progress), 935 October 2010. 937 [I-D.trammell-ipfix-ie-doctors] 938 Trammell, B. and B. Claise, "Guidelines for Authors and 939 Reviewers of IPFIX Information Elements", 940 draft-trammell-ipfix-ie-doctors-00 (work in progress), 941 October 2010. 943 [RFC2508] Casner, S. and V. Jacobson, "Compressing IP/UDP/RTP 944 Headers for Low-Speed Serial Links", RFC 2508, 945 February 1999. 947 [RFC3711] Baugher, M., McGrew, D., Naslund, M., Carrara, E., and K. 948 Norrman, "The Secure Real-time Transport Protocol (SRTP)", 949 RFC 3711, March 2004. 951 [RFC2250] Hoffman, D., Fernando, G., Goyal, V., and M. Civanlar, 952 "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, 953 January 1998. 955 [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", 956 RFC 2890, September 2000. 958 [RFC4303] Kent, S., "IP Encapsulating Security Payload (ESP)", 959 RFC 4303, December 2005. 961 [RFC5761] Perkins, C. and M. Westerlund, "Multiplexing RTP Data and 962 Control Packets on a Single Port", RFC 5761, April 2010. 964 [I-D.huici-ipfix-sipfix] 965 Huici, F., Niccolini, S., and S. Anderson, "SIPFIX: Use 966 Cases and Problem Statement for VoIP Monitoring and 967 Exporting", draft-huici-ipfix-sipfix-00 (work in 968 progress), June 2009. 970 [nProbe] "probe - NetFlow/IPFIX Network Probe 971 (http://www.ntop.org/nProbe.html)". 973 [RFC2321] Bressen, A., "RITA -- The Reliable Internetwork 974 Troubleshooting Agent", RFC 2321, April 1998. 976 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 977 Requirement Levels", BCP 14, RFC 2119, March 1997. 979 [RFC5477] Dietz, T., Claise, B., Aitken, P., Dressler, F., and G. 980 Carle, "Information Model for Packet Sampling Exports", 981 RFC 5477, March 2009. 983 [VoIP-monitor] 984 L. Chang-Yong, H. Kim, K. Ko, J. Jim, and H. Jeong, "A 985 VoIP Traffic Monitoring System based on NetFlow v9, 986 International Journal of Advanced Science and Technology, 987 vol. 4, Mar. 2009". 989 Author's Address 991 Aamer Akhter 992 Cisco Systems, Inc. 993 7025 Kit Creek Road 994 RTP, NC 27709 995 USA 997 Email: aakhter@cisco.com