idnits 2.17.1 draft-ietf-rmonmib-raqmon-pdu-12.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 22. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1702. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1713. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1720. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1726. ** 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 37 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 38 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The abstract seems to contain references ([RAQMON-FRAMEWORK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. 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 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 (23 January 2006) is 6668 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: 'RFC3727' is mentioned on line 632, but not defined == Missing Reference: 'RAQMON-FRAMEWOK' is mentioned on line 696, but not defined == Unused Reference: 'IEEE802.1D' is defined on line 1499, but no explicit reference was found in the text ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) -- No information found for draft-ietf-raqmon-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RAQMON-FRAMEWORK' -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 5 errors (**), 0 flaws (~~), 7 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-pdu-12.txt Avaya Labs. 4 Category: Standards Track Dan Romascanu 5 Expires July 2006 Avaya Inc 6 Mahfuzur Rahman 7 Panasonic 8 Eugene Golovinsky 9 BMC Software 10 Yong Kim 11 Broadcom 12 23 January 2006 14 Transport Mappings for Real-time Application Quality of Service 15 Monitoring (RAQMON) Protocol Data Unit (PDU) 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress". 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Abstract 42 This memo specifies two transport mappings of the Real-time 43 Application Quality of Service Monitoring (RAQMON) information model 44 defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the 45 Simple Network Management Protocol (SNMP) to carry the RAQMON 46 information from a RAQMON Data Source (RDS) to a RAQMON Report 47 Collector (RRC). 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 Transporting RAQMON Protocol Data Units...........................3 57 3 Congestion Safe RAQMON Operation.................................31 58 4 Normative References.............................................31 59 5 Informative References...........................................32 60 6 Acknowledgements.................................................33 61 7 Security Considerations..........................................33 62 8 Authors' Addresses...............................................35 63 A Appendix.........................................................36 64 B Full Copyright Statement.........................................37 66 1. Introduction 68 The Real-Time Application QoS Monitoring (RAQMON) Framework as 69 outlined by [RAQMON-FRAMEWORK] extends the Remote Monitoring family 70 of protocols (RMON) by defining entities such as RAQMON Data Sources 71 (RDS) and RAQMON Report Collectors (RRC) to perform various 72 application monitoring in real time. [RAQMON-FRAMEWORK] defines the 73 relevant metrics for RAQMON monitoring carried by the common protocol 74 data unit (PDU) used between a RDS and RRC to report QoS statistics. 75 This memo contains a syntactical description of the RAQMON PDU 76 structure. 78 The following sections of this memo contain detailed specifications 79 for the usage of TCP and SNMP to carry RAQMON information. 81 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 82 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 83 document are to be interpreted as described in [RFC2119]. 85 2. Transporting RAQMON Protocol Data Units 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. As 91 part of the specification, this memo also specifies the usage of TCP 92 and SNMP as underlying transport protocols to carry RAQMON PDUs 93 between RDSs and RRCs. While two transport protocol choices have been 94 provided as options to chose from for RDS implementers, RRCs MUST 95 implement the TCP transport and MAY implement the SNMP transport. 97 2.1 TCP as an RDS/RRC Network Transport Protocol 99 A transport binding using TCP is included within the RAQMON 100 specification to facilitate reporting from various types of embedded 101 devices that run applications such as Voice over IP, Voice over Wi- 102 Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail, 103 software download applications, e-business style transactions, web 104 access from wired or wireless computing devices etc. For many of 105 these devices PDUs and a TCP-based transport fit the deployment 106 needs. 108 The RAQMON transport requirements for end-to-end congestion control 109 and reliability are inherently built into TCP as a transport protocol 110 [RFC793]. 112 The following section details the RAQMON PDU specifications. Though 113 transmitted as one Protocol Data Unit, a RAQMON PDU is functionally 114 divided into two different parts, namely the basic part and 115 application extensions required for vendor specific extension 116 [RAQMON-FRAMEWORK]. Both functional parts trail a field carrying a 117 SMI Network Management Private Enterprise code currently maintained 118 by IANA http://www.iana.org/assignments/enterprise-numbers, which is 119 used to identify the organization that defined the information 120 carried in the PDU. 122 A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1. 123 The parameters carried by RAQMON PDUs are shown in figure 1 and are 124 defined in section 5 of [RAQMON-FRAMEWORK]. 126 Vendors MUST use the Basic part of the PDU to report parameters pre- 127 listed here in the specification for interoperability as opposed to 128 using the application specific portion. Vendors MAY also use 129 application specific extensios to convey application, vendor, or 130 device specific parameters not included in the Basic part of the 131 specification, and explicitly publish such data externally to attain 132 extended interoperability. 134 2.1.1 The RAQMON PDU 136 0 1 2 3 137 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |PDT = 1 |B| T |P|S|R| RC | Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | DSRC | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | SMI Enterprise Code = 0 |Report Type = 0| RC_N | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | Data Source Address {DA} | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | Receiver's Address (RA) | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | NTP Timestamp, most significant word | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 | NTP Timestamp, least significant word | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Length | Application Name (AN) ... | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 | ... | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Length | Data Source Name (DN) ... | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | ... | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Length | Receiver's Name (RN) ... | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | ... | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Length | Session State ... | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | ... | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Session Duration | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Round Trip End-to-End Network Delay | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | One Way End-to-End Network Delay | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Cumulative Packet Loss | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Cumulative Application Packet Discard | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Total # Application Packets sent | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Total # Application Packets received | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Total # Application Octets sent | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Total # Application Octets received | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Data Source Device Port Used | Receiver Device Port Used | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 |Source Payload |Receiver | CPU | Memory | 194 |Type |Payload Type | Utilization | Utilization | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | Session Setup Delay | Application Delay | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | IP Packet Delay Variation | Inter arrival Jitter | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Packet Discrd | Packet loss | Padding | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | SMI Enterprise Code = "xxx" | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Report Type = "yyy" | Length of Application Part | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | application/vendor specific extension | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | ............... | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | ............... | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 | ............... | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | SMI Enterprise Code = "abc" | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Report Type = "zzz" | Length of Application Part | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | application/vendor specific extension | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | ............... | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 Figure 1 - RAQMON Protocol Data Unit 225 2.1.2 The Basic Part of the RAQMON Protocol Data Unit 227 A RAQMON PDU must contain the following basic part fields at all 228 times: 230 PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being 231 sent. PDT = 1 is used for the current RAQMON PDU version defined in 232 this document. 234 basic (B): 1 bit - While set to 1, the basic flag indicates that the 235 PDU has basic part of the RAQMON PDU. A value of zero is considered 236 to be valid and indicates a RAQMON NULL PDU. 238 trailer (T) : 3 bits - Total number of Application Specific 239 Extensions that trail the BASIC Part of RAQMON PDU. A value of zero 240 is considered to be valid as it may constitute a RAQMON NULL PDU. 242 padding (P): 1 bit - If the padding bit is set, the basic Part of the 243 RAQMON PDU contains some additional padding octets at the end of the 244 Basic Part of the PDU which are not part of the monitoring 245 information. Padding may be needed in some cases as reporting is 246 based on the intent of a RDS to report certain parameters. Also some 247 parameters may be reported only once at the beginning of the 248 reporting session e.g. Data Source Name, Receiver Name, Pay Load type 249 etc. Actual padding at the end of the Basic part of the PDU, is 250 either 0,8, 16 or 24 bits to make the basic part of the PDU multiple 251 of 32 bits long. 253 Source IP version Flag (S): 1 bit - While set to 1, the source IP 254 version flag indicates that the Source IP address contained in the 255 PDU is a IPv6 address. 257 Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP 258 version flag indicates that the receiver IP address contained in the 259 PDU is a IPv6 address. 261 record count (RC): 4 bits - Total number of application records 262 contained in the Basic part of the PDU. A value of zero is considered 263 to be valid but Useless, with the exception of the case of a NULL PDU 264 indicating the end of a RDS reporting session. 266 length: 16 bits (unsigned integer) - The length of the Basic Part of 267 the RAQMON PDU in units of 32-bit words minus one, count which 268 includes the header and any padding. 270 DSRC: 32 bits - Data Source identifier represents a unique RAQMON 271 reporting session descriptor that points to a specific reporting 272 session between RDS and RRC. Uniqueness of DSRC is valid only within 273 a reporting session. DSRC values should be randomly generated using 274 vendor chosen algorithms for each communication session. It is not 275 sufficient to obtain a DSRC simply by calling random() without 276 carefully initializing the state. One could use an algorithm like 277 the one defined in Appendix A.6 in [RFC3550] to create a DSRC. 278 Depending on the choice of algorithm, there is a finite probability 279 that two DSRCS from two different RDSs may be the same. To further 280 reduce the probability that two RDSs pick the same DSRC for two 281 different reporting session, it is recommended that an RRC use 282 parameters like Data Source Address (DA), Data Source Name (DN), 283 layer 2 Media Access Control (MAC) Address in the PDU in conjunction 284 with a DSRC value. It is not mandatory for RDSs to send parameters 285 like Data Source Address (DA), Data Source Name (DN), MAC Address in 286 every PDU sent to RRC, but sending these parameters occasionally will 287 reduce the probability of DSRC collision drastically. However this 288 will cause an additional overhead per PDU. 290 A value of zero for basic (B) bit and trailer (T) bits set 291 constitutes a RAQMON NULL PDU (i.e. nothing to report). RDSs MUST 292 send a RAQMON NULL PDU to RRC to indicate end of RDS reporting 293 session. A NULL PDU ends with the DSRC field. 295 SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is 296 used to indicate RMON WG compliant Basic part of the RAQMON PDU 297 format. 299 Report Type: 8 bits - These bits are reserved by the IETF RMON Work 300 Group. A value of 0 within SMI Enterprise Code = 0 is used for the 301 version of the PDU defined by this document. 303 The basic part of each RAQMON PDU consists of Record Count Number 304 (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the 305 presence of appropriate RAQMON parameters within a record, as defined 306 in table 1. 308 RC_N: 8 bits - The Record Count number indicates a sub-session within 309 a communication session. A value of zero is a valid record number. 310 The maximum number of records that can be described in one RAQMON 311 Packet is 256. 313 RAQMON Parameter Presence Flags (RPPF): 32 bits 315 Each of these flags while set represent that this RAQMON PDU contains 316 corresponding parameters as specified in table 1. 318 Bit Sequence Number Presence/Absence of corresponding 319 Parameter within this RAQMON PDU 321 0 Data Source Address (DA) 322 1 Receiver Address (RA) 323 2 NTP Timestamp 324 3 Application Name 325 4 Data Source Name (DN) 326 5 Receiver Name (RN) 327 6 Session Setup Status 328 7 Session Duration 329 8 Round Trip End-to-End Net Delay (RTT) 330 9 One Way End-to-End Network Delay (OWD) 331 10 Cumulative Packets Loss 332 11 Cumulative Packets Discards 333 12 Total number of App Packets sent 334 13 Total number of App Packets received 335 14 Total number of App Octets sent 336 15 Total number of App Octets received 337 16 Data Source Device Port Used 338 17 Receiver Device Port Used 339 18 Source Layer 2 Priority 340 19 Source Layer 3 Priority 341 20 Destination Layer 2 Priority 342 21 Destination Layer 3 Priority 343 22 Source Payload Type 344 23 Receiver Payload Type 345 24 CPU Utilization 346 25 Memory Utilization 347 26 Session Setup Delay 348 27 Application Delay 349 28 IP Packet Delay Variation 350 29 Inter arrival Jitter 351 30 Packet loss (in fraction) 352 31 Packet Discard (in fraction) 354 Table 1: RAQMON Parameters and corresponding RPPF 356 Data Source Address (DA): 32 bits or 160 bits in binary 357 representation - This parameter is defined in section 5.1 of [RAQMON- 358 FRAMEWORK]. IP version 6 addresses are incorporated in Data Source 359 Address by setting the source IP version flag (S bit) of the RAQMON 360 PDU header to 1. 362 Receiver Address (RA): 32 bits or 160 bits This parameter is defined 363 in section 5.2 of [RAQMON-FRAMEWORK]. Follows exact same syntax as 364 Data Source Address but used to indicate a Receiver Address. IP 365 version 6 addresses are incorporated in Receiver Address by setting 366 the receiver IP version flag (R bit) of the RAQMON PDU header to 1. 368 Data Source Name (DN): - defined in section 5.3 of [RAQMON- 369 FRAMEWORK]. The Data Source Name field starts with an 8-bit octet 370 count describing the length of the text followed by the text itself. 371 Padding is being used to ensure that the length and text encoding 372 occupy a multiple of 32 bit in the DN field of the PDU. The text MUST 373 NOT be longer than 255 octets. The text is encoded according to the 374 UTF-8 encoding specified in [RFC3629]. Applications SHOULD instruct 375 RDSs to send out the Data Source Name infrequently to ensure 376 efficient usage of network resources as this parameter is expected to 377 remain constant for the duration of the reporting session. 379 Receiver Name (RN): - This metric is defined in section 5.4 of 380 [RAQMON-FRAMEWORK]. Like Data Source Name, the Receiver Name field 381 starts with an 8-bit octet count describing the length of the text 382 followed by the text itself. The Receiver Name including the length 383 field encoding is a multiple of 32 bits and follows the same padding 384 rules as applied to the Data Source Name. Since the Receiver Name is 385 expected to remain constant during entire reporting sessions, this 386 information SHOULD be sent out occasionally over random time 387 intervals to maximize success of reaching a RRC and also conserve 388 network bandwidth. 390 Data Source Device Port Used: 16 bits - This parameter is defined in 391 section 5.5 of [RAQMON-FRAMEWORK]and describes the port Number used 392 by the Data Source as used by the application in RC_N session while 393 this RAQMON PDU was generated. 395 Receiver Device Port Used: 16 bits - This parameter is defined in 396 section 5.6 of [RAQMON-FRAMEWORK], and describes the receiver port 397 used by the application to communicate to the receiver. It follows 398 same syntax as Source Device Port Used. 400 Session Setup Date/Time (NTP timestamp): 64 bits - This parameter is 401 defined in section 5.7 of [RAQMON-FRAMEWORK] represented using the 402 timestamp format of the Network Time Protocol (NTP), which is in 403 seconds [RFC1305]. The full resolution NTP timestamp is a 64-bit 404 unsigned fixed-point number with the integer part in the first 32 405 bits and the fractional part in the last 32 bits. 407 A Data Source that does not support NTP SHOULD set the appropriate 408 RAQMON flag to 0 to avoid wasting 64 bits in the PDU. Since the NTP 409 time stamp is intended to provide the setup Date/Time of a session, 410 it is RECOMMENDED that the NTP Timestamp be used only in the first 411 RAQMON PDU after sub-session RC_N setup is completed, in order to use 412 network resources efficiently. 414 Session Setup Delay: 16 bits - The Session (sub-session) Setup Delay 415 metric is defined in section 5.8 of [RAQMON-FRAMEWORK] and expressed 416 in milliseconds. 418 Session Duration: 32 bits - The Session (sub-session) Duration metric 419 is defined in section 5.9 of [RAQMON-FRAMEWORK]. Session Duration is 420 an unsigned integer expressed in seconds. 422 Session Setup Status: - The Session (sub-session) Setup Status is 423 defined in section 5.10 of [RAQMON-FRAMEWORK]. This field starts with 424 an 8-bit length field followed by the text itself. Session Setup 425 Status is a multiple of 32 bits. 427 Round Trip End-to-End Network Delay: 32 bits - The Round Trip End-to- 428 End Network Delay is defined in section 5.11 of [RAQMON-FRAMEWORK]. 429 This field represents the Round Trip End-to-End Delay of sub-session 430 RC_N, which is an unsigned integer, expressed in milliseconds. 432 One Way End-to-End Network Delay: 32 bits - The One Way End-to-End 433 Network Delay is defined in section 5.12 of [RAQMON-FRAMEWORK]. This 434 field represents the One Way End-to-End Delay of sub-session RC_N, 435 which is an unsigned integer, expressed in milliseconds. 437 Application Delay: 16 bits - The Application Delay is defined in 438 section 5.13 of [RAQMON-FRAMEWORK] and is represented as an unsigned 439 integer expressed in milliseconds 441 Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined 442 in section 5.14 of [RAQMON-FRAMEWORK] and is represented as an 443 unsigned integer expressed in milliseconds. 445 IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is 446 defined in section 5.15 of [RAQMON-FRAMEWORK] and is represented as 447 an unsigned integer expressed in milliseconds. 449 Total number of Application Packets received: 32 bits - This 450 parameter is defined in section 5.16 of [RAQMON-FRAMEWORK] and is 451 represented as an unsigned integer, representing the total number of 452 packets transmitted within sub-session RC_N by the receiver. 454 Total number of Application Packets sent: 32 bits - This parameter is 455 defined in section 5.17 of [RAQMON-FRAMEWORK] as an unsigned integer, 456 representing the total number of packets transmitted within sub- 457 session RC_N by the sender. 459 Total number of Application Octets received: 32 bits - This parameter 460 is defined in section 5.18 of [RAQMON-FRAMEWORK] as an unsigned 461 integer representing the total number of payload octets (i.e., not 462 including header or padding) transmitted in packets by the receiver 463 within sub-session RC_N. 465 Total number of Application Octets sent: 32 bits - This parameter is 466 defined in section 5.19 of [RAQMON-FRAMEWORK] as an unsigned integer, 467 representing the total number of payload octets (i.e., not including 468 header or padding) transmitted in packets by the sender within sub- 469 session RC_N. 471 Cumulative Application Packet Loss: 32 bits - This parameter is 472 defined in section 5.20 of [RAQMON-FRAMEWORK] as an unsigned integer, 473 representing the total number of packets from sub-session RC_N that 474 have been lost while this RAQMON PDU was generated. 476 Packet Loss in Fraction: 8 bits - This parameter is defined in 477 section 5.21 of [RAQMON-FRAMEWORK] expressed as a fixed-point number, 478 with the binary point at the left edge of the field. The metric is 479 defined to be the number of packets lost divided by the number of 480 packets expected. The value is calculated by dividing the total 481 number of packets lost (after the effects of applying any error 482 protection such as FEC) by the total number of packets expected, 483 multiplying the result of the division by 256, limiting the maximum 484 value to 255 (to avoid overflow), and taking the integer part. 486 Cumulative Application Discards: 32 bits - This parameter is defined 487 in section 5.22 of [RAQMON-FRAMEWORK] as an unsigned integer 488 representing the total number of packets from sub-session RC_N that 489 have been discarded while this RAQMON PDU was generated. 491 Packet Discard in Fraction: 8 bits - This parameter is defined in 492 section 5.23 of [RAQMON-FRAMEWORK] expressed as a fixed point number 493 with the binary point at the left edge of the field. (That is 494 equivalent to taking the integer part after multiplying the discard 495 fraction by 256.) This metric is defined to be the number of packets 496 discarded divided by the total number of packets. 498 Source Payload Type: 8 bit - This parameter is defined in section 499 5.24 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the 500 payload type of the data source of the communication sub-session RC_N 501 as defined in [RFC3551]. 503 Receiver Payload Type: 8 bit - This parameter is defined in section 504 5.25 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the 505 receiver payload type of the communication sub-session RC_N as 506 defined in [RFC3551]. 508 S_Layer2: 8 bits - This parameter defined in section 5.26 of [RAQMON- 509 FRAMEWORK] is a 8-bit field associated to source's IEEE 802.1D 510 priority tagging of traffic in the communication sub-session RC_N. 511 Since IEEE 802.1 priority tags are 3 bits-long, the first 3 bits of 512 this parameter represent the IEEE 802.1 tag value and the last 5 bits 513 are padded to 0. 515 S_Layer3: 8 bits - This parameter defined in section 5.27 of [RAQMON- 516 FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking 517 used to send packets to the receiver by this data source during sub- 518 session RC_N. 520 D_Layer2: 8 bits - This parameter defined in section 5.28 of [RAQMON- 521 FRAMEWORK] is a 8-bit field which represents layer 2 IEEE 802.1D 522 priority tags used by the receiver to send packets to the data source 523 during sub-session RC_N session if the Data Source can learn such 524 information. Since IEEE 802.1 priority tags are 3 bits-long, the 525 first 3 bits of this parameter represent the IEEE 802.1 priority tag 526 value and the last 5 bits are padded to 0. 528 D_Layer3: 8 bits - This parameter defined in section 5.29 of [RAQMON- 529 FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking 530 used by the receiver to send packets to the data source during sub- 531 session RC_N, if the Data Source can learn such information. 533 CPU Utilization: 8 bits - This parameter defined in section 5.30 of 534 [RAQMON-FRAMEWORK] represents the percentage of CPU used during 535 session RC_N from the last report until the time this RAQMON PDU was 536 generated. The CPU Utilization is expressed in percents in the range 537 0 to 100. The value should indicate not only CPU utilization 538 associated to a session RC_N but also actual CPU Utilization, to 539 indicate a snapshot of the CPU utilization of the host running the 540 RDS while session RC_N in progress. 542 Memory Utilization: 8 bits - This parameter defined in section 5.31 543 of [RAQMON-FRAMEWORK] represents the percentage of total memory used 544 during session RC_N up until the time this RAQMON PDU was generated. 545 The memory utilization is expressed in percents 0 to 100. The Memory 546 Utilization value should indicate not only the memory utilization 547 associated to a session RC_N but the total memory utilization, to 548 indicate a snapshot of end device memory utilization while session 549 RC_N in progress. 551 Application Name: - This parameter is defined in section 5.32 of 552 [RAQMON-FRAMEWORK]. The Application Name field starts with an 8-bit 553 octet count describing the length of the text followed the text 554 itself using UTF-8 encoding. Application Name field is multiple of 555 32 bits, and padding will be used if necessary. 557 padding: 0, 8, 16 or 24 bits - If the padding bit (P) is set , then 558 this field may be present. The actual padding at the end of the Basic 559 part of the PDU is 0,8, 16 or 24 bits to make the basic part of the 560 PDU multiple of 32 bits long. 562 2.1.3 APP Part of RAQMON Protocol Data Unit 564 The APP part of the RAQMON PDU is intended to accommodate extensions 565 for new applications in a modular manner and without requiring a PDU 566 type value registration. 568 Vendors may design and publish application specific extensions. Any 569 RAQMON compliant RRC MUST be able to recognize vendors SMI Enterprise 570 Code and MUST recognize the presence of application specific 571 extensions identified by using Report Type fields. As represented in 572 figure 1, the Report Type and Application Length fields are always 573 located at a fixed offset relative to the start of the extension 574 fields. There is no need for the RRC to understand the semantics of 575 the enterprise specific parts of the PDU. 577 SMI Enterprise Code: 32 bits - Vendors and Application developers 578 should fill in appropriate SMI Enterprise IDs available at 579 http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI 580 Enterprise Code indicates a vendor or application specific extension. 582 RAQMON PDUs are capable of carrying multiple Application Parts within 583 a PDU. 585 Report Type: 16 bits - Vendors and Application developers should fill 586 in appropriate Report type within a specified SMI Enterprise Code. It 587 is RECOMMENDED that vendors publish application specific extensions 588 and maintain such report types for better interoperability. 590 Length of the Application Part: 16 bits (unsigned integer) - The 591 length of the Application Part of the RAQMON PDU in 32-bit words 592 minus one, which includes the header of the Application Part. 594 application-dependent data: variable length - Application/vendor- 595 dependent data is defined by the application developers. It is 596 interpreted by the vendor specific application and not by the RRC 597 itself. It must be a multiple of 32 bits long, and will be padded if 598 necessary. 600 2.1.4 Byte Order, Alignment, and Time Format of RAQMON PDUs 602 All integer fields are carried in network byte order, that is, most 603 significant byte (octet) first. This byte order is commonly known as 604 big-endian. The transmission order is described in detail in 605 [RFC791]. Unless otherwise noted, numeric constants are in decimal 606 (base 10). 608 All header data is aligned to its natural length, i.e., 16-bit fields 609 are aligned on even offsets, 32-bit fields are aligned at offsets 610 divisible by four, etc. Octets designated as padding have the value 611 zero. 613 2.1.5 IANA Considerations 615 Applications using RAQMON Framework requires a single fixed port. 616 Port number 7XXX is registered with IANA for use as the default port 617 for RAQMON PDUs over TCP. Hosts that run multiple applications may 618 use this port as an indication to have used RAQMON or provision a 619 separate TCP port as part of provisioning RAQMON RDS and RAQMON 620 Collector. 622 [editor note we are requiring that 7XXX be allocated by IANA, and 623 this note to be removed] 625 The particular port number was chosen to lie in the range above 5000 626 to accommodate port number allocation practice within the Unix 627 operating system, where privileged processes can only use port 628 numbers below 1024 and port numbers between 1024 and 5000 are 629 automatically assigned by the operating systems. 631 The OID assignment for the raqmonDsMIB MODULE-IDENTITY is made 632 according to [RFC3727] and there is no need for any IANA action on 633 this respect. 635 2.2 SNMP Notifications as an RDS/RRC Network Transport Protocol 637 It was an inherent objective of the RAQMON Framework to re-use 638 existing application level transport protocols to maximize the usage 639 of existing installations as well as to avoid transport protocol 640 level complexities in the design process. Choice of SNMP as a means 641 to transport RAQMON PDU was motivated by the intent of using existing 642 installed based of devices implementing SNMP agents as RAQMON Data 643 Sources (RDS). 645 There are some potential problems with the usage of SNMP as a 646 transport mapping protocol: 648 + The potential of congestion is higher than with the TCP 649 transport, because of the usage of UDP at the transport layer. 650 + The encoding of the information is less efficient and this 651 results in bigger message size, which again may impact 652 negatively congestion conditions and memory size requirements 653 in the devices. 655 In order to avoid these potential problems, the following 656 recommendations are made: 658 + Usage of the TCP transport is RECOMMENDED in deployment over 659 the SNMP transport wherever available for a pair of RDS/RRC. 660 + The usage of Inform PDUs is RECOMMENDED. 661 + The usage of Traps PDU is NOT RECOMMENDED. 662 + It is RECOMMENDED that information carried by notifications be 663 maintained within the limits of the MTU size in order to avoid 664 fragmentation. 666 If SNMP is chosen as a mechanism to transport RAQMON PDUs, the 667 following specification applies to RAQMON related usage of SNMP: 669 + RDSs implement the capability of embedding RAQMON parameters in 670 SNMP Notifications, re-using well known SNMP mechanisms to 671 report RAQMON Statistics. The RAQMON RDS MIB module as 672 specified in 2.1.1 MUST be used in order to map the RAQMON PDUs 673 onto the SNMP Notifications transport. 675 + Since RDSs are not computationally rich and to keep the RDS 676 realization as lightweight as possible, RDSs MAY fail to 677 respond to SNMP requests like GET, SET, etc., with the 678 exception of the GET and SET commands required to implement the 679 User-Based Security Model (USM) defined by [RFC3414]. 681 + In order to meet congestion safety requirements, SNMP INFORM 682 PDUs SHOULD be used. In case INFORM PDUs are used, RDSs MUST 683 process the SNMP INFORM responses from RRCs, and MUST serialize 684 the PDU transmission rate, i.e. limit the number of PDUS sent 685 in a specific time interval. 687 + Standard UDP port 162 SHOULD be used for SNMP Notifications. 689 2.2.1 Encoding RAQMON PDUs using the RAQMON RDS MIB module 691 The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP 692 Notifications for transport purposes. The MIB module defines the 693 objects needed for mapping the Basic part of RAQMON PDU defined in 694 [RAQMON-FRAMEWOK] as well as the Notifications themselves. In order 695 to incorporate any application-specific extensions in the Application 696 (APP) part of RAQMON PDU as defined in [RAQMON-FRAMEWOK], additional 697 variable bindings MAY be included in RAQMON notifications as 698 described in the MIB module. 700 For a detailed overview of the documents that describe the current 701 Internet-Standard Management Framework, please refer to section 7 of 702 RFC 3410 [RFC3410]. 704 Managed objects are accessed via a virtual information store, termed 705 the Management Information Base or MIB. MIB objects are generally 706 accessed through the Simple Network Management Protocol (SNMP). 707 Objects in the MIB are defined using the mechanisms defined in the 708 Structure of Management Information (SMI). This memo specifies a MIB 709 module that is compliant to the SMIv2, which is described in STD 58, 710 RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 711 2580[RFC2580]. 713 The following MIB module IMPORTS definitions from the following: 714 SNMPv2-SMI [RFC2578] 715 SNMPv2-TC [RFC2579] 716 RMON-MIB [RFC2819] 717 DIFFSERV-DSCP-TC [RFC3289] 718 SNMP-FRAMEWORK-MIB [RFC3411] 719 INET-ADDRESS-MIB [RFC4001] 721 It also uses REFERENCE clauses to refer to [RAQMON-FRAMEWORK]. 723 RAQMON-RDS-MIB DEFINITIONS ::= BEGIN 725 IMPORTS 726 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 727 Counter32, Unsigned32 728 FROM SNMPv2-SMI 730 DateAndTime 731 FROM SNMPv2-TC 733 rmon 734 FROM RMON-MIB 736 SnmpAdminString 737 FROM SNMP-FRAMEWORK-MIB 739 InetAddressType, InetAddress, InetPortNumber 740 FROM INET-ADDRESS-MIB 742 Dscp 743 FROM DIFFSERV-DSCP-TC 745 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 746 FROM SNMPv2-CONF; 748 raqmonDsMIB MODULE-IDENTITY 749 LAST-UPDATED "200601230000Z" -- January 23, 2006 750 ORGANIZATION "RMON Working Group" 751 CONTACT-INFO 752 "WG EMail: rmonmib@ietf.org 753 Subscribe: rmonmib-request@ietf.org 755 MIB Editor: 756 Eugene Golovinsky 757 Postal: BMC Software, Inc. 758 2101 CityWest Boulevard, 759 Houston, TX, 77094 760 USA 761 Tel: +713-918-1816 762 Email: egolovin@bmc.com 763 " 764 DESCRIPTION 765 " This is the RAQMON Data Source notification MIB Module. 766 It provides a mapping of RAQMON PDUs to SNMP 767 notifications. 769 Ds stands for data source. 771 Note that all of the object types defined in this module 772 are accessible-for-notify, and would consequently not be 773 available to a browser using simple Get, GetNext, or 774 GetBulk requests. 776 Copyright (c) The Internet Society (2006). 778 -- RFC EDITOR: please replace yyyy with actual number 779 This version of this MIB module is part of RFC yyyy; 780 See the RFC itself for full legal notices. 781 " 783 REVISION "200601230000Z" -- January 23, 2006 784 DESCRIPTION 785 "Initial version, published as RFCyyyy." 786 -- RFC Editor: Please fill in RFCyyyy 788 ::= { rmon 32 } 790 -- This OID allocation conforms to [RFC3737] 792 raqmonDsNotifications OBJECT IDENTIFIER ::= { raqmonDsMIB 0 } 793 raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 } 794 raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 } 796 raqmonDsNotificationTable OBJECT-TYPE 797 SYNTAX SEQUENCE OF RaqmonDsNotificationEntry 798 MAX-ACCESS not-accessible 799 STATUS current 800 DESCRIPTION 801 " This conceptual table provides the SNMP mapping of the 802 RAQMON Basic PDU. It is indexed by the RAQMON Data 803 Source, sub-session, and address of the peer entity. 805 Note that there is no concern about the indexation of 806 this table exceeding the limits defined by RFC 2578 807 Section 3.5. According to [RAQMON-FRAMEWORK], Section 808 5.1, only IPv4 and IPv6 addresses can be reported as 809 participant addresses. 810 " 811 ::= { raqmonDsMIBObjects 1 } 813 raqmonDsNotificationEntry OBJECT-TYPE 814 SYNTAX RaqmonDsNotificationEntry 815 MAX-ACCESS not-accessible 816 STATUS current 817 DESCRIPTION 818 "The entry (row) is not retrievable and is not kept by 819 RDSs. It serves data organization purpose only. 820 " 821 INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType, 822 raqmonDsPeerAddr } 824 ::= { raqmonDsNotificationTable 1 } 826 RaqmonDsNotificationEntry ::= SEQUENCE { 827 raqmonDsDSRC Unsigned32, 828 raqmonDsRCN Unsigned32, 829 raqmonDsPeerAddrType InetAddressType, 830 raqmonDsPeerAddr InetAddress, 831 raqmonDsAppName SnmpAdminString, 832 raqmonDsDataSourceDevicePort InetPortNumber, 833 raqmonDsReceiverDevicePort InetPortNumber, 834 raqmonDsSessionSetupDateTime DateAndTime, 835 raqmonDsSessionSetupDelay Unsigned32, 836 raqmonDsSessionDuration Unsigned32, 837 raqmonDsSessionSetupStatus SnmpAdminString, 838 raqmonDsRoundTripEndToEndNetDelay Unsigned32, 839 raqmonDsOneWayEndToEndNetDelay Unsigned32, 840 raqmonDsApplicationDelay Unsigned32, 841 raqmonDsInterArrivalJitter Unsigned32, 842 raqmonDsIPPacketDelayVariation Unsigned32, 843 raqmonDsTotalPacketsReceived Counter32, 844 raqmonDsTotalPacketsSent Counter32, 845 raqmonDsTotalOctetsReceived Counter32, 846 raqmonDsTotalOctetsSent Counter32, 847 raqmonDsCumulativePacketLoss Counter32, 848 raqmonDsPacketLossFraction Unsigned32, 849 raqmonDsCumulativeDiscards Counter32, 850 raqmonDsDiscardsFraction Unsigned32, 851 raqmonDsSourcePayloadType Unsigned32, 852 raqmonDsReceiverPayloadType Unsigned32, 853 raqmonDsSourceLayer2Priority Unsigned32, 854 raqmonDsSourceDscp Dscp, 855 raqmonDsDestinationLayer2Priority Unsigned32, 856 raqmonDsDestinationDscp Dscp, 857 raqmonDsCpuUtilization Unsigned32, 858 raqmonDsMemoryUtilization Unsigned32 } 860 raqmonDsDSRC OBJECT-TYPE 861 SYNTAX Unsigned32 862 MAX-ACCESS not-accessible 863 STATUS current 864 DESCRIPTION 865 "Data Source identifier represents a unique session 866 descriptor that points to a specific session 867 between communicating entities. Identifiers unique for 868 sessions conducted between two entities are 869 generated by the communicating entities. Zero is a 870 valid value, with no special semantics." 871 ::= { raqmonDsNotificationEntry 1 } 873 raqmonDsRCN OBJECT-TYPE 874 SYNTAX Unsigned32 (0..15) 875 MAX-ACCESS not-accessible 876 STATUS current 877 DESCRIPTION 878 "The Record Count Number indicates a sub-session 879 within a communication session. A maximum number of 16 880 sub-sessions are supported - this limitation is dictated 881 by reasons of compatibility with other transport 882 protocols." 883 ::= { raqmonDsNotificationEntry 2 } 885 raqmonDsPeerAddrType OBJECT-TYPE 886 SYNTAX InetAddressType 887 MAX-ACCESS not-accessible 888 STATUS current 889 DESCRIPTION 890 "The type of the Internet address of the peer participant 891 for this session." 892 REFERENCE 893 "Section 5.2 of [RAQMON-FRAMEWORK]" 894 ::= { raqmonDsNotificationEntry 3 } 896 raqmonDsPeerAddr OBJECT-TYPE 897 SYNTAX InetAddress 898 MAX-ACCESS not-accessible 899 STATUS current 900 DESCRIPTION 901 "The Internet Address of the peer participant for this 902 session." 903 REFERENCE 904 "Section 5.2 of [RAQMON-FRAMEWORK]" 905 ::= { raqmonDsNotificationEntry 4 } 907 raqmonDsAppName OBJECT-TYPE 908 SYNTAX SnmpAdminString 909 MAX-ACCESS accessible-for-notify 910 STATUS current 911 DESCRIPTION 912 "This is a text string giving the name and possibly 913 version of the application associated with that session, 914 e.g., 'XYZ VoIP Agent 1.2'." 915 REFERENCE 916 "Section 5.28 of [RAQMON-FRAMEWORK]" 917 ::= { raqmonDsNotificationEntry 5 } 919 raqmonDsDataSourceDevicePort OBJECT-TYPE 920 SYNTAX InetPortNumber 921 MAX-ACCESS accessible-for-notify 922 STATUS current 923 DESCRIPTION 924 "The port number from which data for this session was sent 925 by the Data Source device." 926 REFERENCE 927 "Section 5.5 of [RAQMON-FRAMEWORK]" 928 ::= { raqmonDsNotificationEntry 6 } 930 raqmonDsReceiverDevicePort OBJECT-TYPE 931 SYNTAX InetPortNumber 932 MAX-ACCESS accessible-for-notify 933 STATUS current 934 DESCRIPTION 935 "The port number where the data for this session was 936 received." 937 REFERENCE 938 "Section 5.6 of [RAQMON-FRAMEWORK]" 939 ::= { raqmonDsNotificationEntry 7 } 941 raqmonDsSessionSetupDateTime OBJECT-TYPE 942 SYNTAX DateAndTime 943 MAX-ACCESS accessible-for-notify 944 STATUS current 945 DESCRIPTION 946 "The time when session was initiated." 947 REFERENCE 948 "Section 5.7 of [RAQMON-FRAMEWORK]" 949 ::= { raqmonDsNotificationEntry 8 } 951 raqmonDsSessionSetupDelay OBJECT-TYPE 952 SYNTAX Unsigned32 (0..65535) 953 UNITS "milliseconds" 954 MAX-ACCESS accessible-for-notify 955 STATUS current 956 DESCRIPTION 957 "Session setup time." 958 REFERENCE 959 "Section 5.8 of [RAQMON-FRAMEWORK]" 960 ::= { raqmonDsNotificationEntry 9 } 962 raqmonDsSessionDuration OBJECT-TYPE 963 SYNTAX Unsigned32 964 UNITS "seconds" 965 MAX-ACCESS accessible-for-notify 966 STATUS current 967 DESCRIPTION 968 "Session duration, including setup time. The SYNTAX of 969 this object allows to express the duration of sessions 970 that do not exceed 4660 hours and 20 minutes." 971 REFERENCE 972 "Section 5.9 of [RAQMON-FRAMEWORK]" 973 ::= { raqmonDsNotificationEntry 10 } 975 raqmonDsSessionSetupStatus OBJECT-TYPE 976 SYNTAX SnmpAdminString 977 MAX-ACCESS accessible-for-notify 978 STATUS current 979 DESCRIPTION 980 "Describes appropriate communication session states e.g. 981 Call Established successfully, RSVP reservation 982 failed etc." 983 REFERENCE 984 "Section 5.10 of [RAQMON-FRAMEWORK]" 985 ::= { raqmonDsNotificationEntry 11 } 987 raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE 988 SYNTAX Unsigned32 989 UNITS "milliseconds" 990 MAX-ACCESS accessible-for-notify 991 STATUS current 992 DESCRIPTION 993 "Most recent available information about the 994 round trip end to end network delay." 995 REFERENCE 996 "Section 5.11 of [RAQMON-FRAMEWORK]" 997 ::= { raqmonDsNotificationEntry 12} 999 raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE 1000 SYNTAX Unsigned32 1001 UNITS "milliseconds" 1002 MAX-ACCESS accessible-for-notify 1003 STATUS current 1004 DESCRIPTION 1005 " Most recent available information about the 1006 one way end to end network delay." 1007 REFERENCE 1008 "Section 5.12 of [RAQMON-FRAMEWORK]" 1009 ::= { raqmonDsNotificationEntry 13} 1011 raqmonDsApplicationDelay OBJECT-TYPE 1012 SYNTAX Unsigned32 (0..65535) 1013 UNITS "milliseconds" 1014 MAX-ACCESS accessible-for-notify 1015 STATUS current 1016 DESCRIPTION 1017 " Most recent available information about the 1018 application delay." 1019 REFERENCE 1020 "Section 5.13 of [RAQMON-FRAMEWORK]" 1021 ::= { raqmonDsNotificationEntry 14} 1023 raqmonDsInterArrivalJitter OBJECT-TYPE 1024 SYNTAX Unsigned32 (0..65535) 1025 UNITS "milliseconds" 1026 MAX-ACCESS accessible-for-notify 1027 STATUS current 1028 DESCRIPTION 1029 "An estimate of the inter-arrival jitter." 1030 REFERENCE 1031 "Section 5.14 of [RAQMON-FRAMEWORK]" 1032 ::= { raqmonDsNotificationEntry 15} 1034 raqmonDsIPPacketDelayVariation OBJECT-TYPE 1035 SYNTAX Unsigned32 (0..65535) 1036 UNITS "milliseconds" 1037 MAX-ACCESS accessible-for-notify 1038 STATUS current 1039 DESCRIPTION 1040 "An estimate of the inter-arrival delay variation." 1041 REFERENCE 1042 "Section 5.15 of [RAQMON-FRAMEWORK]" 1043 ::= { raqmonDsNotificationEntry 16} 1045 raqmonDsTotalPacketsReceived OBJECT-TYPE 1046 SYNTAX Counter32 1047 UNITS "packets" 1048 MAX-ACCESS accessible-for-notify 1049 STATUS current 1050 DESCRIPTION 1051 "The number of packets transmitted within a communication 1052 session by the receiver since the start of the session." 1053 REFERENCE 1054 "Section 5.16 of [RAQMON-FRAMEWORK]" 1055 ::= { raqmonDsNotificationEntry 17 } 1057 raqmonDsTotalPacketsSent OBJECT-TYPE 1058 SYNTAX Counter32 1059 UNITS "packets" 1060 MAX-ACCESS accessible-for-notify 1061 STATUS current 1062 DESCRIPTION 1063 "The number of packets transmitted within a communication 1064 session by the sender since the start of the session." 1066 REFERENCE 1067 "Section 5.17 of [RAQMON-FRAMEWORK]" 1068 ::= { raqmonDsNotificationEntry 18 } 1070 raqmonDsTotalOctetsReceived OBJECT-TYPE 1071 SYNTAX Counter32 1072 UNITS "octets" 1073 MAX-ACCESS accessible-for-notify 1074 STATUS current 1075 DESCRIPTION 1076 "The total number of payload octets (i.e., not including 1077 header or padding octets) transmitted in packets by the 1078 receiver within a communication session since the start 1079 of the session." 1080 REFERENCE 1081 "Section 5.18 of [RAQMON-FRAMEWORK]" 1082 ::= { raqmonDsNotificationEntry 19 } 1084 raqmonDsTotalOctetsSent OBJECT-TYPE 1085 SYNTAX Counter32 1086 UNITS "octets" 1087 MAX-ACCESS accessible-for-notify 1088 STATUS current 1089 DESCRIPTION 1090 "The number of payload octets (i.e., not including headers 1091 or padding) transmitted in packets by the sender within 1092 a communication sub-session since the start of the 1093 session." 1094 REFERENCE 1095 "Section 5.19 of [RAQMON-FRAMEWORK]" 1096 ::= { raqmonDsNotificationEntry 20 } 1098 raqmonDsCumulativePacketLoss OBJECT-TYPE 1099 SYNTAX Counter32 1100 UNITS "packets" 1101 MAX-ACCESS accessible-for-notify 1102 STATUS current 1103 DESCRIPTION 1104 "The number of packets from this session whose loss 1105 had been detected since the start of the session." 1106 REFERENCE 1107 "Section 5.20 of [RAQMON-FRAMEWORK]" 1108 ::= { raqmonDsNotificationEntry 21 } 1110 raqmonDsPacketLossFraction OBJECT-TYPE 1111 SYNTAX Unsigned32 (0..100) 1112 UNITS "percentage of packets sent" 1113 MAX-ACCESS accessible-for-notify 1114 STATUS current 1115 DESCRIPTION 1116 "The percentage of lost packets with respect to the 1117 overall packets sent. This is defined to be 100 times 1118 the number of packets lost divided by the number of 1119 packets expected." 1120 REFERENCE 1121 "Section 5.21 of [RAQMON-FRAMEWORK]" 1122 ::= { raqmonDsNotificationEntry 22 } 1124 raqmonDsCumulativeDiscards OBJECT-TYPE 1125 SYNTAX Counter32 1126 UNITS "packets" 1127 MAX-ACCESS accessible-for-notify 1128 STATUS current 1129 DESCRIPTION 1130 "The number of packet discards 1131 detected since the start of the session." 1132 REFERENCE 1133 "Section 5.22 of [RAQMON-FRAMEWORK]" 1134 ::= { raqmonDsNotificationEntry 23 } 1136 raqmonDsDiscardsFraction OBJECT-TYPE 1137 SYNTAX Unsigned32 (0..100) 1138 UNITS "percentage of packets sent" 1139 MAX-ACCESS accessible-for-notify 1140 STATUS current 1141 DESCRIPTION 1142 "The percentage of discards with respect to the overall 1143 packets sent. This is defined to be 100 times the number 1144 of discards divided by the number of packets expected." 1145 REFERENCE 1146 "Section 5.23 of [RAQMON-FRAMEWORK]" 1147 ::= { raqmonDsNotificationEntry 24 } 1149 raqmonDsSourcePayloadType OBJECT-TYPE 1150 SYNTAX Unsigned32 (0..127) 1151 MAX-ACCESS accessible-for-notify 1152 STATUS current 1153 DESCRIPTION 1154 "The payload type of the packet sent by this RDS." 1155 REFERENCE 1156 "RFC 1890, Section 5.24 of [RAQMON-FRAMEWORK] " 1157 ::= { raqmonDsNotificationEntry 25 } 1159 raqmonDsReceiverPayloadType OBJECT-TYPE 1160 SYNTAX Unsigned32 (0..127) 1161 MAX-ACCESS accessible-for-notify 1162 STATUS current 1163 DESCRIPTION 1164 "The payload type of the packet received by this RDS." 1165 REFERENCE 1166 "RFC 1890, Section 5.25 of [RAQMON-FRAMEWORK] " 1167 ::= { raqmonDsNotificationEntry 26 } 1169 raqmonDsSourceLayer2Priority OBJECT-TYPE 1170 SYNTAX Unsigned32 (0..7) 1171 MAX-ACCESS accessible-for-notify 1172 STATUS current 1173 DESCRIPTION 1174 "Source Layer 2 priority used by the sata source to send 1175 packets to the receiver by this data source during this 1176 communication session. 1177 " 1178 REFERENCE 1179 "Section 5.26 of [RAQMON-FRAMEWORK]" 1180 ::= { raqmonDsNotificationEntry 27 } 1182 raqmonDsSourceDscp OBJECT-TYPE 1183 SYNTAX Dscp 1184 MAX-ACCESS accessible-for-notify 1185 STATUS current 1186 DESCRIPTION 1187 "Layer 3 TOS/DSCP values used by the Data Source to 1188 prioritize traffic sent." 1189 REFERENCE 1190 "Section 5.27 of [RAQMON-FRAMEWORK]" 1191 ::= { raqmonDsNotificationEntry 28 } 1193 raqmonDsDestinationLayer2Priority OBJECT-TYPE 1194 SYNTAX Unsigned32 (0..7) 1195 MAX-ACCESS accessible-for-notify 1196 STATUS current 1197 DESCRIPTION 1198 "Destination Layer 2 priority. This is the priority used 1199 by the peer communicating entity to send packets to the 1200 data source. 1201 " 1202 REFERENCE 1203 "Section 5.28 of [RAQMON-FRAMEWORK]" 1204 ::= { raqmonDsNotificationEntry 29 } 1206 raqmonDsDestinationDscp OBJECT-TYPE 1207 SYNTAX Dscp 1208 MAX-ACCESS accessible-for-notify 1209 STATUS current 1210 DESCRIPTION 1211 "Layer 3 TOS/DSCP values used by the 1212 peer communicating entiy to prioritize traffic 1213 sent to the source." 1214 REFERENCE 1215 "Section 5.29 of [RAQMON-FRAMEWORK]" 1216 ::= { raqmonDsNotificationEntry 30 } 1218 raqmonDsCpuUtilization OBJECT-TYPE 1219 SYNTAX Unsigned32 (0..100) 1220 UNITS "percent" 1221 MAX-ACCESS accessible-for-notify 1222 STATUS current 1223 DESCRIPTION 1224 "Latest available information about the total CPU 1225 utilization." 1226 REFERENCE 1227 "Section 5.30 of [RAQMON-FRAMEWORK]" 1228 ::= { raqmonDsNotificationEntry 31 } 1230 raqmonDsMemoryUtilization OBJECT-TYPE 1231 SYNTAX Unsigned32 (0..100) 1232 UNITS "percent" 1233 MAX-ACCESS accessible-for-notify 1234 STATUS current 1235 DESCRIPTION 1236 "Latest available information about the total memory 1237 utilization." 1238 REFERENCE 1239 "Section 5.31 of [RAQMON-FRAMEWORK]" 1240 ::= { raqmonDsNotificationEntry 32 } 1242 -- definitions of the notifications 1243 -- 1244 -- raqmonDsAppName is the only object that MUST be sent by an 1245 -- RDS every time the static notification is generated. 1247 -- raqmonDsTotalPacketsReceived is the only object that MUST be 1248 -- sent by an RD every time the dynamic notification is generated. 1250 -- Other objects from the raqmonDsNotificationTable may be 1251 -- included in the variable binding list. Specifically, a raqmon 1252 -- notification will include MIB objects that provide information 1253 -- about metrics that characterize the application session 1255 raqmonDsStaticNotification NOTIFICATION-TYPE 1256 OBJECTS { raqmonDsAppName } 1257 STATUS current 1258 DESCRIPTION 1259 "This notification maps the static parameters in the 1260 Basic RAQMON PDU onto an SNMP transport. 1261 This notification is expected to be sent once per 1262 session, or when a new sub-session is initiated. 1263 The following objects MAY be carried by the 1264 raqmonDsStaticNotification: 1266 raqmonDsDataSourceDevicePort, 1267 raqmonDsReceiverDevicePort, 1268 raqmonDsSessionSetupDateTime, 1269 raqmonDsSessionSetupDelay, 1270 raqmonDsSessionDuration, 1271 raqmonDsSourcePayloadType, 1272 raqmonDsReceiverPayloadType, 1273 raqmonDsSourceLayer2Priority, 1274 raqmonDsSourceDscp, 1275 raqmonDsDestinationLayer2Priority, 1276 raqmonDsDestinationDscp 1278 It is RECOMMENDED to keep the size of a notification 1279 within the MTU size limits in order to avoid 1280 fragmentation." 1281 ::= { raqmonDsNotifications 1 } 1283 raqmonDsDynamicNotification NOTIFICATION-TYPE 1284 OBJECTS { raqmonDsTotalPacketsReceived } 1285 STATUS current 1286 DESCRIPTION 1287 "This notification maps the dynamic parameters in the 1288 Basic RAQMON PDU onto an SNMP transport. 1290 The following objects MAY be carried by the 1291 raqmonDsDynamicNotification: 1293 raqmonDsRoundTripEndToEndNetDelay, 1294 raqmonDsOneWayEndToEndNetDelay, 1295 raqmonDsApplicationDelay, 1296 raqmonDsInterArrivalJitter, 1297 raqmonDsIPPacketDelayVariation, 1298 raqmonDsTotalPacketsSent, 1299 raqmonDsTotalOctetsReceived, 1300 raqmonDsTotalOctetsSent, 1301 raqmonDsCumulativePacketLoss, 1302 raqmonDsPacketLossFraction, 1303 raqmonDsCumulativeDiscards, 1304 raqmonDsDiscardsFraction, 1305 raqmonDsCpuUtilization, 1306 raqmonDsMemoryUtilization 1308 It is RECOMMENDED to keep the size of a notification 1309 within the MTU size limits in order to avoid 1310 fragmentation." 1312 ::= { raqmonDsNotifications 2 } 1314 raqmonDsByeNotification NOTIFICATION-TYPE 1315 OBJECTS { raqmonDsAppName } 1316 STATUS current 1317 DESCRIPTION 1318 "The BYE Notification. This Notification is the equivalent 1319 of the RAQMON NULL PDU, which signals the end of a RAQMON 1320 session. 1321 " 1322 ::= { raqmonDsNotifications 3 } 1324 -- 1325 -- conformance information 1326 raqmonDsCompliance OBJECT IDENTIFIER ::= 1327 { raqmonDsConformance 1 } 1328 raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } 1330 raqmonDsBasicCompliance MODULE-COMPLIANCE 1331 STATUS current 1332 DESCRIPTION 1333 "The compliance statement for SNMP entities which 1334 implement this MIB module. 1336 There are a number of INDEX objects that cannot be 1337 represented in the form of OBJECT clauses in SMIv2, but 1338 for which we have the following compliance requirements, 1339 expressed in OBJECT clause form in this description 1340 clause: 1342 -- OBJECT raqmonDsPeerAddrType 1343 -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } 1344 -- DESCRIPTION 1345 -- This MIB requires support for only global IPv4 1346 -- and IPv6 address types. 1347 -- 1348 -- OBJECT raqmonDsPeerAddr 1349 -- SYNTAX InetAddress (SIZE(4|16)) 1350 -- DESCRIPTION 1351 -- This MIB requires support for only global IPv4 1352 -- and IPv6 address types. 1353 -- 1354 " 1355 MODULE -- this module 1356 MANDATORY-GROUPS { raqmonDsNotificationGroup, 1357 raqmonDsPayloadGroup } 1358 ::= { raqmonDsCompliance 1 } 1360 raqmonDsNotificationGroup NOTIFICATION-GROUP 1361 NOTIFICATIONS { raqmonDsStaticNotification, 1362 raqmonDsDynamicNotification, 1363 raqmonDsByeNotification } 1364 STATUS current 1365 DESCRIPTION 1366 "Standard RAQMON Data Source Notification group." 1367 ::= { raqmonDsGroups 1 } 1369 raqmonDsPayloadGroup OBJECT-GROUP 1370 OBJECTS { raqmonDsAppName, 1371 raqmonDsDataSourceDevicePort, 1372 raqmonDsReceiverDevicePort, 1373 raqmonDsSessionSetupDateTime, 1374 raqmonDsSessionSetupDelay, 1375 raqmonDsSessionDuration, 1376 raqmonDsSessionSetupStatus, 1377 raqmonDsRoundTripEndToEndNetDelay, 1378 raqmonDsOneWayEndToEndNetDelay, 1379 raqmonDsApplicationDelay, 1380 raqmonDsInterArrivalJitter, 1381 raqmonDsIPPacketDelayVariation, 1382 raqmonDsTotalPacketsReceived, 1383 raqmonDsTotalPacketsSent, 1384 raqmonDsTotalOctetsReceived, 1385 raqmonDsTotalOctetsSent, 1386 raqmonDsCumulativePacketLoss, 1387 raqmonDsPacketLossFraction, 1388 raqmonDsCumulativeDiscards, 1389 raqmonDsDiscardsFraction, 1390 raqmonDsSourcePayloadType, 1391 raqmonDsReceiverPayloadType, 1392 raqmonDsSourceLayer2Priority, 1393 raqmonDsSourceDscp, 1394 raqmonDsDestinationLayer2Priority, 1395 raqmonDsDestinationDscp, 1396 raqmonDsCpuUtilization, 1397 raqmonDsMemoryUtilization } 1398 STATUS current 1399 DESCRIPTION 1400 "Standard RAQMON Data Source payload MIB objects group." 1401 ::= { raqmonDsGroups 2 } 1403 END 1405 3. Congestion-Safe RAQMON Operation 1407 As outlined in earlier sections, TCP congestion control mechanism 1408 provides inherent congestion safety features when TCP is implemented 1409 as transport to carry RAQMON PDU. 1411 To ensure congestion safety, clearly the best thing to do is to use a 1412 congestion-safe transport protocol such as TCP. If this is not 1413 feasible, it may be necessary to fall back to UDP since SNMP over UDP 1414 is a widely deployed transport protocol. 1416 When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow 1417 section 3.0 of [RAQMON-FRAMEWORK] guidelines that outlines measures 1418 that MUST be taken to use RAQMON in congestion safe manner. 1419 Congestion safety requirements in section 3.0 of [RAQMON-FRAMEWORK] 1420 would ensure that a RAQMON implementation using SNMP over UDP does 1421 not lead to congestion under heavy network load. 1423 4. Normative References 1425 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1426 1981. 1428 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1429 September 1981. 1431 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1432 Requirement Levels", BCP 14, RFC 2119, March 1997. 1434 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1435 Rose, M. and S. Waldbusser, "Structure of Management 1436 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1437 1999. 1439 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1440 Rose, M. and S. Waldbusser, "Textual Conventions for 1441 SMIv2", STD 58, RFC 2579, April 1999. 1443 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1444 Rose, M. and S. Waldbusser, "Conformance Statements for 1445 SMIv2", STD 58, RFC 2580, April 1999. 1447 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 1448 Information Base", STD 59, RFC 2819, May 2000. 1450 [RFC3289] Baker, F., Chan, K. and A. Smith, "Management Information 1451 Base for the Differentiated Services Architecture", RFC 1452 3289, May 2002. 1454 [RFC3411] Harrington, D., Preshun, R. and B. Wijnen, "An 1455 Architecture for Describing Simple Network Management 1456 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 1457 December 2002. 1459 [RFC4001] Daniele, M., Haberman, B., Routhier, S. And J. 1460 Schoenwalder, "Textual Conventions for Internet Network 1461 Addresses", RFC 4001, February 2005. 1463 [RAQMON-FRAMEWORK] Siddiqui, A., Romascanu, D. and E. Golovinsky, 1464 "Framework for Real-time Application Quality of Service 1465 Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon- 1466 framework-13.txt, January 2006. 1468 5. Informative References 1470 [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, 1471 March 1992. 1473 [RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, 1474 April 1992. 1476 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1477 "Introduction and Applicability Statements for Internet- 1478 Standard Management Framework", RFC 3410, December 2002. 1480 [RFC3414] Blumenthal U., and B. Wijnen, "User-based Security Model 1481 (USM) for version 3 of the Simple Network Management 1482 Protocol (SNMPv3)", RFC 3414, December 2002. 1484 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1485 Jacobson, "RTP: A Transport Protocol for Real-Time 1486 Applications", RFC 3550, July 2003. 1488 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio 1489 and Video Conferences with Minimal Control", STD 65, RFC 1490 3551, July 2003. 1492 [RFC3629] F. Yergeau, "UTF-8, a transformation format of ISO 1493 10646", STD 63, RFC 3629, November 2003. 1495 [RFC3737] Wijnen B., and A.Bierman "IANA Guidelines for the 1496 Registry of Remote Monitoring (RMON) MIB modules", RFC 1497 3737, April 2004. 1499 [IEEE802.1D] Information technology-Telecommunications and 1500 information exchange between systems--Local and 1501 metropolitan area networks-Common Specification a--Media 1502 access control (MAC) bridges:15802-3: 1998 (ISO/IEC) 1503 [ANSI/IEEE Std 802.1D, 1998 Edition] 1505 [3DES] American National Standards Institute, ANSI X9.52-1998, 1506 "Triple Data Encryption Algorithm Modes of Operation" 1507 1998. 1509 [AES] Federal Information Processing Standard (FIPS), 1510 "Specification for the ADVANCED ENCRYPTION 1511 STANDARD(AES)", Publication 197, November 2001. 1513 6. Acknowledgements 1515 The authors would like to thank Bill Walker and Joseph Mastroguilio 1516 from Avaya and Bin Hu from Motorola for their discussions. The 1517 authors would also like to extend special thanks to Randy Presuhn, 1518 who reviewed this document for spelling and formatting purposes, as 1519 well as for a deep review of the technical content. We also would 1520 like to thank Bert Wijnen for the permanent coaching during the 1521 evolution of this document and the detailed review of its final 1522 versions. 1524 7. Security Considerations 1526 [RAQMON-FRAMEWORK] outlines a threat model associated with RAQMON and 1527 security considerations to be taken into account in the RAQMON 1528 specification to mitigate against those threats. It is imperative 1529 that RAQMON PDU implementations be able to provide the following 1530 protection mechanisms in order to attain end-to-end security: 1532 1. Authentication - the RRC SHOULD be able to verify that a RAQMON 1533 report was originated by the RDS claiming to have sent it. At 1534 minimum, an RDS/RRC pair MUST use a digest-based authentication 1535 procedure to authenticate, like the one defined in [RFC1321]. 1537 2. Privacy - RAQMON information includes identification of the 1538 parties participating in a communication session. RAQMON 1539 deployments SHOULD be able to provide protection from 1540 eavesdropping, and to prevent an unauthorized third party from 1541 gathering potentially sensitive information. This can be achieved 1542 by using payload encryption technologies such as DES (Data 1543 Encryption Standard), 3-DES [3DES], and AES (Advanced Encryption 1544 Standard) [AES]. 1546 3. Protection from Denial of Service attacks directed at the RRC - 1547 RDSs send RAQMON reports as a side effect of external events (for 1548 example, receipt of a phone call). An attacker can try to 1549 overwhelm the RRC (or the network) by initiating a large number of 1550 events in order to swamp the RRC with excessive numbers of RAQMON 1551 PDUs. 1553 To prevent DoS (denial-of-service) attacks against the RRC, the 1554 RDS will send the first report for a session only after the 1555 session has been established, so that the session set-up process 1556 is not affected. 1558 4. NAT and Firewall Friendly Design: the presence of IP addresses and 1559 TCP/UDP port information in RAQMON PDUs may be NAT unfriendly. 1560 Where NAT-friendliness is a requirement, the RDS MAY omit IP 1561 address information from the RAQMON PDU. Another way to avoid 1562 this problem is by using NAT-Aware Application Layer Gateways 1563 (ALGs) to ensure that correct IP addresses appear in RAQMON PDUs. 1565 For the usage of TCP, TLS MUST be used to provide transport layer 1566 security. 1568 This memo also defines the RAQMON-RDS-MIB module with the purpose of 1569 mapping the RAQMON PDUs into SNMP Notifications. To attain end-to- 1570 end security the following measures have been taken in the RAQMON- 1571 RDS-MIB module design: 1573 There are no management objects defined in this MIB module that have 1574 a MAX-ACCESS clause of read-write and/or read-create. Consequently, 1575 if this MIB module is implemented correctly, there is no risk that an 1576 intruder can alter or create any management objects of this MIB 1577 module via direct SNMP SET operations. 1579 Some of the readable objects in this MIB module (i.e., objects with a 1580 MAX-ACCESS other than not-accessible) may be considered sensitive or 1581 vulnerable in some network environments. It is thus important to 1582 control even GET and/or NOTIFY access to these objects and possibly 1583 to even encrypt the values of these objects when sending them over 1584 the network via SNMP. These are the tables and objects and their 1585 sensitivity/vulnerability: 1587 raqmonDsNotificationTable 1589 The objects in this table contain user session information, and their 1590 disclosure may be sensitive in some environments. 1592 SNMP versions prior to SNMPv3 did not include adequate security. 1593 Even if the network itself is secure (for example by using IPSec), 1594 even then, there is no control as to who on the secure network is 1595 allowed to access and GET/SET (read/change/create/delete) the objects 1596 in this MIB module. 1598 It is RECOMMENDED that implementers consider the security features as 1599 provided by the SNMPv3 framework (see [RFC3410], section 8), 1600 including full support for the SNMPv3 cryptographic mechanisms (for 1601 authentication and privacy). 1603 It is a customer/operator responsibility to ensure that the SNMP 1604 entity giving access to an instance of this MIB module is properly 1605 configured to give access to the objects only to those principals 1606 (users) that have legitimate rights to indeed GET or SET 1607 (change/create/delete) them. 1609 8. Authors' Addresses 1611 Anwar A. Siddiqui 1612 Avaya Labs 1613 307 Middletown Lincroft Road 1614 Lincroft, New Jersey 07738 1615 USA 1616 Tel: +1 732 852-3200 1617 E-mail: anwars@avaya.com 1619 Dan Romascanu 1620 Avaya 1621 Atidim Technology Park, Bldg. #3 1622 Tel Aviv, 61131 1623 Israel 1624 Tel: +972-3-645-8414 1625 Email: dromasca@avaya.com 1627 Eugene Golovinsky 1628 BMC Software 1629 2101 CityWest Blvd. 1630 Houston, Texas 77042 1631 USA 1632 Tel: +1 713 918-1816 1633 Email: eugene_golovinsky@bmc.com 1635 Mahfuzur Rahman 1636 Panasonic Digital Networking Lab 1637 Two Research Way 1638 Princeton, NJ 08540 1639 Tel: +1 609 734 7332 1640 Email: mahfuz@research.panasonic.com 1642 Yongbum "Yong" Kim 1643 Broadcom 1644 3151 Zanker Road 1645 San Jose, CA 95134 1646 Tel: +1 408 501 7800 1647 E-mail: ybkim@broadcom.com 1649 A.Appendix 1651 The implementation notes included in Appendix are for informational 1652 purposes only and are meant to clarify the RAQMON specification. 1654 Pseudo code for RDS & RRC 1656 We provide examples of Psuedo code for aspects of RDS and RRC. There 1657 may be other implementation methods that are faster in particular 1658 operating environments or have other advantages. 1660 RDS: 1661 when (session starts} { 1662 report.identifier = session.endpoints, session.starttime; 1663 report.timestamp = 0; 1664 while (session in progress) { 1665 wait interval; 1666 report.statistics = update statistics; 1667 report.curtimestamp += interval; 1668 if encryption required 1669 report_data = encrypt(report, encrypt parameters); 1671 else 1672 report_data = report; 1673 raqmon_pdu = header, report_data; 1674 send raqmon-pdu; 1675 } 1676 } 1678 RRC: 1679 listen on raqmon port 1680 when ( raqmon_pdu received ) { 1681 decrypt raqmon_pdu.data if needed 1683 if report.identifier in database 1684 if report.current_time_stamp > last update 1685 update session statistics from report.statistics 1686 else 1687 discard report 1688 } 1690 B. Full Copyright Statement 1692 Copyright (C) The Internet Society (2006). This document is subject 1693 to the rights, licenses and restrictions contained in BCP 78, and 1694 except as set forth therein, the authors retain all their rights. 1696 This document and the information contained herein are provided on an 1697 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1698 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1699 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1700 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1701 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1702 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1704 Intellectual Property 1706 The IETF takes no position regarding the validity or scope of any 1707 Intellectual Property Rights or other rights that might be claimed to 1708 pertain to the implementation or use of the technology described in 1709 this document or the extent to which any license under such rights 1710 might or might not be available; nor does it represent that it has 1711 made any independent effort to identify any such rights. Information 1712 on the procedures with respect to rights in RFC documents can be 1713 found in BCP 78 and BCP 79. 1715 Copies of IPR disclosures made to the IETF Secretariat and any 1716 assurances of licenses to be made available, or the result of an 1717 attempt made to obtain a general license or permission for the use of 1718 such proprietary rights by implementers or users of this 1719 specification can be obtained from the IETF on-line IPR repository at 1720 http://www.ietf.org/ipr. 1722 The IETF invites any interested party to bring to its attention any 1723 copyrights, patents or patent applications, or other proprietary 1724 rights that may cover technology that may be required to implement 1725 this standard. Please address the information to the IETF at ietf- 1726 ipr@ietf.org. 1728 Acknowledgement: 1730 Funding for the RFC Editor function is currently provided by the 1731 Internet Society.