idnits 2.17.1 draft-ietf-rmonmib-raqmon-pdu-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 33 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 34 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 102 instances of too long lines in the document, the longest one being 441 characters in excess of 72. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 1103 has weird spacing: '... by the recei...' == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: + Since RDSs are not computationally rich and to keep the RDS realization lightweight, it is not required that RDSs fully implement an SNMP-based Internet Management framework. Specifically RDSs MAY NOT respond to SNMP requests like GET, SET, etc., as an SNMP compliant responder would. -- 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 (10 September 2003) is 7532 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: 'RAQMON-FRAMEWORK' is mentioned on line 670, but not defined -- Looks like a reference, but probably isn't: '17' on line 282 == Missing Reference: 'RFC 3291' is mentioned on line 378, but not defined ** Obsolete undefined reference: RFC 3291 (Obsoleted by RFC 4001) == Missing Reference: 'RFC 1305' is mentioned on line 450, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) == Missing Reference: 'RFC 1890' is mentioned on line 531, but not defined ** Obsolete undefined reference: RFC 1890 (Obsoleted by RFC 3551) == Missing Reference: 'RFC 1889' is mentioned on line 673, but not defined ** Obsolete undefined reference: RFC 1889 (Obsoleted by RFC 3550) == Missing Reference: 'RAQMON FRAMEWORK' is mentioned on line 1165, but not defined == Unused Reference: 'RFC1889' is defined on line 1345, but no explicit reference was found in the text == Unused Reference: 'RFC1890' is defined on line 1366, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 1369, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1372, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1375, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1378, but no explicit reference was found in the text == Unused Reference: 'RFC1597' is defined on line 1381, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 1385, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1388, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1391, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1D' is defined on line 1402, but no explicit reference was found in the text == Unused Reference: 'RFC1349' is defined on line 1408, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 1411, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1414, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 1418, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) -- 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 1890 (Obsoleted by RFC 3551) -- 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) Summary: 11 errors (**), 0 flaws (~~), 28 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Anwar Siddiqui 3 Avaya Inc. 4 Dan Romascanu 5 Avaya Inc. 6 Eugene Golovinsky 7 BMC Software 8 10 September 2003 10 Real-time Application Quality of Service Monitoring (RAQMON) 11 Protocol Data Unit (PDU) 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2003). All Rights Reserved. 35 Abstract 37 This memo defines a common protocol data unit (PDU) used between a 38 RAQMON Data Source (RDS) and a RAQMON Report Collector (RRC) to 39 report application level QOS statistics required for extensions of 40 the RMON Framework. 42 This memo also outlines mechanisms to use the Real Time Transport 43 Control Protocol (RTCP) and the Simple Network Management Protocol 44 (SNMP) to transport these PDUs between the RAQMON Data Source (RDS) 45 and the RAQMON Report Collector (RRC). 47 Distribution of this memo is unlimited. 49 Table of Contents 51 Status of this Memo 1 52 Abstract 1 53 1 Introduction 2 54 2 RAQMON PDU Format 3 55 3 Transporting RAQMON Protocol Data Units 14 56 4 Congestion Safe RAQMON Operation 28 57 5 Normative References 28 58 6 Informative References 29 59 7 Intellectual Property 30 60 8 Appendix 31 61 9 Security Considerations 32 62 10 IANA Considerations 33 63 11 Authors' Addresses 33 64 A Full Copyright Statement 34 66 1. Introduction 68 There is a need to extend the RMON framework [RFC2819] to monitor end 69 devices such as IP phones, pagers, Instant Messaging clients, mobile 70 phones, and various other hand-held computing devices. The Real-Time 71 Application QoS Monitoring (RAQMON) Framework as outlined by [RAQMON- 72 framework] extends RMON by defining entities such as RAQMON Data 73 Source (RDS) and RAQMON Report Collector (RRC) to perform various 74 application monitoring in real time. This memo defines a common 75 protocol data unit (PDU) used between a RDS and RRC to report QoS 76 statistics. This memo contains a syntactical description of the 77 RAQMON PDU structure and of the usage of RTCP and SNMP as underlying 78 transport protocols to carry RAQMON PDUs. Either RTCP or SNMP can be 79 used to carry RAQMON PDUs between RDSs and RRCs. 81 The RAQMON Protocol Data Unit (PDU) utilizes a common data format 82 understood by RDS and RRC. A RAQMON PDU does not transport 83 application data but rather occupies the place of a payload 84 specification at the application layer of the protocol stack. 85 Mechanisms outlined in this draft can be used by many real-time and 86 non-real time applications managed within the RMON Framework which 87 allows network entities to report application level QoS parameters in 88 real time. Voice over IP, Fax over IP, Video over IP, Instant 89 Messaging (IM), Email, software download applications, e-business 90 style transactions, web access from computing devices are a few 91 examples of applications that can potentially use RAQMON Framework 92 for monitoring purposes. 94 Though transmitted as one Protocol Data Unit, a RAQMON PDU is 95 functionally divided into two different parts, namely the basic part 96 and the application extensions required for vendor specific 97 extensions. Both functional parts trail SMI Network Management 98 Private Enterprise Codes that are currently maintained by IANA at 99 http://www.iana.org/assignments/enterprise-numbers. 101 The Basic Part of RAQMON PDU: The basic part of the RAQMON PDU trails 102 the SMI Network Management Private Enterprise Code 0 - reserved by 103 convention for use by the IETF RMON Working Group. The RAQMON PDU 104 basic part offers an entry-type (a.k.a. "Name") from a pre-defined 105 list of QoS parameters defined in table 1 and allows applications to 106 fill in appropriate values for those parameters. Application 107 developers also have the flexibility to report only a sub-set of the 108 parameters listed in table 1 as discussed in later sections. 110 The Application Part of RAQMON PDU: Application and vendor specific 111 extensibility of RAQMON PDU is provided by the application part of 112 the RAQMON PDU to convey application-, vendor-, and device- specific 113 parameters for future use. Additional parameters can be defined by 114 application developers within the payload of the APP part of the PDU 115 as Type Length Value (TLV) tuples. The Application part of the RAQMON 116 PDU trails behind the SMI Network Management Private Enterprise Codes 117 of the vendor found in http://www.iana.org/assignments/enterprise- 118 numbers. Such application-specific extensions should be maintained 119 and published by the application vendor. RAQMON PDUs are also capable 120 of carrying multiple application parts within a PDU that trails 121 multiple SMI Network Management Private Enterprise Codes of the 122 vendor. 124 Though RDS and RRC are designed to be stateless for RAQMON reporting 125 sessions, the framework requires a graceful termination of reporting 126 sessions between RDS and RRC. Such functionality is achieved by NULL 127 PDUs as defined within RAQMON Framework [RAQMON-Framework]. A 128 syntactical specification of NULL PDU is available in section 2 of 129 this memo. 131 The following sections of this memo contain detailed RAQMON PDU 132 specifications and usage of RTCP and SNMP to carry a RAQMON PDU. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in [RFC2119]. 138 2. RAQMON PDU Format 140 Parameters carried by RAQMON PDUs and their usages are defined in sub 141 section 5 of [RAQMON-FRAMEWORK] by reference to existing IETF, ITU 142 and other standards organizations' documents. 144 The RAQMON PDU format specified in this memo provides syntax and 145 structure within a RAQMON PDU to report those parameters. A RAQMON 146 PDU in the current version is marked as PDU Type (PDT) = 1. 148 Vendors SHOULD use the basic part of the PDU to report statistics 149 pre-listed here in the specification which will ensure basic 150 interoperability between multiple vendor and application developers. 151 Vendors SHOULD also use application specific extension to convey 152 application-, vendor-, device- etc. specific parameters not included 153 in the basic part of the specification and publish such data 154 externally to attain extended interoperability. 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | V |PDT = 1|B| T |P|I| RC | Length | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | DSRC | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | SMI Enterprise Code = 0 | Report Type = 0 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | Data Source Address {DA} | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Receiver's Address (RA) | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | NTP Timestamp, most significant word | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | NTP Timestamp, least significant word | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Length | Application Name (AN) ... | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | ... | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | Length | Data Source Name (DN) ... | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | ... | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | Length | Receiver's Name (RN) ... | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | ... | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | Length | Session State ... | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | ... | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Session Duration | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Round Trip End-to-End Delay | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | One Way End-to-End Delay | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Cumulative Packet Loss | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Total # Packets sent | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Total # Packets received | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Total # Octets sent | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Total # Octets received | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Source Port Used | Receiver Port Used | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 |Source Payload |Reciver Payload| CPU | Memory | 212 |Type | Type | Utilization | Utilization | 213 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 214 | Session Setup Delay | Inter arrival Jitter | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Padding | Packet loss | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | SMI Enterprise Code = "xxx" | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Report Type = "yyy" | Length of Application Part | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | application/vendor specific extension | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | ............ | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | ............... | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | ............... | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | SMI Enterprise Code = "abc" | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Report Type = "zzz" | Length of Application Part | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | application/vendor specific extension | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | ............ | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 Figure 1 - RAQMON Protocol Data Unit 240 version (V) : 2 bits - Identifies the version of RAQMON. The number 241 of this version is 1. 243 PDU type (PDT): 4 bits - This indicates the type of RAQMON PDU being 244 sent. PDT = 1 is used for the current RAQMON PDU version. 246 basic (B): 1 bit - While set to 1, the basic flag indicates that the 247 PDU has the basic part of the RAQMON PDU. A value of zero is 248 considered to be valid as it may constitute a RAQMON NULL PDU. 250 trailer (T) : 3 bits - Total number of Application Specific Extension 251 that trails the BASIC Part of RAQMON PDU. A value of zero is 252 considered to be valid as it may constitute a RAQMON NULL PDU. 254 padding (P): 1 bit - If the padding bit is set, the basic part of the 255 RAQMON PDU contains some additional padding octets at the end of the 256 basic part of the PDU which are not part of the monitoring 257 information as padding may be needed by some applications because 258 reporting is based on the intent of RDS to report certain parameters. 259 Also some parameters may be reported only once at the beginning of 260 the reporting session, e.g. Data Source Name, Receiver Name, Pay Load 261 type etc. Actual padding at the end of the Basic part of the PDU is 262 either 0,8, 16 or 24 bits to make the basic part of the PDU a 263 multiple of 32 bits long. 265 IP version (I): 1 bit - While set to 1, IP Version Flag indicates 266 that IP addresses contained in the PDU are IP version 6 compatible. 268 record count (RC): 4 bits - The total number of records contained in 269 the basic part of the PDU. A value of zero is considered to be valid 270 but useless. 272 length: 16 bits - The length of the basic part of the RAQMON PDU in 273 32-bit words minus one which includes the header and any padding. 275 DSRC: 32 bits - The data source identifier represents a unique RAQMON 276 reporting session descriptor that points to a specific reporting 277 session between RDS and RRC. The uniqueness of DSRC is valid only 278 within a reporting session. DSRC values should be randomly generated 279 using vendor chosen algorithms for each communication session. It is 280 not sufficient to obtain a DSRC simply by calling random() without 281 carefully initializing the state. One could use an algorithm like 282 the one defined in Appendix A.6 in [17] to create a DSRC. Depending 283 on the choice of algorithm, there is a finite probability that two 284 DSRCs from two different RDSs may be the same. To further reduce the 285 probability that two RDSs pick the same DSRC for two different 286 reporting sessions, it is recommended that an RRC use parameters like 287 Data Source Address (DA), Data Source Name (DN), and MAC Address in 288 the PDU in conjunction with a DSRC value. It is not mandatory for 289 RDSs to send parameters like Data Source Address (DA), Data Source 290 Name (DN), MAC Address in the every PDU sent to RRC, but sending 291 these parameters occasionally will reduce the probability of DSRC 292 collision drastically. However this will cause an additional overhead 293 per PDU. 295 A RAQMON PDU must contain V, PDT, B, T, P, I, RC, length and DSRC 296 fields at all times. A value of zero for basic (B) bit and trailer 297 (T) bits set constitutes a RAQMON NULL PDU (i.e. nothing to report). 298 RDSs MUST send a RAQMON NULL PDU to RRC to indicate the end of the 299 RDS reporting session. All other parameters listed in the PDU 300 described below are optionally used when RDSs have some information 301 to send to RRC. 303 2.1 The basic part of RAQMON Protocol Data Unit: 305 SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is 306 used to indicate RMON WG compliant basic part of the RAQMON PDU 307 format. The basic part of the RAQMON PDU must trail behind the SMI 308 Enterprise Code = 0 to ensure interoperability. 310 0 1 2 3 311 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 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | V |PDT = 1|B| T |P|I| RC | Length | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 | DSRC | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | SMI Enterprise Code = 0 | Report Type = 0 | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 319 | RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 320 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU 323 Report Type: 16 bits - These bits are reserved by the IETF RMON Work 324 Group. A value of 0 within SMI Enterprise Code = 0 is used for this 325 version of the PDU. 327 The basic part of each RAQMON PDU consists of Record Count Number 328 (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the 329 presence of appropriate RAQMON parameters within a record as defined 330 in table 1. 332 RC_N: 4 bits - Record Count number to which the information in this 333 record pertains. Record Count number indicates a sub-session within a 334 communication session. A value of zero is a valid record number. The 335 maximum number of records that can be described in one RAQMON Packet 336 is 16 (i.e. 0000 - 1111). 338 RAQMON Parameter Presence Flags (RPPF): 28 bits 340 Each of these flags while set represent that this RAQMON PDU contains 341 corresponding parameters as specified in table 1. 343 Sequence Number Presence/Absence of corresponding 344 Parameter within this RAQMON PDU 346 1 Data Source Address (DA) 347 2 Receiver Address (RA) 348 3 NTP Timestamp 349 4 Application Name 350 5 Data Source Name (DN) 351 6 Receiver Name (RN) 352 7 Session Setup Status 353 8 Session Duration 354 9 End-to-End Delay (RTT) 355 0 End-to-End Delay (OWD) 356 1 Cumulative Packet Loss 357 2 Total number of Packets sent 358 3 Total number of Packets received 359 4 Total number of Octets sent 360 5 Total number of Octets received 361 6 Source Port Used 362 7 Receiver Port Used 363 8 S_Layer2 364 9 S_Layer3 365 0 D_Layer2 366 1 D_Layer3 367 2 Source Payload Type 368 3 Receiver Payload Type 369 4 CPU Utilization 370 5 Memory Utilization 371 6 Session Setup Delay 372 7 Inter arrival Jitter 373 8 Packet loss (in fraction) 375 Table 1: RAQMON Parameters and corresponding RPPF 377 Data Source Address (DA): 32 bits or 160 bits - This metrics is 378 defined in section 5.1 of [RAQMON-FRAMEWORK]. The standard [RFC 3291] 379 octet string representation is used to represent the end device's 380 numeric address on the interface used for the communication session. 381 The standard representation of an IP Version 4 address is "dotted 382 decimal", also known as dotted quad. 135.8.45.178 is an example of a 383 valid Data Source Address. IP version 6 addresses are incorporated in 384 Data Source Address by setting the IP version flag (I bit) of the 385 RAQMON PDU header to 1. Since the Data Source Address is expected to 386 remain constant during the entire reporting session, applications 387 should avoid sending these parameters too often to ensure efficient 388 usage of network resources. 390 Receiver Address (RA): 32 bits or 160 bits - This metrics is defined 391 in section 5.2 of [RAQMON-FRAMEWORK]. It follows the exact same 392 syntax as Data Source Address but is used to indicate a receiver's 393 address. Since the Receiver Address is expected to remain constant 394 during entire reporting sessions, applications should avoid sending 395 these parameters too often to ensure efficient usage of network 396 resources. 398 Data Source Name (DN): - This metrics is defined in section 5.3 of 399 [RAQMON-FRAMEWORK]. The Data Source Name field starts with an 8-bit 400 octet count describing the length of the text and the text itself. 401 Note that the text can be no longer than 255 octets. The text is 402 encoded according to the UTF-2 encoding specified in Annex F of ISO 403 standard 10646 [ISO10646],[UNICODE]. This encoding is also known as 404 UTF-8 or UTF-FSS. It is described in "File System Safe UCS 405 Transformation Format (FSS_UTF)", X/Open Preliminary Specification, 406 Document Number P316 and Unicode Technical Report #4. US-ASCII is a 407 subset of this encoding and requires no additional encoding. The 408 presence of multi-octet encoding is indicated by setting the most 409 significant bit of a character to a value of one. Text is not null 410 terminated because some multi-octet encoding include null octets. 411 Data Source Name is terminated by one or more null octets, the first 412 of which is interpreted to denote the end of the string and the 413 remainder as needed to pad until the next 32-bit boundary. 414 Applications should instruct a RDS to send out parameters not too 415 frequently to ensure efficient usage of network resources as this 416 parameter is expected to remain constant for the duration of the 417 reporting session. 419 Receiver Name (RN): - This metrics is defined in section 5.4 of 420 [RAQMON-FRAMEWORK]. Like Data Source Name, the Receiver Name field 421 starts with an 8-bit octet count describing the length of the text 422 and the text itself. The Receiver Name is multiple of 32 bits. It 423 follows the same padding rules as apply to Data Source Name. As Data 424 Source Name and Receiver's Name are contiguous, i.e., items are not 425 individually padded to a 32-bit boundary. Since the Receiver name is 426 expected to remain constant during entire reporting sessions, this 427 information should be sent out occasionally over random time 428 intervals to maximize success of reaching a RRC and also conserve 429 network bandwidth. 431 Source Port Used: 16 bits - This metrics is defined in section 5.5 of 432 [RAQMON-FRAMEWORK]and describes the port number used by the Data 433 Source as used by the application in RC_N session while this RAQMON 434 PDU was generated. Since sometimes the Source Port Used will remain 435 constant during entire reporting sessions, applications in that case 436 should avoid sending these parameters too often to ensure efficient 437 usage of network resources. 439 Receiver Port Used: 16 bits - This metrics is defined in section 5.6 440 of [RAQMON-FRAMEWORK], and describes the receiver port used by the 441 application to communicate to the receiver. It follows same syntax as 442 Source Port Used. Since sometimes the Receiver Port Used will remain 443 constant during entire reporting sessions, applications in that case 444 should avoid sending these parameters too often to ensure efficient 445 usage of network resources. 447 Session Setup Date/Time (NTP timestamp): 64 bits - This metrics is 448 defined in section 5.7 of [RAQMON-FRAMEWORK] represented using the 449 timestamp format of the Network Time Protocol (NTP), which is in 450 seconds [RFC 1305]. The full resolution NTP timestamp is a 64-bit 451 unsigned fixed-point number with the integer part in the first 32 452 bits and the fractional part in the last 32 bits. In some fields 453 where a more compact representation is appropriate, only the middle 454 32 bits are used; that is, the low 16 bits of the integer part and 455 the high 16 bits of the fractional part. The high 16 bits of the 456 integer part must be determined independently. 458 A Data Source that has no notion of wallclock or time SHOULD set the 459 appropriate RAQMON flag to 0 to avoid wasting 64 bits in the PDU. 460 Since NTP time stamp is intended to provide Date/Time of a session, 461 it is recommended that the NTP Timestamp be used only in the first 462 RAQMON pdu in order to use network resources efficiently. However 463 such a recommendation is context sensitive and should be enforced as 464 deemed necessary by each application environment. 466 Session Setup Delay: 16 bits - Session Setup Delay metrics is defined 467 in section 5.8 of [RAQMON-FRAMEWORK] and expressed in milliseconds. 469 Session Duration: 32 bits - Session Setup Delay metrics is defined in 470 section 5.9 of [RAQMON-FRAMEWORK]. Session Duration from session RC_N 471 is an unsigned integer expressed in seconds. 473 Session Setup Status: - Session Setup Status is defined in section 474 5.10 of [RAQMON-FRAMEWORK]. This field starts with an 8-bit octet 475 count describing the length of the text and the text itself. Session 476 Setup Status is a multiple of 32 bits. Since the Session Setup Status 477 is expected to remain constant during entire reporting sessions, 478 applications should avoid sending these parameters too often to 479 ensure efficient usage of network resources. 481 Round Trip End-to-End Delay: 32 bits - Round Trip End-to-End Delay is 482 defined in section 5.11 of [RAQMON-FRAMEWORK]. This field represents 483 Round Trip End-to-End Delay of session RC_N which is an unsigned 484 integer expressed in the order of milliseconds. 486 One Way End-to-End Delay: 32 bits - One Way End-to-End Delay is 487 defined in section 5.12 of [RAQMON-FRAMEWORK]. This field represents 488 One Way End-to-End Delay of sub session RC_N which is an unsigned 489 Integer expressed in the order of milliseconds. 491 Inter-Arrival Jitter: 16 bits - Inter-Arrival Jitter is defined in 492 section 5.13 of [RAQMON-FRAMEWORK] expressed in milliseconds. 494 Total number of application packets received: 32 bits - This 495 parameter is defined in section 5.14 of [RAQMON-FRAMEWORK] as an 496 unsigned integer representing total number of packets transmitted 497 within sub session RC_N by the receiver. 499 Total number of application packets sent: 32 bits - This parameter is 500 defined in section 5.15 of [RAQMON-FRAMEWORK] as an unsigned integer 501 representing total number of packets transmitted within sub session 502 RC_N by the sender. 504 Total number of application octets received: 32 bits - This parameter 505 is defined in section 5.16 of [RAQMON-FRAMEWORK] as an unsigned 506 integer representing total number of payload octets (i.e., not 507 including header or padding) transmitted in packets by the receiver 508 within sub session RC_N. 510 Total number of application octets sent: 32 bits - This parameter is 511 defined in section 5.17 of [RAQMON-FRAMEWORK] as an unsigned integer 512 representing total number of payload octets (i.e., not including 513 header or padding) transmitted in packets by the sender within sub 514 session RC_N. 516 Cumulative application packet Loss: 32 bits - This parameter is 517 defined in section 5.18 of [RAQMON-FRAMEWORK] as unsigned integer 518 representing the total number of packets from sub session RC_N that 519 have been lost while this RAQMON PDU was generated. 521 Packet Loss in Fraction: 8 bits - This parameter is defined in 522 section 5.19 of [RAQMON-FRAMEWORK] expressed as a fixed point number 523 with the binary point at the left edge of the field. (That is 524 equivalent to taking the integer part after multiplying the loss 525 fraction by 256.) This metrics is defined to be the number of 526 packets lost divided by the number of packets expected. 528 Source Payload Type: 8 bit - This parameter is defined in section 529 5.20 of [RAQMON-FRAMEWORK]. It is an 8-bit field that specifies the 530 payload type of data source of communication sub session RC_N per 531 definition of [RFC 1890]. Since the Source Payload type does not vary 532 frequently during reporting sessions, applications should avoid 533 sending these parameters within RAQMON PDU too often to ensure 534 efficient usage of network resources. 536 Receiver Payload Type: 8 bit - This parameter is defined in section 537 5.21 of [RAQMON-FRAMEWORK]. This 8-bit field specifies receiver 538 payload type of communication sub session RC_N. Since the Receiver 539 Payload type does not vary frequently during reporting sessions, 540 applications should avoid sending these parameters within RAQMON PDU 541 too often to ensure efficient usage of network resources. 543 S_Layer2: 8 bits - This parameter defined in section 5.22 of [RAQMON- 544 FRAMEWORK] is an 8-bit field associated to the source's IEEE 802.1p 545 values of communication sub session RC_N. Since IEEE 802.1p value is 546 3 bits, the first 3 bits of this parameter represents IEEE 802.1p 547 value and the last 5 bits are padded to 0. Since this parameter is 548 expected to remain constant most of the time during entire reporting 549 sessions, applications should avoid sending these parameters too 550 often to ensure efficient usage of network resources. 552 S_Layer3: 8 bits - This parameter defined in section 5.23 of [RAQMON- 553 FRAMEWORK] is an 8-bit field which represents layer 3 QoS marking 554 used to send packets to the receiver by this data source during sub- 555 session RC_N. Since most of the time the Source Layer 3 used in sub 556 session RC_N will remain constant, applications should avoid sending 557 these parameters within a PDU too often to ensure efficient usage of 558 network resources. 560 D_Layer2: 8 bits - This parameter defined in section 5.24 of [RAQMON- 561 FRAMEWORK] is an 8-bit field which represents layer 2 priorities used 562 by the receiver to send packets to the data source during sub session 563 RC_N session if the Data Source can learn such information. Since 564 IEEE 802.1p value is 3 bits, the first 3 bits of this parameter 565 represents IEEE 802.1p value and the last 5 bits are padded to 0. 566 Since most of the time the Destination Layer 2 used will remain 567 constant during entire reporting sessions, applications should avoid 568 sending these parameters within a PDU too often to ensure efficient 569 usage of network resources. 571 D_Layer3: 8 bits - This parameter defined in section 5.25 of [RAQMON- 572 FRAMEWORK] is an 8-bit field which represents layer 3 QoS marking 573 used by the receiver to send packets to the data source during sub 574 session RC_N if the Data Source can learn such information. Since 575 most of the time the Destination Layer 3 used will remain constant 576 during entire reporting sessions, applications should avoid sending 577 these parameters within a PDU too often to ensure efficient usage of 578 network resources. 580 CPU Utilization: 8 bits - This parameter defined in section 5.26 of 581 [RAQMON-FRAMEWORK] represents the percentage of CPU used during 582 session RC_N up until the time this RAQMON PDU was generated. CPU 583 Utilization value should indicate not only CPU Utilization associated 584 to a session RC_N but also actual CPU Utilization, to indicate a 585 snapshot of end device Memory Utilization while session RC_N is in 586 progress. 588 Memory Utilization: 8 bits - This parameter defined in section 5.27 589 of [RAQMON-FRAMEWORK] represents the percentage of total memory used 590 during session RC_N up until the time this RAQMON PDU was generated. 591 Memory Utilization value should indicate not only Memory Utilization 592 associated to a session RC_N but also actual Memory Utilization, to 593 indicate a snapshot of end device memory utilization while session 594 RC_N in progress. 596 Application Name: - This parameter is defined in section 5.28 of 597 [RAQMON-FRAMEWORK]. The Application Name field starts with an 8-bit 598 octet count describing the length of the text and the text itself. 599 The Application Name field is multiple of 32 bits. Since the 600 Application Name is expected to remain constant during entire 601 reporting sessions, applications should avoid sending these 602 parameters within a PDU too often to ensure efficient usage of 603 network resources. 605 padding: 0, 8, 16 or 24 bits - As described earlier in this section, 606 if the padding bit (P) is set , the actual padding at the end of the 607 Basic part of the PDU is either 0,8, 16 or 24 bits to make the basic 608 part of the PDU multiple of 32 bits long. 610 2.2 APP part of RAQMON Protocol Data Unit (PDU) 612 The APP part of the RAQMON PDU is intended for experimental use as 613 new applications and new features are developed, without requiring 614 PDU type value registration. 616 Vendors are responsible for designing RDSs with appropriate SMI 617 Enterprise Code and publishing application specific extensions. Any 618 RAQMON compliant RRC MUST be able to recognize vendors SMI Enterprise 619 Code and Report Type, and MUST recognize the presence of application 620 specific extensions that trail behind vendors specific SMI Enterprise 621 Code and Report Type. There is no need for the RRC to understand the 622 semantics of the Enterprise specific parts of the PDU. 624 SMI Enterprise Code: 32 bits - Vendors and Application developers 625 should fill in appropriate SMI Enterprise IDs available here 626 http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI 627 Enterprise Code MUST be treated as a vendor or application specific 628 extension. 630 RAQMON PDUs are capable of carrying multiple Application Parts within 631 a PDU that trails multiple SMI Network Management Private Enterprise 632 Codes of the vendor. 634 Report Type: 16 bits - Vendors and Application developers should fill 635 in the appropriate Report type within a specified SMI Enterprise 636 Code. It is recommended that vendors publish application specific 637 extensions and maintain such report types for better 638 interoperability. 640 Length of the Application Part: 16 bits - The length of the 641 Application Part of the RAQMON PDU is 32-bit words minus one which 642 includes the header of the Application Part. 644 application-dependent data: variable length - Application/vendor- 645 dependent data to be defined by the application developers. It is 646 interpreted by the vendor specific application and not by the RRC 647 itself. It must be a multiple of 32 bits long. 649 2.3 Byte Order, Alignment, and Time Format of RAQMON PDUs 651 All integer fields are carried in network byte order, that is, with 652 the most significant byte (octet) first. This byte order is commonly 653 known as big-endian. The transmission order is described in detail in 654 [RFC791]. Unless otherwise noted, numeric constants are in decimal 655 (base 10). 657 All header data is aligned to its natural length, i.e., 16-bit fields 658 are aligned on even offsets, 32-bit fields are aligned at offsets 659 divisible by four, etc. Octets designated as padding have the value 660 zero. 662 3. Transporting RAQMON Protocol Data Units 664 It is an inherent objective of the RAQMON Framework to re-use 665 existing application level transport protocols to maximize the usage 666 of existing installations as well as to avoid transport protocol 667 level complexities in the design process. A RAQMON PDU does not 668 transport application data but rather occupies the place of a payload 669 specification at the application layer of the protocol stack. As 670 outlined in [RAQMON-FRAMEWORK] both Real-Time Transport Control 671 Protocol (RTCP) and the Simple Network Management Protocol (SNMP) can 672 be used as a transport protocol. Section 3.1 specifies RTCP APP 673 Packets [RFC 1889] to carry RAQMON PDUs between RDS and RRC and 674 section 3.2.reflects usage of SNMP INFORM PDUs as transport protocol. 675 It is left upon the vendors to choose either RTCP or SNMP to 676 transport RAQMON PDU as it fits the deployment need. Guidance in the 677 form of pros and cons of using each protocol has been provided in 678 appropriate sections. 680 3.1 Mapping RAQMON PDUs to RTCP as Transport Protocol 682 The RAQMON PDU transfer is comprised of unidirectional exchange of 683 PDUs between RDSs and an RRC. The protocol data units are mapped to 684 an APP Packet (i.e. PT = 204) in Real-Time Transport Control Protocol 685 (RTCP). As outlined in RFC 1889, an RTCP APP packet allows 686 applications to define new RTCP packets. The RTCP APP packets are 687 intended for use as new applications and new features such as RAQMON 688 are developed, without requiring packet type value registration. 689 RAQMON Framework makes use of such extension to provide backward 690 compatibility to existing deployment. Within the RTCP framework, a 691 RAQMON PDU is represented as an Application Specific Report. 693 RTCP APP packets used by RMON MUST be Internet Assigned Numbers 694 Authority (IANA) Registered, by assigning the string "RMON" as ASCII 695 name. 697 Figure 3 below shows how RAQMON PDUs are mapped into RTCP APP Packets 698 to transport PDUs between RDS and RRC. 700 0 1 2 3 701 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 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 |V=2|P| subtype | PT=APP=204 | length | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 | SSRC/CSRC | 706 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 707 | name (ASCII) = "RMON" | 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | RAQMON PDU | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 712 Figure 3 - Using RTCP APP Packets to transport RAQMON PDUs 714 version (V), padding (P), length: As described for the SR packet 716 subtype: 5 bits subtype 1 MUST be used by the RAQMON PDU. These 717 unique definitions will be IANA registered. 719 packet type (PT): 8 bits Contains the constant 204 to identify this 720 as an RTCP APP packet. 722 name: 4 octets The name chosen by the RMON WG defining the set of APP 723 packets will be unique with respect to other APP packets and will be 724 IANA Registered as "RMON" with all uppercase. The name field in RTCP 725 APP Packet is interpreted as a sequence of ASCII characters. 727 application-dependent data: variable length RAQMON PDUs sent by the 728 RDS in the format specified in Figure 3 will be interpreted by the 729 RAQMON Report Collector (RRC) and not RTP/RTCP itself. RAQMON PDUs 730 must be a multiple of 32 bits long. 732 3.1.1 Port Assignment 734 As specified in the previous sections the transport of RAQMON PDUs 735 can be performed using various underlying network transport protocols 736 like TCP and UDP. 738 Applications using RAQMON Framework may use any unreserved UDP port. 739 For example, a session management program can allocate the port 740 randomly. A single fixed port cannot be required because multiple 741 applications within a host sharing a RDS implementation may encounter 742 difficulties as there are some operating systems that do not allow 743 multiple processes to use the same UDP port with different multicast 744 addresses. 746 However, port numbers 5XXX have been registered with IANA for use as 747 the default port for RAQMON PDUs over RTCP. Hosts that run multiple 748 applications may use this port as an indication to have used RAQMON 749 if they are not subject to the constraint of the previous paragraph. 750 RRCs may also use this port as a default to receive RAQMON PDUs 751 carried over RTCP which will reduce configuration needs for RDSs. 753 Applications need not have a default and may require that the port be 754 explicitly specified. The particular port number was chosen to lie in 755 the range above 5000 to accommodate port number allocation practice 756 within the Unix operating system, where privileged processes can only 757 use port numbers below 1024 and port numbers between 1024 and 5000 758 are automatically assigned by the operating systems. 760 3.2 SNMP INFORM PDUs as RDS/RRC Network Transport Protocol 762 The idea is to re-use SNMP INFORM PDU. If SNMP is chosen as a 763 mechanism to transport RAQMON PDU, the following specification 764 applies: 766 + RDSs implement the capability of embedding RAQMON parameters in 767 SNMP INFORM Request and thus re-using well known SNMP mechanisms to 768 report RAQMON Statistics. The RAQMON RDS MIB as identified in 3.2.1 769 MUST be used in order to map the RAQMON PDUs on SNMP Notifications 770 transport. 772 Managed objects are accessed via a virtual information store, termed 773 the Management Information Base or MIB. MIB objects are generally 774 accessed through the Simple Network Management Protocol (SNMP). 775 Objects in the MIB are defined using the mechanisms defined in the 776 Structure of Management Information (SMI). For a detailed overview of 777 the documents that describe the current Internet-Standard Management 778 Framework, please refer to section 7 of RFC 3410 [RFC3410]. 780 + Since RDSs are not computationally rich and to keep the RDS 781 realization lightweight, it is not required that RDSs fully implement 782 an SNMP-based Internet Management framework. Specifically RDSs MAY 783 NOT respond to SNMP requests like GET, SET, etc., as an SNMP 784 compliant responder would. 786 + Since RRCs are computationally rich, RRCs SHOULD implement a SNMP 787 manager. RRCS should send an SNMP INFORM Response for each associated 788 SNMP INFORM originated by the RDS. 790 + In order to meet congestion safety requirements, RDSs MUST process 791 the SNMP INFORM responses from RRCs, and MUST serialize the PDU 792 transmission rate. 794 + Standard UDP port 162 SHALL be used for SNMP Notifications. 796 3.2.1 Encoding RAQMON PDU by using the RAQMON RDS MIB 798 The RAQMON RDS MIB will be used in order to map the RAQMON PDUs on 799 SNMP Notifications transport. The MIB defines the objects needed for 800 the basic part of RAQMON PDU mapping, as well as the Notification. In 801 order to incorporate any application specific extensions in the APP 802 part of RAQMON PDU, varbinds may be included in the RAQMON 803 notifications described in the MIB. 805 This section specifies a MIB module that is compliant to the SMIv2, 806 which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 807 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 809 RAQMON-RDS-MIB DEFINITIONS ::= BEGIN 811 IMPORTS 812 Unsigned32, 813 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 814 FROM SNMPv2-SMI 815 raqmon, RaqmonDateAndTime 816 FROM RAQMON-MIB 817 Utf8String 818 FROM SYSAPPL-MIB 819 Dscp 820 FROM DIFFSERV-DSCP-TC 821 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 822 FROM SNMPv2-CONF; 824 raqmonDs MODULE-IDENTITY 825 LAST-UPDATED "200308251150Z" -- August 25, 2003 826 ORGANIZATION "RMON Working Group" 827 CONTACT-INFO 828 " 829 WG EMail: rmonmib@ietf.org 830 Subscribe: rmonmib-request@ietf.org 831 MIB Editor: 832 Eugene Golovinsky 833 Postal: BMC Software, Inc. 834 2101 CityWest Blvd, 835 Houston, TX, 77094 836 USA 837 Tel: +713-918-1816 838 Email: egolovin@bmc.com 839 " 840 DESCRIPTION 841 "This is RAQMON Data Source notification Module. 842 It provides mapping of RAQMON PDU to SNMP Notification. 844 Ds is for data source. 846 Note that all of the object types defined in this 847 module are accessible-for-notify, and would consequently 848 not be available to a browser using simple Get, GetNext, 849 or GetBulk requests. 851 This is a branch of the RAQMON module. 853 " 854 REVISION "200308251150Z" -- August 25, 2003 856 DESCRIPTION 857 "Changes after the 57th IETF." 859 ::= { raqmon 3 } 860 raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDs 0 } 862 raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDs 1 } 864 raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDs 2 } 866 raqmonDsNotificationTable OBJECT-TYPE 867 SYNTAX SEQUENCE OF RaqmonDsNotificationEntry 868 MAX-ACCESS not-accessible 869 STATUS current 870 DESCRIPTION 871 "This conceptual table provides the SNMP mapping 872 of the RAQMON Basic PDU. 873 Indexed by RAQMON session 874 " 875 ::= { raqmonDsMIBObjects 1 } 877 raqmonDsNotificationEntry OBJECT-TYPE 878 SYNTAX RaqmonDsNotificationEntry 879 MAX-ACCESS not-accessible 880 STATUS current 881 DESCRIPTION 882 "The entry (row) is not retrievable and is not kept 883 by RDSs. 884 It serves data organization purpose only. 885 " 886 INDEX { raqmonDSRC, 887 raqmonRCN } 888 ::= { raqmonDsNotificationTable 1 } 890 RaqmonDsNotificationEntry ::= 891 SEQUENCE { 892 raqmonDSRC 893 Unsigned32, 894 raqmonRCN 895 Integer32, 896 raqmonAppName 897 Utf8String, 898 raqmonDataSourceDevicePort 899 Unsigned32, 900 raqmonReceiverDevicePort 901 Unsigned32, 902 raqmonSessionSetupDateTime 903 RaqmonDateAndTime, 904 raqmonSessionSetupDelay 905 Unsigned32, 906 raqmonSessionDuration 907 Unsigned32, 908 raqmonSessionSetupStatus 909 Utf8String, 910 raqmonRoundTripEndtoEndDelay 911 Unsigned32, 912 raqmonOneWayEndtoEndDelay 913 Unsigned32, 914 raqmonInterArrivalJitter 915 Unsigned32, 916 raqmonTotalPacketsReceived 917 Counter32, 918 raqmonTotalPacketsSent 919 Counter32, 920 raqmonTotalOctetsReceived 921 Counter32, 922 raqmonTotalOctetsSent 923 Counter32, 924 raqmonCumulativePacketLoss 925 Counter32, 926 raqmonPacketLossFraction 927 Unsigned32, 928 raqmonSourcePayloadType 929 Unsigned32, 930 raqmonReceiverPayloadType 931 Unsigned32, 932 raqmonSourceLayer2Priority 933 Unsigned32, 934 raqmonDestinationLayer2Priority 935 Unsigned32, 936 raqmonSourceDscp 937 Dscp, 938 raqmonDestinationDscp 939 Dscp, 940 raqmonCpuUtilization 941 Unsigned32, 942 raqmonMemoryUtilization 943 Unsigned32 944 } 946 raqmonDSRC OBJECT-TYPE 947 SYNTAX Unsigned32 948 MAX-ACCESS accessible-for-notify 949 STATUS current 950 DESCRIPTION 951 "Data Source identifier represents a unique session 952 descriptor that points to a specific communication session 953 between communicating entities." 954 ::= { raqmonDsNotificationEntry 1 } 956 raqmonRCN OBJECT-TYPE 957 SYNTAX Integer32 (0..15) 958 MAX-ACCESS accessible-for-notify 959 STATUS current 960 DESCRIPTION 961 "The Record Count Number indicates a sub-session 962 within a communication session." 963 ::= { raqmonDsNotificationEntry 2 } 965 raqmonAppName OBJECT-TYPE 966 SYNTAX Utf8String 967 MAX-ACCESS accessible-for-notify 968 STATUS current 969 DESCRIPTION 970 "This is a text string giving the name and possibly version 971 of the application associated to that session, 972 e.g., --XYZ VoIP Agent 1.2." 973 REFERENCE 974 "Section 5.28 of the [RAQMON FRAMEWORK]" 975 ::= { raqmonDsNotificationEntry 3 } 977 raqmonDataSourceDevicePort OBJECT-TYPE 978 SYNTAX Unsigned32 (0..65535) 979 MAX-ACCESS accessible-for-notify 980 STATUS current 981 DESCRIPTION 982 "The port number from which data for this session was sent." 983 REFERENCE 984 "Section 5.5 of the [RAQMON FRAMEWORK]" 985 ::= { raqmonDsNotificationEntry 4 } 987 raqmonReceiverDevicePort OBJECT-TYPE 988 SYNTAX Unsigned32 (0..65535) 989 MAX-ACCESS accessible-for-notify 990 STATUS current 991 DESCRIPTION 992 "The port number where the data for this session was received." 993 REFERENCE 994 "Section 5.6 of the [RAQMON FRAMEWORK]" 995 ::= { raqmonDsNotificationEntry 5 } 997 raqmonSessionSetupDateTime OBJECT-TYPE 998 SYNTAX RaqmonDateAndTime 999 MAX-ACCESS accessible-for-notify 1000 STATUS current 1001 DESCRIPTION 1002 "The time when session was initiated." 1003 REFERENCE 1004 "Section 5.7 of the [RAQMON FRAMEWORK]" 1005 ::= { raqmonDsNotificationEntry 6 } 1007 raqmonSessionSetupDelay OBJECT-TYPE 1008 SYNTAX Unsigned32 1009 MAX-ACCESS accessible-for-notify 1010 STATUS current 1011 DESCRIPTION 1012 "Session setup time in milliseconds." 1013 REFERENCE 1014 "Section 5.8 of the [RAQMON FRAMEWORK]" 1015 ::= { raqmonDsNotificationEntry 7 } 1017 raqmonSessionDuration OBJECT-TYPE 1018 SYNTAX Unsigned32 1019 MAX-ACCESS accessible-for-notify 1020 STATUS current 1021 DESCRIPTION 1022 "Session duration in seconds." 1023 REFERENCE 1024 "Section 5.9 of the [RAQMON FRAMEWORK]" 1025 ::= { raqmonDsNotificationEntry 8 } 1027 raqmonSessionSetupStatus OBJECT-TYPE 1028 SYNTAX Utf8String 1029 MAX-ACCESS accessible-for-notify 1030 STATUS current 1031 DESCRIPTION 1032 "Describes appropriate communication session states e.g. 1033 Call Established successfully, RSVP reservation 1034 failed etc." 1035 REFERENCE 1036 "Section 5.10 of the [RAQMON FRAMEWORK]" 1037 ::= { raqmonDsNotificationEntry 9 } 1039 raqmonRoundTripEndtoEndDelay OBJECT-TYPE 1040 SYNTAX Unsigned32 1041 MAX-ACCESS accessible-for-notify 1042 STATUS current 1043 DESCRIPTION 1044 "Round trip end to end delay in milliseconds." 1045 REFERENCE 1046 "Section 5.10 of the [RAQMON FRAMEWORK]" 1047 ::= { raqmonDsNotificationEntry 10} 1049 raqmonOneWayEndtoEndDelay OBJECT-TYPE 1050 SYNTAX Unsigned32 1051 MAX-ACCESS accessible-for-notify 1052 STATUS current 1053 DESCRIPTION 1054 "One way end to end delay in milliseconds." 1055 REFERENCE 1056 "Section 5.12 of the [RAQMON FRAMEWORK]" 1057 ::= { raqmonDsNotificationEntry 11} 1059 raqmonInterArrivalJitter OBJECT-TYPE 1060 SYNTAX Unsigned32 1061 MAX-ACCESS accessible-for-notify 1062 STATUS current 1063 DESCRIPTION 1064 "An estimate of the statistical variance of packets 1065 inter-arrival time expressed in milliseconds." 1066 REFERENCE 1067 "Section 5.13 of the [RAQMON FRAMEWORK]" 1068 ::= { raqmonDsNotificationEntry 12} 1070 raqmonTotalPacketsReceived OBJECT-TYPE 1071 SYNTAX Counter32 1072 MAX-ACCESS accessible-for-notify 1073 STATUS current 1074 DESCRIPTION 1075 "The total number of packets 1076 transmitted within a communication session by the receiver 1077 since starting transmission up until the time this RAQMON 1078 packet was generated." 1079 REFERENCE 1080 "Section 5.14 of the [RAQMON FRAMEWORK]" 1081 ::= { raqmonDsNotificationEntry 13 } 1083 raqmonTotalPacketsSent OBJECT-TYPE 1084 SYNTAX Counter32 1085 MAX-ACCESS accessible-for-notify 1086 STATUS current 1087 DESCRIPTION 1088 "The total number of packets 1089 transmitted within a communication session by the sender since 1090 starting transmission up until the time this RAQMON packet was 1091 generated." 1092 REFERENCE 1093 "Section 5.15 of the [RAQMON FRAMEWORK]" 1094 ::= { raqmonDsNotificationEntry 14 } 1096 raqmonTotalOctetsReceived OBJECT-TYPE 1097 SYNTAX Counter32 1098 MAX-ACCESS accessible-for-notify 1099 STATUS current 1100 DESCRIPTION 1101 "The total number of payload 1102 octets (i.e., not including header or padding) transmitted in 1103 packets by the receiver within a communication session since 1104 starting transmission up until the time this RAQMON packet 1105 was generated." 1106 REFERENCE 1107 "Section 5.16 of the [RAQMON FRAMEWORK]" 1108 ::= { raqmonDsNotificationEntry 15 } 1110 raqmonTotalOctetsSent OBJECT-TYPE 1111 SYNTAX Counter32 1112 MAX-ACCESS accessible-for-notify 1113 STATUS current 1114 DESCRIPTION 1115 "The total number of payload octets 1116 i.e., not including header or padding) transmitted in packets 1117 by the sender within a communication session since starting 1118 transmission up until the time this RAQMON packet was generated." 1119 REFERENCE 1120 "Section 5.17 of the [RAQMON FRAMEWORK]" 1121 ::= { raqmonDsNotificationEntry 16 } 1123 raqmonCumulativePacketLoss OBJECT-TYPE 1124 SYNTAX Counter32 1125 MAX-ACCESS accessible-for-notify 1126 STATUS current 1127 DESCRIPTION 1128 "The total number of packets from session 1129 that have been lost while this notification was generated. 1130 This number is expected to be less the number of packets 1131 actually received." 1132 REFERENCE 1133 "Section 5.18 of the [RAQMON FRAMEWORK]" 1134 ::= { raqmonDsNotificationEntry 17 } 1136 raqmonPacketLossFraction OBJECT-TYPE 1137 SYNTAX Unsigned32 (0..100) 1138 MAX-ACCESS accessible-for-notify 1139 STATUS current 1140 DESCRIPTION 1141 "The percentage of lost packets with respect to the overall packets 1142 sent. This fraction is defined to be the number of packets lost 1143 divided by the number of packets expected." 1144 REFERENCE 1145 "Section 5.19 of the [RAQMON FRAMEWORK]" 1146 ::= { raqmonDsNotificationEntry 18 } 1148 raqmonSourcePayloadType OBJECT-TYPE 1149 SYNTAX Unsigned32 (0..127) 1150 MAX-ACCESS accessible-for-notify 1151 STATUS current 1152 DESCRIPTION 1153 "The payload type of the packet sent by this RD." 1154 REFERENCE 1155 "RFC 1890, Section 5.20 of the [RAQMON FRAMEWORK] " 1156 ::= { raqmonDsNotificationEntry 19 } 1158 raqmonReceiverPayloadType OBJECT-TYPE 1159 SYNTAX Unsigned32 (0..127) 1160 MAX-ACCESS accessible-for-notify 1161 STATUS current 1162 DESCRIPTION 1163 "The payload type of the packet received by this RD." 1164 REFERENCE 1165 "RFC 1890, Section 5.21 of the [RAQMON FRAMEWORK] " 1166 ::= { raqmonDsNotificationEntry 20 } 1168 raqmonSourceLayer2Priority OBJECT-TYPE 1169 SYNTAX Unsigned32 (0..7) 1170 MAX-ACCESS accessible-for-notify 1171 STATUS current 1172 DESCRIPTION 1173 "Source Layer 2 priorities used to send packets to the 1174 receiver by this data source during this communication 1175 session." 1176 REFERENCE 1177 "Section 5.22 of the [RAQMON FRAMEWORK]" 1178 ::= { raqmonDsNotificationEntry 21 } 1180 raqmonDestinationLayer2Priority OBJECT-TYPE 1181 SYNTAX Unsigned32 (0..7) 1182 MAX-ACCESS accessible-for-notify 1183 STATUS current 1184 DESCRIPTION 1185 "Destination Layer 2 priority." 1186 REFERENCE 1187 "Section 5.24 of the [RAQMON FRAMEWORK]" 1188 ::= { raqmonDsNotificationEntry 22 } 1190 raqmonSourceDscp OBJECT-TYPE 1191 SYNTAX Dscp 1192 MAX-ACCESS accessible-for-notify 1193 STATUS current 1194 DESCRIPTION 1195 "Source DSCP value." 1197 REFERENCE 1198 "Section 5.23 of the [RAQMON FRAMEWORK]" 1199 ::= { raqmonDsNotificationEntry 23 } 1201 raqmonDestinationDscp OBJECT-TYPE 1202 SYNTAX Dscp 1203 MAX-ACCESS accessible-for-notify 1204 STATUS current 1205 DESCRIPTION 1206 "Destination DSCP value." 1207 REFERENCE 1208 "Section 5.25 of the [RAQMON FRAMEWORK]" 1209 ::= { raqmonDsNotificationEntry 24 } 1211 raqmonCpuUtilization OBJECT-TYPE 1212 SYNTAX Unsigned32 (0..100) 1213 MAX-ACCESS accessible-for-notify 1214 STATUS current 1215 DESCRIPTION 1216 "Percentage of total CPU utilization over a time duration." 1217 REFERENCE 1218 "Section 5.26 of the [RAQMON FRAMEWORK]" 1219 ::= { raqmonDsNotificationEntry 25 } 1221 raqmonMemoryUtilization OBJECT-TYPE 1222 SYNTAX Unsigned32 (0..100) 1223 MAX-ACCESS accessible-for-notify 1224 STATUS current 1225 DESCRIPTION 1226 "Percentage of total memory utilization over a time duration." 1227 REFERENCE 1228 "Section 5.27 of the [RAQMON FRAMEWORK]" 1229 ::= { raqmonDsNotificationEntry 26 } 1231 -- 1232 -- definitions of the notifications 1233 -- The object list includes only the OBJECTS that will be send by a 1234 -- RD in any notification. 1235 -- Other objects from the raqmonDsNotificationTable may be included 1236 -- in the varbind. 1238 raqmonDsNotification NOTIFICATION-TYPE 1239 OBJECTS { 1240 raqmonDSRC, 1241 raqmonRCN 1242 } 1243 STATUS current 1244 DESCRIPTION 1245 "This notification maps basic RAQMON PDU into SNMP transport." 1246 ::= { raqmonDsEvents 1 } 1248 raqmonDsByeNotification NOTIFICATION-TYPE 1249 OBJECTS { 1250 raqmonDSRC } 1251 STATUS current 1252 DESCRIPTION 1253 "The BYE Notification. This Notification is the equivalent 1254 of the RAQMON BYE PDU, which signals the end of a RAQMON 1255 session." 1256 ::= { raqmonDsEvents 2 } 1258 -- 1259 -- conformance information 1260 -- These don't show up on the wire, so they only need to be unique. 1261 -- 1262 raqmonDsCompliances OBJECT IDENTIFIER ::= { raqmonDsConformance 1 } 1263 raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } 1265 raqmonDsBasicCompliances MODULE-COMPLIANCE 1266 STATUS current 1267 DESCRIPTION 1268 "The compliance statement for SNMP entities which 1269 implement this MIB module." 1270 MODULE -- this module 1271 MANDATORY-GROUPS { raqmonDsNotificationGroup, 1272 raqmonDsPayloadGroup } 1273 ::= { raqmonDsCompliances 1 } 1275 raqmonDsNotificationGroup NOTIFICATION-GROUP 1276 NOTIFICATIONS { raqmonDsNotification, 1277 raqmonDsByeNotification } 1278 STATUS current 1279 DESCRIPTION 1280 "The notifications implemented by an SNMP entity 1281 claiming conformance to this MIB. 1282 " 1283 ::= { raqmonDsGroups 1 } 1285 raqmonDsPayloadGroup OBJECT-GROUP 1286 OBJECTS { 1287 raqmonDSRC, 1288 raqmonRCN, 1289 raqmonAppName, 1290 raqmonDataSourceDevicePort, 1291 raqmonReceiverDevicePort, 1292 raqmonSessionSetupDateTime, 1293 raqmonSessionSetupDelay, 1294 raqmonSessionDuration, 1295 raqmonSessionSetupStatus, 1296 raqmonRoundTripEndtoEndDelay, 1297 raqmonOneWayEndtoEndDelay, 1298 raqmonInterArrivalJitter, 1299 raqmonTotalPacketsReceived, 1300 raqmonTotalPacketsSent, 1301 raqmonTotalOctetsReceived, 1302 raqmonTotalOctetsSent, 1303 raqmonCumulativePacketLoss, 1304 raqmonPacketLossFraction, 1305 raqmonSourcePayloadType, 1306 raqmonReceiverPayloadType, 1307 raqmonSourceLayer2Priority, 1308 raqmonDestinationLayer2Priority, 1309 raqmonSourceDscp, 1310 raqmonDestinationDscp, 1311 raqmonCpuUtilization, 1312 raqmonMemoryUtilization 1313 } 1314 STATUS current 1315 DESCRIPTION 1316 "These objects are required for entities 1317 claiming conformance to this MIB. 1318 " 1319 ::= { raqmonDsGroups 2 } 1321 END 1323 4.0 Congestion Safe RAQMON Operation: 1325 RAQMON PDU can be transmitted over multiple transport protocols. A RAQMON PDU allows the usage of UDP as transport, which might lead to network congestion under heavy network load. To ensure congestion safety clearly the best thing to do is to use a transport protocol like TCP or SCTP, etc. If this is not feasible, it may be necessary to fall back to UDP. Implementers MUST follow section 3.0 of [RAQMON-Framework] guidelines that outlines measures that MUST be taken to use RAQMON in congestion safe manner. 1327 5. Normative References 1329 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1330 Rose, M. and S. Waldbusser, "Structure of Management 1331 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1332 1999. 1334 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1335 Rose, M. and S. Waldbusser, "Textual Conventions for 1336 SMIv2", STD 58, RFC 2579, April 1999. 1338 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1339 Rose, M. and S. Waldbusser, "Conformance Statements for 1340 SMIv2", STD 58, RFC 2580, April 1999. 1342 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 1343 Information Base", STD 59, RFC 2819, May 2000 1345 [RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 1346 "RTP: A Transport Protocol for Real-Time Applications" 1347 RFC 1889, January 1996. 1349 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1350 1981. 1352 [RAQMON-Framework] A. Siddiqui, D.Romascanu, and E. Golovinsky, 1353 "Framework for Real-time Application Quality of Service 1354 Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon- 1355 framework-03.txt, September 2003 1357 6. Informative References 1359 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1360 "Introduction and Applicability Statements for Internet- 1361 Standard Management Framework", RFC 3410, December 2002 1363 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1364 Requirement Levels", BCP 14, RFC 2119, March 1997. 1366 [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video 1367 Conferences with Minimal Control" RFC 1890, January 1996. 1369 [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, 1370 March 1992. 1372 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 1373 STD 13, RFC 1034, November 1987. 1375 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 1376 Specification", STD 13, RFC 1035, November 1987. 1378 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1379 and Support", STD 3, RFC 1123, October 1989. 1381 [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, 1382 "Address Allocation for Private Internets", RFC 1597, March 1383 1994. 1385 [RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay 1386 Metric for IPPM", RFC 2679, September 1999 1388 [RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet 1389 Loss Metric for IPPM", RFC 2680, September 1999 1391 [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay 1392 Metric for IPPM", RFC 2681, September 1999 1394 [ISO10646] International Standards Organization, "ISO/IEC DIS 1395 10646-1:1993information technology -- universal 1396 multiple-octet coded character set (UCS) -- part I: 1397 Architecture and basic multilingual plane," 1993. 1399 [UNICODE] The Unicode Consortium, The Unicode Standard New York, 1400 New York:Addison-Wesley, 1991. 1402 [IEEE802.1D] Information technology-Telecommunications and information 1403 exchange between systems--Local and metropolitan area 1404 networks-Common Specification a--Media access control (MAC) 1405 bridges:15802-3: 1998 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1406 1998 Edition] 1408 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite", 1409 RFC 1349, July 1992 1411 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812, 1412 June 1995 1414 [RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition of 1415 the Differentiated Services Field (DS Field) in the IPv4 and 1416 IPv6 Headers", RFC2474, December 1998 1418 [RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss, 1419 "An Architecture for Differentiated Services" RFC2475, 1420 December 1998 1422 7. Intellectual Property 1424 The IETF takes no position regarding the validity or scope of any 1425 intellectual property or other rights that might be claimed to 1426 pertain to the implementation or use of the technology described in 1427 this document or the extent to which any license under such rights 1428 might or might not be available; neither does it represent that it 1429 has made any effort to identify any such rights. Information on the 1430 IETF's procedures with respect to rights in standards-track and 1431 standards-related documentation can be found in BCP-11. Copies of 1432 claims of rights made available for publication and any assurances of 1433 licenses to be made available, or the result of an attempt made to 1434 obtain a general license or permission for the use of such 1435 proprietary rights by implementors or users of this specification can 1436 be obtained from the IETF Secretariat. 1438 The IETF invites any interested party to bring to its attention any 1439 copyrights, patents or patent applications, or other proprietary 1440 rights which may cover technology that may be required to practice 1441 this standard. Please address the information to the IETF Executive 1442 Director. 1444 8. Appendix 1446 The implementation notes included in this Appendix are for 1447 informational purposes only and are meant to clarify the RAQMON 1448 specification. 1450 Pseudo code for RDS & RRC 1452 We provide examples of Pseudo code for aspects of RDS and RRC. There 1453 may be other implementation methods that are faster in particular 1454 operating environments or have other advantages. 1456 RDS: 1457 when (session starts} { 1458 report.identifier = session.endpoints, session.starttime; 1459 report.timestamp = 0; 1460 while (session in progress) { 1461 wait interval; 1462 report.statistics = update statistics; 1463 report.curtimestamp += interval; 1464 if encryption required 1465 report_data = encrypt(report, encrypt parameters); 1466 else 1467 report_data = report; 1468 raqmon_pdu = header, report_data; 1469 send raqmon-pdu; 1470 } 1471 } RRC: 1472 listen on raqmon port 1473 when ( raqmon_pdu received ) { 1474 decrypt raqmon_pdu.data if needed 1476 if report.identifier in database 1477 if report.current_time_stamp > last update 1478 update session statistics from report.statistics 1479 else 1480 discard report 1481 } 1483 9. Security Considerations 1485 The [RAQMON-Framework] memo outlined a threat model associated to 1486 RAQMON and some security considerations taken into account within 1487 RAQMON specification to alleviate those threats. It is imperative 1488 that the RAQMON PDU implementations be able to provide the following 1489 protection mechanisms to attain end-to-end security: 1491 1. Authentication - the RRC SHOULD be able to verify that a RAQMON 1492 report was originated by the RDS who claims to have sent it. At 1493 minimum, a RDS/RRC pair MUST use a digest based authentication 1494 procedure to authenticate. 1496 2. Privacy - RAQMON information includes identification of the 1497 parties participating in a communication session. RAQMON deployment 1498 SHOULD be able to provide protection from eavesdropping, and to 1499 prevent an unauthorized third party from gathering potentially 1500 sensitive information. This can be achieved by using payload 1501 encryption technologies like DES, 3-DES, AES 1503 3. Protection from Denial of Service attacks directed at the RRC - 1504 RDSs send RAQMON reports as a side effect of an external event (for 1505 example, a phone call is being received). An attacker can try and 1506 overwhelm the RRC (or the network) by initiating a large number of 1507 events for the purpose of swamping the RRC with too many RAQMON PDUs. 1509 To prevent DoS attacks against RRC, the RDS will send the first 1510 report for a session only after the session has been in progress. 1512 4. NAT and Firewall Friendly Design: Presence for IP addresses, 1513 TCP/UDP ports information in RAQMON PDUs may be NAT un-friendly. In 1514 such a scenario, where NAT Friendliness is a requirement, the RDS may 1515 opt to not to provide IP Addresses in RAQMON PDU. Another way to 1516 avoid this problem is by using NAT Aware Application Layer Gateways 1517 (ALGs)to fill out IP Addresses in RAQMON PDUs. 1519 This memo also defines a RDS SNMP MIB with the purpose of mapping the 1520 RAQMON PDUs into SNMP Notifications. To attain end to end security 1521 The following measures have been taken in RDS MIB implementation: 1523 There are no management objects defined in this MIB module that have 1524 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1525 MIB module is implemented correctly, then there is no risk that an 1526 intruder can alter or create any management objects of this MIB 1527 module via direct SNMP SET operations. 1529 Some of the readable objects in this MIB module (i.e., objects with a 1530 MAX-ACCESS other than not-accessible) may be considered sensitive or 1531 vulnerable in some network environments. It is thus important to 1532 control even GET and/or NOTIFY access to these objects and possibly 1533 to even encrypt the values of these objects when sending them over 1534 the network via SNMP. These are the tables and objects and their 1535 sensitivity/vulnerability: 1537 raqmonDsNotificationTable 1539 The objects in this table contain user sessions information, and 1540 their disclosure may be sensitive in some environments. 1542 SNMP versions prior to SNMPv3 did not include adequate security. Even 1543 if the network itself is secure (for example by using IPSec), even 1544 then, there is no control as to who on the secure network is allowed 1545 to access and GET/SET (read/change/create/delete) the objects in this 1546 MIB module. 1548 It is RECOMMENDED that implementers consider the security features as 1549 provided by the SNMPv3 framework (see [RFC3410], section 8), 1550 including full support for the SNMPv3 cryptographic mechanisms (for 1551 authentication and privacy). 1553 Though not mandatory for RAQMON compliance, it is RECOMMENDED to 1554 deploy SNMPv3 and to enable cryptographic security for RAQMON PDUs. 1555 It is a customer/operator responsibility to ensure that the SNMP 1556 entity giving access to an instance of this MIB module is properly 1557 configured to give access to the objects only to those principals 1558 (users) that have legitimate rights to indeed GET or SET 1559 (change/create/delete) them. 1561 10. IANA Considerations 1563 This memo introduces a port for usage of RTCP as transport protocol, 1564 a "name" for specific RTCP APP name == "RMON", and mandates the use 1565 of subtype 1 for RAQMON PDUs, as specified in Section 3.1, at 1566 http://www.iana.org/numbers.html 1568 11. Authors' Addresses 1569 Anwar A. Siddiqui 1570 Avaya Labs 1571 307 Middletown Lincroft Road 1572 Lincroft, New Jersey 07738 1573 USA 1574 Tel: +1 732 852-3200 1575 E-mail: anwars@avaya.com 1577 Dan Romascanu 1578 Avaya Inc. 1580 Atidim Technology Park, Bldg. #3 1581 Tel Aviv, 61131 1582 Israel 1583 Tel: +972-3-645-8414 1584 Email: dromasca@avaya.com 1586 Eugene Golovinsky 1587 BMC Software 1588 2101 CityWest Blvd. 1589 Houston, Texas 77042 1590 USA 1591 Tel: +1 713 918-1816 1592 Email: eugene_golovinsky@bmc.com 1594 A. Full Copyright Statement 1596 This document and translations of it may be copied and furnished to 1597 others, and derivative works that comment on or otherwise explain it 1598 or assist in its implementation may be prepared, copied, published 1599 and distributed, in whole or in part, without restriction of any 1600 kind, provided that the above copyright notice and this paragraph are 1601 included on all such copies and derivative works. However, this 1602 document itself may not be modified in any way, such as by removing 1603 the copyright notice or references to the Internet Society or other 1604 Internet organizations, except as needed for the purpose of 1605 developing Internet standards in which case the procedures for 1606 copyrights defined in the Internet Standards process must be 1607 followed, or as required to translate it into languages other than 1608 English. 1610 The limited permissions granted above are perpetual and will not be 1611 revoked by the Internet Society or its successors or assigns. 1613 This document and the information contained herein is provided on an 1614 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1615 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1616 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1617 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1618 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.