idnits 2.17.1 draft-ietf-rmonmib-raqmon-framework-16.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1629. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1640. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1647. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1653. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 36 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (20 February 2006) is 6633 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: 'RFC3416' is defined on line 1520, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2475 ** Obsolete normative reference: RFC 2679 (Obsoleted by RFC 7679) ** Obsolete normative reference: RFC 2680 (Obsoleted by RFC 7680) -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) -- No information found for draft-ietf-raqmon-pdu - is the name correct? Summary: 6 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Anwar Siddiqui 3 draft-ietf-rmonmib-raqmon-framework-16.txt Avaya Inc. 4 Category: Standards Track Dan Romascanu 5 Expires August 2006 Avaya 6 Eugene Golovinsky 7 BMC Software 8 20 February 2006 10 Real-time Application Quality of Service 11 Monitoring (RAQMON) Framework 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress". 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 There is a need to monitor end devices such as IP phones, pagers, 39 Instant Messaging clients, mobile phones, and various other hand-held 40 computing devices. This memo extends the remote network monitoring 41 (RMON) family of specifications to allow real-time quality of service 42 (QoS) monitoring of various applications that run on these devices, 43 and allows this information to be integrated with the RMON family 44 using the Simple Network Management Protocol (SNMP). This memo 45 defines the framework, architecture, relevant metrics, and transport 46 requirements for real-time quality of service monitoring of 47 applications. 49 Distribution of this memo is unlimited. 51 Table of Contents 53 Status of this Memo.................................................1 54 Abstract............................................................1 55 1 Introduction......................................................3 56 2 RAQMON Functional Architecture....................................5 57 3 RAQMON Operation in Congestion-Safe Mode.........................12 58 4 Measurement Methodology..........................................14 59 5 Metrics pre-defined for the BASIC Part of the RAQMON PDU.........15 60 6 Report Aggregation and Statistical Data processing...............29 61 7 Keeping Historical Data and Storage..............................30 62 8 Acknowledgements.................................................31 63 9 Security Considerations..........................................31 64 10 Normative References............................................33 65 11 Informative References .........................................34 66 12 IANA Considerations ............................................35 67 Authors' Addresses.................................................36 68 Full Copyright Statement...........................................36 70 1. Introduction 72 With the growth of the Internet and advancements in embedded 73 technologies, smart IP devices, such as IP phones, pagers, instant 74 message clients, mobile phones, wireless hand-helds and various other 75 computing devices, have become an integral part of our day-to-day 76 operations. Enterprise operators, information technology (IT) 77 managers, application service providers, network service providers, 78 and so on need to monitor these application and device types in order 79 to ensure that end user quality of service (QoS) objectives are met. 80 This memo describes a monitoring solution for these environments, 81 extending the remote network monitoring (RMON) family of 82 specifications [RFC2819]. These extensions support real-time QoS 83 monitoring of typical applications that run on end devices like 84 these, and allow this information to be integrated using the familiar 85 RMON family of specifications via SNMP. 87 The Real-time Application QoS Monitoring Framework (RAQMON) allows 88 end devices and applications to report QoS statistics in real time. 89 Many real-time applications as well as non-real-time applications 90 managed within the RMON family of specifications can report 91 application level QoS statistics in real time using the RAQMON 92 Framework outlined in this memo. Some possible applications 93 scenarios include applications such as Voice over IP, Fax over IP, 94 Video over IP, Instant Messaging (IM), Email, software download 95 applications, e-business style transactions, web access from handheld 96 computing devices, etc. 98 The user experience of an application running on an IP end device 99 depends upon the type of application the user is running and the 100 surrounding resources available to that application. An end-to-end 101 application quality of service (QoS) experience is a compound effect 102 of various application level transactions and available network and 103 host resources. For example, the end-to-end user experience of a 104 Voice over IP (VoIP) call depends on the total time required to set 105 up the call as much as on media related performance parameters such 106 as end-to-end network delay, jitter, packet loss, and the type of 107 codec used in a call. Behavior of network protocols like the 108 Reservation Protocol (RSVP), explicit tags in differentiated services 109 (DiffServ) [RFC2475] or IEEE 802.1 [IEEE802.1D] along with available 110 host resources such as device CPU or memory utilized by other 111 applications while the call is ongoing also influence the performance 112 of a VoIP call. 114 The end-to-end application quality of service (QoS) experience is 115 application context sensitive. For example, the kinds of parameters 116 reported by an IP telephony application may not really be needed for 117 other applications such as Instant Messaging. The Real Time 118 Application QoS Monitoring (RAQMON) Framework offers a mechanism to 119 report the end-to-end QoS experience appropriate for a specific 120 application context by providing mechanisms to report a subset of 121 metrics from a pre-defined list. 123 In order to facilitate a complete end-to-end view, RAQMON correlates 124 statistics that involve: 126 i. "User, Application, Session" specific parameters - e.g. 127 session setup time, session duration parameters based on 128 application context. 130 ii. "IP end device" specific parameters during a session - e.g. 131 CPU usage, memory usage. 133 iii. "Transport network" specific parameters during a session - 134 e.g. end-to-end delay, one-way delay, jitter, packet loss 135 etc. 137 At any given point, it's the applications at these devices that can 138 correlate such diverse data and report end-to-end performance. The 139 RAQMON Framework specified in this memo offers a mechanism to report 140 such end-to-end QoS view and integrate such a view into the RMON 141 family of specifications. In particular, the RAQMON Framework 142 specifies the following: 144 a. A set of basic metrics sent as reports between the RAQMON 145 entities using for transport existing Internet Protocols such 146 as TCP or SNMP. 148 b. Requirements to be met by the underlying transport protocols 149 that carry the RAQMON reports. 151 c. A portion of the Management Information Base (MIB) as an 152 extension of the RMON MIB Modules for use with network 153 management protocols in the Internet community. 155 This memo provides the RAQMON functional architecture, RAQMON entity 156 definitions and requirements, requirements for the transport 157 protocols, a set of metrics and an information model for the RAQMON 158 reports, 160 Supplementary memos will describe the mapping of the basic RAQMON 161 metrics onto different transport protocols. For example the RAQMON 162 PDU [RAQMON-PDU] memo provides definitions of syntactical PDU 163 structure and use case scenarios of transmission of such PDUs over 164 the Transmission Control Protocol (TCP) and the Simple Network 165 Management Protocol (SNMP). 167 The RAQMON MIB [RAQMON-MIB] memo describes the Management Information 168 Base (MIB) for use with the SNMP protocol in the Internet community. 169 The document proposes an extension to the Remote Monitoring MIB 170 [RFC2819] to accommodate RAQMON solutions. 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in [RFC2119]. 176 2. RAQMON Functional Architecture 178 The RAQMON Framework extends the architecture created in the RMON MIB 179 [RFC2819] by providing application performance information as 180 experienced by end-users. The RAQMON architecture is based on three 181 functional components named below: 183 - RAQMON Data Source (RDS) 185 - RAQMON Report Collector (RRC) 187 - RAQMON MIB Structure 189 A RAQMON Data Source (RDS) is a functional component that acts as a 190 source of data for monitoring purposes. End-devices like IP phones, 191 cell phones, pagers, application clients like instant messaging 192 clients, soft phones in PCs, etc. are envisioned to act as RDSs 193 within the RAQMON Framework. 195 +----------------------+ +---------------------------+ 196 | IP End-Device | | IP End-Device >----+ | 197 |+--------------------+| |+--------------------+ | | 198 || APPLICATION || || APPLICATION | | | 199 || -Voice over IP <----(1)----> -Voice over IP >- + | | 200 || -Instant Messaging|| || -Instant Messaging| | 3 | 201 || -Email || || -Email | 2 | | 202 |+--------------------+| |+--------------------+ | | | 203 | | | | | | 204 | | | +------------------+ | | | 205 +----------------------+ | |RAQMON Data Source|<-+ | | 206 | | (RDS) |<---+ | 207 | +------------------+ | 208 +-----------|---------------+ 209 | 210 (4) RAQMON PDU transported 211 over TCP or SNMP Notifications 212 | 213 +----------------------------+ 214 | | 215 |/ |/ 216 +------------------+ +------------------+ +------------+ 217 |RAQMON Report | .. |RAQMON Report | | Management | 218 |Collector (RRC) #n| |Collector (RRC) #1|<--5-->| Application| 219 +------------------+ +------------------+ +------------+ 221 Figure 1 - RAQMON Framework. 223 (1) Communication Session between real-time applications 225 (2) Context-Sensitive Metrics 227 (3) Device State Specific Metrics 229 (4) reporting session - RAQMON metrics transmitted over specified 230 interfaces (Specific Protocol Interface, IP Address, port) 232 (5) Management Application - RRC interaction using the RAQMON MIB 234 A RAQMON Report Collector (RRC) collects statistics from multiple 235 RDSs, analyzes them, and stores such information appropriately. A 236 RAQMON Report Collector (RRC) is envisioned to be a network server, 237 serving an administrative domain defined by the network 238 administrator. The RRC component of the RAQMON architecture is 239 envisioned to be computationally resourceful. Only RRCs should 240 implement the RAQMON MIB module. 242 The RAQMON Management Information Base (RAQMON MIB) extends the 243 Remote Monitoring MIB [RFC2819] to accommodate the RAQMON Framework 244 and exposes End-to-End Application QoS information to Network 245 Management Applications. 247 2.1 RAQMON Data Source (RDS) 249 2.1.1 RAQMON Data Source (RDS) Functional Architecture 251 A RAQMON Data Source (RDS) is a source of data for monitoring 252 purposes. The RDS monitoring function is performed in real time 253 during communication sessions. The RDS entities capture QoS 254 attributes of such communication sessions and report them within a 255 RAQMON "reporting session". 257 A RDS is primarily responsible for abstracting IP end devices and 258 applications within the RAQMON architecture. It gathers the 259 parameters for a particular communication session and forwards them 260 to the appropriate RAQMON Report Collector (RRC). Since it is 261 envisioned that the RDS functionality will be realized by writing 262 firmware/software running on potentially small, low-powered end 263 devices, the design of the RDS element is optimized towards that end. 264 Like the implementations of routing and management protocols, an 265 implementation of RDS in an end device will typically execute in the 266 background, not in the data-forwarding path. 268 RDSs use a PUSH mechanism to report QoS parameters. While the 269 applications running on the RDS decide about the content of the PDU 270 appropriate for an application context, a RAQMON Data Source (RDS) 271 asynchronously sends out reports to RRC. 273 The rate at which PDUs are sent from RDSs to RRCs is controlled by 274 the applications' administrative domain policy. While this mechanism 275 provides flexibility to gather a detailed end-to-end experience 276 required by IT managers and system administrators, certain steps 277 should be followed to operate RAQMON in congestion-safe manner. 278 Section 3 addresses steps required for congestion-safe operation. 280 A RAQMON Data Source (RDS) reports QoS statistics for simplex flows. 281 At a given instance, a report from RDS is logically viewed as a 282 collection of QoS parameters associated with a communication session 283 as perceived by the reporting RDS. For example, if two IP phone 284 users, Alice and John, are involved in a communication session, the 285 end-to-end delay experienced by the IP phone user Alice could be 286 different from the one experienced by the IP phone user John for a 287 variety of reasons. Hence a report from Alice's IP phone represents 288 the QoS performance of that call as perceived by the RDS that resides 289 in Alice's IP phone. 291 2.1.2 RAQMON Data Source (RDS) Requirements 293 1. RAQMON Data Sources SHALL gather reports from multiple 294 applications residing in that device and SHALL send out 295 compound QoS reports associated with multiple communication 296 sessions at a given moment. 298 Examples include a conference bridge hosting several different 299 conference calls or a two party video call consisting of 300 audio/video sessions. In each case an RDS could send out one 301 single RAQMON report that consists of multiple sub-reports 302 associated with audio and video sessions or sub-reports for 303 each conference call. 305 2. RAQMON Data Sources MUST implement the TCP transport and MAY 306 implement the SNMP transport. 308 2.1.3 Configuring RAQMON Data Sources 310 In order to report statistics to RAQMON Report Collectors, RDSs will 311 need to be configured with the following parameters: 313 1. The time interval between RAQMON PDUs. This parameter MUST be 314 configured such that overflow of any RAQMON parameter within a 315 PDU between consecutive transmissions is avoided. 317 2. The IP address and port of target RRC. 319 A RDS may use manual configuration for the RDS configuration 320 parameters using command line interface (CLI), Telephone User 321 Interface (TUI), etc. 323 One of the following mechanisms to gain access to configuration 324 parameters can also be considered: 326 - RDS acts as a trivial file transfer protocol (TFTP) client and 327 downloads text scripts to read the parameters 328 - RDS acts as a Dynamic Host Configuration Protocol (DHCP) Client 329 and gets RRC addressing information as a DHCP option 330 - RDS acts as a DNS client and gets target collector information 331 from a DNS Server 332 - RDS acts as a LDAP Client and uses directory look-ups 334 Identifying the DHCP option and structure to use, or defining the 335 structure of the configuration information in DNS, or defining a LDAP 336 schema could be explored as items of future work. 338 Compliance to the RAQMON specification does not require usage of any 339 specific configuration mechanisms mentioned above. It is left to the 340 implementers to choose appropriate provisioning mechanisms for a 341 system. 343 2.2 RAQMON Report Collector (RRC) 345 2.2.1 RAQMON Report Collector (RRC) Functional Architecture 347 A RAQMON Report Collector (RRC) receives RAQMON PDUs from multiple 348 RDSs, and analyzes and stores the information in the RAQMON MIB. The 349 RRC is envisioned to be computationally resourceful, providing a 350 storage and aggregation point for a set of RDSs. 352 Since RDSs can belong to separate administrative domains, the RAQMON 353 Framework allows RDSs to report QoS parameters to separate RRCs. 354 Vendors can develop a management application to correlate information 355 residing in different RRCs across multiple administrative domains to 356 represent one communication session. However such an application 357 level specification is beyond the scope of this memo. 359 2.2.2 RAQMON Report Collector (RRC) Requirements 361 1. RAQMON Report Collectors MUST support the mandatory mapping 362 over TCP of the RAQMON information model defined in [RAQMON- 363 PDU] with the purpose of receiving RAQMON reports from RAQMON 364 Data Sources (RDS). 366 2. RAQMON Report Collectors MAY support the optional mapping over 367 SNMP notifications of the RAQMON information model defined in 368 [RAQMON-PDU]. 370 3. RAQMON Report Collectors MUST implement session time out 371 mechanisms to assume end of reporting for RDSs that have been 372 out of reporting for a reasonable duration of time. Such time 373 out parameters SHOULD be configurable in vendor 374 implementations, as programmable parameters at deployment. 376 4. RAQMON Report Collectors MUST support the RAQMON-MIB module and 377 meet the compliance requirements of the raqmonCompliance 378 MODULE-COMPLIANCE definition as described in [RAQMON-MIB]. The 379 population of the RAQMON MIB with performance monitoring 380 information is independent of the transport protocol, or 381 protocols used to carry the information between RDSs and RRCs. 383 2.3 Information model and RAQMON Protocol Data Unit (PDU) 385 2.3.1. RAQMON Information model 387 RAQMON defines a set of basic metrics that characterize the Quality 388 of Service (QoS) of applications, as reported by RAQMON Data Sources. 389 This basic set of metrics is defined in Section 5 of this memo. There 390 is no minimal requirement for a mandatory set of metrics to be 391 supported by a RAQMON data source. 393 Specific applications, new types of network appliances or new methods 394 to measure and characterize the QoS of applications lead to the 395 requirement for the information model to be extensible. To answer 396 this need the information model is designed so that vendors can 397 extend it by adding new metrics. 399 Although NOT REQUIRED for RAQMON conformance, extensions of the 400 information model can offer useful information for specific 401 applications. An example of metrics that can extend the basic RAQMON 402 information model are the detailed metrics for Voice over IP (VoIP) 403 media monitoring and call quality included in the VoIP Metrics Report 404 Block defined in [RFC3611]. 406 The RAQMON Information model is expressed by defining a conceptual 407 RAQMON Protocol Data Unit (PDU). 409 2.3.2 RAQMON Protocol Data Unit 411 A RAQMON Protocol Data Unit (PDU) is a common data format understood 412 by RDSs and RRCs. A RAQMON PDU does not transport application data 413 but rather occupies the place of a payload specification at the 414 application layer of the protocol stack. Different transport 415 mappings may be used to carry RAQMON PDU between RDSs and RRCs. 416 Transport protocol requirements are being defined in Section 2.4 of 417 this memo. 419 Though architected conceptually as a single Protocol Data Unit, the 420 RAQMON PDU is functionally divided into two different parts. They 421 are the BASIC Part, and the Application Specific Extensions, required 422 for application -, vendor-, device-, etc. specific extensions. 424 The BASIC Part of the RAQMON PDU: 425 The BASIC part of the RAQMON PDU follows the SMI Network 426 Management Private Enterprise Code 0 - indicating an IETF standard 427 construct. The RAQMON PDU BASIC part offers an entry-type from a 428 pre-defined list of QoS parameters defined in Section 5 and allows 429 applications to fill in appropriate values for those parameters. 430 Application developers also have the flexibility to make an RDS 431 report built only of a sub-set of the parameters listed in Section 432 5. There is no need to carry all metrics in every PDU, moreover it 433 is RECOMMENDED that static or pseudo-static metrics which do not 434 change, or seldom change for a given session or application will 435 be send only when the session or application are initiated, and 436 then at large time intervals. 438 The Application Part of RAQMON PDU: 439 Since it is difficult to structure a BASIC Part that meets the 440 needs of all applications, RAQMON provides extension capabilities 441 to convey application-, vendor-, device-, etc. specific parameters 442 for future use. Additional parameters can be defined within 443 payload of the APP part of the PDU by the application developers 444 or vendors. The owner of the definition of the application part 445 of the RAQMON PDU is indicated by a vendor's SMI Network 446 Management Private Enterprise Code defined in 447 http://www.iana.org/assignments/enterprise-numbers. Such 448 application specific extensions should be maintained and published 449 by the application vendor. 451 Though RDSs and RRCs are designed to be stateless for an entire 452 reporting session, the framework requires an indication for the end 453 of the reporting. For this purpose an RDS MUST send a RAQMON NULL 454 PDU. A NULL PDU is a RAQMON PDU containing ALL NULL values (i.e. 455 nothing to report). 457 2.4 RDS/RRC Network Transport Protocol Requirements 459 The RAQMON PDUs rely on the underlying protocol(s) to provide 460 transport functionalities and other attributes of a transport 461 protocol, e.g., transport reliability, re-transmission, error 462 correction, length indication, congestion safety, 463 fragmentation/defragmentation, etc. The maximum length of the RAQMON 464 data packet is limited only by the underlying protocols. 466 The following requirements MUST be met by the transport protocols: 468 1. The transport protocol SHOULD allow for RDS lightweight 469 implementations - RDSs will be implemented on low powered 470 embedded devices with limited device resources. 472 2. Scalability - since RRCs need to interact with a very large 473 number (many tenth, many hundreds, more) of RDSs, scalability 474 of the transport protocol is REQUIRED. 476 3. Congestion safety - as per [RFC2914] - see also Section 3 478 4. Security - Since RAQMON statistics may carry sensitive system 479 information requiring protection from unauthorized disclosure 480 and modification in transit, a transport protocol that provides 481 strong secure modes, or allows for data encryption and 482 integrity to be applied is REQUIRED 484 5. NAT Friendly - The transport protocol SHOULD comply with 485 [RFC3235], so that an RDS could communicate with an RRC through 486 a Firewall/Network Address Translation device. 488 6. The transport protocol MAY implement session time out 489 mechanisms to assume end of reporting for RDSs that have been 490 out of reporting for a reasonable duration of time. Such time 491 out parameters SHOULD be configurable in vendor 492 implementations, programmable at deployment. 494 7. Reliability - The RAQMON Framework expects PDUs to operate in 495 lossy networks. However, retransmission is not included in the 496 RAQMON framework, in order to keep the design simple. If 497 retransmission is a necessity, RAQMON MAY operate over 498 transport protocols, such as TCP. 500 In the future, if RAQMON PDUs are to be carried in an underlying 501 protocol that provides the abstraction of a continuous octet stream 502 rather than messages (packets), an encapsulation for the RAQMON 503 packets must be defined to provide a framing mechanism. Framing is 504 also needed if the underlying protocol contains padding so that the 505 extent of the RAQMON payload cannot be determined. No framing 506 mechanism is defined in this document. Carrying several RAQMON 507 packets in one network or transport packet reduces header overhead. 509 Further memos like [RAQMON-PDU] describe how the PDU is transported 510 over existing protocols like the Transmission Control Protocol (TCP) 511 or the Simple Network Management Protocol (SNMP). 513 3. RAQMON Operation in Congestion-Safe Mode 515 RAQMON PDUs can be transmitted over multiple transport protocols. 516 The RAQMON Framework will be congestion safe, if a RAQMON PDU is 517 transported over TCP. 519 One solution to the congestion awareness problem could have been to 520 discourage the use of UDP entirely for RAQMON. Though RAQMON PDUs 521 can be transported over TCP, some transports like SNMP over TCP are 522 not commonly practiced in practical deployments. 524 The use of UDP inherently increases the risks of network congestion 525 problems, as UDP itself does not define congestion prevention, 526 avoidance, detection, or correction mechanisms. The fundamental 527 problem with UDP is that it provides no feedback mechanism to allow a 528 sender to pace its transmissions against the real performance of the 529 network. While this tends to have no significant effect on extremely 530 low-volume sender-receiver pairs, the impact of high-volume 531 relationships on the network can be severe. This problem could be 532 further aggravated by large RAQMON PDUs fragmented at the UDP level. 533 Transport protocols such as DCCP can also be used as underlying 534 RAQMON PDU transport, which provides flexibility of UDP style 535 datagram transmission with congestion control. 537 It should be noted that the congestion problem is not just between 538 RDS and RRC pairs, but whenever there is a high fan-in ratio, 539 congestion could occur. E.g. many RDSs reporting to an RRC. Within 540 the RAQMON Framework using UDP as a transport, congestion safety can 541 be achieved in following ways: 543 1. Constant Transmission Rate: In a well-managed network a 544 constant transmission rate policy (e.g. 1 RAQMON PDU per device 545 every N seconds) will ensure congestion safety as devices are 546 introduced into the network in a controlled manner. For 547 example, in an enterprise network, IP Phones are added in a 548 controlled manner and a constant transmission rate policy can 549 be sufficient to ensure congestion safe operation. The 550 configured rate needs to be related to the expected peak number 551 of devices. As a worst-case scenario, if the RDSs enforce an 552 administrative policy where the maximum PDU transmission rate 553 is no more than one RAQMON PDU every two minutes, a UDP based 554 implementation can be as congestion safe as a TCP based 555 implementation. Such policies can be enforced while 556 configuring RDSs, and the timers for the constant rate need to 557 be randomly jittered. 559 2. Single outstanding requests: This approach requires that a 560 request be sent at the application level, then there is a wait 561 for some sort of response indicating that the request was 562 received before sending anything else. This produces an effect 563 described by some as "ping-ponging" - traffic bounces back and 564 forth between two nodes like a ping-pong ball in a match. 565 Since there's only one ball in play between any two players at 566 any given time, most of the potential for congestion cascades 567 is eliminated. For reliability and efficiency reasons this 568 technique must include backed-off retransmissions. For example 569 if RAQMON PDUs are transported using SNMP INFORM PDUs over UDP, 570 a SNMP response from the RRC SHOULD be processed by the RDS to 571 implement this mechanism. [RAQMON-PDU] specifies that if the 572 SNMP notifications transport mapping mechanism is implemented, 573 it is RECOMMENDED to use INFORM PDUs, and it is NOT RECOMMENDED 574 to use Trap PDUs. 576 This pacing or serialization approach has the side-effect of 577 significantly reducing the maximum throughput, as transmission 578 occurs in only one direction at a time and there is at least a 579 2xRTT (round-trip time) delay between transmissions. More 580 sophisticated algorithms such as those in TCP and SCTP have 581 been developed to address this, and it would be inappropriate 582 to duplicate that work at the application level. Consequently, 583 if greater efficiency is required than that provided by this 584 simple approach, implementers SHOULD use TCP, SCTP, or another 585 such protocol. But if one absolutely must use UDP, this 586 approach works. It has been also used in other application 587 scenarios like SIP over UDP. 589 3. By restricting transmission to a maximum transmission unit 590 (MTU) size: A RDS may be faced with a request to deliver a 591 large message using UDP as a transport. Fragmentation of such 592 messages is problematic in several ways. Loss of any fragment 593 requires time-out and retransmission of the message. The 594 fragments are commonly transmitted out of the interface at 595 local interface (usually LAN) rates, without awareness of the 596 intervening network conditions. For these reasons, it is 597 generally considered a bad practice to send large PDUs over 598 UDP. If the MTU size is known, as an implementation, an RDS 599 should not allow an application to send more information by 600 limiting the size of transmissions over UDP to reduce the 601 effects of fragmentation. As an alternate, an RDS MAY also 602 send parameters to RRC over multiple RAQMON PDUs but identify 603 them as part of the same RAQMON reporting session with exactly 604 the same Network Time Protocol (NTP) [RFC1305] time stamp. 606 While the actual MTU of a link may not be known, common 607 practice seems to indicate that the RDS local interface MTU is 608 likely to be a reasonable "approximation". Where the actual 609 path MTU is known, that value SHOULD be used instead. 611 4. Irrespective of choice of transport protocol, it is also 612 RECOMMENDED that no more than 10% network bandwidth be used for 613 RDS/RRC reporting. More frequent reports from an RDS to RRC 614 would imply requirements for higher network bandwidth usage. 616 4. Measurement Methodology 617 It is not the intent of this document to recommend a methodology to 618 measure any of the QoS parameters defined in Section 5. Measurement 619 algorithms are left to the implementers and equipment vendors to 620 choose. There are many different measurement methodologies available 621 for measuring application performance. These include probe-based, 622 client-based, synthetic-transaction, and other approaches. This 623 specification does not mandate a particular methodology and is open 624 to any methodology that meets the minimum requirements. For 625 conformance to this specification, it is REQUIRED that the collected 626 data match the semantics described herein. However, it is 627 RECOMMENDED that vendors use IETF defined and International 628 Telecommunication Union (ITU) specified methodologies to measure 629 parameters when possible. 631 5. Metrics pre-defined for the BASIC part of the RAQMON PDU 633 The BASIC part of the RAQMON PDU provides for a list of pre-defined 634 parameters frequently used by applications to characterize end-to-end 635 application Quality of Service. This section defines a set of simple 636 metrics to be contained in the BASIC part of the RAQMON PDU, through 637 reference to existing IETF, ITU, and other standards organizations' 638 documents. Appropriate IETF or ITU references are included in the 639 metrics definitions. 641 As mentioned earlier, the RAQMON PDU also contains an application- 642 specific part, where application- and vendor-specific information not 643 included in BASIC part can be added as pairs, or as a 644 variable binding list. These extensions, managed independently by 645 vendors or other organizations, should be published for wider 646 interoperability. 648 Applications are not required to report all the parameters mentioned 649 in this section, but should have the flexibility to report a subset 650 of these parameters appropriate to an application context. The memo 651 further identifies the parameters that RDSs are required to include 652 in all PDUs for compliance, as well as optional parameters that RDSs 653 may report as needed. The definitions presented here are meant to 654 provide guidance to implementers, and IETF metric definition 655 references are provided for each metric. Application developers 656 should choose the metrics appropriate to their applications' needs. 657 Syntactical representations of the parameters identified here are 658 provided in the [RAQMON-PDU] specification. 660 5.1 Data Source Address (DA) 662 The Data Source Address (DA) is the address of the data source. This 663 could be either a globally unique IPv4 or IPv6 address, or a 664 privately IPv4 allocated address as defined in [RFC1918]. 666 It is expected that the Data Source Address (DA) would remain 667 constant within a given communication session. RDSs SHOULD avoid 668 sending these parameters within RAQMON reports too often to ensure an 669 efficient usage of network resources. 671 5.2 Receiver Address (RA) 673 The Receiver Source Address (RA) takes the same form as the Data 674 Source Address (DA) but represents the Receiver's Source Address. In 675 a communication session the reporting RDSs SHOULD fill in the other 676 party's address as a Receiver Source Address. Like the Data Source 677 Address, this could be either a globally unique IPv4 or IPv6 address, 678 or a privately IPv4 allocated address as defined in [RFC1918]. 680 It is expected that the Receiver Source Address (RA) would remain 681 constant within a given communication session. RDSs SHOULD avoid 682 sending these parameters within RAQMON reports too often to ensure an 683 efficient usage of network resources. 685 5.3 Data Source Name (DN) 687 The DN item could be of various formats as needed by the application. 688 Forms the DN could take include, but are not restricted to: 690 - "user@host", or "host" if a user name is not available as on 691 single-user systems. For both of these formats, "host" is the 692 fully qualified domain name of the host from which the payload 693 originates, formatted according to the rules specified in 694 [RFC1034], [RFC1035] and Section 2.1 of [RFC1123]. Use example 695 names are "big-guy@example.com" or "big-guy@192.0.2.178" for a 696 multi-user system. On a system with no user name, an example 697 would be "ip-phone4630.example.com". It is RECOMMENDED that the 698 standard host's numeric address not be reported via the DN 699 parameter, as the Data Source Address (DA) parameter is used for 700 that purpose. 702 - Another instance of a DN could be a valid E.164 phone number, a 703 SIP URI or any other form of telephone or pager number. It is 704 recommended that the phone number SHOULD be formatted with the 705 plus sign replacing the international access code. Example: 706 "+44-116-496-0348" for a number in the UK. 708 The DN value is expected to remain constant for the duration of a 709 session. RDSs SHOULD avoid sending these parameters within RAQMON 710 reports too often to ensure an efficient usage of network resources. 712 5.4 Receiver Name (RN) 713 The Receiver Name (RN) takes the same form as Data Source Name (DN), 714 but represents the Receiver's name. In a communication session, an 715 application SHOULD supply as a Receiver Name the name of the other 716 party with which it is communicating. 718 The RN value is expected to remain constant for the duration of a 719 session. RDSs SHOULD avoid sending these parameters within RAQMON 720 reports too often to ensure an efficient usage of network resources. 722 5.5 Data Source Device Port Used 724 This parameter indicates the source port used by the application for 725 a particular session or sub-session in communication. Examples of 726 ports include TCP Ports or UDP Ports, as used by communication 727 application protocols such as Session Initiation Protocol (SIP), SIP 728 for Instant Messaging and Presence Leveraging Extensions (SIMPLE), 729 H.323, RTP, HyperText Transport Protocol (HTTP), and so on. 731 This parameter MUST be sent in the first RAQMON PDU. 733 5.6 Receiver Device Port Used 735 This parameter indicates the receiver port used by the application 736 for a particular session or sub-session. Examples of ports include 737 TCP Ports, or UDP Ports used by communication application protocols 738 such as SIP, SIMPLE, H.323, RTP, HTTP, etc. 740 This parameter MUST be sent in the first RAQMON PDU. 742 5.7 Session Setup Date/Time 744 This parameter gives the time when the setup was initiated, if the 745 application has a setup phase, or when the session was started, if 746 such a setup phase does not exist. The time is represented using the 747 timestamp format of the Network Time Protocol (NTP), which is in 748 seconds relative to 0h UTC (Coordinated Universal Time) on 1 January 749 1900 [RFC1305]. 751 This parameter SHOULD be sent only in the first RAQMON PDU, after the 752 session setup is completed. 754 5.8 Session Setup Delay 756 The Session Setup Delay metric reports the time taken from an 757 origination request being initiated by a host/endpoint to the media 758 path being established (or a session progress indication being 759 received from the remote host/endpoint) expressed in milliseconds. 760 For example, in VoIP systems, a session setup time can be measured as 761 the interval from the last DTMF (dual-tone multi-frequency) button 762 pushed to the first ring-back tone that indicates that the far end is 763 ringing. Another example would be the Session Setup Delay of a SIP 764 call, which is measured as the elapsed time between when an INVITE is 765 generated by a User Agent and when the 200 OK is received. 767 This parameter SHOULD be sent only in the first RAQMON PDU, after the 768 session setup is completed. 770 5.9 Session Duration 772 The Session Duration metric reports how long a session or a sub- 773 session lasted. This metric is application context sensitive. For 774 example a VoIP Call Session Duration can be measured as the elapsed 775 time between call pick up and call termination, including session 776 setup time. 778 This parameter SHOULD be sent only in the first RAQMON PDU, after the 779 session is terminated. 781 5.10 Session Setup Status 783 The Session Setup Status metric is intended to report the 784 communication status of a session. Its values identify appropriate 785 communication session states, such as Call Progressing, Call 786 Established successfully, "trying," "ringing," "re-trying," "RSVP 787 reservation failed", and so on. 789 Session setup status is meaningful in the context of applications. 790 For this reason applications SHOULD use this metric together with the 791 application / name metrics defined in Section 5.32. 793 This information could be used by network management systems to 794 calculate parameters such as call success rate, call failure rate, 795 etc., or by a debugging tool that captures the status of a call's 796 setup phase as soon as a call is established. 798 This parameter SHOULD be sent after each change in the session 799 status. 801 5.11 Round Trip End-to-End Network Delay 802 The Round Trip End-to-End Network Delay defined in [RFC3550] for 803 applications running over RTP and in [RFC2681] for all other IP 804 applications is a key metric for Application QoS Monitoring. Some 805 applications do not perform well (or at all) if the end-to-end delay 806 between hosts is large relative to some threshold value. Erratic 807 variation in delay values makes it difficult (or impossible) to 808 support many real-time applications such as Voice over IP, Video over 809 IP, Fax over IP etc. 811 The Round Trip End-to-End Network delay of the underlying transport 812 network are measured using methodologies described in [RFC3550] for 813 RTP and [RFC2681] for other IP applications. 815 Note that the packets used for measurement in some methodologies may 816 be of different type to those used for media (e.g. ICMP instead of 817 RTP) and hence may differ in terms of route and queue priority. This 818 may result in measured delays being different to those experienced on 819 the media path. Conformance for this metric requires that actual 820 application packets, or packets of the same application type be used. 822 Support for RTP can be determined by the support of the RTP MIB 823 [RFC2959] in the hosts running the applications or by inclusion of 824 the string RTP at the beginning of the Application Name (Section 825 5.32). 827 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 828 capability of determining its value and if the parameter is relevant 829 for the application. 831 5.12 One Way End-to-End Network Delay 833 The One Way End-to-End Network Delay [RFC2679] metric reports the One 834 Way End-to-End delay encountered by traffic from the source to the 835 destination network interface. One-Way Delay measurements identified 836 by the IP Performance Metrics (IPPM) Working Group [RFC2679] will be 837 used to measure one-way end-to-end network delay. 839 The need for such a metric is derived from the fact that the path 840 from a source to a destination may be different from the path from 841 the destination back to the source ("asymmetric paths"), such that 842 different sequences of routers are used for the forward and reverse 843 paths. Therefore round-trip measurements actually measure the 844 performance of two distinct paths together. 846 Measuring each path independently highlights the performance 847 difference between the two paths that may traverse different Internet 848 service providers, and even radically different types of networks(for 849 example, research versus commodity networks, or ATM (asynchronous 850 transfer mode) versus Packet-over-SONET (synchronous optical) 851 transport networks. 853 Even when the two paths are symmetric, they may have radically 854 different performance characteristics due to asymmetric queuing. 855 Performance of an application may depend mostly on the performance in 856 one direction. For example, a file transfer using TCP may depend 857 more on the performance in the direction that data flows, rather than 858 the direction in which acknowledgements travel. 860 In quality-of-service (QoS) enabled networks, provisioning in one 861 direction may be radically different from provisioning in the reverse 862 direction, and thus the QoS guarantees differ. Measuring the paths 863 independently allows the verification of both guarantees. 865 RAQMON SHOULD NOT derive One Way End-to-End Network Delay by assuming 866 internet paths are symmetric (i.e. dividing Round Trip Delay by two). 868 Note that the packets used for measurement in some methodologies may 869 be of different type to those used for media (e.g. ICMP instead of 870 RTP) and hence may differ in terms of route and queue priority. This 871 may result in measured delays being different to those experienced on 872 the media path. Conformance for this metric requires that actual 873 application packets, or packets of the same application type be used. 875 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 876 capability of determining its value and if the parameter is relevant 877 for the application. 879 5.13 Application Delay 881 Various Network Delay versions as outlined in section 5.11 and 5.12 882 do not include delays associated to buffering, play-out, packet- 883 sequencing, coding/decoding etc. in the end devices. The Application 884 Delay metric defined in this section is targeted to capture all such 885 delay parameters, providing a total application endpoint delay. 887 Application delay can be expressed as the time delay introduced 888 between the network interface and the application level presentation. 889 Since it is difficult to envision usage of all sorts of applications 890 the following guidance is provided to the implementers to measure the 891 application delay: 893 - The sending end contribution to application delay is defined as the 894 sum of sample sequencing, accumulation and encoding delay. 896 - The receiving end contribution to application delay is calculated 897 as the sum of delays associated to buffering, play-out, packet- 898 sequencing, decoding associated with the receiving direction, if 899 relevant. 901 The endpoint application delay is defined as the sum of the receiving 902 and sending contributions to delay measured or estimated within the 903 endpoint that is generating this report. 905 It is easy to recognize that applications running on an IP device can 906 experience same network delay but have different application 907 associated delay values and hence the user experience associated to 908 specific applications may vary while the network delay value remains 909 same for both the applications. 911 Having network delay and application delay measurements available, a 912 management application can represent the delay experienced by the end 913 user at the application level as a sum of network delay and the 914 application delays reported from the endpoints. However the 915 specification of such a management application is outside the scope 916 of the RAQMON specification. 918 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 919 capability of determining its value and if the parameter is relevant 920 for the application. 922 5.14 Inter-Arrival Jitter 924 The Inter-Arrival Jitter metric provides a short-term measure of 925 network congestion [RFC3550]. The jitter measure may indicate 926 congestion before it leads to packet loss. The inter-arrival jitter 927 field is only a snapshot of the jitter at the time when a RAQMON PDU 928 is generated and is not intended to be taken quantitatively as 929 indicated in [RFC3550]. Rather, it is intended for comparison of 930 inter-arrival jitter from one receiver over time. Such inter-arrival 931 jitter information is extremely useful to understand the behavior of 932 certain applications such as Voice over IP, Video over IP etc. Inter- 933 arrival jitter information is also used in the sizing of play-out 934 buffers for applications requiring the regular delivery of packets 935 (for example, voice or video play-out). 937 In [RFC3550], the selection function is implicitly applied to 938 consecutive packet pairs, and the "jitter estimate" is computed by 939 applying an exponential filter with parameter 1/16 to generate the 940 estimate (i.e., j_new = 15/16* j_old + 1/16*j_new). 942 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 943 capability of determining its value and if the parameter is relevant 944 for the application. 946 5.15 IP Packet Delay Variation 948 [RFC3393] provides guidance to several absolute jitter parameters. 949 RAQMON uses the [RFC3393] definition of the IP Packet Delay Variation 950 (ipdv) for packets inside a stream of packets. The IP Delay Variation 951 metric is used to determine the dynamics of queues within a network 952 (or router) where the changes in delay variation can be linked to 953 changes in the queue length processes at a given link or a 954 combination of links. Such a parameter provides visibility within an 955 IP Network and a better understanding of application level 956 performance problems as it relates to IP Network performance. 958 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 959 capability of determining its value and if the parameter is relevant 960 for the application. 962 5.16 Total Number of Application Packets Received 964 This metric reports the number of application payload packets 965 received by the RDS as part of this session since the last RAQMON PDU 966 was sent up until the time this RAQMON PDU was generated. 968 This parameter represents a very simple incremental counter that 969 counts the number of "application" packets that an RDS has received. 970 Applications packets MAY include signaling packets. Since this count 971 is a snapshot in time, depending on application type, it also varies 972 based on the application states e.g. an RDS within an application 973 session will report aggregated number of application packets that 974 were sent out during signaling setup, media packets received, session 975 termination etc. 977 For example, during Voice over IP or Video over IP sessions setup 978 this counter represents the number of signaling session related 979 packets that have been received which will be derived from the 980 relevant application signaling protocol stack such as SIP or H.323, 981 SIMPLE and various other signaling protocols used by the application 982 to establish the communication session. 984 However, during a period when media is established between the 985 communicating entities, this counter will be indicative of the number 986 of RTP Frames that have been sent out to the communicating party 987 since last PDU was sent out. The methodology described within RTCP 988 SR/RR reports [RFC3550] to count RTP frames will be applied wherever 989 applications use RTP. These being a cumulative counter, applications 990 need to take into consideration the possibility of the counter 991 overflowing and restarting counting from zero. 993 Support for RTP can be determined by the support of the RTP MIB 994 [RFC2959] in the hosts running the applications or by inclusion of 995 the string RTP at the beginning of the Application Name (Section 996 5.32). 998 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 999 capability of determining its value and if the parameter is relevant 1000 for the application. 1002 5.17 Total Number of Application Packets Sent 1004 This metric reports the number of signaling and payload packets sent 1005 by the RDS as part of this session since the last RAQMON PDU was sent 1006 until the time this RAQMON PDU was generated. Applications packets 1007 MAY include signaling packets. Similar to the total number of 1008 application packets received parameter in section 5.16, this count is 1009 a snapshot in time. Depending on the application type, the counter 1010 also varies based on various application states, including packet 1011 counts for signaling setup, media establishment, session termination 1012 states, and so on. These being a cumulative counter, applications 1013 need to take into consideration the possibility of the counter 1014 overflowing and restarting counting from zero. 1016 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1017 capability of determining its value and if the parameter is relevant 1018 for the application. 1020 5.18 Total number of Application Octets Received 1022 This metric reports the total number of signaling and payload octets 1023 received in packets by the RDS as part of this session since the last 1024 RAQMON PDU was sent, up until the time this RAQMON packet was 1025 generated. Applications octets MAY include signaling octets. The 1026 methodology described by [RFC3550] will be applied wherever 1027 applications use RTP. These being a cumulative counter, applications 1028 need to take into consideration the possibility of the counter 1029 overflowing and restarting counting from zero. 1031 Support for RTP can be determined by the support of the RTP MIB 1032 [RFC2959] in the hosts running the applications or by inclusion of 1033 the string RTP at the beginning of the Application Name (Section 1034 5.32). 1036 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1037 capability of determining its value and if the parameter is relevant 1038 for the application. 1040 5.19 Total number of Application Octets Sent 1042 This metric reports the total number of signaling and payload octets 1043 received in packets by the RDS as part of this session since the last 1044 RAQMON PDU was sent, up until the time this RAQMON packet was 1045 generated. This is similar to the Total Number of Application Octets 1046 Received metric. Applications octets MAY include signaling octets. 1047 The methodology described by [RFC3550] will be applied wherever 1048 applications use RTP. These being a cumulative counter, applications 1049 need to take into consideration the possibility of the counter 1050 overflowing and restarting counting from zero. 1052 Support for RTP can be determined by the support of the RTP MIB 1053 [RFC2959] in the hosts running the applications or by inclusion of 1054 the string RTP at the beginning of the Application Name (Section 1055 5.32). 1057 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1058 capability of determining its value and if the parameter is relevant 1059 for the application. 1061 5.20 Cumulative Packet Loss 1063 The cumulative packet loss metric indicates the loss associated with 1064 the network as well as local device losses over time. This parameter 1065 is counted as the total number of application packets from the source 1066 that have been lost since the beginning of the session. This number 1067 is defined to be the number of packets expected less the number of 1068 packets actually received, where the number of packets received 1069 includes the count of packets which are late or duplicates. If a 1070 packet is discarded due to late arrival then it MUST be counted as 1071 either lost or discarded but MUST NOT be counted as both. 1073 Packet loss by the underlying transport network SHALL be measured 1074 using the methodologies described in [RFC3550] for RTP traffic and 1075 [RFC2680] for other IP traffic. The number of packets expected is 1076 defined to be the extended last sequence number received, as defined 1077 next, less the initial sequence number received. For RTP traffic 1078 this may be calculated using techniques such as shown in Appendix A.3 1079 of [RFC3550]. 1081 Support for RTP can be determined by the support of the RTP MIB 1082 [RFC2959] in the hosts running the applications or by inclusion of 1083 the string RTP at the beginning of the Application Name (Section 1084 5.32). 1086 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1087 capability of determining its value and if the parameter is relevant 1088 for the application. 1090 5.21 Packet loss in Fraction 1092 The Packet loss in Fraction metric represents the packet loss as 1093 defined above, but expressed as a fraction of the total traffic over 1094 time. 1096 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1097 capability of determining its value and if the parameter is relevant 1098 for the application. 1100 5.22 Cumulative Application Packet Discards 1102 RAQMON Framework allows applications to distinguish between packets 1103 lost by the network and those discarded due to jitter and other 1104 application level errors. Though packet loss and discards have equal 1105 effect on the quality of the application, having separate counts for 1106 packet loss and discards help identify the source of quality 1107 degradation. 1109 The packet discard metric indicates packets discarded locally by the 1110 device over time. Local device level packet discard is captured as 1111 the total number of application level packets from the source that 1112 have been discarded since the beginning of reception, due to late or 1113 early arrival, under-run or overflow at the receiving jitter buffer 1114 or any other application specific reasons. 1116 If the RDS cannot tell the difference between discards and lost 1117 packets then it MUST report only lost packets and MUST NOT report 1118 discards. 1120 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1121 capability of determining its value and if the parameter is relevant 1122 for the application. 1124 5.23 Packet Discards in Fraction 1126 The packet discards in fraction metric represents packets from the 1127 source that have been discarded since the beginning of the reception 1128 but expressed as a fraction of the total traffic over time. 1130 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1131 capability of determining its value and if the parameter is relevant 1132 for the application. 1134 5.24 Source Payload Type 1136 The source payload type reports payload formats (e.g. media encoding) 1137 as sent by the data source, e.g. ITU G.711, ITU G.729B, H.263, 1138 MPEG-2, ASCII, etc. This memo follows the definition of Payload Type 1139 (PT) in [RFC3551]. For example, to indicate that the source payload 1140 type used for a session is PCMA (pulse-code modulation with A-law 1141 scaling), the value of the source payload field for the respective 1142 session will be 8. 1144 The source payload type value is expected to remain constant for the 1145 duration of a session, with the exception of events like dynamic 1146 codec changes. RDSs SHOULD avoid sending these parameters within 1147 RAQMON reports more often then necessary (e.g. at dynamic codec 1148 changes) to ensure an efficient usage of network resources. 1150 If dynamic types - values 96 to 127 according to [RFC3551] are being 1151 used to identify the source payload type, a RAQMON extension 1152 parameter MAY be defined to indicate the MIME subtypes. In the case 1153 where the RDS does send reports noting dynamic codec changes, there 1154 may be instances where this extension parameter is used only before 1155 or after the codec change, as the source payload may shift between 1156 the dynamic and static types. 1158 5.25 Receiver Payload Type 1160 The receiver payload type reports payload formats (e.g. media 1161 encodings) as sent by the other communicating party back to the 1162 source, e.g. ITU G.711, ITU G.729B, H.263, MPEG-2, ASCII, etc. This 1163 document follows the definition of payload type (PT) in [RFC3551]. 1164 For example, to indicate that the destination payload type used for a 1165 session is PCMA the destination payload type field for the respective 1166 session will be 8. 1168 The destination payload type value is expected to remain constant for 1169 the duration of a session, with the exception of events like dynamic 1170 codec changes. RDSs SHOULD avoid sending these parameters within 1171 RAQMON reports more often then necessary (e.g. at dynamic codec 1172 changes) to ensure an efficient usage of network resources. 1174 If dynamic types - values 96 to 127 according to [RFC3551] are being 1175 used to identify the destination payload type, a RAQMON extension 1176 parameter MAY be defined to indicate the MIME subtypes. In the case 1177 where the RDS does send reports noting dynamic codec changes, there 1178 may be instances where this extension parameter is used only before 1179 or after the codec change, as the destination payload may shift 1180 between the dynamic and static types. 1182 5.26 Source Layer 2 Priority 1184 Many devices use Layer 2 technologies to prioritize certain types of 1185 traffic in the Local Area Network environment. For example, the 1998 1186 Edition of IEEE 802.1D [IEEE802.1D] "Media Access Control Bridges" 1187 contains expedited traffic capabilities to support transmission of 1188 time critical information. Many devices use that standard to mark 1189 Ethernet frames according to IEEE P802.1p standard. Details on these 1190 can be found in [IEEE802.1D], which incorporates P802.1p. The Source 1191 Layer 2 Priority RAQMON field indicates what Layer 2 values were used 1192 by the host running the RDS to prioritize these packets in the Local 1193 Area Network environment. 1195 The Source Layer 2 Priority value is expected to remain constant for 1196 the duration of a session. Hosts running the RDSs SHOULD avoid 1197 sending these parameters within RAQMON reports too often to ensure an 1198 efficient usage of network resources. 1200 5.27 Source TOS/DSCP Value 1202 Various Layer 3 technologies are in place to prioritize traffic in 1203 the Internet. For example, the traditional IP Precedence [RFC791], 1204 and Type Of Service (TOS) [RFC1812], or more recent technologies like 1205 Differentiated Services [RFC2474][RFC2475], use the TOS octet in 1206 IPv4, while the traffic class octet is used to prioritize traffic in 1207 Ipv6. Source Layer TOS/DCP RAQMON field reports the appropriate 1208 Layer 3 values used by the Data Source to prioritize these packets. 1210 The Source TOS/DSCP value is expected to remain constant for the 1211 duration of a session. Hosts running the RDSs SHOULD avoid sending 1212 these parameters within RAQMON reports too often to ensure an 1213 efficient usage of network resources. 1215 5.28 Destination Layer 2 Priority 1217 The Destination Layer 2 Priority reports the Layer 2 value used by 1218 the communication receiver to prioritize packets while sending 1219 traffic to the data source in the Local Area Networks environment. 1220 Like Source Layer 2 Priority, Destination Layer 2 Priority could 1221 indicate whether the destination has used a Layer 2 technologies like 1222 IEEE P802.1p for priority queuing. 1224 The Destination Layer 2 Priority value is expected to remain constant 1225 for the duration of a session. Hosts running the RDSs SHOULD avoid 1226 sending these parameters within RAQMON reports too often to ensure an 1227 efficient usage of network resources. 1229 5.29 Destination TOS/DSCP Value 1231 The Destination TOS/DSCP RAQMON field reports the values used by the 1232 Data Receiver to prioritize these packets received by the source. 1233 Similar to Source Layer 3 Priority, Destination Layer 3 Priority 1234 indicates whether the destination has used any Layer 3 technologies 1235 like IP Precedence [RFC791], Type Of Service (TOS) [RFC2474], 1236 [RFC1812] or more recent technologies like Differentiated Service 1237 [RFC2474], [RFC2475]. 1239 The Destination TOS/DSCP value is expected to remain constant for the 1240 duration of a session. Hosts running the RDSs SHOULD avoid sending 1241 these parameters within RAQMON reports too often to ensure an 1242 efficient usage of network resources. 1244 5.30 CPU Utilization in Fraction 1246 This parameter captures the CPU usage of the hosts running the RDSs 1247 which may have very critical implications for QoS of an end device. 1248 It is computed as an average since the last reporting interval, and 1249 corresponds to the percentage of that time that the CPU was busy. 1251 In the case of multiple CPU hosts, the maximum utilization among the 1252 different CPUs MUST be reported. 1254 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1255 capability of determining its value and if the parameter is relevant 1256 for the application. 1258 5.31 Memory Utilization in Fraction 1259 This parameter captures the memory usage of the hosts running the 1260 RDSs which may have very critical implications for QoS of an end 1261 device. It is computed as an average since the last reporting 1262 interval, and corresponds to the average percentage of the total 1263 memory space critical for the applications in use during that time 1264 interval (e.g. primary CPU RAM, buffers). 1266 In the case of multiple CPU hosts, the maximum memory utilization 1267 among the different CPUs MUST be reported. 1269 This parameter SHOULD be sent in each RAQMON PDU, if the RDS has the 1270 capability of determining its value and if the parameter is relevant 1271 for the application. 1273 5.32 Application Name/version 1275 The Application Name/version parameter gives the name and optionally 1276 the version of the application associated with that session or sub- 1277 session, e.g., "XYZ VoIP Agent 1.2". This information may be useful 1278 for scenarios where the end device is running multiple applications 1279 with various priorities and could be very handy for debugging 1280 purposes. 1282 If the application is using RTP [RFC3550] the Application Name SHOULD 1283 begin with the string RTP. 1285 This parameter MUST be sent in the first RAQMON PDU. 1287 6. Report Aggregation and Statistical Data processing 1289 Within the RAQMON Framework, RRCs are expected to have significantly 1290 greater computational resources than RDSs. consequently, various 1291 aggregation functions are performed by the RRCs, while RDSs are not 1292 burdened by statistical data processing such as computation of 1293 minima, maxima, averages, standard deviations, etc. 1295 The RAQMON MIB is provides minimal aggregation of the RAQMON 1296 parameters defined above. The RAQMON MIB is not designed to provide 1297 extensive aggregation like the Application Performance Measurement 1298 (APM) MIB [RFC3729] or the Transport Performance Metrics (TPM) MIB 1299 [RFC4150]. One should use APM and TPM MIBs to aggregate parameters 1300 based on protocols (e.g. performance of HTTP, RTP) or based on 1301 applications (e.g. performance of VoIP, Video Applications). 1303 In the RAQMON MIB, aggregation can be performed only on specific 1304 RAQMON metric parameters. Aggregation always results in statistical 1305 Mean/Min/Max values, according to these definitions: 1307 Mean: Mean is defined as the statistical average of a metric over 1308 the duration of a communication session. For example, if an 1309 RDS reported End-to-End delay metric N times within a 1310 communication session, then the Mean End-to-End Delay can be 1311 computed by summing of these N reported values, and then 1312 dividing by N. 1314 Min: Min is defined as the statistical minimum of a metric over 1315 the duration of a communication session. For example, if 1316 the end-to-end delay metric of an end device within a 1317 communication session is reported N times by the RDS, then 1318 the Min end-to-end delay is the smallest of the N end-to-end 1319 delay metric values reported. 1321 Max: Max is defined as the statistical maximum of a metric over 1322 the duration of a communication session. For example, if 1323 the end-to-end delay metric of an end device within a 1324 communication session is reported N times by the RDS, then 1325 the Max End-to-End Delay is the largest of the N End-to-End 1326 Delay metric values reported. 1328 7. Keeping Historical Data and Storage 1330 It is evident from the document that the RAQMON MIB data need to be 1331 managed to optimize storage space. The large volume of data gathered 1332 in a communication session could be optimized for storage space by 1333 performing and storing only aggregated RAQMON metrics for history if 1334 required. 1336 Examples of how such storage space optimization can be performed 1337 include: 1339 1. Make data available through the MIB only at the end of a 1340 communication session, i.e., upon receipt of a NULL PDU. The 1341 aggregated data could be made available using the RAQMON MIB as 1342 Mean, Max or Min entries and be saved for historical purposes. 1344 2. Use a time-based algorithm that aggregates data over a specific 1345 period of time within a communication session, thus requiring 1346 fewer entries, to reduce storage space requirements. For 1347 example, if an RDS sends data out every 10 seconds and the RRC 1348 updates the RAQMON MIB once every minute, for every 6 data 1349 points there would be one MIB entry. 1351 3. Periodically delete historical data in accordance with an 1352 administrative policy. An example of such a policy would be to 1353 delete historical data older than 60 days. The implementation 1354 of such policies is left to the application developer's 1355 discretion, and their use is an operational concern. 1357 8. Acknowledgements 1359 The authors would like to thank to Andy Bierman, Alan Clark, 1360 Mahalingam Mani, Colin Perkins, Steve Waldbusser, Magnus Westerlund 1361 and Itai Zilbershtein for the precious advices and real contributions 1362 brought to this document. The authors would also like to extend 1363 special thanks to Randy Presuhn, who reviewed this document for 1364 spelling and formatting purposes, as well as for a deep review of the 1365 technical content. We also would like to thank Bert Wijnen for the 1366 permanent coaching during the evolution of this document and the 1367 detailed review of its final versions. 1369 9. Security Considerations 1371 Security considerations associated with the RAQMON Framework are 1372 discussed below, and in greater detail in other RAQMON memos as is 1373 appropriate. 1375 9.1 The RAQMON Threat Model 1377 The vulnerabilities associated with the RAQMON Framework are a 1378 combination of those associated with the underlying layers up to the 1379 transport layer, and of possible exploits of RAQMON payload. 1380 Possible exploits of RAQMON payloads fall within these classes: 1382 1. Unauthorized examination of sensitive information in the 1383 payload in transit; 1385 2. Unauthorized modification of payload contents in transit, 1386 leading to: 1388 a. Mis-identification of information from one RAQMON reporting 1389 session as belonging to another destined to the same RRC; 1391 b. Mismapping of RAQMON sessions; 1393 c. Various forms of session-level denial-of-service (DoS) 1394 attacks; 1396 d. DoS through modification of RAQMON parameter values and 1397 statistics; 1399 e. Invalid timestamps, leading to false interpretation of the 1400 monitored data, affecting call records information, and 1401 making difficult to place monitoring events in their 1402 appropriate temporal context. 1404 3. Malformed payloads, permitting the exploitation of potential 1405 implementation weaknesses to compromise an RRC; 1407 4. Unauthorized disclosure of sensitive data carried by 1408 application PDUs, leading to a breach of confidentiality; 1410 Consequently, threats based on unauthorized disclosure or 1411 modification of payloads or headers will have to be assumed. 1413 9.2 The RAQMON Security Requirements and Assumptions 1415 In order to preserve integrity of the RAQMON PDU against these 1416 threats, the RAQMON model must provide for cryptographically strong 1417 security services. 1419 Consequently, the RAQMON framework must be able to provide for the 1420 following protections: 1422 1. Authentication - the RRC should be able to verify that a RAQMON 1423 PDU was in fact originated by the RDS that claims to have sent 1424 it. 1426 2. Privacy - Since RAQMON information includes identification of 1427 the parties participating in a communication session, the 1428 RAQMON framework should be able to provide for protection from 1429 eavesdropping, to prevent an unauthorized third party from 1430 gathering potentially sensitive information. This can be 1431 achieved by using various payload encryption technologies, such 1432 as Data Encryption Standard (DES), 3-DES, Advanced Encyrption 1433 Standard (AES), etc. 1435 3. Protection from denial of service attacks directed at the RRC - 1436 RDSs send RAQMON reports as a side effect of an external event 1437 (for example, a phone call is being received). An attacker can 1438 try and overwhelm the RRC (or the network) by initiating a 1439 large number of events (i.e., calls) for the purpose of 1440 swamping the RRC with too many RAQMON PDUs. 1442 To prevent DoS attacks against RRC, the RDS will send the first 1443 report for a session only after the session has been in 1444 progress for the five seconds reporting interval. Sessions 1445 shorter than that should be stored in the RDS and will be 1446 reported only after that interval has expired. 1448 9.3 RAQMON Security Model 1450 The RAQMON architecture permits the use of multiple transport 1451 protocols. Most of these support a secure mode of operation. There 1452 are advantages to relying on the security provided at the transport 1453 protocol layer. 1455 1. Transport protocol level security can generally protect the 1456 payload with end-to-end authentication, confidentiality, 1457 message integrity and replay protection services. 1459 2. A good cryptographic security protocol always has an associated 1460 key management protocol. Use of transport protocol security 1461 relies on its key management, rather than requiring development 1462 of another mechanism. 1464 3. When transport protocol security is already enabled between the 1465 RDS and RRC, additional encryption and message authentication 1466 at the application level is avoided. 1468 However, there are also shortcomings to be noted in relying on 1469 transport protocol security. 1471 1. When session-level isolation of the different RAQMON sessions 1472 of an RDS-RRC pair is required, it will be necessary to open 1473 separate transport protocol instances. Such cases, however, 1474 may be rare. 1476 2. Since security services are not provided by the RAQMON 1477 framework, the absence of transport or lower protocol security 1478 implies the absence of RAQMON security. 1480 10. Normative References 1482 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 1483 September 1981. 1485 [RFC1812] Baker, F., "Requirements for IP Version 4 Routers", 1486 RFC1812, June 1995. 1488 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1489 Requirement Levels", BCP 14, RFC 2119, March 1997. 1491 [RFC2474] Nicholas, K., Blake, S., Baker, F, and D. Black, 1492 "Definition of the Differentiated Services Field (DS 1493 Field) in the IPv4 and IPv6 Headers", RFC2474, December 1494 1998. 1496 [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., 1497 and W. Weiss, "An Architecture for Differentiated 1498 Services", RFC2475, December 1998. 1500 [RFC2679] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1501 Delay Metric for IPPM", RFC 2679, September 1999. 1503 [RFC2680] Almes, G., Kalidindi, S., and M. Zekauskas, "A One-way 1504 Packet Loss Metric for IPPM", RFC 2680, September 1999. 1506 [RFC2681] Almes, G., Kalidindi, S., and M. Zekauskas, "A Round- 1507 Trip Delay Metric for IPPM", RFC 2681, September 1999. 1509 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 1510 Information Base", STD 59, RFC 2819, May 2000. 1512 [RFC2959] Baugher, M., Strahm, B., and I. Suckonick, "Real-Time 1513 Transport Protocol Management Information Base", RFC 1514 2959, October 2000. 1516 [RFC3393] Demichelis, C. and P. Chimento, "IP Packet Delay 1517 Variation Metric for IP Performance Metrics (IPPM)", RFC 1518 3393, November 2002. 1520 [RFC3416] Presuhn, R., Ed., "Version 2 of the Protocol Operations 1521 for the Simple Network Management Protocol (SNMP)", STD 1522 62, RFC 3416, December 2002. 1524 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1525 Jacobson, "RTP: A Transport Protocol for Real-Time 1526 Applications", RFC 3550, July 2003. 1528 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio 1529 and Video Conferences with Minimal Control", STD 65, RFC 1530 3551, July 2003. 1532 11. Informative References 1534 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 1535 Facilities", STD 13, RFC 1034, November 1987. 1537 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 1538 Specification", STD 13, RFC 1035, November 1987. 1540 [RFC1123] Braden, R., "Requirements for Internet Hosts - 1541 Application and Support", STD 3, RFC 1123, October 1989. 1543 [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, 1544 March 1992. 1546 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., de Groot, 1547 G., and E. Lear, "Address Allocation for Private 1548 Internets", BCP 5, RFC 1918, March 1996. 1550 [RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 1551 2914, September 2000. 1553 [RFC3235] Senie, D., "Network Address Translator (NAT)-Friendly 1554 Application Design Guidelines", RFC3235, January 2002. 1556 [RFC3611] Friedman T., Caceres R., and A. Clark, "RTP Control 1557 Protocol Extended Reports (RTCP XR)", RFC 3611, November 1558 2003. 1560 [RFC3729] Waldbusser, S., "Application Performance Measurement 1561 MIB", RFC 3729, March 2004. 1563 [RFC4150] Dietz R., and R. Cole, "Transport Performance Metrics 1564 MIB", RFC 4150, August 2005. 1566 [RAQMON-PDU] Siddiqui, A., Romascanu, D., Golovinsky, E., Ramhman, 1567 M., and B. Hu, "Transport Mappings for Real-time 1568 Application Quality of Service Monitoring (RAQMON) 1569 Protocol Data Unit (PDU)", Internet-Draft, draft-ietf- 1570 raqmon-pdu-13.txt, February 2006. 1572 [RAQMON-MIB] Siddiqui, A., Romascanu, D., and E. Golovinsky, "Real- 1573 time Application Quality of Service Monitoring (RAQMON) 1574 MIB", Internet-Draft, draft-ietf-rmonmib-raqmon- 1575 mib-12.txt, February 2006. 1577 [IEEE802.1D] Information technology - Telecommunications and 1578 information exchange between systems - Local and 1579 metropolitan area networks - Common Specification a - 1580 Media access control (MAC) bridges:15802-3: 1998 1581 (ISO/IEC). Revision. This is a revision of ISO/IEC 1582 10038: 1993, 802.1j-1992 and 802.6k-1992. It 1583 incorporates P802.11c, P802.1p and P802.12e [ANSI/IEEE 1584 Std 802.1D, 1998 Edition] 1586 12. IANA Considerations 1588 No actions are required from IANA as result of the publication of 1589 this document. 1591 Authors' Addresses 1593 Anwar A. Siddiqui 1594 Avaya Labs 1595 307 Middletown Lincroft Road 1596 Lincroft, New Jersey 07738 1597 USA 1598 Tel: +1 732 852-3200 1599 E-mail: anwars@avaya.com 1601 Dan Romascanu 1602 Avaya 1603 Atidim Technology Park, Building #3 1604 Tel Aviv, 61131 1605 Israel 1606 Tel: +972-3-645-8414 1607 Email: dromasca@avaya.com 1609 Eugene Golovinsky 1610 BMC Software Inc. 1611 2101 CityWest Boulecard 1612 Houston, Texas 77042 1613 USA 1614 Tel: +1 713 918-1816 1615 Email: eugene_golovinsky@bmc.com 1617 Full Copyright Statement 1619 Copyright (C) The Internet Society (2006). This document is subject 1620 to the rights, licenses and restrictions contained in BCP 78, and 1621 except as set forth therein, the authors retain all their rights. 1623 This document and the information contained herein are provided on an 1624 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1625 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1626 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1627 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1628 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1629 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1631 IPR Disclosure Acknowledgement 1633 The IETF takes no position regarding the validity or scope of any 1634 Intellectual Property Rights or other rights that might be claimed to 1635 pertain to the implementation or use of the technology described in 1636 this document or the extent to which any license under such rights 1637 might or might not be available; nor does it represent that it has 1638 made any independent effort to identify any such rights. Information 1639 on the procedures with respect to rights in RFC documents can be 1640 found in BCP 78 and BCP 79. 1642 Copies of IPR disclosures made to the IETF Secretariat and any 1643 assurances of licenses to be made available, or the result of an 1644 attempt made to obtain a general license or permission for the use of 1645 such proprietary rights by implementers or users of this 1646 specification can be obtained from the IETF on-line IPR repository at 1647 http://www.ietf.org/ipr. 1649 The IETF invites any interested party to bring to its attention any 1650 copyrights, patents or patent applications, or other proprietary 1651 rights that may cover technology that may be required to implement 1652 this standard. Please address the information to the IETF at ietf- 1653 ipr@ietf.org. 1655 Acknowledgement: 1657 Funding for the RFC Editor function is currently provided by the 1658 Internet Society.