idnits 2.17.1 draft-ietf-rmonmib-raqmon-pdu-06.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 3667, Section 5.1 on line 839. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 953), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 39. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 21 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 22 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** There are 41 instances of too long lines in the document, the longest one being 8 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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 (8 July 2004) is 7231 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) == Missing Reference: 'RFC 3414' is mentioned on line 144, but not defined == Missing Reference: 'RAQMON-FRAMEWOK' is mentioned on line 160, but not defined == Missing Reference: 'RFC 1321' is mentioned on line 852, but not defined == Unused Reference: 'RFC1321' is defined on line 792, but no explicit reference was found in the text == Unused Reference: 'RFC3414' is defined on line 802, but no explicit reference was found in the text -- No information found for draft-ietf-raqmon-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RAQMON-FRAMEWORK' Summary: 13 errors (**), 0 flaws (~~), 8 warnings (==), 5 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-pdu-06.txt Avaya Inc. 4 Category: Standards Track Dan Romascanu 5 Expires January 2005 Avaya 6 Eugene Golovinsky 7 BMC Software 8 8 July 2004 9 SNMP Notification Transport for 10 Real-time Application Quality of Service Monitoring (RAQMON) 11 Protocol Data Unit (PDU) 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other intellectual property right (IPR) claims 17 of which he or she is aware have been or will be disclosed, and any 18 of which he or she becomes aware will be disclosed, in accordance 19 with Section 6 of RFC 3668. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt 34 To view the list Internet-Draft Shadow Directories, see 35 http://www.ietf.org/shadow.html. 37 Copyright Notice 39 Copyright (C) The Internet Society (2004). All Rights Reserved. 41 Abstract 43 A common Protocol Data Unit (PDU) has been defined to be used between 44 a Real-Time Application Quality of Service (QoS) Monitoring (RAQMON) 45 Data Source (RDS) and a RAQMON Report Collector (RRC) to report 46 application level Quality of Service (QoS) information. This allows 47 monitoring of end devices such as IP phones, pagers, Instant 48 Messaging clients, mobile phones, and various other hand-held 49 computing devices. This model fits into the Remote Monitoring (RMON) 50 family of specifications. 52 This memo specifies how the Simple Network Management Protocol (SNMP) 53 is used to transport RAQMON PDUs between a RAQMON Data Source (RDS) 54 and a RAQMON Report Collector (RRC). 56 Distribution of this memo is unlimited. 58 Table of Contents 60 Status of this Memo..................................................1 61 Abstract.............................................................1 62 1 Introduction.......................................................3 63 2 Transporting RAQMON Protocol Data Units............................3 64 3 Congestion Safe RAQMON Operation..................................16 65 4 Normative References..............................................17 66 5 Informative References............................................17 67 6 Intellectual Property.............................................18 68 7 Security Considerations...........................................18 69 8 Authors' Addresses................................................20 70 Full Copyright Statement............................................21 72 1. Introduction 74 There is a need to add mechanisms within RMON [RFC2819] family of 75 specifications to monitor end devices such as IP phones, pagers, 76 Instant Messaging clients, mobile phones, and various other hand-held 77 computing devices. The Real-Time Application QoS Monitoring (RAQMON) 78 Framework as outlined by [RAQMON-FRAMEWORK] extends RMON by defining 79 entities such as RAQMON Data Source (RDS) and RAQMON Report Collector 80 (RRC) to perform various application monitoring in real time. 81 [RAQMON-FRAMEWORK] defines an informational model in the format of a 82 common protocol data unit (PDU) used between a RDS and RRC to report 83 QoS statistics. This memo contains a syntactical description of the 84 RAQMON PDU structure and of the usage of SNMP as underlying transport 85 protocol to carry RAQMON PDUs between RDSs and RRCs. 87 The RAQMON Protocol Data Unit (PDU) utilizes a common data format 88 understood by the RDS and the RRC. A RAQMON PDU does not transport 89 application data but rather occupies the place of a payload 90 specification at the application layer of the protocol stack. 91 Mechanisms outlined in this draft can be used by many real-time and 92 non-real-time applications managed within the RMON family of 93 specifications which allows network appliances to report application 94 level QoS parameters in real time. Voice over IP, Fax over IP, Video 95 over IP, Instant Messaging (IM), Email, software download 96 applications, e-business style transactions, web access from 97 computing devices are a few examples of applications that can 98 potentially use the RAQMON Framework for monitoring purposes. 100 The following sections of this memo contain detailed specifications 101 of the usage of SNMP to carry RAQMON PDUs. 103 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 104 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 105 document are to be interpreted as described in [RFC2119]. 107 2. Transporting RAQMON Protocol Data Units 109 It is an inherent objective of the RAQMON Framework to re-use 110 existing application level transport protocols to maximize the usage 111 of existing installations as well as to avoid transport protocol 112 level complexities in the design process. A RAQMON PDU does not 113 transport application data but rather occupies the place of a payload 114 specification at the application layer of the protocol stack. As 115 outlined in [RAQMON-FRAMEWORK] both the Simple Network Management 116 Protocol (SNMP) MUST be used as a transport protocol, while other 117 transport protocols meeting the transport requirements MAY also be 118 used. 120 2.1 SNMP INFORM PDUs as an RDS/RRC Network Transport Protocol 122 If SNMP is chosen as a mechanism to transport RAQMON PDUs, the 123 following specification applies: 125 + RDSs implement the capability of embedding RAQMON parameters in 126 SNMP INFORM Requests, re-using well known SNMP mechanisms to 127 report RAQMON Statistics. The RAQMON RDS MIB module as 128 specified in 2.1.1 MUST be used in order to map the RAQMON PDUs 129 onto the SNMP Notifications transport. 131 Managed objects are accessed via a virtual information store, termed 132 the Management Information Base or MIB. MIB objects are generally 133 accessed through the Simple Network Management Protocol (SNMP). 134 Objects in the MIB are defined using the mechanisms defined in the 135 Structure of Management Information (SMI). For a detailed overview 136 of the documents that describe the current Internet-Standard 137 Management Framework, please refer to section 7 of RFC 3410 138 [RFC3410]. 140 + Since RDSs are not computationally rich and to keep the RDS 141 realization as lightweight as possible, RDSs MAY fail to 142 respond to SNMP requests like GET, SET, etc., with the 143 exception of the GET and SET commands required to implement the 144 User-Based Security Model (USM) defined by [RFC 3414]. 146 + In order to meet congestion safety requirements, RDSs MUST 147 process the SNMP INFORM responses from RRCs, and MAY serialize 148 the PDU transmission rate, i.e. limit the number of PDUS sent 149 in a specific time tinterval. 151 + Standard UDP port 162 SHOULD be used for SNMP Notifications. 153 2.1.1 Encoding RAQMON PDUs using the RAQMON RDS MIB module 155 The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP 156 Notifications for transport purposes. The MIB modules defines the 157 objects needed for mapping the Basic part of RAQMON PDU defined in 158 [RAQMON-FRAMEWOK] as well as the Notifications themselves. In order 159 to incorporate any application-specific extensions in the Application 160 (APP) part of RAQMON PDU as defined in [RAQMON-FRAMEWOK], additional 161 variable bindings MAY be included in RAQMON notifications as 162 described in the MIB module. 164 This section specifies a MIB module that is compliant to the SMIv2, 165 which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 166 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 168 RAQMON-RDS-MIB DEFINITIONS ::= BEGIN 170 IMPORTS 171 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 172 Counter32, Integer32, Unsigned32 173 FROM SNMPv2-SMI 175 DateAndTime 176 FROM SNMPv2-TC 178 rmon 179 FROM RMON-MIB 181 SnmpAdminString 182 FROM SNMP-FRAMEWORK-MIB 184 InetAddressType, InetAddress 185 FROM INET-ADDRESS-MIB 187 Dscp 188 FROM DIFFSERV-DSCP-TC 190 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 191 FROM SNMPv2-CONF; 193 raqmonDs MODULE-IDENTITY 194 LAST-UPDATED "200406150000Z" -- June 15. 2004 195 ORGANIZATION "RMON Working Group" 196 CONTACT-INFO 197 "WG EMail: rmonmib@ietf.org 198 Subscribe: rmonmib-request@ietf.org 200 MIB Editor: 201 Eugene Golovinsky 202 Postal: BMC Software, Inc. 203 2101 CityWest Boulevard, 204 Houston, TX, 77094 205 USA 206 Tel: +713-918-1816 207 Email: egolovin@bmc.com 208 " 209 DESCRIPTION 210 "This is the RAQMON Data Source notification MIB Module. It 211 provides a mapping of RAQMON PDUs to SNMP Notifications. 213 Ds stands for data source. 215 Note that all of the object types defined in this module are 216 accessible-for-notify, and would consequently not be 217 available to a browser using simple Get, GetNext, or GetBulk 218 requests. 220 Copyright (c) The Internet Society (2004). 222 -- RFC EDITOR: please replace yyyy with actual number 223 This version of this MIB module is part of RFC yyyy; See the 224 RFC itself for full legal notices. 225 " 227 REVISION "200406150000Z" -- June 15, 2004 228 DESCRIPTION 229 "Changes after the 59th IETF." 231 REVISION "200311111150Z" -- November 11, 2003 232 DESCRIPTION 233 "Changes after the 58th IETF." 235 ::= { rmon 32 } 237 raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDs 0 } 238 raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDs 1 } 239 raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDs 2 } 241 raqmonDsNotificationTable OBJECT-TYPE 242 SYNTAX SEQUENCE OF RaqmonDsNotificationEntry 243 MAX-ACCESS not-accessible 244 STATUS current 245 DESCRIPTION 246 "This conceptual table provides the SNMP mapping of the 247 RAQMON Basic PDU. It is indexed by the RAQMON Data Source, 248 sub-session, and address of the peer entity. 250 Note that there is no concern about the indexation of this 251 table exceeding the limits defined by RFC 2578 Section 3.5. 252 According to [RAQMON-FRAMEWORK], Section 5.1, only IPv4 and 253 IPv6 addresses can be reported as participant addresses. 254 " 255 ::= { raqmonDsMIBObjects 1 } 257 raqmonDsNotificationEntry OBJECT-TYPE 258 SYNTAX RaqmonDsNotificationEntry 259 MAX-ACCESS not-accessible 260 STATUS current 261 DESCRIPTION 262 "The entry (row) is not retrievable and is not kept by RDSs. 264 It serves data organization purpose only. 265 " 266 INDEX { raqmonDSRC, raqmonRCN, raqmonPeerAddrType, 267 raqmonPeerAddr } 268 ::= { raqmonDsNotificationTable 1 } 270 RaqmonDsNotificationEntry ::= SEQUENCE { 271 raqmonDSRC Unsigned32, 272 raqmonRCN Integer32, 273 raqmonPeerAddrType InetAddressType, 274 raqmonPeerAddr InetAddress, 275 raqmonAppName SnmpAdminString, 276 raqmonDataSourceDevicePort Unsigned32, 277 raqmonReceiverDevicePort Unsigned32, 278 raqmonSessionSetupDateTime DateAndTime, 279 raqmonSessionSetupDelay Unsigned32, 280 raqmonSessionDuration Unsigned32, 281 raqmonSessionSetupStatus SnmpAdminString, 282 raqmonRoundTripEndtoEndDelay Unsigned32, 283 raqmonOneWayEndtoEndDelay Unsigned32, 284 raqmonJitterType INTEGER, 285 raqmonJitterValue Unsigned32, 286 raqmonTotalPacketsReceived Counter32, 287 raqmonTotalPacketsSent Counter32, 288 raqmonTotalOctetsReceived Counter32, 289 raqmonTotalOctetsSent Counter32, 290 raqmonCumulativePacketLoss Counter32, 291 raqmonPacketLossFraction Unsigned32, 292 raqmonSourcePayloadType Unsigned32, 293 raqmonReceiverPayloadType Unsigned32, 294 raqmonSourceLayer2Priority Unsigned32, 295 raqmonDestinationLayer2Priority Unsigned32, 296 raqmonSourceDscp Dscp, 297 raqmonDestinationDscp Dscp, 298 raqmonCpuUtilization Unsigned32, 299 raqmonMemoryUtilization Unsigned32 } 301 raqmonDSRC OBJECT-TYPE 302 SYNTAX Unsigned32 303 MAX-ACCESS accessible-for-notify 304 STATUS current 305 DESCRIPTION 306 "Data Source identifier represents a unique session 307 descriptor that points to a specific communication session 308 between communicating entities. Identifiers unique for 309 sessions conducted between two entities are 310 generated by the communicating entities." 311 ::= { raqmonDsNotificationEntry 1 } 313 raqmonRCN OBJECT-TYPE 314 SYNTAX Integer32 (0..15) 315 MAX-ACCESS accessible-for-notify 316 STATUS current 317 DESCRIPTION 318 "The Record Count Number indicates a sub-session 319 within a communication session. A maximum number of 16 320 sub-sessions are supported - this limitation is dictated 321 by reasons of compatibility with other transport protocols." 322 ::= { raqmonDsNotificationEntry 2 } 324 raqmonPeerAddrType OBJECT-TYPE 325 SYNTAX InetAddressType 326 MAX-ACCESS accessible-for-notify 327 STATUS current 328 DESCRIPTION 329 "The type of the Internet address of the peer participant 330 for this session." 331 REFERENCE 332 "Section 5.2 of [RAQMON-FRAMEWORK]" 333 ::= { raqmonDsNotificationEntry 3 } 335 raqmonPeerAddr OBJECT-TYPE 336 SYNTAX InetAddress 337 MAX-ACCESS accessible-for-notify 338 STATUS current 339 DESCRIPTION 340 "The Internet Address of the peer participant for this 341 session." 342 REFERENCE 343 "Section 5.2 of [RAQMON-FRAMEWORK]" 344 ::= { raqmonDsNotificationEntry 4 } 346 raqmonAppName OBJECT-TYPE 347 SYNTAX SnmpAdminString 348 MAX-ACCESS accessible-for-notify 349 STATUS current 350 DESCRIPTION 351 "This is a text string giving the name and possibly version 352 of the application associated with that session, 353 e.g., 'XYZ VoIP Agent 1.2'." 354 REFERENCE 355 "Section 5.28 of [RAQMON-FRAMEWORK]" 356 ::= { raqmonDsNotificationEntry 5 } 358 raqmonDataSourceDevicePort OBJECT-TYPE 359 SYNTAX Unsigned32 (0..65535) 360 MAX-ACCESS accessible-for-notify 361 STATUS current 362 DESCRIPTION 363 "The port number from which data for this session was sent 364 by the Data Source device." 365 REFERENCE 366 "Section 5.5 of [RAQMON-FRAMEWORK]" 367 ::= { raqmonDsNotificationEntry 6 } 369 raqmonReceiverDevicePort OBJECT-TYPE 370 SYNTAX Unsigned32 (0..65535) 371 MAX-ACCESS accessible-for-notify 372 STATUS current 373 DESCRIPTION 374 "The port number where the data for this session was received." 375 REFERENCE 376 "Section 5.6 of [RAQMON-FRAMEWORK]" 377 ::= { raqmonDsNotificationEntry 7 } 379 raqmonSessionSetupDateTime OBJECT-TYPE 380 SYNTAX DateAndTime 381 MAX-ACCESS accessible-for-notify 382 STATUS current 383 DESCRIPTION 384 "The time when session was initiated." 385 REFERENCE 386 "Section 5.7 of [RAQMON-FRAMEWORK]" 387 ::= { raqmonDsNotificationEntry 8 } 389 raqmonSessionSetupDelay OBJECT-TYPE 390 SYNTAX Unsigned32 391 UNITS "milliseconds" 392 MAX-ACCESS accessible-for-notify 393 STATUS current 394 DESCRIPTION 395 "Session setup time." 396 REFERENCE 397 "Section 5.8 of [RAQMON-FRAMEWORK]" 398 ::= { raqmonDsNotificationEntry 9 } 400 raqmonSessionDuration OBJECT-TYPE 401 SYNTAX Unsigned32 402 UNITS "seconds" 403 MAX-ACCESS accessible-for-notify 404 STATUS current 405 DESCRIPTION 406 "Session duration, including setup time. The SYNTAX of this 407 object allows to express the duration of sessions that do 408 not exceed 4660 hours and 20 minutes." 410 REFERENCE 411 "Section 5.9 of [RAQMON-FRAMEWORK]" 412 ::= { raqmonDsNotificationEntry 10 } 414 raqmonSessionSetupStatus OBJECT-TYPE 415 SYNTAX SnmpAdminString 416 MAX-ACCESS accessible-for-notify 417 STATUS current 418 DESCRIPTION 419 "Describes appropriate communication session states e.g. 420 Call Established successfully, RSVP reservation 421 failed etc." 422 REFERENCE 423 "Section 5.10 of [RAQMON-FRAMEWORK]" 424 ::= { raqmonDsNotificationEntry 11 } 426 raqmonRoundTripEndtoEndDelay OBJECT-TYPE 427 SYNTAX Unsigned32 428 UNITS "milliseconds" 429 MAX-ACCESS accessible-for-notify 430 STATUS current 431 DESCRIPTION 432 "Most recent available information about the 433 round trip end to end delay." 434 REFERENCE 435 "Section 5.11 of [RAQMON-FRAMEWORK]" 436 ::= { raqmonDsNotificationEntry 12} 438 raqmonOneWayEndtoEndDelay OBJECT-TYPE 439 SYNTAX Unsigned32 440 UNITS "milliseconds" 441 MAX-ACCESS accessible-for-notify 442 STATUS current 443 DESCRIPTION 444 " Most recent available information about the 445 one way end to end delay." 446 REFERENCE 447 "Section 5.12 of [RAQMON-FRAMEWORK]" 448 ::= { raqmonDsNotificationEntry 13} 450 raqmonJitterType OBJECT-TYPE 451 SYNTAX INTEGER 452 { 453 interArrival(1), 454 absolute(2) 455 } 456 MAX-ACCESS accessible-for-notify 457 STATUS current 458 DESCRIPTION 459 "The type of jitter measurement as reported by the RDS. 460 A value of interArrival(1) indicates relative jitter measurement 461 and reporting. 462 A value of absolute(2) indicates absolute jitter measurement 463 and reporting." 464 REFERENCE 465 "Section 5.13 of [RAQMON-FRAMEWORK]" 466 ::= { raqmonDsNotificationEntry 14} 468 raqmonJitterValue OBJECT-TYPE 469 SYNTAX Unsigned32 470 UNITS "milliseconds" 471 MAX-ACCESS accessible-for-notify 472 STATUS current 473 DESCRIPTION 474 "An estimate of the jitter." 475 REFERENCE 476 "Section 5.13 of [RAQMON-FRAMEWORK]" 477 ::= { raqmonDsNotificationEntry 15} 479 raqmonTotalPacketsReceived OBJECT-TYPE 480 SYNTAX Counter32 481 UNITS "packets" 482 MAX-ACCESS accessible-for-notify 483 STATUS current 484 DESCRIPTION 485 "The number of packets transmitted within a communication 486 session by the receiver since starting transmission up until 487 the time this RAQMON PDU was generated. 488 " 489 REFERENCE 490 "Section 5.14 of [RAQMON-FRAMEWORK]" 491 ::= { raqmonDsNotificationEntry 16 } 493 raqmonTotalPacketsSent OBJECT-TYPE 494 SYNTAX Counter32 495 UNITS "packets" 496 MAX-ACCESS accessible-for-notify 497 STATUS current 498 DESCRIPTION 499 "The number of packets transmitted within a communication 500 session by the sender since starting transmission up until 501 the time this RAQMON PDU was generated. 502 " 503 REFERENCE 504 "Section 5.15 of [RAQMON-FRAMEWORK]" 505 ::= { raqmonDsNotificationEntry 17 } 507 raqmonTotalOctetsReceived OBJECT-TYPE 508 SYNTAX Counter32 509 UNITS "octets" 510 MAX-ACCESS accessible-for-notify 511 STATUS current 512 DESCRIPTION 513 "The total number of payload octets (i.e., not including 514 header or padding octets) transmitted in packets by the 515 receiver within a communication session since starting 516 transmission up until the time this RAQMON PDU was 517 generated. 518 " 519 REFERENCE 520 "Section 5.16 of [RAQMON-FRAMEWORK]" 521 ::= { raqmonDsNotificationEntry 18 } 523 raqmonTotalOctetsSent OBJECT-TYPE 524 SYNTAX Counter32 525 UNITS "octets" 526 MAX-ACCESS accessible-for-notify 527 STATUS current 528 DESCRIPTION 529 "The number of payload octets (i.e., not including headers 530 or padding) transmitted in packets by the sender within 531 a communication session since starting transmission up 532 until the time this RAQMON notification was generated." 533 REFERENCE 534 "Section 5.17 of [RAQMON-FRAMEWORK]" 535 ::= { raqmonDsNotificationEntry 19 } 537 raqmonCumulativePacketLoss OBJECT-TYPE 538 SYNTAX Counter32 539 UNITS "packets" 540 MAX-ACCESS accessible-for-notify 541 STATUS current 542 DESCRIPTION 543 "The number of packets from this session whose loss had been 544 detected when this notification was generated. 545 " 546 REFERENCE 547 "Section 5.18 of [RAQMON-FRAMEWORK]" 548 ::= { raqmonDsNotificationEntry 20 } 550 raqmonPacketLossFraction OBJECT-TYPE 551 SYNTAX Unsigned32 (0..100) 552 UNITS "percentage of packets sent" 553 MAX-ACCESS accessible-for-notify 554 STATUS current 555 DESCRIPTION 556 "The percentage of lost packets with respect to the overall 557 packets sent. This is defined to be 100 times the number 558 of packets lost divided by the number of packets expected." 559 REFERENCE 560 "Section 5.19 of [RAQMON-FRAMEWORK]" 561 ::= { raqmonDsNotificationEntry 21 } 563 raqmonSourcePayloadType OBJECT-TYPE 564 SYNTAX Unsigned32 (0..127) 565 MAX-ACCESS accessible-for-notify 566 STATUS current 567 DESCRIPTION 568 "The payload type of the packet sent by this RDS." 569 REFERENCE 570 "RFC 1890, Section 5.20 of [RAQMON-FRAMEWORK] " 571 ::= { raqmonDsNotificationEntry 22 } 573 raqmonReceiverPayloadType OBJECT-TYPE 574 SYNTAX Unsigned32 (0..127) 575 MAX-ACCESS accessible-for-notify 576 STATUS current 577 DESCRIPTION 578 "The payload type of the packet received by this RDS." 579 REFERENCE 580 "RFC 1890, Section 5.21 of [RAQMON-FRAMEWORK] " 581 ::= { raqmonDsNotificationEntry 23 } 583 raqmonSourceLayer2Priority OBJECT-TYPE 584 SYNTAX Unsigned32 (0..7) 585 MAX-ACCESS accessible-for-notify 586 STATUS current 587 DESCRIPTION 588 "Source Layer 2 priority used by the sata source to send 589 packets to the receiver by this data source during this 590 communication session. 591 " 592 REFERENCE 593 "Section 5.22 of [RAQMON-FRAMEWORK]" 594 ::= { raqmonDsNotificationEntry 24 } 596 raqmonDestinationLayer2Priority OBJECT-TYPE 597 SYNTAX Unsigned32 (0..7) 598 MAX-ACCESS accessible-for-notify 599 STATUS current 600 DESCRIPTION 601 "Destination Layer 2 priority. This is the priority use by 602 the peer communicating entity to send packets to the data 603 source. 604 " 605 REFERENCE 606 "Section 5.24 of [RAQMON-FRAMEWORK]" 607 ::= { raqmonDsNotificationEntry 25 } 609 raqmonSourceDscp OBJECT-TYPE 610 SYNTAX Dscp 611 MAX-ACCESS accessible-for-notify 612 STATUS current 613 DESCRIPTION 614 "Layer 3 TOS/DSCP values used by the Data Source to 615 prioritize traffic sent." 616 REFERENCE 617 "Section 5.23 of [RAQMON-FRAMEWORK]" 618 ::= { raqmonDsNotificationEntry 26 } 620 raqmonDestinationDscp OBJECT-TYPE 621 SYNTAX Dscp 622 MAX-ACCESS accessible-for-notify 623 STATUS current 624 DESCRIPTION 625 "Layer 3 TOS/DSCP values used by the 626 peer communicating entiy to prioritize traffic 627 sent to the source." 628 REFERENCE 629 "Section 5.25 of [RAQMON-FRAMEWORK]" 630 ::= { raqmonDsNotificationEntry 27 } 632 raqmonCpuUtilization OBJECT-TYPE 633 SYNTAX Unsigned32 (0..100) 634 UNITS "percent" 635 MAX-ACCESS accessible-for-notify 636 STATUS current 637 DESCRIPTION 638 "Latest available information about the total CPU utilization." 639 REFERENCE 640 "Section 5.26 of [RAQMON-FRAMEWORK]" 641 ::= { raqmonDsNotificationEntry 28 } 643 raqmonMemoryUtilization OBJECT-TYPE 644 SYNTAX Unsigned32 (0..100) 645 UNITS "percent" 646 MAX-ACCESS accessible-for-notify 647 STATUS current 648 DESCRIPTION 649 "Latest available information about the total memory utilization." 650 REFERENCE 651 "Section 5.27 of [RAQMON-FRAMEWORK]" 652 ::= { raqmonDsNotificationEntry 29 } 654 -- definitions of the notifications 655 -- 656 -- The object lists include only the OBJECTS that will be sent by an 657 -- RD every time the notification is generated. 658 -- Other objects from the raqmonDsNotificationTable may be included 659 -- in the variable binding list. 660 -- 662 raqmonDsNotification NOTIFICATION-TYPE 663 OBJECTS { raqmonDSRC, 664 raqmonRCN, 665 raqmonPeerAddrType, 666 raqmonPeerAddr 667 } 668 STATUS current 669 DESCRIPTION 670 "This notification maps the Basic RAQMON PDU onto an SNMP 671 transport. 672 " 673 ::= { raqmonDsEvents 1 } 675 raqmonDsByeNotification NOTIFICATION-TYPE 676 OBJECTS { raqmonDSRC, 677 raqmonPeerAddrType, 678 raqmonPeerAddr 679 } 680 STATUS current 681 DESCRIPTION 682 "The BYE Notification. This Notification is the equivalent of 683 the RAQMON BYE PDU, which signals the end of a RAQMON 684 session. 685 " 686 ::= { raqmonDsEvents 2 } 688 -- 689 -- conformance information 690 -- These don't show up on the wire, so they only need to be unique. 691 -- 692 raqmonDsCompliances OBJECT IDENTIFIER ::= { raqmonDsConformance 1 } 693 raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } 695 raqmonDsBasicCompliances MODULE-COMPLIANCE 696 STATUS current 697 DESCRIPTION 698 "The compliance statement for SNMP entities which 699 implement this MIB module." 700 MODULE -- this module 701 MANDATORY-GROUPS { raqmonDsNotificationGroup, 702 raqmonDsPayloadGroup } 703 ::= { raqmonDsCompliances 1 } 705 raqmonDsNotificationGroup NOTIFICATION-GROUP 706 NOTIFICATIONS { raqmonDsNotification, 707 raqmonDsByeNotification } 708 STATUS current 709 DESCRIPTION 710 "The notifications implemented by an SNMP entity claiming 711 conformance to this MIB. 712 " 713 ::= { raqmonDsGroups 1 } 715 raqmonDsPayloadGroup OBJECT-GROUP 716 OBJECTS { raqmonDSRC, 717 raqmonRCN, 718 raqmonPeerAddrType, 719 raqmonPeerAddr, 720 raqmonAppName, 721 raqmonDataSourceDevicePort, 722 raqmonReceiverDevicePort, 723 raqmonSessionSetupDateTime, 724 raqmonSessionSetupDelay, 725 raqmonSessionDuration, 726 raqmonSessionSetupStatus, 727 raqmonRoundTripEndtoEndDelay, 728 raqmonOneWayEndtoEndDelay, 729 raqmonJitterType, 730 raqmonJitterValue, 731 raqmonTotalPacketsReceived, 732 raqmonTotalPacketsSent, 733 raqmonTotalOctetsReceived, 734 raqmonTotalOctetsSent, 735 raqmonCumulativePacketLoss, 736 raqmonPacketLossFraction, 737 raqmonSourcePayloadType, 738 raqmonReceiverPayloadType, 739 raqmonSourceLayer2Priority, 740 raqmonDestinationLayer2Priority, 741 raqmonSourceDscp, 742 raqmonDestinationDscp, 743 raqmonCpuUtilization, 744 raqmonMemoryUtilization } 745 STATUS current 746 DESCRIPTION 747 "These objects are required for entities claiming conformance 748 to this MIB." 749 ::= { raqmonDsGroups 2 } 751 END 753 3. Congestion-Safe RAQMON Operation 755 The transport of RAQMON PDUs in SNMP can be handled by any underlying 756 network transport protocols that can be used by SNMP. 758 One of the more widely deployed transport protocols for SNMP is UDP, 759 which might lead to network congestion under heavy network load. To 760 ensure congestion safety, clearly the best thing to do is to use a 761 congestion-safe transport protocol, such as TCP or DCCP. If this is 762 not feasible, it may be necessary to fall back to UDP. Implementers 763 MUST follow section 3.0 of the [RAQMON-FRAMEWORK] guidelines, which 764 outlines measures that MUST be taken to use RAQMON in a congestion- 765 safe manner, especially when using UDP. 767 4. Normative References 769 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 770 Rose, M. and S. Waldbusser, "Structure of Management 771 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 772 1999. 774 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 775 Rose, M. and S. Waldbusser, "Textual Conventions for 776 SMIv2", STD 58, RFC 2579, April 1999. 778 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 779 Rose, M. and S. Waldbusser, "Conformance Statements for 780 SMIv2", STD 58, RFC 2580, April 1999. 782 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 783 Information Base", STD 59, RFC 2819, May 2000. 785 [RAQMON-FRAMEWORK] Siddiqui, A., Romascanu, D. and E. Golovinsky, 786 "Framework for Real-time Application Quality of Service 787 Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon- 788 framework-06.txt, July 2004. 790 5. Informative References 792 [RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, 793 April 1992. 795 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 796 Requirement Levels", BCP 14, RFC 2119, March 1997. 798 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 799 "Introduction and Applicability Statements for Internet- 800 Standard Management Framework", RFC 3410, December 2002. 802 [RFC3414] Blumenthal U., and B. Weijnen, "User-based Security Model 803 (USM) for version 3 of the Simple Network Management 804 Protocol (SNMPv3)", RFC 3414, December 2002. 806 [3DES] American National Standards Institute, ANSI X9.52-1998, 807 "Triple Data Encryption Algorithm Modes of Operation" 808 1998. 810 [AES] Federal Information Processing Standard (FIPS), 811 "Specification for the ADVANCED ENCRYPTION 812 STANDARD(AES)", Publication 197, November 2001. 814 6. Intellectual Property 816 The IETF takes no position regarding the validity or scope of any 817 intellectual property or other rights that might be claimed to 818 pertain to the implementation or use of the technology described in 819 this document or the extent to which any license under such rights 820 might or might not be available; neither does it represent that it 821 has made any effort to identify any such rights. Information on the 822 IETF's procedures with respect to rights in standards-track and 823 standards-related documentation can be found in BCP-11. Copies of 824 claims of rights made available for publication and any assurances of 825 licenses to be made available, or the result of an attempt made to 826 obtain a general license or permission for the use of such 827 proprietary rights by implementors or users of this specification can 828 be obtained from the IETF Secretariat. 830 The IETF invites any interested party to bring to its attention any 831 copyrights, patents or patent applications, or other proprietary 832 rights which may cover technology that may be required to practice 833 this standard. Please address the information to the IETF Executive 834 Director. 836 By submitting this Internet-Draft, we certify that any applicable 837 patent or other IPR claims of which we are aware have been disclosed, 838 and any of which we become aware will be disclosed, in accordance 839 with RFC 3668. 841 7. Security Considerations 843 [RAQMON-FRAMEWORK] outlines a threat model associated with RAQMON and 844 security considerations to be taken into account in the RAQMON 845 specification to mitigate against those threats. It is imperative 846 that RAQMON PDU implementations be able to provide the following 847 protection mechanisms in order to attain end-to-end security: 849 1. Authentication - the RRC SHOULD be able to verify that a RAQMON 850 report was originated by the RDS claiming to have sent it. At 851 minimum, an RDS/RRC pair MUST use a digest-based authentication 852 procedure to authenticate, like the one defined in [RFC 1321]. 854 2. Privacy - RAQMON information includes identification of the 855 parties participating in a communication session. RAQMON 856 deployments SHOULD be able to provide protection from 857 eavesdropping, and to prevent an unauthorized third party from 858 gathering potentially sensitive information. This can be achieved 859 by using payload encryption technologies such as DES (Data 860 Encryption Standard), 3-DES [3DES], and AES (Advanced Encryption 861 Standard) [AES]. 863 3. Protection from Denial of Service attacks directed at the RRC - 864 RDSs send RAQMON reports as a side effect of external events (for 865 example, receipt of a phone call). An attacker can try to 866 overwhelm the RRC (or the network) by initiating a large number of 867 events in order to swamp the RRC with excessive numbers of RAQMON 868 PDUs. 870 To prevent DoS (denial-of-service) attacks against the RRC, the 871 RDS will send the first report for a session only after the 872 session has been established, so that the session set-up process 873 is not affected. 875 4. NAT and Firewall Friendly Design: the presence of IP addresses and 876 TCP/UDP port information in RAQMON PDUs may be NAT unfriendly. 877 Where NAT-friendliness is a requirement, the RDS MAY omit IP 878 address information from the RAQMON PDU. Another way to avoid 879 this problem is by using NAT-Aware Application Layer Gateways 880 (ALGs) to ensure that correct IP addresses appear in RAQMON PDUs. 882 This memo also defines an RDS SNMP MIB module with the purpose of 883 mapping the RAQMON PDUs into SNMP Notifications. To attain end-to- 884 end security the following measures have been taken in RDS MIB module 885 design: 887 There are no management objects defined in this MIB module that have 888 a MAX-ACCESS clause of read-write and/or read-create. Consequently, 889 if this MIB module is implemented correctly, there is no risk that an 890 intruder can alter or create any management objects of this MIB 891 module via direct SNMP SET operations. 893 Some of the readable objects in this MIB module (i.e., objects with a 894 MAX-ACCESS other than not-accessible) may be considered sensitive or 895 vulnerable in some network environments. It is thus important to 896 control even GET and/or NOTIFY access to these objects and possibly 897 to even encrypt the values of these objects when sending them over 898 the network via SNMP. These are the tables and objects and their 899 sensitivity/vulnerability: 901 raqmonDsNotificationTable 903 The objects in this table contain user session information, and their 904 disclosure may be sensitive in some environments. 906 SNMP versions prior to SNMPv3 did not include adequate security. 907 Even if the network itself is secure (for example by using IPSec), 908 even then, there is no control as to who on the secure network is 909 allowed to access and GET/SET (read/change/create/delete) the objects 910 in this MIB module. 912 It is RECOMMENDED that implementers consider the security features as 913 provided by the SNMPv3 framework (see [RFC3410], section 8), 914 including full support for the SNMPv3 cryptographic mechanisms (for 915 authentication and privacy). 917 It is a customer/operator responsibility to ensure that the SNMP 918 entity giving access to an instance of this MIB module is properly 919 configured to give access to the objects only to those principals 920 (users) that have legitimate rights to indeed GET or SET 921 (change/create/delete) them. 923 8. Authors' Addresses 925 Anwar A. Siddiqui 926 Avaya Labs 927 307 Middletown Lincroft Road 928 Lincroft, New Jersey 07738 929 USA 930 Tel: +1 732 852-3200 931 E-mail: anwars@avaya.com 933 Dan Romascanu 934 Avaya 935 Atidim Technology Park, Bldg. #3 936 Tel Aviv, 61131 937 Israel 938 Tel: +972-3-645-8414 939 Email: dromasca@avaya.com 941 Eugene Golovinsky 942 BMC Software 943 2101 CityWest Blvd. 944 Houston, Texas 77042 945 USA 946 Tel: +1 713 918-1816 947 Email: eugene_golovinsky@bmc.com 949 A. Full Copyright Statement 951 Copyright (C) The Internet Society (2004). This document is subject 952 to the rights, licenses and restrictions contained in BCP 78, and 953 except as set forth therein, the authors retain all their rights. 955 This document and the information contained herein are provided on an 956 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 957 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 958 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 959 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 960 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 961 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE." 963 Intellectual Property 965 The IETF takes no position regarding the validity or scope of any 966 intellectual property or other rights that might be claimed to 967 pertain to the implementation or use of the technology described in 968 this document or the extent to which any license under such rights 969 might or might not be available; neither does it represent that it 970 has made any effort to identify any such rights. Information on the 971 IETF's procedures with respect to rights in standards-track and 972 standards-related documentation can be found in BCP-11. 974 Copies of IPR disclosures made to the IETF secretariat and any 975 assurances of licenses to be made available, or the result of an 976 attempt made to obtain a general license or permission for the use of 977 such proprietary rights by implementors or users of this 978 specification can be obtained from the IETF on-line repository at 979 http://www.ietf.org/ipr. The IETF invites any interested party to 980 bring to its attention any copyrights, patents or patent 981 applications, or other proprietary rights which may cover technology 982 that may be required to practice this standard. Please address the 983 information to the IETF at ietf-ipr@ietf.org. 985 Acknowledgement: 987 Funding for the RFC Editor function is currently provided by the 988 Internet Society.