idnits 2.17.1 draft-ietf-rmonmib-raqmon-pdu-02.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 34 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 35 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 80 instances of too long lines in the document, the longest one being 5 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 1140 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 (9 June 2003) is 7598 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) -- Looks like a reference, but probably isn't: '17' on line 273 == Missing Reference: 'RFC 1889' is mentioned on line 695, but not defined ** Obsolete undefined reference: RFC 1889 (Obsoleted by RFC 3550) == Unused Reference: 'RFC1889' is defined on line 1396, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 1420, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1423, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1426, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1429, but no explicit reference was found in the text == Unused Reference: 'RFC1597' is defined on line 1432, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 1436, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1439, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1442, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1D' is defined on line 1453, but no explicit reference was found in the text == Unused Reference: 'RFC1349' is defined on line 1459, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 1462, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1465, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 1469, 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: 8 errors (**), 0 flaws (~~), 22 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 9 June 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 QOS statistics using RTCP and SNMP as Transport Protocols. 41 This memo also outlines mechanisms to use the Real Time Transport 42 Control Protocol (RTCP) and the Simple Network Management Protocol 43 (SNMP) to transport these PDUs between RAQMON Data Source (RDS) and 44 RAQMON Report Collector (RRC). 46 Distribution of this memo is unlimited. 48 Table of Contents 50 Status of this Memo 1 51 Abstract 1 52 1 Introduction 2 53 2 RAQMON PDU Format 3 54 3 Transporting RAQMON Protocol Data Units 15 55 4 Congestion Safe RAQMON Operation 29 56 5 Normative References 29 57 6 Informative References 30 58 7 Intellectual Property 31 59 8 Security Considerations 32 60 9 IANA Considerations 33 61 10 Authors' Addresses 34 62 A Full Copyright Statement 34 64 1. Introduction 66 There is a need to extend the RMON framework [RFC2819] to monitor end 67 devices such as IP Phones, Pagers, Instant Message Clients, Mobile 68 Phones, and various other Hand held computing devices. Real-Time 69 Application QoS Monitoring (RAQMON) Framework as outlined by [RAQMON- 70 framework] extends RMON by defining entities such as RAQMON Data 71 Source (RDS) and RAQMON Report Collector (RRC) to perform various 72 application monitoring in Real-time. This memo defines a common 73 protocol data unit (PDU) used between a RAQMON Data Source (RDS) and 74 a RAQMON Report Collector (RRC) to report a QoS statistics. This memo 75 contains detailed RAQMON PDU specification and specifies usage of 76 RTCP and SNMP as an underlying transport protocols to carry RAQMON 77 PDUs. Either RTCP or SNMP is used to carry RAQMON PDU between RDS and 78 RRC. 80 The RAQMON Protocol Data Unit (PDU) is a common data format (i.e. 81 "Name" and "Value" pair) understood by RDS and RRC. A RAQMON PDU does 82 not transport application data but rather occupies the place of a 83 payload specification at the application layer of the protocol stack. 84 Mechanisms outlined in this draft can be used by many Real-Time 85 Applications as well as for non-real time applications managed within 86 RMON Framework and allows network entities to report application 87 level QoS parameters in Realtime. Voice over IP, Fax over IP, Video 88 over IP, Instant Messaging (IM), Email, software download 89 applications, e-business style transactions, web access from handheld 90 computing devices are few examples of applications that can 91 potentially use RAQMON Framework for monitoring purposes. 93 Though transmitted as one Protocol Data Unit, RAQMON PDU is 94 functionally divided into two different parts namely Basic Part and 95 an Application specific extensions required for vendor specific 96 extension. Both functional parts trail behind SMI Network Management 97 Private Enterprise Codes and currently maintained by IANA 98 http://www.iana.org/assignments/enterprise-numbers. 100 BASIC Part of RAQMON PDU: The basic part of the RAQMON PDU trails 101 behind the SMI Network Management Private Enterprise Code 0 - 102 reserved by convention for use by the IETF RMON Working Group. The 103 RAQMON PDU basic part offers an entry-type (a.k.a. "Name") from a 104 pre-defined list of QoS parameters defined in table 1 and allows 105 applications to fill in appropriate values for those parameters. 106 Application developers also have the flexibility to report only a 107 sub-set of the parameters listed in table 1 as discussed in later 108 sections. 110 Application Part of RAQMON PDU: Since it is difficult to structure a 111 BASIC Part that meets the needs of all applications, RAQMON provides 112 extension capabilities to convey application-, vendor-, device- etc. 113 specific parameters for future use. Additional parameters can be 114 defined within payload of the APP part of the PDU as Type Length 115 Value (TLV) pairs and defined by the application developers or 116 vendors. Application part of the RAQMON PDU trails behind the SMI 117 Network Management Private Enterprise Codes of the vendor found in 118 http://www.iana.org/assignments/enterprise-numbers. Such application 119 specific extensions should be maintained and published by the 120 application vendor. 122 Though RDS and RRC are designed to be mostly stateless for an entire 123 reporting session, the framework would require an indication for end 124 of reporting session between RDS and RRC. In order to achieve this 125 functionality, the RDS should send a RAQMON PDU with all NULL values 126 to indicate end of reporting session to RRC. A NULL PDU is a RAQMON 127 PDU with containing ALL NULL values (i.e. nothing to report) and a 128 NULL PDU specification is available in section 2. 130 Following sections of this memo contains detailed RAQMON PDU 131 specifications and usage of RTCP and SNMP to carry a RAQMON PDU. 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 2. RAQMON PDU Format 139 Parameters carried by RAQMON PDUs are defined in [RAQMON-Framework] 140 through reference to existing IETF, ITU and other standards 141 organizations' documents. 143 The RAQMON PDU format is specified in this memo provides syntax and 144 structure within a RAQMON PDU to report those parameters. A RAQMON 145 PDU in the current version is marked as PDU Type (PDT) = 1. 147 A RAQMON PDU has two parts i.e. Basic Part and an Application 148 specific Part. The applications vendors should use the Basic part of 149 the PDU to report statistics pre-listed here in the specification 150 which will ensure basic interoperability between multiple vendor and 151 application developers. It is also envisioned that vendors would use 152 application specific extension while needed to convey application-, 153 vendor-, device- etc. specific parameters not included in the Basic 154 part of the specification and publish such data to attain extended 155 interoperability. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | V |PDT = 1|B|T|P|I| RC | Length | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | DSRC | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | SMI Enterprise Code = 0 | Report Type = 0 | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Data Source Address {DA} | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Receiver's Address (RA) | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 172 | NTP Timestamp, most significant word | 173 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 | NTP Timestamp, least significant word | 175 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 | Length | Application Name (AN) ... | 177 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 178 | ... | 179 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 | Length | Data Source Name (DN) ... | 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 | ... | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | Length | Receiver's Name (RN) ... | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 | ... | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | Length | Session State ... | 189 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 190 | ... | 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 | Session Duration | 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 194 | Round Trip End-to-End Delay | 195 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 196 | One Way End-to-End Delay | 197 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 | Cumulative Packet Loss | 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 | Total # Packets sent | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | Total # Packets received | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 | Total # Octets sent | 205 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 206 | Total # Octets received | 207 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 208 | Source Port Used | Receiver Port Used | 209 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 210 | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | 211 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 212 |Source Payload |Reciver Payload| CPU | Memory | 213 |Type | Type | Utilization | Utilization | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Session Setup Delay | Inter arrival Jitter | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Padding | Packet loss | 218 | | (In fraction)| 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | SMI Enterprise Code = "xxx" | Report Type = "yyy" | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | application/vendor specific extension | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | ............ | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | ............... | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | ............... | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 Figure 1 - RAQMON Protocol Data Unit 232 version (V) : 4 bits - Identifies the version of RAQMON. This version 233 is 1. 235 PDU type (PDT): 4 bits - This indicates the type of RAQMON PDU being 236 sent. PDT = 1 is used for current RAQMON PDU version. 238 basic (B): 1 bit - While set to 1, basic flag indicates that the PDU 239 has Basic part of the RAQMON PDU. A value of zero is considered to be 240 valid as it may constitute a RAQMON NULL PDU. 242 trailer (T) : 1 bit - While set to 1, trailer flag indicates that the 243 PDU has Application specific extension. A value of zero is considered 244 to be valid as it may constitute a RAQMON NULL PDU. 246 padding (P): 1 bit - If the padding bit is set, this RAQMON PDU 247 contains some additional padding octets at the end of the Basic Part 248 of the PDU which are not part of the monitoring information as 249 padding may be needed by some applications as reporting is based on 250 the intent of RDS to report certain parameters. Also some parameters 251 may be reported only once at the beginning of the reporting session 252 e.g. Data Source Name, Receiver Name, Pay Load type etc. Actual 253 padding at the end of the Basic part of the PDU, is either 0,8, 16 or 254 24 bits to make the basic part of the PDU multiple of 32 bits long. 256 IP version (I): 1 bit - While set to 1, IP Version Flag indicates 257 that IP addresses contained in the PDU are IP version 6 compatible. 259 record count (RC): 4 bits - Total number of records contained in the 260 Basic part of the PDU. A value of zero is considered to be valid but 261 useless. 263 length: 16 bits - The length of this RAQMON PDU in 32-bit words minus 264 one which includes the header and any padding. 266 DSRC: 32 bits - Data Source identifier represents a unique RAQMON 267 reporting session descriptor that points to a specific reporting 268 session between RDS and RRC. Uniqueness of DSRC is valid only within 269 a reporting session. DSRC values should be randomly generated using 270 vendor chosen algorithms for each communication session. It is not 271 sufficient to obtain a DSRC simply by calling random() without 272 carefully initializing the state. One could use an algorithm like 273 the one defined in Appendix A.6 in [17] to create a DSRC. Depending 274 on the choice of algorithm, there is a finite probability that two 275 DSRCS from two different RDSs may be same. To further reduce the 276 probability that two RDSs pick the same DSRC for two different 277 reporting session, it is recommended that an RRC use parameters like 278 Data Source Address (DA), Data Source Name (DN), MAC Address in the 279 PDU in conjunction with a DSRC value. Though it is not mandatory for 280 RDSs to send parameters like Data Source Address (DA), Data Source 281 Name (DN), MAC Address in the every PDU sent to RRC, but sending 282 these parameters occasionally will reduce the probability of DSRC 283 collision drastically. However this will cause an additional overhead 284 per PDU. 286 A RAQMON PDU must contain V, PDT, B, T, P, I, RC, length and DSRC 287 fields at all times. A value of zero for basic (B) bit and trailer 288 (T) bit set constitutes a RAQMON NULL PDU (i.e. nothing to report). 289 RDSs MUST send a RAQMON NULL PDU to RRC to indicate end of RDS 290 reporting session. All other parameters listed in the PDU described 291 below are optionally used when RDSs have some information to send to 292 RRC. 294 2.1 BASIC part of RAQMON Protocol Data Unit: 296 SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is 297 used to indicate RMON WG compliant Basic part of the RAQMON PDU 298 format. http://www.iana.org/assignments/enterprise-numbers. Basic 299 Part of the RAQMON PDU must trail behind the SMI Enterprise Code = 0 300 to ensure interoperability. 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 | V |PDT = 1|B|T|P|I| RC | Length | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | DSRC | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 | SMI Enterprise Code = 0 | Report Type = 0 | 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 | RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU 313 Report Type: 16 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 Basic part of Each RAQMON PDU consists of Record Count Number (RC_N) 318 and RAQMON Parameter Presence Flags (RPPF) to indicate presence of 319 appropriate RAQMON parameters within a record as defined in table 1. 321 RC_N: 4 bits - Record Count number to which the information in this 322 record pertains. Record Count number indicates a sub-session within a 323 communication session. A value of zero is a valid record number. 324 Maximum number of records that can be described in one RAQMON Packet 325 is 16 (i.e. 0000 - 1111). 327 RAQMON Parameter Presence Flags (RPPF): 28 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 1 Data Source Address (DA) 336 2 Receiver Address (RA) 337 3 NTP Timestamp 338 4 Application Name 339 5 Data Source Name (DN) 340 6 Receiver Name (RN) 341 7 Session Setup Status 342 8 Session Duration 343 9 End-to-End Delay (RTT) 344 0 End-to-End Delay (OWD) 345 1 Cumulative Packet Loss 346 2 Total number of Packets sent 347 3 Total number of Packets received 348 4 Total number of Octets sent 349 5 Total number of Octets received 350 6 Source Port Used 351 7 Receiver Port Used 352 8 S_Layer2 353 9 S_Layer3 354 0 D_Layer2 355 1 D_Layer3 356 2 Source Payload Type 357 3 Receiver Payload Type 358 4 CPU Utilization 359 5 Memory Utilization 360 6 Session Setup Delay 361 7 Inter arrival Jitter 362 8 Packet loss (in fraction) 364 Table 1: RAQMON Parameters and corresponding RPPF 366 Data Source Name (DN): - The Data Source Name field starts with an 367 8-bit octet count describing the length of the text and the text 368 itself. Note that the text can be no longer than 255 octets. The text 369 is encoded according to the UTF-2 encoding specified in Annex F of 370 ISO standard 10646 [ISO10646],[UNICODE]. This encoding is also known 371 as UTF-8 or UTF-FSS. It is described in "File System Safe UCS 372 Transformation Format (FSS_UTF)", X/Open Preliminary Specification, 373 Document Number P316 and Unicode Technical Report #4. US-ASCII is a 374 subset of this encoding and requires no additional encoding. The 375 presence of multi-octet encoding is indicated by setting the most 376 significant bit of a character to a value of one. Text is not null 377 terminated because some multi-octet encoding include null octets. 378 Data Source Name is terminated by one or more null octets, the first 379 of which is interpreted as to denote the end of the string and the 380 remainder as needed to pad until the next 32-bit boundary. If the 381 network is known to be lossless, Applications should instruct a RDS 382 to send out parameters like this only once to ensure efficient usage 383 of network resources as this parameter is expected to remain constant 384 for the duration of the reporting session. However if RDSs are 385 operating in a lossy environment, this information should be sent out 386 occasionally over random time intervals to maximize success of 387 reaching a RRC. 389 Receiver Name (RN): - The Receiver Name is multiple of 32 bits. 390 Follows the same padding rules as applies to Data Source Name. As 391 Data Source Name and Receiver's Name are contiguous, i.e., items are 392 not individually padded to a 32-bit boundary. If the network is known 393 to be lossless, applications should instruct a RDS to send out 394 parameters like this only once to ensure efficient usage of network 395 resources as this parameter is expected to remain constant for the 396 duration of the reporting session. However if RDSs are operating in a 397 lossy environment, this information should be sent out occasionally 398 over random time intervals to maximize success of reaching a RRC. 400 Data Source Address (DA): 32 bits - The standard ASCII representation 401 of the end device's numeric address on the interface used for the 402 communication session. The standard ASCII representation of an IP 403 Version 4 address is "dotted decimal", also known as dotted quad. 404 Other address types are expected to have ASCII representations that 405 are mutually unique. 135.8.45.178 is an example of a valid Data 406 Source Address. Since the Data Source Address is expected to remain 407 constant for the duration of the session, it is recommended that RDS 408 report such field only once within a communication session to ensure 409 efficient usage of network and system resources. If the network is 410 known to be lossless, Applications should instruct a RDS to send out 411 parameters like this only once to ensure efficient usage of network 412 resources as this parameter is expected to remain constant for the 413 duration of the reporting session. However if RDSs are operating in a 414 lossy environment, this information should be sent out occasionally 415 over random time intervals to maximize success of reaching a RRC. 417 IP addresses, TCP/UDP ports information should be removed (NAT un- 418 friendly). One of the ways to avoid this problem is to use 419 Application Layer Gateways (ALGs) to fill out IP Addresses on RDS's 420 behalf. 422 Receiver Address (RA): 32 bits - Follows exact same syntax as Data 423 Source Address but used to indicate a Receiver's Address. If the 424 network is known to be lossless, applications should instruct a RDS 425 to send out parameters like this only once to ensure efficient usage 426 of network resources as this parameter is expected to remain constant 427 for the duration of the reporting session. However if RDSs are 428 operating in a lossy environment, this information should be sent out 429 occasionally over random time intervals t0 maximize the chances of 430 reaching a RRC. 432 Application Name: - The Application Name field starts with an 8-bit 433 octet count describing the length of the text and the text itself. 434 Application name field has same format as Data Source Name. This is a 435 text string giving the name and possibly version of the application 436 associated to that session, e.g., "XYZ VoIP Agent 1.2". This 437 information may be useful for debugging purposes and is similar to 438 the Mailer or Mail-System-Version SMTP headers. Since the 439 Application Name is expected to remain constant for the duration of 440 the session, it is recommended that RDS report such field only once 441 within a communication session to ensure efficient usage of network 442 and system resources. If the network is known to be lossless, 443 Applications should instruct a RDS to send out parameters like this 444 only once to ensure efficient usage of network resources as this 445 parameter is expected to remain constant for the duration of the 446 reporting session. However if RDSs are operating in a lossy 447 environment, this information should be sent out occasionally over 448 random time intervals to maximize success of reaching a RRC. 450 NTP timestamp: 64 bits - Indicates the wallclock time when the RAQMON 451 packet was sent so that it may be used by the RRC to store Date/Time. 452 A Data Source that has no notion of wallclock or time may set the NTP 453 timestamp to zero. However that will waste 32 bits in the packet. An 454 RDS should set the appropriate RAQMON flag to 0 to avoid such waste. 455 Since NTP time stamp is intended to provide Date/Time of a session, 456 it is recommended that the NTP Timestamp be used only in the first 457 RAQMON packet to use network resources efficiently. However such a 458 recommendation is context sensitive and should be enforced as deemed 459 necessary by each application environment. 461 The full resolution NTP timestamp is a 64-bit unsigned fixed-point 462 number with the integer part in the first 32 bits and the fractional 463 part in the last 32 bits. In some fields where a more compact 464 representation is appropriate, only the middle 32 bits are used; that 465 is, the low 16 bits of the integer part and the high 16 bits of the 466 fractional part. The high 16 bits of the integer part must be 467 determined independently. 469 Session Setup Status: - Session State field starts with an 8-bit 470 octet count describing the length of the text and the text itself. 471 This field is used to describe appropriate communication session 472 states e.g. Call Progressing, Call Established successfully, RSVP 473 reservation failed and various other status codes but encoded as a 474 text strings. If the network is known to be lossless, Applications 475 should instruct a RDS to send out parameters like this only once to 476 ensure efficient usage of network resources as this parameter is 477 expected to remain constant for the duration of the reporting 478 session. However if RDSs are operating in a lossy environment, this 479 information should be sent out occasionally over random time 480 intervals to maximize success of reaching a RRC. 482 Session Duration: 32 bits - Session Duration from session RC_N is an 483 unsigned Integer expressed in the order of seconds. 485 Round Trip End-to-End Delay: 32 bits - Round Trip End-to-End Delay 486 from session RC_N is an unsigned Integer expressed in the order of 487 milliseconds. 489 One Way End-to-End Delay: 32 bits - One way End-to-End Delay from 490 session RC_N is an unsigned Integer expressed in the order of 491 milliseconds. 493 Cumulative Packet Loss: 32 bits - The total number of packets from 494 session RC_N that have been lost while this RAQMON packet was 495 generated. This number is defined to be the number of packets 496 expected less the number of packets actually received. 498 Total number of Packets sent: 32 bits - The total number of packets 499 transmitted within session RC_N by the sender since starting 500 transmission up until the time this RAQMON packet was generated. This 501 counter is reset if the DSRC identifier is changed as it indicates a 502 different session. 504 Total number of Packets received: 32 bits - The total number of 505 packets transmitted within session RC_N by the receiver since 506 starting transmission up until the time this RAQMON packet was 507 generated. This counter is reset if the DSRC identifier is changed as 508 it indicates a different session. 510 Total number of Octets sent: 32 bits - The total number of payload 511 octets (i.e., not including header or padding) transmitted in packets 512 by the sender within session RC_N since starting transmission up 513 until the time this RAQMON PDU was generated. This counter is reset 514 if the DSRC identifier is changed as it indicates a different 515 session. 517 Total number of Octets received: 32 bits - The total number of 518 payload octets (i.e., not including header or padding) transmitted in 519 packets by the receiver within session RC_N since starting 520 transmission up until the time this RAQMON PDU was generated. This 521 counter is reset if the DSRC identifier is changed as it indicates a 522 different session. 524 Source Port Used: 16 bits - Port Number used by the Data Source as 525 used by the application in RC_N session while this RAQMON PDU was 526 generated. If the network is known to be lossless, Applications 527 should instruct a RDS to send out parameters like this only once to 528 ensure efficient usage of network resources as this parameter may 529 remain constant for the duration of the reporting session. However if 530 RDSs are operating in a lossy environment, this information should be 531 sent out occasionally over random time intervals to maximize success 532 of reaching a RRC. 534 Receiver Port Used: 16 bits - Receiver port used by the application 535 to communicate to the receiver. Follows same syntax as as Source Port 536 Used. If the network is known to be lossless, Applications should 537 instruct a RDS to send out parameters like this only once to ensure 538 efficient usage of network resources as this parameter may remain 539 constant for the duration of the reporting session. However if RDSs 540 are operating in a lossy environment, this information should be sent 541 out occasionally over random time intervals to maximize success of 542 reaching a RRC. 544 S_Layer2: 8 bits - Source Layer 2 priorities used to send packets to 545 the receiver by this data source during this communication session. 546 For example priority bits associated to IEEE 802.1p values for 547 appropriate priorities. For example priority bits associated to IEEE 548 802.1p tag value of 5 reported via S_Layer2 parameter would indicate 549 Video over IP from this data source prioritized by some Layer 2 550 switch. If the network is known to be lossless, Applications should 551 instruct a RDS to send out parameters like this only once to ensure 552 efficient usage of network resources as this parameter may remain 553 constant for the duration of the reporting session. However if RDSs 554 are operating in a lossy environment, this information should be sent 555 out occasionally over random time intervals to maximize success of 556 reaching a RRC. 558 S_Layer3: 8 bits - Layer 3 QoS marking used to send packets to the 559 receiver by this data source during this communication session. For 560 example priority bits associated to IP Precedence (i.e. 101XXXXX) or 561 DiffServ PHB values (i.e EF, AF41) etc. reported via S_Layer3 562 parameter would indicate whether applications from this data source 563 is prioritized by some router or not. If the network is known to be 564 lossless, Applications should instruct a RDS to send out parameters 565 like this only once to ensure efficient usage of network resources as 566 this parameter may remain constant for the duration of the reporting 567 session. However if RDSs are operating in a lossy environment, this 568 information should be sent out occasionally over random time 569 intervals to maximize success of reaching a RRC. 571 D_Layer2: 8 bits - Layer 2 priorities used by the receiver to send 572 packets to the data source during this RC_N session if the Data 573 Source can learn such information. If the network is known to be 574 lossless, Applications should instruct a RDS to send out parameters 575 like this only once to ensure efficient usage of network resources as 576 this parameter may remain constant for the duration of the reporting 577 session. However if RDSs are operating in a lossy environment, this 578 information should be sent out occasionally over random time 579 intervals to maximize success of reaching a RRC. 581 D_Layer3: 8 bits - Layer 3 QoS marking used by the receiver to send 582 packets to the data source during this communication session if the 583 Data Source can learn such information. If the network is known to be 584 lossless, Applications should instruct a RDS to send out parameters 585 like this only once to ensure efficient usage of network resources as 586 this parameter may remain constant for the duration of the reporting 587 session. However if RDSs are operating in a lossy environment, this 588 information should be sent out occasionally over random time 589 intervals to maximize success of reaching a RRC. 591 Source Payload Type: 8 bit - This document follows definition of 592 Payload Type (PT) as in [RFC1890]. This 8-bit field specifies the 593 type of audio, video or data media used to send packets to the 594 receiver by this data source during communication session RC_N. To 595 give an example, if an application ought to indicate that the Source 596 Pay Load Type used for a session were PCMA, Source Payload Field for 597 RC_N ought to be 8. Please refer to [RFC1890] for various other 598 Audio, Video and Data related payload types. 600 CPU Utilization: 8 bits - The percentage of CPU used during session 601 RC_N up until the time this RAQMON PDU was generated. CPU Utilization 602 value should indicate not only CPU Utilization associated to a 603 session RC_N but also actual CPU Utilization, to indicate a snapshot 604 of end device Memory Utilization while session RC_N in progress. 606 Memory Utilization: 8 bits - The percentage of total memory used 607 during session RC_N up until the time this RAQMON PDU was generated. 608 Memory Utilization value should indicate not only Memory Utilization 609 associated to a session RC_N but also actual Memory Utilization, to 610 indicate a snapshot of end device Memory Utilization while session 611 RC_N in progress. 613 Session Setup Delay: 16 bits - This parameter is expressed in 614 milliseconds. Indicates the duration of time required by a network 615 communication controller to set a media path between the 616 communicating entities or the end devices. Session Setup Delay is 617 Application context sensitive. For example Session Setup Delay of a 618 SIP call is measured as the elapsed time between an INVITE generated 619 from a User Agent to reception of a 200 OK. If the network is known 620 to be lossless, Applications should instruct a RDS to send out 621 parameters like this only once to ensure efficient usage of network 622 resources as this parameter is expected to remain constant for the 623 duration of the reporting session. However if RDSs are operating in a 624 lossy environment, this information should be sent out occasionally 625 over random time intervals to maximize success of reaching a RRC. 627 Inter-Arrival Jitter: 16 bits - An estimate of the statistical 628 variance of packets inter-arrival time expressed in milliseconds. 630 Packet Loss in Fraction: 8 bits - The fraction of packets from data 631 source lost since the previous RAQMON was dispatched, expressed as a 632 fixed point number with the binary point at the left edge of the 633 field. (That is equivalent to taking the integer part after 634 multiplying the loss fraction by 256.) This fraction is defined to be 635 the number of packets lost divided by the number of packets expected. 637 padding: 0, 8, 16 or 24 bits - As described earlier in this section 638 that if the padding bit (P) is set , the actual padding at the end of 639 the Basic part of the PDU is either 0,8, 16 or 24 bits to make the 640 basic part of the PDU multiple of 32 bits long. 642 2.2 APP part of RAQMON Protocol Data Unit (PDU): 644 The APP part of the RAQMON PDU is intended for experimental use as 645 new applications and new features are developed, without requiring 646 PDU type value registration. 648 Vendors are responsible for designing RDSs with appropriate SMI 649 Enterprise Code and publishing App specific extensions. Any RAQMON 650 compliant RRC must be able to recognize vendors SMI Enterprise Code 651 and Report Type but should be able to operate without recognizing 652 Application specific extensions that trails behind vendors specific 653 SMI Enterprise Code and Report Type. 655 SMI Enterprise Code: 16 bits - Vendors and Application developers 656 should fill in appropriate SMI Enterprise IDs available here 657 http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI 658 Enterprise Code MUST be treated as a vendor or application specific 659 extension. 661 Report Type: 16 bits - Vendors and Application developers should fill 662 in appropriate Report type within a specified SMI Enterprise Code. It 663 is recommended that vendors publish app specific extensions and 664 maintain such report types for better interoperability. 666 application-dependent data: variable length - Application/vendor- 667 dependent data to be defined by the application developers. It is 668 interpreted by the vendor specific application and not by the RRC 669 itself. It must be a multiple of 32 bits long. 671 2.3 Byte Order, Alignment, and Time Format of RAQMON PDUs 673 All integer fields are carried in network byte order, that is, most 674 significant byte (octet) first. This byte order is commonly known as 675 big-endian. The transmission order is described in detail in 676 [RFC791]. Unless otherwise noted, numeric constants are in decimal 677 (base 10). 679 All header data is aligned to its natural length, i.e., 16-bit fields 680 are aligned on even offsets, 32-bit fields are aligned at offsets 681 divisible by four, etc. Octets designated as padding have the value 682 zero. 684 3. Transporting RAQMON Protocol Data Units 686 It is an inherent objective of the RAQMON Framework to re-use 687 existing application level transport protocols to maximize the usage 688 of existing installations as well as to avoid transport protocol 689 level complexities in the design process. A RAQMON PDU does not 690 transport application data but rather occupies the place of a payload 691 specification at the application layer of the protocol stack. As 692 outlined in the RAQMON framework document both Real-Time Transport 693 Control Protocol (RTCP) and the Simple Network Management Protocol 694 (SNMP) can be used as a transport protocol. Section 3.1 specifies 695 RTCP APP Packets [RFC 1889] to carry RAQMON PDUs between RDS and RRC 696 and section 3.2.reflects usage of SNMP INFORM PDUs as transport 697 protocol. It is left upon the vendors to choose either RTCP or SNMP 698 to transport RAQMON PDU as it fit the deployment need. Guidance in 699 the form of Pros and cons of using each protocol has been provided in 700 appropriate sections. 702 3.1 Mapping RAQMON PDUs to RTCP as Transport Protocol 704 The RAQMON PDU transfer is comprised of unidirectional exchange of 705 PDUs between RDSs and an RRC. The protocol data units are mapped to 706 an APP Packet (i.e. PT = 204) in Real-Time Transport Control Protocol 707 (RTCP). As outlined in RFC 1889, an RTCP APP packet allows 708 applications to define new RTCP packets. The RTCP APP packets are 709 intended for use as new applications and new features such as RAQMON 710 are developed, without requiring packet type value registration. 711 RAQMON Framework makes use of such extension to provide backward 712 compatibility to existing deployment. Within the RTCP framework, a 713 RAQMON PDU is represented as an Application Specific Report. 715 To be backward compatible RTCP APP packets used by RAQMON SHOULD be 716 Internet Assigned Numbers Authority (IANA) Registered. 718 Figure 3 below shows how RAQMON framework can use RTCP APP Packets to 719 transport RAQMON PDUs between RDS/RRC pairs. 721 0 1 2 3 722 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 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 |V=2|P| subtype | PT=APP=204 | length | 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 | SSRC/CSRC | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | name (ASCII) = "RAQMON" | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | RAQMON PDU | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Figure 3 - Using RTCP APP Packets to transport RAQMON PDUs 735 version (V), padding (P), length: As described for the SR packet 737 subtype: 5 bits subtype 1 in RAQMON Specific RTCP APP packet SHOULD 738 be used by the BASIC RAQMON PDU and subtype 2 should be preserved for 739 RAQMON APP PDUs. These unique definitions will be IANA registered. 741 packet type (PT): 8 bits Contains the constant 204 to identify this 742 as an RTCP APP packet. 744 name: 4 octets The name chosen by the RMON WG defining the set of APP 745 packets will be unique with respect to other APP packets and will be 746 IANA Registered as "RAQMON" with all uppercase. The name field in 747 RTCP APP Packet is interpreted as a sequence of ASCII characters. 749 application-dependent data: variable length RAQMON PDUs sent by the 750 RDS in the format specified in Figure 3 will be interpreted by the 751 RAQMON Report Collector (RRC) and not RTP/RTCP itself. RAQMON PDUs 752 must be a multiple of 32 bits long. 754 + During a monitored real-time session, the RDS emits a Report PDU 755 toward the RRC per configured transmission rate as provisioned by the 756 RDS. Such transmission is unidirectional in nature and follows 757 congestion safety guidelines outlined in RAQMON Framework 758 Specification. 760 + The RRC collects the RAQMON PDUs and correlate them with its 761 database. 763 Though this is a simple one-way send protocol, the RDSs will not be 764 capable of inferring whether a PDU was received by the RRC as RAQMON 765 PDUs could be transmitted over a lossy network. As outlined in RAQMON 766 Framework, RDS/RRC pairs rely on underlying transport protocol to 767 attain transport reliability. 769 3.1.1 - Pseudo code for RDS & RRC 771 RDS: 773 when (session starts} { 774 report.identifier = session.endpoints, session.starttime; 775 report.timestamp = 0; 776 while (session in progress) { 777 wait interval; 778 report.statistics = update statistics; 779 report.curtimestamp += interval; 780 if encryption required 781 report_data = encrypt(report, encrypt parameters); 782 else 783 report_data = report; 784 raqmon_pdu = header, report_data; 785 send raqmon-pdu; 786 } 787 } RRC: 788 listen on raqmon port 789 when ( raqmon_pdu received ) { 790 decrypt raqmon_pdu.data if needed 792 if report.identifier in database 793 if report.current_time_stamp > last update 794 update session statistics from report.statistics 795 else 796 discard report 797 } 799 3.1.2 Port Assignment 801 As specified in the previous sections the transport of RAQMON PDUs 802 can be performed using various underlying network transport protocols 803 like TCP and UDP. 805 Applications using RAQMON Framework may use any unreserved UDP port. 806 For example, a session management program can allocate the port 807 randomly. A single fixed port cannot be required because multiple 808 applications within a host sharing a RDS implementation may encounter 809 difficulties as there are some operating systems that do not allow 810 multiple processes to use the same UDP port with different multicast 811 addresses. 813 However, port numbers 5XXX have been registered with IANA for use 814 with those applications that choose to use them as the default port 815 for RAQMON PDUs over RTCP. Hosts that run multiple applications may 816 use this port as an indication to have used RAQMON if they are not 817 subject to the constraint of the previous paragraph. RRCs may also 818 use this port as a default to receive RAQMON PDUs carried over RTCP 819 which will reduce configuration needs for RDSs. 821 Applications need not have a default and may require that the port be 822 explicitly specified. The particular port number was chosen to lie in 823 the range above 5000 to accommodate port number allocation practice 824 within the Unix operating system, where privileged processes can only 825 use port numbers below 1024 and port numbers between 1024 and 5000 826 are automatically assigned by the operating systems. 828 3.2 SNMP INFORM PDUs as RDS/RRC Network Transport Protocol 830 The idea is to re-use SNMP INFORM PDU. If SNMP is chosen as a 831 mechanism to transport RAQMON PDU, following specification applies: 833 + RDSs implement the capability of embedding RAQMON parameters in 834 SNMP INFORM Request and thus re-using well known SNMP mechanisms to 835 report RAQMON Statistics. The RAQMON RDS MIB as identified in 3.2.1 836 should be used in order to map the RAQMON PDUs on SNMP Notifications 837 transport. 839 Managed objects are accessed via a virtual information store, termed 840 the Management Information Base or MIB. MIB objects are generally 841 accessed through the Simple Network Management Protocol (SNMP). 842 Objects in the MIB are defined using the mechanisms defined in the 843 Structure of Management Information (SMI). For a detailed overview of 844 the documents that describe the current Internet-Standard Management 845 Framework, please refer to section 7 of RFC 3410 [RFC3410]. 847 + Since RDSs are not computationally rich and to keep the RDS 848 realization lightweight, it is not required that RDSs fully implement 849 an SNMP-based Internet Management framework. Specifically RDSs MAY 850 NOT respond to SNMP requests like GET, SET, etc., as an SNMP 851 compliant responder would. 853 + Since RRCs are computationally rich, RRCs should implement a SNMP 854 manager. RRCS should send an SNMP INFORM Response for each associated 855 SNMP INFORM originated by the RDS. 857 + RDSs may ignore the SNMP INFORM Responses in a network where 858 congestion may not be a critical need. However per RAQMON Framework 859 Specification, if better congestion safety is required, RDSs should 860 serialize PDU transmission rate by using these SNMP INFORM responses 861 from RRC. 863 + Standard UDP port 162 shall be used for SNMP Notifications. 865 3.2.1 Encoding RAQMON PDU by using the RAQMON RDS MIB 867 The RAQMON RDS MIB will be used in order to map the RAQMON PDUs on 868 SNMP Notifications transport. The MIB defines the objects needed for 869 Basic part of RAQMON PDU mapping, as well as the Notification. In 870 order to incorporate any Application specific extensions in APP part 871 of RAQMON PDU, varbinds may be included in the RAQMON notifications 872 described in the MIB. 874 This section specifies a MIB module that is compliant to the SMIv2, 875 which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 876 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 878 RAQMON-RDS-MIB DEFINITIONS ::= BEGIN 880 IMPORTS 881 enterprises, 882 Unsigned32, 883 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE 884 FROM SNMPv2-SMI 885 DateAndTime 886 FROM SNMPv2-TC 887 SnmpAdminString 888 FROM SNMP-FRAMEWORK-MIB 889 raqmon, RaqmonDateAndTime 890 FROM RAQMON-MIB 891 Utf8String 892 FROM SYSAPPL-MIB 893 Dscp 894 FROM DIFFSERV-DSCP-TC 895 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 896 FROM SNMPv2-CONF; 898 raqmonDs MODULE-IDENTITY 899 LAST-UPDATED "200304021150Z" -- April 2, 2003 900 ORGANIZATION "RMON Working Group" 901 CONTACT-INFO 902 " 903 WG EMail: rmonmib@ietf.org 904 Subscribe: rmonmib-request@ietf.org 905 MIB Editor: 906 Eugene Golovinsky 907 Postal: BMC Software, Inc. 908 2101 CityWest Blvd, 909 Houston, TX, 77094 910 USA 911 Tel: +713-918-1816 912 Email: egolovin@bmc.com 913 " 914 DESCRIPTION 915 "This is RAQMON Data Source notification Module. 916 It provides mapping of RAQMON PDU to SNMP Notification. 918 Ds is for data source. 920 Note that all of the object types defined in this 921 module are accessible-for-notify, and would consequently 922 not be available to a browser using simple Get, GetNext, 923 or GetBulk requests. 925 This is a branch of the RAQMON module. 927 " 928 REVISION "200304021150Z" -- April 2, 2003 930 ::= { raqmon 3 } 932 raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDs 0 } 934 raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDs 1 } 936 raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDs 2 } 938 raqmonDsNotificationTable OBJECT-TYPE 939 SYNTAX SEQUENCE OF RaqmonRdsNotificationEntry 940 MAX-ACCESS not-accessible 941 STATUS current 942 DESCRIPTION 943 "This conceptual table provides the SNMP mapping 944 of the RAQMON Basic PDU. 945 Indexed by RAQMON session 946 " 947 ::= { raqmonDsMIBObjects 1 } 949 raqmonDsNotificationEntry OBJECT-TYPE 950 SYNTAX RaqmonRdsNotificationEntry 951 MAX-ACCESS not-accessible 952 STATUS current 953 DESCRIPTION 954 "The entry (row) is not retrievable and is not kept 955 by RDSs. 956 It serves data organization purpose only. 957 " 958 INDEX { raqmonDSRC } 959 ::= { raqmonDsNotificationTable 1 } 961 RaqmonDsNotificationEntry ::= 962 SEQUENCE { 963 raqmonDSRC 964 Unsigned32 965 raqmonAppName 966 Utf8String 967 raqmonDataSourceDevicePort 968 Unsigned32 969 raqmonReceiverDevicePort 970 Unsigned32 971 raqmonSessionSetupDateTime 972 RaqmonDateAndTime 973 raqmonSessionSetupDelay 974 Unsigned32 975 raqmonSessionDuration 976 Unsigned32 977 raqmonSessionSetupStatus 978 Utf8String 979 raqmonRoundTripEndtoEndDelay 980 Unsigned32 981 raqmonOneWayEndtoEndDelay 982 Unsigned32 983 raqmonInterArrivalJitter 984 Unsigned32 985 raqmonTotalPacketsReceived 986 Counter32 987 raqmonTotalPacketsSent 988 Counter32 989 raqmonTotalOctetsReceived 990 Counter32 991 raqmonTotalOctetsSent 992 Counter32 993 raqmonCumulativePacketLoss 994 Counter32 995 raqmonPacketLossFraction 996 Unsigned32 997 raqmonSourcePayloadType 998 Unsigned32 1000 raqmonReceiverPayloadType 1001 Unsigned32 1002 raqmonSourceLayer2Priority 1003 Unsigned32 1004 raqmonDestinationLayer2Priority 1005 Unsigned32 1006 raqmonSourceDscp 1007 Dscp 1008 raqmonDestinationDscp 1009 Dscp 1010 raqmonCpuUtilization 1011 Unsigned32 1012 raqmonMemoryUtilization 1013 Unsigned32 1014 } 1016 raqmonDSRC OBJECT-TYPE 1017 SYNTAX Unsigned32 1018 MAX-ACCESS accessible-for-notify 1019 STATUS current 1020 DESCRIPTION 1021 "Data Source identifier represents a unique session 1022 descriptor that points to a specific communication session 1023 between communicating entities." 1024 ::= { raqmonDsNotificationEntry 1 } 1026 raqmonAppName OBJECT-TYPE 1027 SYNTAX Utf8String 1028 MAX-ACCESS accessible-for-notify 1029 STATUS current 1030 DESCRIPTION 1031 "This is a text string giving the name and possibly version 1032 of the application associated to that session, 1033 e.g., --XYZ VoIP Agent 1.2." 1034 ::= { raqmonDsNotificationEntry 2 } 1036 raqmonDataSourceDevicePort OBJECT-TYPE 1037 SYNTAX Unsigned32 (0..65535) 1038 MAX-ACCESS accessible-for-notify 1039 STATUS current 1040 DESCRIPTION 1041 "The port number from which data for this session was sent." 1042 ::= { raqmonDsNotificationEntry 3 } 1044 raqmonReceiverDevicePort OBJECT-TYPE 1045 SYNTAX Unsigned32 (0..65535) 1046 MAX-ACCESS accessible-for-notify 1047 STATUS current 1048 DESCRIPTION 1049 "The port number where the data for this session was received." 1050 ::= { raqmonDsNotificationEntry 4 } 1052 raqmonSessionSetupDateTime OBJECT-TYPE 1053 SYNTAX RaqmonDateAndTime 1054 MAX-ACCESS accessible-for-notify 1055 STATUS current 1056 DESCRIPTION 1057 "The time when session was initiated." 1058 ::= { raqmonDsNotificationEntry 5 } 1060 raqmonSessionSetupDelay OBJECT-TYPE 1061 SYNTAX Unsigned32 1062 MAX-ACCESS accessible-for-notify 1063 STATUS current 1064 DESCRIPTION 1065 "Session setup time in milliseconds." 1066 ::= { raqmonDsNotificationEntry 6 } 1068 raqmonSessionDuration OBJECT-TYPE 1069 SYNTAX Unsigned32 1070 MAX-ACCESS accessible-for-notify 1071 STATUS current 1072 DESCRIPTION 1073 "Session duration in seconds." 1074 ::= { raqmonDsNotificationEntry 7 } 1076 raqmonSessionSetupStatus OBJECT-TYPE 1077 SYNTAX Utf8String 1078 MAX-ACCESS accessible-for-notify 1079 STATUS current 1080 DESCRIPTION 1081 "Describes appropriate communication session states e.g. 1082 Call Established successfully, RSVP reservation 1083 failed etc." 1084 ::= { raqmonDsNotificationEntry 8 } 1086 raqmonRoundTripEndtoEndDelay OBJECT-TYPE 1087 SYNTAX Unsigned32 1088 MAX-ACCESS accessible-for-notify 1089 STATUS current 1090 DESCRIPTION 1091 "Round trip end to end delay in milliseconds." 1092 ::= { raqmonDsNotificationEntry 9} 1094 raqmonOneWayEndtoEndDelay OBJECT-TYPE 1095 SYNTAX Unsigned32 1096 MAX-ACCESS accessible-for-notify 1097 STATUS current 1098 DESCRIPTION 1099 "One way end to end delay in milliseconds." 1100 ::= { raqmonDsNotificationEntry 10} 1102 raqmonInterArrivalJitter OBJECT-TYPE 1103 SYNTAX Unsigned32 1104 MAX-ACCESS accessible-for-notify 1105 STATUS current 1106 DESCRIPTION 1107 "An estimate of the statistical variance of packets 1108 inter-arrival time expressed in milliseconds." 1109 ::= { raqmonDsNotificationEntry 11} 1111 raqmonTotalPacketsReceived OBJECT-TYPE 1112 SYNTAX Counter32 1113 MAX-ACCESS accessible-for-notify 1114 STATUS current 1115 DESCRIPTION 1116 "The total number of packets 1117 transmitted within a communication session by the receiver 1118 since starting transmission up until the time this RAQMON 1119 packet was generated." 1120 ::= { raqmonDsNotificationEntry 12 } 1122 raqmonTotalPacketsSent OBJECT-TYPE 1123 SYNTAX Counter32 1124 MAX-ACCESS accessible-for-notify 1125 STATUS current 1126 DESCRIPTION 1127 "The total number of packets 1128 transmitted within a communication session by the sender since 1129 starting transmission up until the time this RAQMON packet was 1130 generated." 1131 ::= { raqmonDsNotificationEntry 13 } 1133 raqmonTotalOctetsReceived OBJECT-TYPE 1134 SYNTAX Counter32 1135 MAX-ACCESS accessible-for-notify 1136 STATUS current 1137 DESCRIPTION 1138 "The total number of payload 1139 octets (i.e., not including header or padding) transmitted in 1140 packets by the receiver within a communication session since 1141 starting transmission up until the time this RAQMON packet 1142 was generated." 1143 ::= { raqmonDsNotificationEntry 14 } 1145 raqmonTotalOctetsSent OBJECT-TYPE 1146 SYNTAX Counter32 1147 MAX-ACCESS accessible-for-notify 1148 STATUS current 1149 DESCRIPTION 1150 "The total number of payload octets 1151 i.e., not including header or padding) transmitted in packets 1152 by the sender within a communication session since starting 1153 transmission up until the time this RAQMON packet was generated." 1154 ::= { raqmonDsNotificationEntry 15 } 1156 raqmonCumulativePacketLoss OBJECT-TYPE 1157 SYNTAX Counter32 1158 MAX-ACCESS accessible-for-notify 1159 STATUS current 1160 DESCRIPTION 1161 "The total number of packets from session 1162 that have been lost while this notification was generated. 1163 This number is expected to be less the number of packets 1164 actually received." 1165 ::= { raqmonDsNotificationEntry 16 } 1167 raqmonPacketLossFraction OBJECT-TYPE 1168 SYNTAX Unsigned32 (0..100) 1169 MAX-ACCESS accessible-for-notify 1170 STATUS current 1171 DESCRIPTION 1172 "The percentage of lost packets with respect to the overall packets 1173 sent. This fraction is defined to be the number of packets lost 1174 divided by the number of packets expected." 1175 ::= { raqmonDsNotificationEntry 17 } 1177 raqmonSourcePayloadType OBJECT-TYPE 1178 SYNTAX Unsigned32 (0..127) 1179 MAX-ACCESS accessible-for-notify 1180 STATUS current 1181 DESCRIPTION 1182 "The payload type of the packet sent by this RD." 1183 REFERENCE 1184 "RFC 1890" 1185 ::= { raqmonDsNotificationEntry 18 } 1187 raqmonReceiverPayloadType OBJECT-TYPE 1188 SYNTAX Unsigned32 (0..127) 1189 MAX-ACCESS accessible-for-notify 1190 STATUS current 1191 DESCRIPTION 1192 "The payload type of the packet received by this RD." 1194 REFERENCE 1195 "RFC 1890" 1196 ::= { raqmonDsNotificationEntry 19 } 1198 raqmonSourceLayer2Priority OBJECT-TYPE 1199 SYNTAX Unsigned32 (0..7) 1200 MAX-ACCESS accessible-for-notify 1201 STATUS current 1202 DESCRIPTION 1203 "Source Layer 2 priorities used to send packets to the 1204 receiver by this data source during this communication 1205 session." 1206 ::= { raqmonDsNotificationEntry 20 } 1208 raqmonDestinationLayer2Priority OBJECT-TYPE 1209 SYNTAX Unsigned32 (0..7) 1210 MAX-ACCESS accessible-for-notify 1211 STATUS current 1212 DESCRIPTION 1213 "Destination Layer 2 priority." 1214 ::= { raqmonDsNotificationEntry 21 } 1216 raqmonSourceDscp OBJECT-TYPE 1217 SYNTAX Dscp 1218 MAX-ACCESS accessible-for-notify 1219 STATUS current 1220 DESCRIPTION 1221 "Source DSCP value." 1222 ::= { raqmonDsNotificationEntry 22 } 1224 raqmonDestinationDscp OBJECT-TYPE 1225 SYNTAX Dscp 1226 MAX-ACCESS accessible-for-notify 1227 STATUS current 1228 DESCRIPTION 1229 "Destination DSCP value." 1230 ::= { raqmonDsNotificationEntry 23 } 1232 raqmonCpuUtilization OBJECT-TYPE 1233 SYNTAX Unsigned32 (0..100) 1234 MAX-ACCESS accessible-for-notify 1235 STATUS current 1236 DESCRIPTION 1237 "Percentage of total CPU utilization over a time duration." 1238 ::= { raqmonDsNotificationEntry 24 } 1240 raqmonMemoryUtilization OBJECT-TYPE 1241 SYNTAX Unsigned32 (0..100) 1242 MAX-ACCESS accessible-for-notify 1243 STATUS current 1244 DESCRIPTION 1245 "Percentage of total memory utilization over a time duration." 1246 ::= { raqmonDsNotificationEntry 25 } 1248 -- 1249 -- definitions of the notifications 1250 -- The object list includes only the OBJECTS that will be send by a 1251 -- RD in any notification. 1252 -- Other objects from the raqmonDsNotificationTable may be included 1253 -- in the varbind. 1255 raqmonDsNotification NOTIFICATION-TYPE 1256 OBJECTS { 1257 raqmonDSRC, 1258 raqmonOneWayEndtoEndDelay, 1259 raqmonInterArrivalJitter, 1260 raqmonPacketLossFraction 1261 } 1262 STATUS current 1263 DESCRIPTION 1264 "This notification maps basic RAQMON PDU into SNMP transport." 1265 ::= { raqmonDsEvents 1 } 1267 -- 1268 -- conformance information 1269 -- These don't show up on the wire, so they only need to be unique. 1270 -- 1271 raqmonDsCompliances OBJECT IDENTIFIER ::= { raqmonDsConformance 1 } 1272 raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } 1274 raqmonDsBasicCompliances MODULE-COMPLIANCE 1275 STATUS current 1276 DESCRIPTION 1277 "The compliance statement for SNMP entities which 1278 implement this MIB module." 1279 MODULE -- this module 1280 MANDATORY-GROUPS { raqmonDsNotificationGroup, 1281 raqmonDsPayloadGroup } 1282 ::= { raqmonDsCompliances 1 } 1284 raqmonDsNotificationGroup NOTIFICATION-GROUP 1285 NOTIFICATIONS { raqmonDsNotification } 1286 STATUS current 1287 DESCRIPTION 1288 "The notifications implemented by an SNMP entity 1289 claiming conformance to this MIB. 1291 " 1292 ::= { raqmonDsGroups 1 } 1294 raqmonDsPayloadGroup OBJECT-GROUP 1295 OBJECTS { 1296 raqmonDSRC, 1297 raqmonAppName, 1298 raqmonDataSourceDevicePort, 1299 raqmonReceiverDevicePort, 1300 raqmonSessionSetupDateTime, 1301 raqmonSessionSetupDelay, 1302 raqmonSessionDuration, 1303 raqmonSessionSetupStatus, 1304 raqmonRoundTripEndtoEndDelay, 1305 raqmonOneWayEndtoEndDelay, 1306 raqmonInterArrivalJitter, 1307 raqmonTotalPacketsReceived, 1308 raqmonTotalPacketsSent, 1309 raqmonTotalOctetsReceived, 1310 raqmonTotalOctetsSent, 1311 raqmonCumulativePacketLoss, 1312 raqmonPacketLossFraction, 1313 raqmonSourcePayloadType, 1314 raqmonReceiverPayloadType, 1315 raqmonSourceLayer2Priority, 1316 raqmonDestinationLayer2Priority, 1317 raqmonSourceDscp, 1318 raqmonDestinationDscp, 1319 raqmonCpuUtilization, 1320 raqmonMemoryUtilization 1321 } 1322 STATUS current 1323 DESCRIPTION 1324 "These objects are required for entities 1325 claiming conformance to this MIB. 1326 " 1327 ::= { raqmonDsGroups 2 } 1329 END 1331 3.2.2 Pros and Cons of using SNMP Inform as RAQMON PDU Transport 1333 Using SNMP INFORM PDUs for RAQMON has all the advantages offered by a 1334 well known protocol like SNMP. Privacy and authentication issues 1335 related to RAQMON are "mostly" covered by SNMPv3. Usage of SNMP to 1336 carry RAQMON PDU, further reduces the need for specific RAQMON code 1337 in the RRC, as it can use an SNMP manager implementation to process 1338 Informs. However there are certain challenges in using SNMP for 1339 RAQMON as well. 1341 i. One of the drawbacks of using SNMP is the associated overhead SNMP 1342 puts on low-powered RDSs, for instance - BER encoding, SNMP INFORM 1343 Responses sent from RRC to RDS etc. As a result added flexibility of 1344 the proposed RAQMON Framework could be constrained in real life 1345 deployment scenario depending on the use case. 1347 ii. SNMP uses UDP only transport. Hence the only way to achieve 1348 congestion safety is by serializing PDUs based on INFORM Responses in 1349 RRC, resulting in reduced throughput inefficiency as transport layer 1350 functionality provided by TCP or SCTP can never be used. 1352 iii. Sending out Acknowledgements from RRCs to RDSs can create 1353 bottleneck as additional RDS load is created, specially when the RRCs 1354 will be receving many Inform PDUs from many RRcs. 1356 iv. While a good mechanism to serialize RAQMON PDU Transmission, ACKs 1357 for SNMP I NFORM from RRC also wastes network bandwidth and cause 1358 throughput inefficiency. In a reasonable sized Enterprise and Service 1359 provider systems this can be a significant amount of load. 1361 As an alternate, SNMP Traps could be used to avoid such ACKs. This 1362 will allow usage of SNMP without avoiding performance related issues 1363 as mentioned above, but with the added disadvantage of reduced 1364 congestion safety functionality. 1366 4.0 Congestion Safe RAQMON Operation: 1368 RAQMON PDU can be transmitted over multiple transport protocols. A 1369 RAQMON PDU from RDS to RRC either over RTCP or SNMP allows the use of 1370 UDP for transport which might lead to network congestion under heavy 1371 network load. To ensure congestion safety clearly the best thing to 1372 do is to use a transport protocol like TCP or SCTP, etc. If this is 1373 not feasible, it may be necessary to fall back to UDP. Implementers 1374 should follow section 3.0 of [RAQMON-Framework] guidelines that 1375 outlines measures that can be taken to use RAQMON in congestion safe 1376 manner. 1378 5. Normative References 1380 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1381 Rose, M. and S. Waldbusser, "Structure of Management 1382 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1383 1999. 1385 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1386 Rose, M. and S. Waldbusser, "Textual Conventions for 1387 SMIv2", STD 58, RFC 2579, April 1999. 1389 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1390 Rose, M. and S. Waldbusser, "Conformance Statements for 1391 SMIv2", STD 58, RFC 2580, April 1999. 1393 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 1394 Information Base", STD 59, RFC 2819, May 2000 1396 [RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 1397 "RTP: A Transport Protocol for Real-Time Applications" 1398 RFC 1889, January 1996. 1400 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1401 1981. 1403 [RAQMON-Framework] A. Siddiqui, D.Romascanu, and E. Golovinsky, 1404 "Framework for Real-time Application Quality of Service 1405 Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon- 1406 framework-02.txt, May 2003 1408 6. Informative References 1410 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1411 "Introduction and Applicability Statements for Internet- 1412 Standard Management Framework", RFC 3410, December 2002 1414 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1415 Requirement Levels", BCP 14, RFC 2119, March 1997. 1417 [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video 1418 Conferences with Minimal Control" RFC 1890, January 1996. 1420 [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, 1421 March 1992. 1423 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 1424 STD 13, RFC 1034, November 1987. 1426 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 1427 Specification", STD 13, RFC 1035, November 1987. 1429 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1430 and Support", STD 3, RFC 1123, October 1989. 1432 [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, 1433 "Address Allocation for Private Internets", RFC 1597, March 1434 1994. 1436 [RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay 1437 Metric for IPPM", RFC 2679, September 1999 1439 [RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet 1440 Loss Metric for IPPM", RFC 2680, September 1999 1442 [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay 1443 Metric for IPPM", RFC 2681, September 1999 1445 [ISO10646] International Standards Organization, "ISO/IEC DIS 1446 10646-1:1993information technology -- universal 1447 multiple-octet coded character set (UCS) -- part I: 1448 Architecture and basic multilingual plane," 1993. 1450 [UNICODE] The Unicode Consortium, The Unicode Standard New York, 1451 New York:Addison-Wesley, 1991. 1453 [IEEE802.1D] Information technology-Telecommunications and information 1454 exchange between systems--Local and metropolitan area 1455 networks-Common Specification a--Media access control (MAC) 1456 bridges:15802-3: 1998 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1457 1998 Edition] 1459 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite", 1460 RFC 1349, July 1992 1462 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812, 1463 June 1995 1465 [RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition of 1466 the Differentiated Services Field (DS Field) in the IPv4 and 1467 IPv6 Headers", RFC2474, December 1998 1469 [RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss, 1470 "An Architecture for Differentiated Services" RFC2475, 1471 December 1998 1473 7. Intellectual Property 1475 The IETF takes no position regarding the validity or scope of any 1476 intellectual property or other rights that might be claimed to 1477 pertain to the implementation or use of the technology described in 1478 this document or the extent to which any license under such rights 1479 might or might not be available; neither does it represent that it 1480 has made any effort to identify any such rights. Information on the 1481 IETF's procedures with respect to rights in standards-track and 1482 standards-related documentation can be found in BCP-11. Copies of 1483 claims of rights made available for publication and any assurances of 1484 licenses to be made available, or the result of an attempt made to 1485 obtain a general license or permission for the use of such 1486 proprietary rights by implementors or users of this specification can 1487 be obtained from the IETF Secretariat. 1489 The IETF invites any interested party to bring to its attention any 1490 copyrights, patents or patent applications, or other proprietary 1491 rights which may cover technology that may be required to practice 1492 this standard. Please address the information to the IETF Executive 1493 Director. 1495 8. Security Considerations 1497 [RAQMON-Framework] memo outlined a threat model associated to RAQMON 1498 and some security considerations taken into account within RAQMON 1499 specification to alleviate those threats. It is imperative that the 1500 RAQMON PDU implementations be able to provide the following 1501 protection mechanisms to attain end-to-end security: 1503 1. Authentication - the RRC should be able to verify that a RAQMON 1504 report was originated by the RDS whom ever claims to have sent it. At 1505 minimal, a RDS/RRC pairs could use a digest based authentication 1506 procedure to authenticate. 1508 2. Privacy - RAQMON information include identification of the parties 1509 participating in a communication session. RAQMON framework should be 1510 able to provide protection from eavesdropping, to prevent an 1511 unauthorized third party from gathering potentially sensitive 1512 information. This can be achieved by using various payload encryption 1513 technologies like DES, 3-DES, AES 1515 3. Protection from Denial of Service attacks directed at the RRC - 1516 RDSs send RAQMON reports as a side effect of an external event (for 1517 example, a phone call is being received). An attacker can try and 1518 overwhelm the RRC (or the network) by initiating a large number of 1519 events (i.e., calls) for the purpose of swamping the RRC with too 1520 many RAQMON PDUs. 1522 To prevent DoS attacks against RRC, the RDS will send the first 1523 report for a session only after the session has been in progress for 1524 the TBD reporting interval. 1526 4. NAT and Firewall Friendly Design: Presence for IP addresses, 1527 TCP/UDP ports information in RAQMON PDUs may be NAT un-friendly. In 1528 such a scenario, where NAT Friendliness is a requirement, the RDS may 1529 opt to not to provide IP Addresses in RAQMON PDU. Another way to 1530 avoid this problem is by using NAT Aware Application Layer Gateways 1531 (ALGs)to fill out IP Addresses in RAQMON PDUs. 1533 This memo also defines a RDS SNMP MIB with the purpose of mapping the 1534 RAQMON PDUs into SNMP Notifications. To attain end to end security 1535 following measures has bee taken in RDS MIB implementation: 1537 There are no management objects defined in this MIB module that have 1538 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1539 MIB module is implemented correctly, then there is no risk that an 1540 intruder can alter or create any management objects of this MIB 1541 module via direct SNMP SET operations. 1543 Some of the readable objects in this MIB module (i.e., objects with a 1544 MAX-ACCESS other than not-accessible) may be considered sensitive or 1545 vulnerable in some network environments. It is thus important to 1546 control even GET and/or NOTIFY access to these objects and possibly 1547 to even encrypt the values of these objects when sending them over 1548 the network via SNMP. These are the tables and objects and their 1549 sensitivity/vulnerability: 1551 raqmonDsNotificationTable 1553 The objects in this table contain user sessions information, and 1554 their disclosure may be sensitive in some environments. 1556 SNMP versions prior to SNMPv3 did not include adequate security. Even 1557 if the network itself is secure (for example by using IPSec), even 1558 then, there is no control as to who on the secure network is allowed 1559 to access and GET/SET (read/change/create/delete) the objects in this 1560 MIB module. 1562 It is RECOMMENDED that implementers consider the security features as 1563 provided by the SNMPv3 framework (see [RFC3410], section 8), 1564 including full support for the SNMPv3 cryptographic mechanisms (for 1565 authentication and privacy). 1567 Though not mandatory for RAQMON compliance, it is RECOMMENDED to 1568 deploy SNMPv3 and to enable cryptographic security for RAQMON PDUs. 1569 It is a customer/operator responsibility to ensure that the SNMP 1570 entity giving access to an instance of this MIB module is properly 1571 configured to give access to the objects only to those principals 1572 (users) that have legitimate rights to indeed GET or SET 1573 (change/create/delete) them. 1575 9. IANA Considerations 1576 This memo introduces one new port for IANA registration and a "name" 1577 for specific RTCP APP name == "RAQMON", as specified in Section 1578 5.2.2, at http://www.iana.org/numbers.html 1580 10. Authors' Addresses 1581 Anwar A. Siddiqui 1582 Avaya Labs 1583 307 Middletown Lincroft Road 1584 Lincroft, New Jersey 07738 1585 USA 1586 Tel: +1 732 852-3200 1587 E-mail: anwars@avaya.com 1589 Dan Romascanu 1590 Avaya Inc. 1591 Atidim Technology Park, Bldg. #3 1592 Tel Aviv, 61131 1593 Israel 1594 Tel: +972-3-645-8414 1595 Email: dromasca@avaya.com 1597 Eugene Golovinsky 1598 BMC Software 1599 2101 CityWest Blvd. 1600 Houston, Texas 77042 1601 USA 1602 Tel: +1 713 918-1816 1603 Email: eugene_golovinsky@bmc.com 1605 A. Full Copyright Statement 1607 This document and translations of it may be copied and furnished to 1608 others, and derivative works that comment on or otherwise explain it 1609 or assist in its implementation may be prepared, copied, published 1610 and distributed, in whole or in part, without restriction of any 1611 kind, provided that the above copyright notice and this paragraph are 1612 included on all such copies and derivative works. However, this 1613 document itself may not be modified in any way, such as by removing 1614 the copyright notice or references to the Internet Society or other 1615 Internet organizations, except as needed for the purpose of 1616 developing Internet standards in which case the procedures for 1617 copyrights defined in the Internet Standards process must be 1618 followed, or as required to translate it into languages other than 1619 English. 1621 The limited permissions granted above are perpetual and will not be 1622 revoked by the Internet Society or its successors or assigns. 1624 This document and the information contained herein is provided on an 1625 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1626 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1627 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1628 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1629 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.