idnits 2.17.1 draft-ietf-rmonmib-raqmon-pdu-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 1477. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1665. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 1657), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 42. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(A) Disclaimer.) ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? ( - It does however have an RFC 2026 Section 10.4(B) IPR Disclosure Invitation.) ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == The page length should not exceed 58 lines per page, but there was 36 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 37 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 46 instances of too long lines in the document, the longest one being 8 characters in excess of 72. ** 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 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 (16 December 2004) is 7063 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 416, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) == Missing Reference: 'RFC 3550' is mentioned on line 513, but not defined == Missing Reference: 'RFC 3414' is mentioned on line 666, but not defined == Missing Reference: 'RAQMON-FRAMEWOK' is mentioned on line 683, but not defined == Missing Reference: 'RFC 1321' is mentioned on line 1536, but not defined == Unused Reference: 'RFC793' is defined on line 1340, but no explicit reference was found in the text == Unused Reference: 'RFC2819' is defined on line 1356, but no explicit reference was found in the text == Unused Reference: 'RFC1321' is defined on line 1366, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 1375, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1378, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1381, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1384, but no explicit reference was found in the text == Unused Reference: 'RFC1597' is defined on line 1387, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1394, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1397, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1D' is defined on line 1412, but no explicit reference was found in the text == Unused Reference: 'RFC1349' is defined on line 1418, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 1421, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1424, but no explicit reference was found in the text == Unused Reference: 'RFC3291' is defined on line 1428, but no explicit reference was found in the text == Unused Reference: 'RFC3414' is defined on line 1436, 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: 15 errors (**), 0 flaws (~~), 25 warnings (==), 12 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-08.txt Avaya Labs. 4 Category: Standards Track Dan Romascanu 5 Expires June 2005 Avaya Inc 6 Mahfuzur Rahman 7 Panasonic 8 Eugene Golovinsky 9 BMC Software 10 Yong Kim 11 Broadcom 12 16 December 2004 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, I certify that any applicable 20 patent or other IPR claims of which I am aware have been disclosed, 21 or will be disclosed, and any of which I become aware will be 22 disclosed, in accordance with RFC 3668. 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 To view the list Internet-Draft Shadow Directories, see 38 http://www.ietf.org/shadow.html. 40 Copyright Notice 42 Copyright (C) The Internet Society (2004). All Rights Reserved. 44 Abstract 46 This memo specifies two transport mappings of the Real-time 47 Application Quality of Service Monitoring (RAQMON) information model 48 defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the 49 Simple Network Management Protocol (SNMP) to carry the RAQMON 50 information from a RAQMON Data Source (RDS) to a RAQMON Report 51 Collector (RRC). 53 Distribution of this memo is unlimited. 55 Table of Contents 57 Status of this Memo..................................................1 58 Abstract.............................................................1 59 1 Introduction.......................................................3 60 2 Transporting RAQMON Protocol Data Units............................3 61 3 Congestion Safe RAQMON Operation..................................29 62 4 Normative References..............................................29 63 5 Informative References............................................30 64 6 Intellectual Property.............................................32 65 7 Acknowledgements..................................................32 66 8 Appendix..........................................................32 67 9 Security Considerations...........................................33 68 10 Authors' Addresses...............................................35 69 Full Copyright Statement............................................36 71 1. Introduction 73 The Real-Time Application QoS Monitoring (RAQMON) Framework as 74 outlined by [RAQMON-FRAMEWORK] extends the Remote Monitoring family 75 of protocols (RMON) by defining entities such as RAQMON Data Sources 76 (RDS) and RAQMON Report Collectors (RRC) to perform various 77 application monitoring in real time. [RAQMON-FRAMEWORK] defines an 78 information model in the format of a common protocol data unit (PDU) 79 used between a RDS and RRC to report QoS statistics. This memo 80 contains a syntactical description of the RAQMON PDU structure. 82 The following sections of this memo contain detailed specifications 83 for the usage of TCP and SNMP to carry RAQMON information. 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Transporting RAQMON Protocol Data Units 91 The RAQMON Protocol Data Unit (PDU) utilizes a common data format 92 understood by the RDS and the RRC. A RAQMON PDU does not transport 93 application data but rather occupies the place of a payload 94 specification at the application layer of the protocol stack. As 95 part of the specification, this memo also specifies the usage of TCP 96 and SNMP as underlying transport protocols to carry RAQMON PDUs 97 between RDSs and RRCs. While two transport protocol choices have been 98 provided as options to chose from for RDS implementers, RRCs MUST 99 implement both transport options defined by this document to ensure 100 interoperability. 102 2.1 TCP as an RDS/RRC Network Transport Protocol 104 A transport binding using TCP is included within the RAQMON 105 specification to facilitate reporting from various types of embedded 106 devices that run applications such as Voice over IP, Voice over Wi- 107 Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail, 108 software download applications, e-business style transactions, web 109 access from wired or wireless computing devices etc. For many of 110 these devices PDUs and a TCP-based transport fit the deployment 111 needs. 113 The RAQMON transport requirements for end-to-end congestion control 114 and reliability are inherently built into TCP as a transport 115 protocol. 117 The following section details the RAQMON PDU specifications. Though 118 transmitted as one Protocol Data Unit, a RAQMON PDU is functionally 119 divided into two different parts, namely the basic part and 120 application extensions required for vendor specific extension 121 [RAQMON-FRAMEWORK]. Both functional parts trail SMI Network 122 Management Private Enterprise Codes currently maintained by IANA 123 http://www.iana.org/assignments/enterprise-numbers. 125 A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1. 126 The parameters carried by RAQMON PDUs as shown in figure 1 and their 127 semantics are defined in section 5 of [RAQMON-FRAMEWORK]. 129 Vendors MUST use the Basic part of the PDU to report parameters pre- 130 listed here in the specification for interoperability as opposed to 131 using the application specific portion. Vendors MAY also use 132 application specific extensios to convey application, vendor, or 133 device specific parameters not included in the Basic part of the 134 specification, and explicitly publish such data externally to attain 135 extended interoperability. 137 2.1.1 The RAQMON PDU 139 0 1 2 3 140 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 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 |PDT = 1 |B| T |P|S|R| RC | Length | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | DSRC | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 | SMI Enterprise Code = 0 |Report Type = 0| RC_N | 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Data Source Address {DA} | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 | Receiver's Address (RA) | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | NTP Timestamp, most significant word | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | NTP Timestamp, least significant word | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 | Length | Application Name (AN) ... | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | ... | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | Length | Data Source Name (DN) ... | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | ... | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Length | Receiver's Name (RN) ... | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | ... | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Length | Session State ... | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | ... | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | Session Duration | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Round Trip End-to-End Network Delay | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | One Way End-to-End Network Delay | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Cumulative Packet Loss | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | Cumulative Application Packet Discard | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Total # Application Packets sent | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | Total # Application Packets received | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Total # Application Octets sent | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | Total # Application Octets received | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Data Source Device Port Used | Receiver Device Port Used | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 |Source Payload |Receiver | CPU | Memory | 197 |Type |Payload Type | Utilization | Utilization | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Session Setup Delay | Application Delay | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | IP Packet Delay Variation | Inter arrival Jitter | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Padding | Packet Discrd | Packet loss | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | SMI Enterprise Code = "xxx" | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Report Type = "yyy" | Length of Application Part | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | application/vendor specific extension | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | ............... | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | ............... | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | ............... | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | SMI Enterprise Code = "abc" | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | Report Type = "zzz" | Length of Application Part | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | application/vendor specific extension | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | ............... | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 Figure 1 - RAQMON Protocol Data Unit 228 2.1.2 The Basic Part of the RAQMON Protocol Data Unit 230 A RAQMON PDU must contain the following basic part fields at all 231 times: 233 PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being 234 sent. PDT = 1 is used for the current RAQMON PDU version. 236 basic (B): 1 bit - While set to 1, the basic flag indicates that the 237 PDU has basic part of the RAQMON PDU. A value of zero is considered 238 to be valid and indicates a RAQMON NULL PDU. 240 trailer (T) : 3 bits - Total number of Application Specific 241 Extensions that trail the BASIC Part of RAQMON PDU. A value of zero 242 is considered to be valid as it may constitute a RAQMON NULL PDU. 244 padding (P): 1 bit - If the padding bit is set, the basic Part of the 245 RAQMON PDU contains some additional padding octets at the end of the 246 Basic Part of the PDU which are not part of the monitoring 247 information. Padding may be needed in some cases as reporting is 248 based on the intent of a RDS to report certain parameters. Also some 249 parameters may be reported only once at the beginning of the 250 reporting session e.g. Data Source Name, Receiver Name, Pay Load type 251 etc. Actual padding at the end of the Basic part of the PDU, is 252 either 0,8, 16 or 24 bits to make the basic part of the PDU multiple 253 of 32 bits long. 255 Source IP version Flag (S): 1 bit - While set to 1, the source IP 256 version flag indicates that the Source IP address contained in the 257 PDU is a IPv6 address. 259 Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP 260 version flag indicates that the receiver IP address contained in the 261 PDU is a IPv6 address. 263 record count (RC): 4 bits - Total number of records contained in the 264 Basic part of the PDU. A value of zero is considered to be valid but 265 useless. 267 length: 16 bits - The length of the Basic Part of the RAQMON PDU in 268 32-bit words minus one which 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 same. To further reduce 280 the probability that two RDSs pick the same DSRC for two different 281 reporting session, it is recommended that an RRC use parameters like 282 Data Source Address (DA), Data Source Name (DN), MAC Address in the 283 PDU in conjunction with a DSRC value. It is not mandatory for RDSs to 284 send parameters like Data Source Address (DA), Data Source Name (DN), 285 MAC Address in every PDU sent to RRC, but sending these parameters 286 occasionally will reduce the probability of DSRC collision 287 drastically. However this will cause an additional overhead per PDU. 289 A value of zero for basic (B) bit and trailer (T) bits set 290 constitutes a RAQMON NULL PDU (i.e. nothing to report). RDSs MUST 291 send a RAQMON NULL PDU to RRC to indicate end of RDS reporting 292 session. All other parameters listed in the PDU described below are 293 optionally used when RDSs have some new information to send to RRC. 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 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | V |PDT = 1|B| T |P|I| RC | Length | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | DSRC | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | SMI Enterprise Code = 0 |Report Type = 0| RC_N | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU 313 Report Type: 8 bits - These bits are reserved by the IETF RMON Work 314 Group. A value of 0 within SMI Enterprise Code = 0 is used for this 315 version of the PDU. 317 The basic part of Each RAQMON PDU consists of Record Count Number 318 (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the 319 presence of appropriate RAQMON parameters within a record, as defined 320 in table 1. 322 RC_N: 8 bits - The Record Count number indicates a sub-session within 323 a communication session. A value of zero is a valid record number. 324 The maximum number of records that can be described in one RAQMON 325 Packet is 256. 327 RAQMON Parameter Presence Flags (RPPF): 32 bits 329 Each of these flags while set represent that this RAQMON PDU contains 330 corresponding parameters as specified in table 1. 332 Sequence Number Presence/Absence of corresponding 333 Parameter within this RAQMON PDU 335 0 Data Source Address (DA) 336 1 Receiver Address (RA) 337 2 NTP Timestamp 338 3 Application Name 339 4 Data Source Name (DN) 340 5 Receiver Name (RN) 341 6 Session Setup Status 342 7 Session Duration 343 8 Round Trip End-to-End Network Delay (RTT) 344 9 One Way End-to-End Network Delay (OWD) 345 0 Cumulative Packets Loss 346 1 Cumulative Packets Discards 347 2 Total number of Application Packets sent 348 3 Total number of Application Packets received 349 4 Total number of Application Octets sent 350 5 Total number of Application Octets received 351 6 Data Source Device Port Used 352 7 Receiver Device Port Used 353 8 Source Layer 2 Priority 354 9 Source Layer 3 Priority 355 0 Destination Layer 2 Priority 356 1 Destination Layer 3 Priority 357 2 Source Payload Type 358 3 Receiver Payload Type 359 4 CPU Utilization 360 5 Memory Utilization 361 6 Session Setup Delay 362 7 Application Delay 363 8 IP Packet Delay Variation 364 9 Inter arrival Jitter 365 0 Packet loss (in fraction) 366 1 Packet Discard (in fraction) 368 Table 1: RAQMON Parameters and corresponding RPPF 370 Data Source Address (DA): 32 bits or 160 bits in binary 371 representation - This metrics is defined in section 5.1 of [RAQMON- 372 FRAMEWORK]. IP version 6 addresses are incorporated in Data Source 373 Address by setting the source IP version flag (S bit) of the RAQMON 374 PDU header to 1. 376 Receiver Address (RA): 32 bits or 160 bits - This metrics is defined 377 in section 5.2 of [RAQMON-FRAMEWORK]. Follows exact same syntax as 378 Data Source Address but used to indicate a Receiver's Address. IP 379 version 6 addresses are incorporated in Receiver Address by setting 380 the receiver IP version flag (R bit) of the RAQMON PDU header to 1. 382 Data Source Name (DN): - This metric is defined in section 5.3 of 383 [RAQMON-FRAMEWORK]. The Data Source Name field starts with an 8-bit 384 octet count describing the length of the text followed by the text 385 itself. Note that the text can be no longer than 255 octets. The 386 text is encoded according to the UTF-2 encoding specified in Annex F 387 of ISO standard 10646 [ISO10646],[UNICODE]. This encoding is also 388 known as UTF-8 or UTF-FSS. Applications SHOULD instruct RDSs to send 389 out the Data Source Name infrequently to ensure efficient usage of 390 network resources as this parameter is expected to remain constant 391 for the duration of the reporting session. 393 Receiver Name (RN): - This metric is defined in section 5.4 of 394 [RAQMON-FRAMEWORK]. Like Data Source Name, the Receiver Name field 395 starts with an 8-bit octet count describing the length of the text 396 followed by the text itself. The Receiver Name is a multiple of 32 397 bits and follows the same padding rules as applied to the Data Source 398 Name. Since the Receiver Name is expected to remain constant during 399 entire reporting sessions, this information SHOULD be sent out 400 occasionally over random time intervals to maximize success of 401 reaching a RRC and also conserve network bandwidth. 403 Data Source Device Port Used: 16 bits - This metric is defined in 404 section 5.5 of [RAQMON-FRAMEWORK]and describes the port Number used 405 by the Data Source as used by the application in RC_N session while 406 this RAQMON PDU was generated. 408 Receiver Device Port Used: 16 bits - This metric is defined in 409 section 5.6 of [RAQMON-FRAMEWORK], and describes the receiver port 410 used by the application to communicate to the receiver. It follows 411 same syntax as Source Device Port Used. 413 Session Setup Date/Time (NTP timestamp): 64 bits - This metric is 414 defined in section 5.7 of [RAQMON-FRAMEWORK] represented using the 415 timestamp format of the Network Time Protocol (NTP), which is in 416 seconds [RFC 1305]. The full resolution NTP timestamp is a 64-bit 417 unsigned fixed-point number with the integer part in the first 32 418 bits and the fractional part in the last 32 bits. 420 A Data Source that does not support NTP SHOULD set the appropriate 421 RAQMON flag to 0 to avoid wasting 64 bits in the PDU. Since the NTP 422 time stamp is intended to provide the setup Date/Time of a session, 423 it is RECOMMENDED that the NTP Timestamp be used only in the first 424 RAQMON packet, to use network resources efficiently. 426 Session Setup Delay: 16 bits - The Session Setup Delay metric is 427 defined in section 5.8 of [RAQMON-FRAMEWORK] and expressed in 428 milliseconds. 430 Session Duration: 32 bits - The Session Setup Duration metric is 431 defined in section 5.9 of [RAQMON-FRAMEWORK]. Session Duration is an 432 unsigned integer expressed in seconds. 434 Session Setup Status: - The Session Setup Status is defined in 435 section 5.10 of [RAQMON-FRAMEWORK]. This field starts with an 8-bit 436 length field followed by the text itself. Session Setup Status is a 437 multiple of 32 bits. 439 Round Trip End-to-End Network Delay: 32 bits - The Round Trip End-to- 440 End Network Delay is defined in section 5.11 of [RAQMON-FRAMEWORK]. 441 This field represents the Round Trip End-to-End Delay of session 442 RC_N, which is an unsigned integer, expressed in milliseconds. 444 One Way End-to-End Network Delay: 32 bits - The One Way End-to-End 445 Network Delay is defined in section 5.12 of [RAQMON-FRAMEWORK]. This 446 field represents the One Way End-to-End Delay of sub-session RC_N, 447 which is an unsigned integer, expressed in milliseconds. 449 Application Delay: 16 bits - The Application Delay is defined in 450 section 5.13 of [RAQMON-FRAMEWORK] and is represented as an unsigned 451 integer expressed in milliseconds 453 Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined 454 in section 5.14 of [RAQMON-FRAMEWORK] and is represented as an 455 unsigned integer expressed in milliseconds. 457 IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is 458 defined in section 5.15 of [RAQMON-FRAMEWORK] and is represented as 459 an unsigned integer expressed in milliseconds. 461 Total number of Application Packets received: 32 bits - This 462 parameter is defined in section 5.16 of [RAQMON-FRAMEWORK] and is 463 represented as an unsigned integer, representing the total number of 464 packets transmitted within sub-session RC_N by the receiver. 466 Total number of Application Packets sent: 32 bits - This parameter is 467 defined in section 5.17 of [RAQMON-FRAMEWORK] as an unsigned integer, 468 representing the total number of packets transmitted within sub- 469 session RC_N by the sender. 471 Total number of Application Octets received: 32 bits - This parameter 472 is defined in section 5.18 of [RAQMON-FRAMEWORK] as an unsigned 473 integer representing the total number of payload octets (i.e., not 474 including header or padding) transmitted in packets by the receiver 475 within sub-session RC_N. 477 Total number of Application Octets sent: 32 bits - This parameter is 478 defined in section 5.19 of [RAQMON-FRAMEWORK] as an unsigned integer, 479 representing the total number of payload octets (i.e., not including 480 header or padding) transmitted in packets by the sender within sub- 481 session RC_N. 483 Cumulative Application Packet Loss: 32 bits - This parameter is 484 defined in section 5.20 of [RAQMON-FRAMEWORK] as an unsigned integer, 485 representing the total number of packets from sub-session RC_N that 486 have been lost while this RAQMON PDU was generated. 488 Packet Loss in Fraction: 8 bits - This parameter is defined in 489 section 5.21 of [RAQMON-FRAMEWORK] expressed as a fixed-point number, 490 with the binary point at the left edge of the field. The metric is 491 defined to be the number of packets lost divided by the number of 492 packets expected. The value is calculated by dividing the total 493 number of packets lost (after the effects of applying any error 494 protection such as FEC) by the total number of packets expected, 495 multiplying the result of the division by 256, limiting the maximum 496 value to 255 (to avoid overflow), and taking the integer part. 498 Cumulative Application Discards: 32 bits - This parameter is defined 499 in section 5.22 of [RAQMON-FRAMEWORK] as an unsigned integer 500 representing the total number of packets from sub-session RC_N that 501 have been discarded while this RAQMON PDU was generated. 503 Packet Discard in Fraction: 8 bits - This parameter is defined in 504 section 5.23 of [RAQMON-FRAMEWORK] expressed as a fixed point number 505 with the binary point at the left edge of the field. (That is 506 equivalent to taking the integer part after multiplying the discard 507 fraction by 256.) This metric is defined to be the number of packets 508 discarded divided by the total number of packets. 510 Source Payload Type: 8 bit - This parameter is defined in section 511 5.24 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the 512 payload type of the data source of the communication sub-session RC_N 513 as defined in [RFC 3550]. 515 Receiver Payload Type: 8 bit - This parameter is defined in section 516 5.25 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the 517 receiver payload type of the communication sub-session RC_N. 519 S_Layer2: 8 bits - This parameter defined in section 5.26 of [RAQMON- 520 FRAMEWORK] is a 8-bit field associated to source's IEEE 802.1D 521 priority tagging of traffic in the communication sub-session RC_N. 522 Since IEEE 802.1 priority tags are 3 bits-long, the first 3 bits of 523 this parameter represent the IEEE 802.1 tag value and the last 5 bits 524 are padded to 0. 526 S_Layer3: 8 bits - This parameter defined in section 5.27 of [RAQMON- 527 FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking 528 used to send packets to the receiver by this data source during sub- 529 session RC_N. 531 D_Layer2: 8 bits - This parameter defined in section 5.28 of [RAQMON- 532 FRAMEWORK] is a 8-bit field which represents layer 2 IEEE 802.1D 533 priority tags used by the receiver to send packets to the data source 534 during sub-session RC_N session if the Data Source can learn such 535 information. Since IEEE 802.1 priority tags are 3 bits-long, the 536 first 3 bits of this parameter represent the IEEE 802.1 priority tag 537 value and the last 5 bits are padded to 0. 539 D_Layer3: 8 bits - This parameter defined in section 5.29 of [RAQMON- 540 FRAMEWORK] is a 8-bit field which represents the layer 3 QoS marking 541 used by the receiver to send packets to the data source during sub- 542 session RC_N, if the Data Source can learn such information. 544 CPU Utilization: 8 bits - This parameter defined in section 5.30 of 545 [RAQMON-FRAMEWORK] represents the percentage of CPU used during 546 session RC_N up until the time this RAQMON PDU was generated. The CPU 547 Utilization is expressed in percents in the range 0 to 100. The value 548 should indicate not only CPU utilization associated to a session RC_N 549 but also actual CPU Utilization, to indicate a snapshot of the end 550 device CPU utilization while session RC_N in progress. 552 Memory Utilization: 8 bits - This parameter defined in section 5.31 553 of [RAQMON-FRAMEWORK] represents the percentage of total memory used 554 during session RC_N up until the time this RAQMON PDU was generated. 555 The memory utilization is expressed in percents 0 to 100. The Memory 556 Utilization value should indicate not only the memory utilization 557 associated to a session RC_N but the total memory utilization, to 558 indicate a snapshot of end device memory utilization while session 559 RC_N in progress. 561 Application Name: - This parameter is defined in section 5.32 of 562 [RAQMON-FRAMEWORK]. The Application Name field starts with an 8-bit 563 octet count describing the length of the text followed the text 564 itself. Application Name field is multiple of 32 bits. 566 padding: 0, 8, 16 or 24 bits - If the padding bit (P) is set , then 567 this field may be present. The actual padding at the end of the Basic 568 part of the PDU is 0,8, 16 or 24 bits to make the basic part of the 569 PDU multiple of 32 bits long. 571 2.1.3 APP Part of RAQMON Protocol Data Unit 573 The APP part of the RAQMON PDU is intended for experimental use as 574 new applications and new features are developed, without requiring a 575 PDU type value registration. 577 Vendors may design and publish application specific extensions. Any 578 RAQMON compliant RRC MUST be able to recognize vendors SMI Enterprise 579 Code and Report Type fields, and MUST recognize the presence of 580 application specific extensions that trail behind these fileds. There 581 is no need for the RRC to understand the semantics of the Enterprise 582 specific parts of the PDU. 584 SMI Enterprise Code: 32 bits - Vendors and Application developers 585 should fill in appropriate SMI Enterprise IDs available at 586 http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI 587 Enterprise Code indicates a vendor or application specific extension. 589 RAQMON PDUs are capable of carrying multiple Application Parts within 590 a PDU. 592 Report Type: 16 bits - Vendors and Application developers should fill 593 in appropriate Report type within a specified SMI Enterprise Code. It 594 is recommended that vendors publish application specific extensions 595 and maintain such report types for better interoperability. 597 Length of the Application Part: 16 bits - The length of the 598 Application Part of the RAQMON PDU in 32-bit words minus one, which 599 includes the header of the Application Part. 601 application-dependent data: variable length - Application/vendor- 602 dependent data is defined by the application developers. It is 603 interpreted by the vendor specific application and not by the RRC 604 itself. It must be a multiple of 32 bits long. 606 2.1.4 Byte Order, Alignment, and Time Format of RAQMON PDUs 608 All integer fields are carried in network byte order, that is, most 609 significant byte (octet) first. This byte order is commonly known as 610 big-endian. The transmission order is described in detail in 611 [RFC791]. Unless otherwise noted, numeric constants are in decimal 612 (base 10). 614 All header data is aligned to its natural length, i.e., 16-bit fields 615 are aligned on even offsets, 32-bit fields are aligned at offsets 616 divisible by four, etc. Octets designated as padding have the value 617 zero. 619 2.1.5 IANA Considerations 621 Applications using RAQMON Framework requires a single fixed port. 622 Port numbers 7XXX have been registered with IANA for use as the 623 default port for RAQMON PDUs over TCP. Hosts that run multiple 624 applications may use this port as an indication to have used RAQMON 625 or provision a separate TCP port as part of provisioning RAQMON RDS 626 and RAQMON Collector. 628 [editor note - 7XXX will be completely specified at RFC release, 629 after IANA allocates the number, and this note will be removed] 631 The particular port number was chosen to lie in the range above 5000 632 to accommodate port number allocation practice within the Unix 633 operating system, where privileged processes can only use port 634 numbers below 1024 and port numbers between 1024 and 5000 are 635 automatically assigned by the operating systems. 637 2.2 SNMP Notifications as an RDS/RRC Network Transport Protocol 638 It was an inherent objective of the RAQMON Framework to re-use 639 existing application level transport protocols to maximize the usage 640 of existing installations as well as to avoid transport protocol 641 level complexities in the design process. Choice of SNMP as a means 642 to transport RAQMON PDU was motivated by that intent. 644 If SNMP is chosen as a mechanism to transport RAQMON PDUs, the 645 following specification applies to RAQMON related usage of SNMP: 647 + RDSs implement the capability of embedding RAQMON parameters in 648 SNMP Notifications, re-using well known SNMP mechanisms to 649 report RAQMON Statistics. The RAQMON RDS MIB module as 650 specified in 2.1.1 MUST be used in order to map the RAQMON PDUs 651 onto the SNMP Notifications transport. 653 Managed objects are accessed via a virtual information store, termed 654 the Management Information Base or MIB. MIB objects are generally 655 accessed through the Simple Network Management Protocol (SNMP). 656 Objects in the MIB are defined using the mechanisms defined in the 657 Structure of Management Information (SMI). For a detailed overview 658 of the documents that describe the current Internet-Standard 659 Management Framework, please refer to section 7 of RFC 3410 660 [RFC3410]. 662 + Since RDSs are not computationally rich and to keep the RDS 663 realization as lightweight as possible, RDSs MAY fail to 664 respond to SNMP requests like GET, SET, etc., with the 665 exception of the GET and SET commands required to implement the 666 User-Based Security Model (USM) defined by [RFC 3414]. 668 + In order to meet congestion safety requirements, SNMP INFORM 669 PDUs SHOULD be used. In case INFORM PDUs are used, RDSs MUST 670 process the SNMP INFORM responses from RRCs, and MAY serialize 671 the PDU transmission rate, i.e. limit the number of PDUS sent 672 in a specific time interval. 674 + Standard UDP port 162 SHOULD be used for SNMP Notifications. 676 2.2.1 Encoding RAQMON PDUs using the RAQMON RDS MIB module 678 The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP 679 Notifications for transport purposes. The MIB modules defines the 680 objects needed for mapping the Basic part of RAQMON PDU defined in 681 [RAQMON-FRAMEWOK] as well as the Notifications themselves. In order 682 to incorporate any application-specific extensions in the Application 683 (APP) part of RAQMON PDU as defined in [RAQMON-FRAMEWOK], additional 684 variable bindings MAY be included in RAQMON notifications as 685 described in the MIB module. 687 This section specifies a MIB module that is compliant to the SMIv2, 688 which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 689 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 691 RAQMON-RDS-MIB DEFINITIONS ::= BEGIN 693 IMPORTS 694 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 695 Counter32, Integer32, Unsigned32 696 FROM SNMPv2-SMI 698 DateAndTime 699 FROM SNMPv2-TC 701 rmon 702 FROM RMON-MIB 704 SnmpAdminString 705 FROM SNMP-FRAMEWORK-MIB 707 InetAddressType, InetAddress 708 FROM INET-ADDRESS-MIB 710 Dscp 711 FROM DIFFSERV-DSCP-TC 713 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 714 FROM SNMPv2-CONF; 716 raqmonDs MODULE-IDENTITY 717 LAST-UPDATED "200410140000Z" -- October 14, 2004 718 ORGANIZATION "RMON Working Group" 719 CONTACT-INFO 720 "WG EMail: rmonmib@ietf.org 721 Subscribe: rmonmib-request@ietf.org 723 MIB Editor: 724 Eugene Golovinsky 725 Postal: BMC Software, Inc. 726 2101 CityWest Boulevard, 727 Houston, TX, 77094 728 USA 729 Tel: +713-918-1816 730 Email: egolovin@bmc.com 731 " 732 DESCRIPTION 733 "This is the RAQMON Data Source notification MIB Module. It 734 provides a mapping of RAQMON PDUs to SNMP Notifications. 736 Ds stands for data source. 738 Note that all of the object types defined in this module are 739 accessible-for-notify, and would consequently not be 740 available to a browser using simple Get, GetNext, or GetBulk 741 requests. 743 Copyright (c) The Internet Society (2004). 745 -- RFC EDITOR: please replace yyyy with actual number 746 This version of this MIB module is part of RFC yyyy; See the 747 RFC itself for full legal notices. 748 " 750 REVISION "200410140000Z" -- October 14, 2004 751 DESCRIPTION 752 "Changes after the 60th IETF." 754 REVISION "200406150000Z" -- June 15, 2004 755 DESCRIPTION 756 "Changes after the 59th IETF." 758 REVISION "200311111150Z" -- November 11, 2003 759 DESCRIPTION 760 "Changes after the 58th IETF." 762 ::= { rmon 32 } 764 -- This OID allocation conforms to [RFC3737] 766 raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDs 0 } 767 raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDs 1 } 768 raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDs 2 } 770 raqmonDsNotificationTable OBJECT-TYPE 771 SYNTAX SEQUENCE OF RaqmonDsNotificationEntry 772 MAX-ACCESS not-accessible 773 STATUS current 774 DESCRIPTION 775 "This conceptual table provides the SNMP mapping of the 776 RAQMON Basic PDU. It is indexed by the RAQMON Data Source, 777 sub-session, and address of the peer entity. 779 Note that there is no concern about the indexation of this 780 table exceeding the limits defined by RFC 2578 Section 3.5. 781 According to [RAQMON-FRAMEWORK], Section 5.1, only IPv4 and 782 IPv6 addresses can be reported as participant addresses. 783 " 784 ::= { raqmonDsMIBObjects 1 } 786 raqmonDsNotificationEntry OBJECT-TYPE 787 SYNTAX RaqmonDsNotificationEntry 788 MAX-ACCESS not-accessible 789 STATUS current 790 DESCRIPTION 791 "The entry (row) is not retrievable and is not kept by RDSs. 792 It serves data organization purpose only. 793 " 794 INDEX { raqmonDSRC, raqmonRCN, raqmonPeerAddrType, 795 raqmonPeerAddr } 796 ::= { raqmonDsNotificationTable 1 } 798 RaqmonDsNotificationEntry ::= SEQUENCE { 799 raqmonDSRC Unsigned32, 800 raqmonRCN Integer32, 801 raqmonPeerAddrType InetAddressType, 802 raqmonPeerAddr InetAddress, 803 raqmonAppName SnmpAdminString, 804 raqmonDataSourceDevicePort Unsigned32, 805 raqmonReceiverDevicePort Unsigned32, 806 raqmonSessionSetupDateTime DateAndTime, 807 raqmonSessionSetupDelay Unsigned32, 808 raqmonSessionDuration Unsigned32, 809 raqmonSessionSetupStatus SnmpAdminString, 810 raqmonRoundTripEndToEndNetDelay Unsigned32, 811 raqmonOneWayEndToEndNetDelay Unsigned32, 812 raqmonApplicationDelay Unsigned32, 813 raqmonInterArrivalJitter Unsigned32, 814 raqmonIPPacketDelayVariation Unsigned32, 815 raqmonTotalPacketsReceived Counter32, 816 raqmonTotalPacketsSent Counter32, 817 raqmonTotalOctetsReceived Counter32, 818 raqmonTotalOctetsSent Counter32, 819 raqmonCumulativePacketLoss Counter32, 820 raqmonPacketLossFraction Unsigned32, 821 raqmonCumulativeDiscards Counter32, 822 raqmonDiscardsFraction Unsigned32, 823 raqmonSourcePayloadType Unsigned32, 824 raqmonReceiverPayloadType Unsigned32, 825 raqmonSourceLayer2Priority Unsigned32, 826 raqmonSourceDscp Dscp, 827 raqmonDestinationLayer2Priority Unsigned32, 828 raqmonDestinationDscp Dscp, 829 raqmonCpuUtilization Unsigned32, 830 raqmonMemoryUtilization Unsigned32 } 832 raqmonDSRC OBJECT-TYPE 833 SYNTAX Unsigned32 834 MAX-ACCESS accessible-for-notify 835 STATUS current 836 DESCRIPTION 837 "Data Source identifier represents a unique session 838 descriptor that points to a specific communication session 839 between communicating entities. Identifiers unique for 840 sessions conducted between two entities are 841 generated by the communicating entities." 842 ::= { raqmonDsNotificationEntry 1 } 844 raqmonRCN OBJECT-TYPE 845 SYNTAX Integer32 (0..15) 846 MAX-ACCESS accessible-for-notify 847 STATUS current 848 DESCRIPTION 849 "The Record Count Number indicates a sub-session 850 within a communication session. A maximum number of 16 851 sub-sessions are supported - this limitation is dictated 852 by reasons of compatibility with other transport protocols." 853 ::= { raqmonDsNotificationEntry 2 } 855 raqmonPeerAddrType OBJECT-TYPE 856 SYNTAX InetAddressType 857 MAX-ACCESS accessible-for-notify 858 STATUS current 859 DESCRIPTION 860 "The type of the Internet address of the peer participant 861 for this session." 862 REFERENCE 863 "Section 5.2 of [RAQMON-FRAMEWORK]" 864 ::= { raqmonDsNotificationEntry 3 } 866 raqmonPeerAddr OBJECT-TYPE 867 SYNTAX InetAddress 868 MAX-ACCESS accessible-for-notify 869 STATUS current 870 DESCRIPTION 871 "The Internet Address of the peer participant for this 872 session." 873 REFERENCE 874 "Section 5.2 of [RAQMON-FRAMEWORK]" 875 ::= { raqmonDsNotificationEntry 4 } 877 raqmonAppName OBJECT-TYPE 878 SYNTAX SnmpAdminString 879 MAX-ACCESS accessible-for-notify 880 STATUS current 881 DESCRIPTION 882 "This is a text string giving the name and possibly version 883 of the application associated with that session, 884 e.g., 'XYZ VoIP Agent 1.2'." 885 REFERENCE 886 "Section 5.28 of [RAQMON-FRAMEWORK]" 887 ::= { raqmonDsNotificationEntry 5 } 889 raqmonDataSourceDevicePort OBJECT-TYPE 890 SYNTAX Unsigned32 (0..65535) 891 MAX-ACCESS accessible-for-notify 892 STATUS current 893 DESCRIPTION 894 "The port number from which data for this session was sent 895 by the Data Source device." 896 REFERENCE 897 "Section 5.5 of [RAQMON-FRAMEWORK]" 898 ::= { raqmonDsNotificationEntry 6 } 900 raqmonReceiverDevicePort OBJECT-TYPE 901 SYNTAX Unsigned32 (0..65535) 902 MAX-ACCESS accessible-for-notify 903 STATUS current 904 DESCRIPTION 905 "The port number where the data for this session was received." 906 REFERENCE 907 "Section 5.6 of [RAQMON-FRAMEWORK]" 908 ::= { raqmonDsNotificationEntry 7 } 910 raqmonSessionSetupDateTime OBJECT-TYPE 911 SYNTAX DateAndTime 912 MAX-ACCESS accessible-for-notify 913 STATUS current 914 DESCRIPTION 915 "The time when session was initiated." 916 REFERENCE 917 "Section 5.7 of [RAQMON-FRAMEWORK]" 918 ::= { raqmonDsNotificationEntry 8 } 920 raqmonSessionSetupDelay OBJECT-TYPE 921 SYNTAX Unsigned32 922 UNITS "milliseconds" 923 MAX-ACCESS accessible-for-notify 924 STATUS current 925 DESCRIPTION 926 "Session setup time." 927 REFERENCE 928 "Section 5.8 of [RAQMON-FRAMEWORK]" 929 ::= { raqmonDsNotificationEntry 9 } 931 raqmonSessionDuration OBJECT-TYPE 932 SYNTAX Unsigned32 933 UNITS "seconds" 934 MAX-ACCESS accessible-for-notify 935 STATUS current 936 DESCRIPTION 937 "Session duration, including setup time. The SYNTAX of this 938 object allows to express the duration of sessions that do 939 not exceed 4660 hours and 20 minutes." 940 REFERENCE 941 "Section 5.9 of [RAQMON-FRAMEWORK]" 942 ::= { raqmonDsNotificationEntry 10 } 944 raqmonSessionSetupStatus OBJECT-TYPE 945 SYNTAX SnmpAdminString 946 MAX-ACCESS accessible-for-notify 947 STATUS current 948 DESCRIPTION 949 "Describes appropriate communication session states e.g. 950 Call Established successfully, RSVP reservation 951 failed etc." 952 REFERENCE 953 "Section 5.10 of [RAQMON-FRAMEWORK]" 954 ::= { raqmonDsNotificationEntry 11 } 956 raqmonRoundTripEndToEndNetDelay OBJECT-TYPE 957 SYNTAX Unsigned32 958 UNITS "milliseconds" 959 MAX-ACCESS accessible-for-notify 960 STATUS current 961 DESCRIPTION 962 "Most recent available information about the 963 round trip end to end network delay." 964 REFERENCE 965 "Section 5.11 of [RAQMON-FRAMEWORK]" 966 ::= { raqmonDsNotificationEntry 12} 968 raqmonOneWayEndToEndNetDelay OBJECT-TYPE 969 SYNTAX Unsigned32 970 UNITS "milliseconds" 971 MAX-ACCESS accessible-for-notify 972 STATUS current 973 DESCRIPTION 974 " Most recent available information about the 975 one way end to end network delay." 976 REFERENCE 977 "Section 5.12 of [RAQMON-FRAMEWORK]" 978 ::= { raqmonDsNotificationEntry 13} 980 raqmonApplicationDelay OBJECT-TYPE 981 SYNTAX Unsigned32 982 UNITS "milliseconds" 983 MAX-ACCESS accessible-for-notify 984 STATUS current 985 DESCRIPTION 986 " Most recent available information about the 987 application delay." 988 REFERENCE 989 "Section 5.13 of [RAQMON-FRAMEWORK]" 990 ::= { raqmonDsNotificationEntry 14} 992 raqmonInterArrivalJitter OBJECT-TYPE 993 SYNTAX Unsigned32 994 UNITS "milliseconds" 995 MAX-ACCESS accessible-for-notify 996 STATUS current 997 DESCRIPTION 998 "An estimate of the inter-arrival jitter." 999 REFERENCE 1000 "Section 5.14 of [RAQMON-FRAMEWORK]" 1001 ::= { raqmonDsNotificationEntry 15} 1003 raqmonIPPacketDelayVariation OBJECT-TYPE 1004 SYNTAX Unsigned32 1005 UNITS "milliseconds" 1006 MAX-ACCESS accessible-for-notify 1007 STATUS current 1008 DESCRIPTION 1009 "An estimate of the inter-arrival delay variation." 1010 REFERENCE 1011 "Section 5.15 of [RAQMON-FRAMEWORK]" 1012 ::= { raqmonDsNotificationEntry 16} 1014 raqmonTotalPacketsReceived OBJECT-TYPE 1015 SYNTAX Counter32 1016 UNITS "packets" 1017 MAX-ACCESS accessible-for-notify 1018 STATUS current 1019 DESCRIPTION 1020 "The number of packets transmitted within a communication 1021 session by the receiver since starting transmission up until 1022 the time this RAQMON PDU was generated. 1023 " 1024 REFERENCE 1025 "Section 5.16 of [RAQMON-FRAMEWORK]" 1026 ::= { raqmonDsNotificationEntry 17 } 1028 raqmonTotalPacketsSent OBJECT-TYPE 1029 SYNTAX Counter32 1030 UNITS "packets" 1031 MAX-ACCESS accessible-for-notify 1032 STATUS current 1033 DESCRIPTION 1034 "The number of packets transmitted within a communication 1035 session by the sender since starting transmission up until 1036 the time this RAQMON PDU was generated. 1037 " 1038 REFERENCE 1039 "Section 5.17 of [RAQMON-FRAMEWORK]" 1040 ::= { raqmonDsNotificationEntry 18 } 1042 raqmonTotalOctetsReceived OBJECT-TYPE 1043 SYNTAX Counter32 1044 UNITS "octets" 1045 MAX-ACCESS accessible-for-notify 1046 STATUS current 1047 DESCRIPTION 1048 "The total number of payload octets (i.e., not including 1049 header or padding octets) transmitted in packets by the 1050 receiver within a communication session since starting 1051 transmission up until the time this RAQMON PDU was 1052 generated. 1053 " 1054 REFERENCE 1055 "Section 5.18 of [RAQMON-FRAMEWORK]" 1056 ::= { raqmonDsNotificationEntry 19 } 1058 raqmonTotalOctetsSent OBJECT-TYPE 1059 SYNTAX Counter32 1060 UNITS "octets" 1061 MAX-ACCESS accessible-for-notify 1062 STATUS current 1063 DESCRIPTION 1064 "The number of payload octets (i.e., not including headers 1065 or padding) transmitted in packets by the sender within 1066 a communication session since starting transmission up 1067 until the time this RAQMON notification was generated." 1068 REFERENCE 1069 "Section 5.19 of [RAQMON-FRAMEWORK]" 1070 ::= { raqmonDsNotificationEntry 20 } 1072 raqmonCumulativePacketLoss OBJECT-TYPE 1073 SYNTAX Counter32 1074 UNITS "packets" 1075 MAX-ACCESS accessible-for-notify 1076 STATUS current 1077 DESCRIPTION 1078 "The number of packets from this session whose loss had been 1079 detected when this notification was generated. 1080 " 1081 REFERENCE 1082 "Section 5.20 of [RAQMON-FRAMEWORK]" 1083 ::= { raqmonDsNotificationEntry 21 } 1085 raqmonPacketLossFraction OBJECT-TYPE 1086 SYNTAX Unsigned32 (0..100) 1087 UNITS "percentage of packets sent" 1088 MAX-ACCESS accessible-for-notify 1089 STATUS current 1090 DESCRIPTION 1091 "The percentage of lost packets with respect to the overall 1092 packets sent. This is defined to be 100 times the number 1093 of packets lost divided by the number of packets expected." 1094 REFERENCE 1095 "Section 5.21 of [RAQMON-FRAMEWORK]" 1096 ::= { raqmonDsNotificationEntry 22 } 1098 raqmonCumulativeDiscards OBJECT-TYPE 1099 SYNTAX Counter32 1100 UNITS "packets" 1101 MAX-ACCESS accessible-for-notify 1102 STATUS current 1103 DESCRIPTION 1104 "The number of packet discards 1105 detected when this notification was generated." 1106 REFERENCE 1107 "Section 5.22 of [RAQMON-FRAMEWORK]" 1108 ::= { raqmonDsNotificationEntry 23 } 1110 raqmonDiscardsFraction 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 discards with respect to the overall 1117 packets sent. This is defined to be 100 times the number 1118 of discards divided by the number of packets expected." 1119 REFERENCE 1120 "Section 5.23 of [RAQMON-FRAMEWORK]" 1121 ::= { raqmonDsNotificationEntry 24 } 1123 raqmonSourcePayloadType OBJECT-TYPE 1124 SYNTAX Unsigned32 (0..127) 1125 MAX-ACCESS accessible-for-notify 1126 STATUS current 1127 DESCRIPTION 1128 "The payload type of the packet sent by this RDS." 1129 REFERENCE 1130 "RFC 1890, Section 5.24 of [RAQMON-FRAMEWORK] " 1131 ::= { raqmonDsNotificationEntry 25 } 1133 raqmonReceiverPayloadType OBJECT-TYPE 1134 SYNTAX Unsigned32 (0..127) 1135 MAX-ACCESS accessible-for-notify 1136 STATUS current 1137 DESCRIPTION 1138 "The payload type of the packet received by this RDS." 1139 REFERENCE 1140 "RFC 1890, Section 5.25 of [RAQMON-FRAMEWORK] " 1141 ::= { raqmonDsNotificationEntry 26 } 1143 raqmonSourceLayer2Priority OBJECT-TYPE 1144 SYNTAX Unsigned32 (0..7) 1145 MAX-ACCESS accessible-for-notify 1146 STATUS current 1147 DESCRIPTION 1148 "Source Layer 2 priority used by the sata source to send 1149 packets to the receiver by this data source during this 1150 communication session. 1151 " 1152 REFERENCE 1153 "Section 5.26 of [RAQMON-FRAMEWORK]" 1154 ::= { raqmonDsNotificationEntry 27 } 1156 raqmonSourceDscp OBJECT-TYPE 1157 SYNTAX Dscp 1158 MAX-ACCESS accessible-for-notify 1159 STATUS current 1160 DESCRIPTION 1161 "Layer 3 TOS/DSCP values used by the Data Source to 1162 prioritize traffic sent." 1163 REFERENCE 1164 "Section 5.27 of [RAQMON-FRAMEWORK]" 1166 ::= { raqmonDsNotificationEntry 28 } 1168 raqmonDestinationLayer2Priority OBJECT-TYPE 1169 SYNTAX Unsigned32 (0..7) 1170 MAX-ACCESS accessible-for-notify 1171 STATUS current 1172 DESCRIPTION 1173 "Destination Layer 2 priority. This is the priority use by 1174 the peer communicating entity to send packets to the data 1175 source. 1176 " 1177 REFERENCE 1178 "Section 5.28 of [RAQMON-FRAMEWORK]" 1179 ::= { raqmonDsNotificationEntry 29 } 1181 raqmonDestinationDscp OBJECT-TYPE 1182 SYNTAX Dscp 1183 MAX-ACCESS accessible-for-notify 1184 STATUS current 1185 DESCRIPTION 1186 "Layer 3 TOS/DSCP values used by the 1187 peer communicating entiy to prioritize traffic 1188 sent to the source." 1189 REFERENCE 1190 "Section 5.29 of [RAQMON-FRAMEWORK]" 1191 ::= { raqmonDsNotificationEntry 30 } 1193 raqmonCpuUtilization OBJECT-TYPE 1194 SYNTAX Unsigned32 (0..100) 1195 UNITS "percent" 1196 MAX-ACCESS accessible-for-notify 1197 STATUS current 1198 DESCRIPTION 1199 "Latest available information about the total CPU utilization." 1200 REFERENCE 1201 "Section 5.30 of [RAQMON-FRAMEWORK]" 1202 ::= { raqmonDsNotificationEntry 31 } 1204 raqmonMemoryUtilization OBJECT-TYPE 1205 SYNTAX Unsigned32 (0..100) 1206 UNITS "percent" 1207 MAX-ACCESS accessible-for-notify 1208 STATUS current 1209 DESCRIPTION 1210 "Latest available information about the total memory utilization." 1211 REFERENCE 1212 "Section 5.31 of [RAQMON-FRAMEWORK]" 1213 ::= { raqmonDsNotificationEntry 32 } 1215 -- definitions of the notifications 1216 -- 1217 -- The object lists include only the OBJECTS that will be sent by an 1218 -- RD every time the notification is generated. 1219 -- Other objects from the raqmonDsNotificationTable may be included 1220 -- in the variable binding list. 1221 -- 1223 raqmonDsNotification NOTIFICATION-TYPE 1224 OBJECTS { raqmonDSRC, 1225 raqmonRCN, 1226 raqmonPeerAddrType, 1227 raqmonPeerAddr 1228 } 1229 STATUS current 1230 DESCRIPTION 1231 "This notification maps the Basic RAQMON PDU onto an SNMP 1232 transport. 1233 " 1234 ::= { raqmonDsEvents 1 } 1236 raqmonDsByeNotification NOTIFICATION-TYPE 1237 OBJECTS { raqmonDSRC, 1238 raqmonPeerAddrType, 1239 raqmonPeerAddr 1240 } 1241 STATUS current 1242 DESCRIPTION 1243 "The BYE Notification. This Notification is the equivalent of 1244 the RAQMON BYE PDU, which signals the end of a RAQMON 1245 session. 1246 " 1247 ::= { raqmonDsEvents 2 } 1249 -- 1250 -- conformance information 1251 -- These don't show up on the wire, so they only need to be unique. 1252 -- 1253 raqmonDsCompliances OBJECT IDENTIFIER ::= { raqmonDsConformance 1 } 1254 raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } 1256 raqmonDsBasicCompliances MODULE-COMPLIANCE 1257 STATUS current 1258 DESCRIPTION 1259 "The compliance statement for SNMP entities which 1260 implement this MIB module." 1261 MODULE -- this module 1262 MANDATORY-GROUPS { raqmonDsNotificationGroup, 1263 raqmonDsPayloadGroup } 1264 ::= { raqmonDsCompliances 1 } 1266 raqmonDsNotificationGroup NOTIFICATION-GROUP 1267 NOTIFICATIONS { raqmonDsNotification, 1268 raqmonDsByeNotification } 1269 STATUS current 1270 DESCRIPTION 1271 "The notifications implemented by an SNMP entity claiming 1272 conformance to this MIB. 1273 " 1274 ::= { raqmonDsGroups 1 } 1276 raqmonDsPayloadGroup OBJECT-GROUP 1277 OBJECTS { raqmonDSRC, 1278 raqmonRCN, 1279 raqmonPeerAddrType, 1280 raqmonPeerAddr, 1281 raqmonAppName, 1282 raqmonDataSourceDevicePort, 1283 raqmonReceiverDevicePort, 1284 raqmonSessionSetupDateTime, 1285 raqmonSessionSetupDelay, 1286 raqmonSessionDuration, 1287 raqmonSessionSetupStatus, 1288 raqmonRoundTripEndToEndNetDelay, 1289 raqmonOneWayEndToEndNetDelay, 1290 raqmonApplicationDelay, 1291 raqmonInterArrivalJitter, 1292 raqmonIPPacketDelayVariation, 1293 raqmonTotalPacketsReceived, 1294 raqmonTotalPacketsSent, 1295 raqmonTotalOctetsReceived, 1296 raqmonTotalOctetsSent, 1297 raqmonCumulativePacketLoss, 1298 raqmonPacketLossFraction, 1299 raqmonCumulativeDiscards, 1300 raqmonDiscardsFraction, 1301 raqmonSourcePayloadType, 1302 raqmonReceiverPayloadType, 1303 raqmonSourceLayer2Priority, 1304 raqmonSourceDscp, 1305 raqmonDestinationLayer2Priority, 1306 raqmonDestinationDscp, 1307 raqmonCpuUtilization, 1308 raqmonMemoryUtilization } 1309 STATUS current 1310 DESCRIPTION 1311 "These objects are required for entities claiming conformance 1312 to this MIB." 1313 ::= { raqmonDsGroups 2 } 1315 END 1317 3. Congestion-Safe RAQMON Operation 1319 As outlined in earlier sections, TCP congestion control mechanism 1320 provides inherent congestion safety features when TCP is implemnted 1321 as transport to carry RAQMON PDU. 1323 To ensure congestion safety, clearly the best thing to do is to use a 1324 congestion-safe transport protocol such as TCP. If this is not 1325 feasible, it may be necessary to fall back to UDP since SNMP over UDP 1326 is more widely deployed transport protocol. 1328 When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow 1329 section 3.0 of [RAQMON-FRAMEWORK] guidelines that outlines measures 1330 that MUST be taken to use RAQMON in congestion safe manner. 1331 Congestion safety requirements in section 3.0 of [RAQMON-FRAMEWORK] 1332 would ensure that a RAQMON implementation using SNMP over UDP does 1333 not lead to congestion under heavy network load. 1335 4. Normative References 1337 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1338 1981. 1340 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, RFC 793, 1341 September 1981. 1343 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1344 Rose, M. and S. Waldbusser, "Structure of Management 1345 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1346 1999. 1348 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1349 Rose, M. and S. Waldbusser, "Textual Conventions for 1350 SMIv2", STD 58, RFC 2579, April 1999. 1352 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1353 Rose, M. and S. Waldbusser, "Conformance Statements for 1354 SMIv2", STD 58, RFC 2580, April 1999. 1356 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 1357 Information Base", STD 59, RFC 2819, May 2000. 1359 [RAQMON-FRAMEWORK] Siddiqui, A., Romascanu, D. and E. Golovinsky, 1360 "Framework for Real-time Application Quality of Service 1361 Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon- 1362 framework-08.txt, December 2004. 1364 5. Informative References 1366 [RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, 1367 April 1992. 1369 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1370 Requirement Levels", BCP 14, RFC 2119, March 1997. 1372 [RFC3550] H. Schulzrinne, "RTP Profile for Audio and Video 1373 Conferences with Minimal Control" RFC 3550, July 2003. 1375 [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, 1376 March 1992. 1378 [RFC1034] Mockapetris, P., "Domain Names - Concepts and 1379 Facilities", STD 13, RFC 1034, November 1987. 1381 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 1382 Specification", STD 13, RFC 1035, November 1987. 1384 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1385 and Support", STD 3, RFC 1123, October 1989. 1387 [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de 1388 Groot, "Address Allocation for Private Internets", RFC 1389 1597, March 1994. 1391 [RFC2679] G. Almes, S.Kalidindi and M.Zekauskas, "A One-way Delay 1392 Metric for IPPM", RFC 2679, September 1999 1394 [RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet 1395 Loss Metric for IPPM", RFC 2680, September 1999 1397 [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay 1398 Metric for IPPM", RFC 2681, September 1999 1400 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 1401 Jacobson, "RTP: A Transport Protocol for Real-Time 1402 Applications", RFC 3550, July 2003. 1404 [ISO10646] International Standards Organization, "ISO/IEC DIS 1405 10646-1:1993information technology -- universal multiple- 1406 octet coded character set (UCS) -- part I: Architecture 1407 and basic multilingual plane," 1993. 1409 [UNICODE] The Unicode Consortium, The Unicode Standard New York, 1410 New York:Addison-Wesley, 1991. 1412 [IEEE802.1D] Information technology-Telecommunications and 1413 information exchange between systems--Local and 1414 metropolitan area networks-Common Specification a--Media 1415 access control (MAC) bridges:15802-3: 1998 (ISO/IEC) 1416 [ANSI/IEEE Std 802.1D, 1998 Edition] 1418 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol 1419 Suite", RFC 1349, July 1992 1421 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812, 1422 June 1995 1424 [RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition 1425 of the Differentiated Services Field (DS Field) in the 1426 IPv4 and IPv6 Headers", RFC2474, December 1998 1428 [RFC3291] Daniele, M., Haberman, B., Routhier, S., and J. 1429 Schoenwaelder "Textual Conventions for Internet Network 1430 Addresses", RFC 3291, May 2002. 1432 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1433 "Introduction and Applicability Statements for Internet- 1434 Standard Management Framework", RFC 3410, December 2002. 1436 [RFC3414] Blumenthal U., and B. Wijnen, "User-based Security Model 1437 (USM) for version 3 of the Simple Network Management 1438 Protocol (SNMPv3)", RFC 3414, December 2002. 1440 [RFC3737] Wijnen B., and A.Bierman "IANA Guidelines for the 1441 Registry of Remote Monitoring (RMON) MIB modules", RFC 1442 3737, April 2004. 1444 [3DES] American National Standards Institute, ANSI X9.52-1998, 1445 "Triple Data Encryption Algorithm Modes of Operation" 1446 1998. 1448 [AES] Federal Information Processing Standard (FIPS), 1449 "Specification for the ADVANCED ENCRYPTION 1450 STANDARD(AES)", Publication 197, November 2001. 1452 6. Intellectual Property 1454 The IETF takes no position regarding the validity or scope of any 1455 intellectual property or other rights that might be claimed to 1456 pertain to the implementation or use of the technology described in 1457 this document or the extent to which any license under such rights 1458 might or might not be available; neither does it represent that it 1459 has made any effort to identify any such rights. Information on the 1460 IETF's procedures with respect to rights in standards-track and 1461 standards-related documentation can be found in BCP-11. Copies of 1462 claims of rights made available for publication and any assurances of 1463 licenses to be made available, or the result of an attempt made to 1464 obtain a general license or permission for the use of such 1465 proprietary rights by implementors or users of this specification can 1466 be obtained from the IETF Secretariat. 1468 The IETF invites any interested party to bring to its attention any 1469 copyrights, patents or patent applications, or other proprietary 1470 rights which may cover technology that may be required to practice 1471 this standard. Please address the information to the IETF Executive 1472 Director. 1474 By submitting this Internet-Draft, we certify that any applicable 1475 patent or other IPR claims of which we are aware have been disclosed, 1476 and any of which we become aware will be disclosed, in accordance 1477 with RFC 3668. 1479 7. Acknowledgements 1481 The authors would like to thank Bill Walker and Joseph Mastroguilio 1482 from Avaya and Bin Hu from Motorola for their discussions. The 1483 authors would also like to extend special thanks to Randy Presuhn, 1484 who reviewed this document for spelling and formatting purposes, as 1485 well as for a deep review of the technical content. 1487 8.Appendix 1489 The implementation notes included in Appendix are for informational 1490 purposes only and are meant to clarify the RAQMON specification. 1492 Pseudo code for RDS & RRC 1493 We provide examples of Psuedo code for aspects of RDS and RRC. There 1494 may be other implementation methods that are faster in particular 1495 operating environments or have other advantages. 1497 RDS: 1498 when (session starts} { 1499 report.identifier = session.endpoints, session.starttime; 1500 report.timestamp = 0; 1501 while (session in progress) { 1502 wait interval; 1503 report.statistics = update statistics; 1504 report.curtimestamp += interval; 1505 if encryption required 1506 report_data = encrypt(report, encrypt parameters); 1508 else 1509 report_data = report; 1510 raqmon_pdu = header, report_data; 1511 send raqmon-pdu; 1512 } 1513 } RRC: 1514 listen on raqmon port 1515 when ( raqmon_pdu received ) { 1516 decrypt raqmon_pdu.data if needed 1518 if report.identifier in database 1519 if report.current_time_stamp > last update 1520 update session statistics from report.statistics 1521 else 1522 discard report 1523 } 1525 9. Security Considerations 1527 [RAQMON-FRAMEWORK] outlines a threat model associated with RAQMON and 1528 security considerations to be taken into account in the RAQMON 1529 specification to mitigate against those threats. It is imperative 1530 that RAQMON PDU implementations be able to provide the following 1531 protection mechanisms in order to attain end-to-end security: 1533 1. Authentication - the RRC SHOULD be able to verify that a RAQMON 1534 report was originated by the RDS claiming to have sent it. At 1535 minimum, an RDS/RRC pair MUST use a digest-based authentication 1536 procedure to authenticate, like the one defined in [RFC 1321]. 1538 2. Privacy - RAQMON information includes identification of the 1539 parties participating in a communication session. RAQMON 1540 deployments SHOULD be able to provide protection from 1541 eavesdropping, and to prevent an unauthorized third party from 1542 gathering potentially sensitive information. This can be achieved 1543 by using payload encryption technologies such as DES (Data 1544 Encryption Standard), 3-DES [3DES], and AES (Advanced Encryption 1545 Standard) [AES]. 1547 3. Protection from Denial of Service attacks directed at the RRC - 1548 RDSs send RAQMON reports as a side effect of external events (for 1549 example, receipt of a phone call). An attacker can try to 1550 overwhelm the RRC (or the network) by initiating a large number of 1551 events in order to swamp the RRC with excessive numbers of RAQMON 1552 PDUs. 1554 To prevent DoS (denial-of-service) attacks against the RRC, the 1555 RDS will send the first report for a session only after the 1556 session has been established, so that the session set-up process 1557 is not affected. 1559 4. NAT and Firewall Friendly Design: the presence of IP addresses and 1560 TCP/UDP port information in RAQMON PDUs may be NAT unfriendly. 1561 Where NAT-friendliness is a requirement, the RDS MAY omit IP 1562 address information from the RAQMON PDU. Another way to avoid 1563 this problem is by using NAT-Aware Application Layer Gateways 1564 (ALGs) to ensure that correct IP addresses appear in RAQMON PDUs. 1566 For the usage of TCP, TLS SHOULD be used to provide transport layer 1567 security. 1569 Following SNMP Specific guidelines SHOULD be followed to ensure a 1570 secure implementation: 1572 This memo also defines an RDS SNMP MIB module with the purpose of 1573 mapping the RAQMON PDUs into SNMP Notifications. To attain end-to- 1574 end security the following measures have been taken in RDS MIB module 1575 design: 1577 There are no management objects defined in this MIB module that have 1578 a MAX-ACCESS clause of read-write and/or read-create. Consequently, 1579 if this MIB module is implemented correctly, there is no risk that an 1580 intruder can alter or create any management objects of this MIB 1581 module via direct SNMP SET operations. 1583 Some of the readable objects in this MIB module (i.e., objects with a 1584 MAX-ACCESS other than not-accessible) may be considered sensitive or 1585 vulnerable in some network environments. It is thus important to 1586 control even GET and/or NOTIFY access to these objects and possibly 1587 to even encrypt the values of these objects when sending them over 1588 the network via SNMP. These are the tables and objects and their 1589 sensitivity/vulnerability: 1591 raqmonDsNotificationTable 1593 The objects in this table contain user session information, and their 1594 disclosure may be sensitive in some environments. 1596 SNMP versions prior to SNMPv3 did not include adequate security. 1597 Even if the network itself is secure (for example by using IPSec), 1598 even then, there is no control as to who on the secure network is 1599 allowed to access and GET/SET (read/change/create/delete) the objects 1600 in this MIB module. 1602 It is RECOMMENDED that implementers consider the security features as 1603 provided by the SNMPv3 framework (see [RFC3410], section 8), 1604 including full support for the SNMPv3 cryptographic mechanisms (for 1605 authentication and privacy). 1607 It is a customer/operator responsibility to ensure that the SNMP 1608 entity giving access to an instance of this MIB module is properly 1609 configured to give access to the objects only to those principals 1610 (users) that have legitimate rights to indeed GET or SET 1611 (change/create/delete) them. 1613 10. Authors' Addresses 1615 Anwar A. Siddiqui 1616 Avaya Labs 1617 307 Middletown Lincroft Road 1618 Lincroft, New Jersey 07738 1619 USA 1620 Tel: +1 732 852-3200 1621 E-mail: anwars@avaya.com 1623 Dan Romascanu 1624 Avaya 1625 Atidim Technology Park, Bldg. #3 1626 Tel Aviv, 61131 1627 Israel 1628 Tel: +972-3-645-8414 1629 Email: dromasca@avaya.com 1631 Eugene Golovinsky 1632 BMC Software 1633 2101 CityWest Blvd. 1634 Houston, Texas 77042 1635 USA 1636 Tel: +1 713 918-1816 1637 Email: eugene_golovinsky@bmc.com 1639 Mahfuzur Rahman 1640 Panasonic Digital Networking Lab 1641 Two Research Way 1642 Princeton, NJ 08540 1643 Tel: +1 609 734 7332 1644 Email: mahfuz@research.panasonic.com 1646 Yongbum "Yong" Kim 1647 Broadcom 1648 3151 Zanker Road 1649 San Jose, CA 95134 1650 Tel: +1 408 501 7800 1651 E-mail: ybkim@broadcom.com 1653 A. Full Copyright Statement 1655 Copyright (C) The Internet Society (2004). This document is subject 1656 to the rights, licenses and restrictions contained in BCP 78, and 1657 except as set forth therein, the authors retain all their rights. 1659 This document and the information contained herein are provided on an 1660 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1661 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1662 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1663 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1664 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1665 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1667 Intellectual Property 1669 The IETF takes no position regarding the validity or scope of any 1670 intellectual property or other rights that might be claimed to 1671 pertain to the implementation or use of the technology described in 1672 this document or the extent to which any license under such rights 1673 might or might not be available; neither does it represent that it 1674 has made any effort to identify any such rights. Information on the 1675 IETF's procedures with respect to rights in standards-track and 1676 standards-related documentation can be found in BCP-11. 1678 Copies of IPR disclosures made to the IETF secretariat and any 1679 assurances of licenses to be made available, or the result of an 1680 attempt made to obtain a general license or permission for the use of 1681 such proprietary rights by implementors or users of this 1682 specification can be obtained from the IETF on-line repository at 1683 http://www.ietf.org/ipr. The IETF invites any interested party to 1684 bring to its attention any copyrights, patents or patent 1685 applications, or other proprietary rights which may cover technology 1686 that may be required to practice this standard. Please address the 1687 information to the IETF at ietf-ipr@ietf.org. 1689 Acknowledgement: 1691 Funding for the RFC Editor function is currently provided by the 1692 Internet Society.