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