idnits 2.17.1 draft-ietf-rmonmib-raqmon-pdu-14.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 24. -- Found old boilerplate from RFC 3978, Section 5.5 on line 2294. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 2271. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 2278. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 2284. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 27 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RAQMON-FRAMEWORK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 25, 2006) is 6486 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) == Unused Reference: 'IEEE802.1D' is defined on line 2130, but no explicit reference was found in the text -- No information found for draft-ietf-raqmon-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RAQMON-FRAMEWORK' ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2246 (ref. 'TLS') (Obsoleted by RFC 4346) -- Obsolete informational reference (is this intentional?): RFC 2830 (ref. 'LDAP-TLS') (Obsoleted by RFC 4510, RFC 4511, RFC 4513) -- Obsolete informational reference (is this intentional?): RFC 1305 (Obsoleted by RFC 5905) Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group A. Siddiqui 3 Internet-Draft Avaya Labs 4 Expires: January 26, 2007 D. Romascanu 5 Avaya Inc. 6 E. Golovinsky 7 BMC Software 8 M. Rahman 9 Samsung Information Systems 10 America 11 Y. Kim 12 Broadcom 13 July 25, 2006 15 Transport Mappings for Real-time Application Quality of Service 16 Monitoring (RAQMON) Protocol Data Unit (PDU) 17 draft-ietf-rmonmib-raqmon-pdu-14 19 Status of this Memo 21 By submitting this Internet-Draft, each author represents that any 22 applicable patent or other IPR claims of which he or she is aware 23 have been or will be disclosed, and any of which he or she becomes 24 aware will be disclosed, in accordance with Section 6 of BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on January 26, 2007. 44 Copyright Notice 46 Copyright (C) The Internet Society (2006). 48 Abstract 49 This memo specifies two transport mappings of the Real-time 50 Application Quality of Service Monitoring (RAQMON) information model 51 defined in [RAQMON-FRAMEWORK] using TCP as a native transport and the 52 Simple Network Management Protocol (SNMP) to carry the RAQMON 53 information from a RAQMON Data Source (RDS) to a RAQMON Report 54 Collector (RRC). 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 2. Transporting RAQMON Protocol Data Units . . . . . . . . . . . 4 60 2.1. TCP as an RDS/RRC Network Transport Protocol . . . . . . . 4 61 2.1.1. The RAQMON PDU . . . . . . . . . . . . . . . . . . . . 5 62 2.1.2. The basic part of the RAQMON Protocol Data Unit . . . 7 63 2.1.3. APP part of the RAQMON Protocol Data Unit . . . . . . 15 64 2.1.4. Byte Order, Alignment and Time Format of RAQMON 65 PDUs . . . . . . . . . . . . . . . . . . . . . . . . . 16 66 2.2. Securing RAQMON session . . . . . . . . . . . . . . . . . 16 67 2.2.1. Sequencing of the Start TLS Operation . . . . . . . . 19 68 2.2.2. Closing a TLS Connection . . . . . . . . . . . . . . . 22 69 2.3. SNMP Notifications as an RDS/RRC Network Transport 70 Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 22 71 2.3.1. Encoding RAQMON using the RAQMON RDS MIB module . . . 24 72 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 41 73 4. Congestion-safe RAQMON Operation . . . . . . . . . . . . . . . 42 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 43 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 44 76 6.1. Usage of TLS with RAQMON . . . . . . . . . . . . . . . . . 45 77 6.1.1. Confidentiality & Message Integrity . . . . . . . . . 45 78 6.1.2. TLS CipherSuites . . . . . . . . . . . . . . . . . . . 46 79 6.1.3. RAQMON Authorization State . . . . . . . . . . . . . . 47 80 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 48 81 7.1. Normative References . . . . . . . . . . . . . . . . . . . 48 82 7.2. Informative References . . . . . . . . . . . . . . . . . . 49 83 Appendix A. Pseudo-code . . . . . . . . . . . . . . . . . . . . . 51 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 52 85 Intellectual Property and Copyright Statements . . . . . . . . . . 54 87 1. Introduction 89 The Real-Time Application QoS Monitoring (RAQMON) Framework as 90 outlined by [RAQMON-FRAMEWORK] extends the Remote Monitoring family 91 of protocols (RMON) by defining entities such as RAQMON Data Sources 92 RDS) and RAQMON Report Collectors (RRC) to perform various 93 application monitoring in real time. [RAQMON-FRAMEWORK] defines the 94 relevant metrics for RAQMON monitoring carried by the common protocol 95 data unit (PDU) used between a RDS and RRC to report QoS statistics. 96 This memo contains a syntactical description of the RAQMON PDU 97 structure. 99 The following sections of this memo contain detailed specifications 100 for the usage of TCP and SNMP to carry RAQMON information. 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in [RFC2119]. 106 2. Transporting RAQMON Protocol Data Units 108 The RAQMON Protocol Data Unit (PDU) utilizes a common data format 109 understood by the RDS and the RRC. A RAQMON PDU does not transport 110 application data but rather occupies the place of a payload 111 specification at the application layer of the protocol stack. As 112 part of the specification, this memo also specifies the usage of TCP 113 and SNMP as underlying transport protocols to carry RAQMON PDUs 114 between RDSs and RRCs. While two transport protocol choices have 115 been provided as options to chose from for RDS implementers, RRCs 116 MUST implement the TCP transport and MAY implement the SNMP 117 transport. 119 2.1. TCP as an RDS/RRC Network Transport Protocol 121 A transport binding using TCP is included within the RAQMON 122 specification to facilitate reporting from various types of embedded 123 devices that run applications such as Voice over IP, Voice over Wi- 124 Fi, Fax over IP, Video over IP, Instant Messaging (IM), E-mail, 125 software download applications, e-business style transactions, web 126 access from wired or wireless computing devices etc. For many of 127 these devices PDUs and a TCP-based transport fit the deployment 128 needs. 130 The RAQMON transport requirements for end-to-end congestion control 131 and reliability are inherently built into TCP as a transport protocol 132 [RFC793]. 134 To use TCP to transport RAQMON PDUs, it is sufficient to send the 135 PDUs as TCP data. As each PDU carries its length, the receiver can 136 determine the PDU boundaries. 138 The following section details the RAQMON PDU specifications. Though 139 transmitted as one Protocol Data Unit, a RAQMON PDU is functionally 140 divided into two different parts, namely the basic part and 141 application extensions required for vendor specific extension 142 [RAQMON-FRAMEWORK]. Both functional parts follow a field carrying a 143 SMI Network Management Private Enterprise code currently maintained 144 by IANA http://www.iana.org/assignments/enterprise-numbers, which is 145 used to identify the organization that defined the information 146 carried in the PDU. 148 A RAQMON PDU in the current version is marked as PDU Type (PDT) = 1. 149 The parameters carried by RAQMON PDUs are shown in Figure 1 and are 150 defined in section 5 of [RAQMON-FRAMEWORK]. 152 Vendors MUST use the Basic part of the PDU to report parameters pre- 153 listed here in the specification for interoperability as opposed to 154 using the application specific portion. Vendors MAY also use 155 application specific extensios to convey application, vendor, or 156 device specific parameters not included in the Basic part of the 157 specification, and explicitly publish such data externally to attain 158 extended interoperability. 160 2.1.1. The RAQMON PDU 162 0 1 2 3 163 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 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 |PDT = 1 |B| T |P|S|R| RC | Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | DSRC | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | SMI Enterprise Code = 0 |Report Type = 0| RC_N | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |flag 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | Data Source Address {DA} | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | Receiver's Address (RA) | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | NTP Timestamp, most significant word | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | NTP Timestamp, least significant word | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Length | Application Name (AN) ... | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | ... | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Length | Data Source Name (DN) ... | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | ... | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Length | Receiver's Name (RN) ... | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | ... | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Length | Session State ... | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | ... | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | Session Duration | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Round Trip End-to-End Network Delay | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | One Way End-to-End Network Delay | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Cumulative Packet Loss | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Cumulative Application Packet Discard | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Total # Application Packets sent | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Total # Application Packets received | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | Total # Application Octets sent | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 | Total # Application Octets received | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Data Source Device Port Used | Receiver Device Port Used | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 |Source Payload |Receiver | CPU | Memory | 220 |Type |Payload Type | Utilization | Utilization | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Session Setup Delay | Application Delay | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | IP Packet Delay Variation | Inter arrival Jitter | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Packet Discrd | Packet loss | Padding | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | SMI Enterprise Code = "xxx" | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | Report Type = "yyy" | Length of Application Part | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | application/vendor specific extension | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | ............... | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | ............... | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | ............... | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 240 | SMI Enterprise Code = "abc" | 241 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 242 | Report Type = "zzz" | Length of Application Part | 243 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 244 | application/vendor specific extension | 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | ............... | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 RAQMON Protocol Data Unit 250 Figure 1 252 2.1.2. The basic part of the RAQMON Protocol Data Unit 254 A RAQMON PDU must contain the following basic part fields at all 255 times: 257 PDU type (PDT): 5 bits - This indicates the type of RAQMON PDU being 258 sent. PDT = 1 is used for the current RAQMON PDU version defined 259 in this document. 261 basic (B): 1 bit - While set to 1, the basic flag indicates that the 262 PDU has basic part of the RAQMON PDU. A value of zero is 263 considered to be valid and indicates a RAQMON NULL PDU. 265 trailer (T) : 3 bits - Total number of Application Specific 266 Extensions that follow the BASIC Part of RAQMON PDU. A value of 267 zero is considered to be valid as many times there is no 268 application specific information to add to the basic information. 270 padding (P): 1 bit - If the padding bit is set, the basic Part of the 271 RAQMON PDU contains some additional padding octets at the end of 272 the Basic Part of the PDU which are not part of the monitoring 273 information. Padding may be needed in some cases as reporting is 274 based on the intent of a RDS to report certain parameters. Also 275 some parameters may be reported only once at the beginning of the 276 reporting session e.g. Data Source Name, Receiver Name, Pay Load 277 type etc. Actual padding at the end of the Basic part of the PDU, 278 is either 0,8, 16 or 24 bits to make the basic part of the PDU 279 multiple of 32 bits long. 281 Source IP version Flag (S): 1 bit - While set to 1, the source IP 282 version flag indicates that the Source IP address contained in the 283 PDU is a IPv6 address. 285 Receiver IP version Flag (R): 1 bit - While set to 1, the receiver IP 286 version flag indicates that the receiver IP address contained in 287 the PDU is a IPv6 address. 289 record count (RC): 4 bits - Total number of application records 290 contained in the Basic part of the PDU. A value of zero is 291 considered to be valid but Useless, with the exception of the case 292 of a NULL PDU indicating the end of a RDS reporting session. 294 length: 16 bits (unsigned integer) - The length of the Basic Part of 295 the RAQMON PDU in units of 32-bit words minus one, count which 296 includes the header and any padding. 298 DSRC: 32 bits - Data Source identifier represents a unique RAQMON 299 reporting session descriptor that points to a specific reporting 300 session between RDS and RRC. Uniqueness of DSRC is valid only 301 within a reporting session. DSRC values should be randomly 302 generated using vendor chosen algorithms for each communication 303 session. It is not sufficient to obtain a DSRC simply by calling 304 random() without carefully initializing the state. One could use 305 an algorithm like the one defined in Appendix A.6 in [RFC3550] to 306 create a DSRC. Depending on the choice of algorithm, there is a 307 finite probability that two DSRCS from two different RDSs may be 308 the same. To further reduce the probability that two RDSs pick 309 the same DSRC for two different reporting session, it is 310 recommended that an RRC use parameters like Data Source Address 311 (DA), Data Source Name (DN), layer 2 Media Access Control (MAC) 312 Address in the PDU in conjunction with a DSRC value. It is not 313 mandatory for RDSs to send parameters like Data Source Address 314 (DA), Data Source Name (DN), MAC Address in every PDU sent to RRC, 315 but sending these parameters occasionally will reduce the 316 probability of DSRC collision drastically. However this will 317 cause an additional overhead per PDU. 319 A value of zero for basic (B) bit and trailer (T) bits set 320 constitutes a RAQMON NULL PDU (i.e. nothing to report). RDSs MUST 321 send a RAQMON NULL PDU to RRC to indicate end of RDS reporting 322 session. A NULL PDU ends with the DSRC field. 324 SMI Enterprise Code: 16 bits. A value of SMI Enterprise Code = 0 is 325 used to indicate RMON WG compliant Basic part of the RAQMON PDU 326 format. 328 Report Type: 8 bits - These bits are reserved by the IETF RMON Work 329 Group. A value of 0 within SMI Enterprise Code = 0 is used for 330 the version of the PDU defined by this document. 332 The basic part of each RAQMON PDU consists of Record Count Number 333 (RC_N) and RAQMON Parameter Presence Flags (RPPF) to indicate the 334 presence of appropriate RAQMON parameters within a record, as 335 defined in Table 1. 337 RC_N: 8 bits - The Record Count number indicates a sub-session within 338 a communication session. A value of zero is a valid record 339 number. The maximum number of records that can be described in 340 one RAQMON Packet is 256. 342 RAQMON Parameter Presence Flags (RPPF): 32 bits 343 Each of these flags while set represent that this RAQMON PDU 344 contains corresponding parameters as specified in Table 1. 346 +---------------+---------------------------------------------------+ 347 | Bit Sequence | Presence/Absence of corresponding Parameter | 348 | Number | within this RAQMON PDU | 349 +---------------+---------------------------------------------------+ 350 | 0 | Data Source Address (DA) | 351 | | | 352 | 1 | Receiver Address (RA) | 353 | | | 354 | 2 | NTP Timestamp | 355 | | | 356 | 3 | Application Name | 357 | | | 358 | 4 | Data Source Name (DN) | 359 | | | 360 | 5 | Receiver Name (RN) | 361 | | | 362 | 6 | Session Setup Status | 363 | | | 364 | 7 | Session Duration | 365 | | | 366 | 8 | ound Trip End-to-End Net Delay (RTT) | 367 | | | 368 | 9 | One Way End-to-End Network Delay (OWD) | 369 | | | 370 | 10 | Cumulative Packets Loss | 371 | | | 372 | 11 | Cumulative Packets Discards | 373 | | | 374 | 12 | Total number of App Packets sent | 375 | | | 376 | 13 | Total number of App Packets received | 377 | | | 378 | 14 | Total number of App Octets sent | 379 | | | 380 | 15 | Total number of App Octets received | 381 | | | 382 | 16 | Data Source Device Port Used | 383 | | | 384 | 17 | Receiver Device Port Used | 385 | | | 386 | 18 | Source Layer 2 Priority | 387 | | | 388 | 19 | Source Layer 3 Priority | 389 | | | 390 | 20 | Destination Layer 2 Priority | 391 | 21 | Destination Layer 3 Priority | 392 | | | 393 | 22 | Source Payload Type | 394 | | | 395 | 23 | Receiver Payload Type | 396 | | | 397 | 24 | CPU Utilization | 398 | | | 399 | 25 | Memory Utilization | 400 | | | 401 | 26 | Session Setup Delay | 402 | | | 403 | 27 | Application Delay | 404 | | | 405 | 28 | IP Packet Delay Variation | 406 | | | 407 | 29 | Inter arrival Jitter | 408 | | | 409 | 30 | Packet Discard (in fraction) | 410 | | | 411 | 31 | Packet Loss (in fraction) | 412 +---------------+---------------------------------------------------+ 414 RAQMON Parameters and corresponding RPPF 416 Table 1 418 Data Source Address (DA): 32 bits or 160 bits in binary 419 representation - This parameter is defined in section 5.1 of 420 [RAQMON-FRAMEWORK]. IP version 6 addresses are incorporated in 421 Data Source Address by setting the source IP version flag (S bit) 422 of the RAQMON PDU header to 1. 424 Receiver Address (RA): 32 bits or 160 bits - This parameter is 425 defined in section 5.2 of [RAQMON-FRAMEWORK]. Follows exact same 426 syntax as Data Source Address but used to indicate a Receiver 427 Address. IP version 6 addresses are incorporated in Receiver 428 Address by setting the receiver IP version flag (R bit) of the 429 RAQMON PDU header to 1. 431 Session Setup Date/Time (NTP timestamp): 64 bits - This parameter is 432 defined in section 5.7 of [RAQMON-FRAMEWORK] represented using the 433 timestamp format of the Network Time Protocol (NTP), which is in 434 seconds [RFC1305]. The full resolution NTP timestamp is a 64-bit 435 unsigned fixed-point number with the integer part in the first 32 436 bits and the fractional part in the last 32 bits. 438 Application Name: - This parameter is defined in section 5.32 of 439 [RAQMON-FRAMEWORK]. The Application Name field starts with an 440 8-bit octet count describing the length of the text followed the 441 text itself using UTF-8 encoding. Application Name field is 442 multiple of 32 bits, and padding will be used if necessary. 444 A Data Source that does not support NTP SHOULD set the appropriate 445 RAQMON flag to 0 to avoid wasting 64 bits in the PDU. Since the 446 NTP time stamp is intended to provide the setup Date/Time of a 447 session, it is RECOMMENDED that the NTP Timestamp be used only in 448 the first RAQMON PDU after sub-session RC_N setup is completed, in 449 order to use network resources efficiently. 451 Data Source Name (DN): - defined in section 5.3 of [RAQMON- 452 FRAMEWORK]. The Data Source Name field starts with an 8-bit octet 453 count describing the length of the text followed by the text 454 itself. Padding is being used to ensure that the length and text 455 encoding occupy a multiple of 32 bit in the DN field of the PDU. 456 The text MUST NOT be longer than 255 octets. The text is encoded 457 according to the UTF-8 encoding specified in [RFC3629]. 458 Applications SHOULD instruct RDSs to send out the Data Source Name 459 infrequently to ensure efficient usage of network resources as 460 this parameter is expected to remain constant for the duration of 461 the reporting session. 463 Receiver Name (RN): - This metric is defined in section 5.4 of 464 [RAQMON-FRAMEWORK]. Like Data Source Name, the Receiver Name 465 field starts with an 8-bit octet count describing the length of 466 the text followed by the text itself. The Receiver Name including 467 the length field encoding is a multiple of 32 bits and follows the 468 same padding rules as applied to the Data Source Name. Since the 469 Receiver Name is expected to remain constant during entire 470 reporting sessions, this information SHOULD be sent out 471 occasionally over random time intervals to maximize success of 472 reaching a RRC and also conserve network bandwidth. 474 Session Setup Status: - The Session (sub-session) Setup Status is 475 defined in section 5.10 of [RAQMON-FRAMEWORK]. This field starts 476 with an 8-bit length field followed by the text itself. Session 477 Setup Status is a multiple of 32 bits. 479 Session Duration: 32 bits - The Session (sub-session) Duration metric 480 is defined in section 5.9 of [RAQMON-FRAMEWORK]. Session Duration 481 is an unsigned integer expressed in seconds. 483 Round Trip End-to-End Network Delay: 32 bits - The Round Trip End-to- 484 End Network Delay is defined in section 5.11 of [RAQMON- 485 FRAMEWORK]. This field represents the Round Trip End-to-End Delay 486 of sub-session RC_N, which is an unsigned integer, expressed in 487 milliseconds. 489 One Way End-to-End Network Delay: 32 bits - The One Way End-to-End 490 Network Delay is defined in section 5.12 of [RAQMON-FRAMEWORK]. 491 This field represents the One Way End-to-End Delay of sub-session 492 RC_N, which is an unsigned integer, expressed in milliseconds. 494 Cumulative Application Packet Loss: 32 bits - This parameter is 495 defined in section 5.20 of [RAQMON-FRAMEWORK] as an unsigned 496 integer, representing the total number of packets from sub-session 497 RC_N that have been lost while this RAQMON PDU was generated. 499 Cumulative Application Packet Discards: 32 bits - This parameter is 500 defined in section 5.22 of [RAQMON-FRAMEWORK] as an unsigned 501 integer representing the total number of packets from sub-session 502 RC_N that have been discarded while this RAQMON PDU was generated. 504 Total number of Application Packets sent: 32 bits - This parameter is 505 defined in section 5.17 of [RAQMON-FRAMEWORK] as an unsigned 506 integer, representing the total number of packets transmitted 507 within sub- session RC_N by the sender. 509 Total number of Application Packets received: 32 bits - This 510 parameter is defined in section 5.16 of [RAQMON-FRAMEWORK] and is 511 represented as an unsigned integer, representing the total number 512 of packets transmitted within sub-session RC_N by the receiver. 514 Total number of Application Octets sent: 32 bits - This parameter is 515 defined in section 5.19 of [RAQMON-FRAMEWORK] as an unsigned 516 integer, representing the total number of payload octets (i.e., 517 not including header or padding) transmitted in packets by the 518 sender within sub- session RC_N. 520 Total number of Application Octets received: 32 bits - This parameter 521 is defined in section 5.18 of [RAQMON-FRAMEWORK] as an unsigned 522 integer representing the total number of payload octets (i.e., not 523 including header or padding) transmitted in packets by the 524 receiver within sub-session RC_N. 526 Data Source Device Port Used: 16 bits - This parameter is defined in 527 section 5.5 of [RAQMON-FRAMEWORK] and describes the port Number 528 used by the Data Source as used by the application in RC_N session 529 while this RAQMON PDU was generated. 531 Receiver Device Port Used: 16 bits - This parameter is defined in 532 section 5.6 of [RAQMON-FRAMEWORK], and describes the receiver port 533 used by the application to communicate to the receiver. It 534 follows same syntax as Source Device Port Used. 536 S_Layer2: 8 bits - This parameter defined in section 5.26 of [RAQMON- 537 FRAMEWORK] is a 8-bit field associated to source's IEEE 802.1D 538 priority tagging of traffic in the communication sub-session RC_N. 539 Since IEEE 802.1 priority tags are 3 bits-long, the first 3 bits 540 of this parameter represent the IEEE 802.1 tag value and the last 541 5 bits are padded to 0. 543 S_Layer3: 8 bits - This parameter defined in section 5.27 of [RAQMON- 544 FRAMEWORK] is a 8-bit field which represents the layer 3 QoS 545 marking used to send packets to the receiver by this data source 546 during sub- session RC_N. 548 D_Layer2: 8 bits - This parameter defined in section 5.28 of [RAQMON- 549 FRAMEWORK] is a 8-bit field which represents layer 2 IEEE 802.1D 550 priority tags used by the receiver to send packets to the data 551 source during sub-session RC_N session if the Data Source can 552 learn such information. Since IEEE 802.1 priority tags are 3 553 bits-long, the first 3 bits of this parameter represent the IEEE 554 802.1 priority tag value and the last 5 bits are padded to 0. 556 D_Layer3: 8 bits - This parameter defined in section 5.29 of [RAQMON- 557 FRAMEWORK] is a 8-bit field which represents the layer 3 QoS 558 marking used by the receiver to send packets to the data source 559 during sub- session RC_N, if the Data Source can learn such 560 information. 562 Source Payload Type: 8 bit - This parameter is defined in section 563 5.24 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the 564 payload type of the data source of the communication sub-session 565 RC_N as defined in [RFC3551]. 567 Receiver Payload Type: 8 bit - This parameter is defined in section 568 5.25 of [RAQMON-FRAMEWORK] as an 8-bit field. It specifies the 569 receiver payload type of the communication sub-session RC_N as 570 defined in [RFC3551]. 572 CPU Utilization: 8 bits - This parameter defined in section 5.30 of 573 [RAQMON-FRAMEWORK] represents the percentage of CPU used during 574 session RC_N from the last report until the time this RAQMON PDU 575 was generated. The CPU Utilization is expressed in percents in 576 the range 0 to 100. The value should indicate not only CPU 577 utilization associated to a session RC_N but also actual CPU 578 Utilization, to indicate a snapshot of the CPU utilization of the 579 host running the RDS while session RC_N in progress. 581 Memory Utilization: 8 bits - This parameter defined in section 5.31 582 of [RAQMON-FRAMEWORK] represents the percentage of total memory 583 used during session RC_N up until the time this RAQMON PDU was 584 generated. The memory utilization is expressed in percents 0 to 585 100. The Memory Utilization value should indicate not only the 586 memory utilization associated to a session RC_N but the total 587 memory utilization, to indicate a snapshot of end device memory 588 utilization while session RC_N in progress. 590 Session Setup Delay: 16 bits - The Session (sub-session) Setup Delay 591 metric is defined in section 5.8 of [RAQMON-FRAMEWORK] and 592 expressed in milliseconds. 594 Application Delay: 16 bits - The Application Delay is defined in 595 section 5.13 of [RAQMON-FRAMEWORK] and is represented as an 596 unsigned integer expressed in milliseconds. 598 IP Packet Delay Variation: 16 bits - The IP Packet Delay Variation is 599 defined in section 5.15 of [RAQMON-FRAMEWORK] and is represented 600 as an unsigned integer expressed in milliseconds. 602 Inter-Arrival Jitter: 16 bits - The Inter-Arrival Jitter is defined 603 in section 5.14 of [RAQMON-FRAMEWORK] and is represented as an 604 unsigned integer expressed in milliseconds. 606 Packet Discard in Fraction: 8 bits - This parameter is defined in 607 section 5.23 of [RAQMON-FRAMEWORK] expressed as a fixed point 608 number with the binary point at the left edge of the field. (That 609 is equivalent to taking the integer part after multiplying the 610 discard fraction by 256.) This metric is defined to be the number 611 of packets discarded divided by the total number of packets. 613 Packet Loss in Fraction: 8 bits - This parameter is defined in 614 section 5.21 of [RAQMON-FRAMEWORK] expressed as a fixed-point 615 number, with the binary point at the left edge of the field. The 616 metric is defined to be the number of packets lost divided by the 617 number of packets expected. The value is calculated by dividing 618 the total number of packets lost (after the effects of applying 619 any error protection such as FEC) by the total number of packets 620 expected, multiplying the result of the division by 256, limiting 621 the maximum value to 255 (to avoid overflow), and taking the 622 integer part. 624 padding: 0, 8, 16 or 24 bits - If the padding bit (P) is set , then 625 this field may be present. The actual padding at the end of the 626 Basic part of the PDU is 0,8, 16 or 24 bits to make the basic part 627 of the PDU multiple of 32 bits long. 629 2.1.3. APP part of the RAQMON Protocol Data Unit 631 The APP part of the RAQMON PDU is intended to accommodate extensions 632 for new applications in a modular manner and without requiring a PDU 633 type value registration. 635 Vendors may design and publish application specific extensions. Any 636 RAQMON compliant RRC MUST be able to recognize vendors SMI Enterprise 637 Code and MUST recognize the presence of application specific 638 extensions identified by using Report Type fields. As represented in 639 Figure 1, the Report Type and Application Length fields are always 640 located at a fixed offset relative to the start of the extension 641 fields. There is no need for the RRC to understand the semantics of 642 the enterprise specific parts of the PDU. 644 SMI Enterprise Code: 32 bits - Vendors and Application developers 645 should fill in appropriate SMI Enterprise IDs available at 646 http://www.iana.org/assignments/enterprise-numbers. A Non-Zero 647 SMI Enterprise Code indicates a vendor or application specific 648 extension. 650 RAQMON PDUs are capable of carrying multiple Application Parts 651 within a PDU. 653 Report Type: 16 bits - Vendors and Application developers should fill 654 in appropriate Report type within a specified SMI Enterprise Code. 655 It is RECOMMENDED that vendors publish application specific 656 extensions and maintain such report types for better 657 interoperability. 659 Length of the Application Part: 16 bits (unsigned integer) - The 660 length of the Application Part of the RAQMON PDU in 32-bit words 661 minus one, which includes the header of the Application Part. 663 Application-dependent data: variable length - Application/vendor- 664 dependent data is defined by the application developers. It is 665 interpreted by the vendor specific application and not by the RRC 666 itself. It must be a multiple of 32 bits long, and will be padded 667 if necessary. 669 2.1.4. Byte Order, Alignment and Time Format of RAQMON PDUs 671 All integer fields are carried in network byte order, that is, most 672 significant byte (octet) first. This byte order is commonly known as 673 big-endian. The transmission order is described in detail in 674 [RFC791]. Unless otherwise noted, numeric constants are in decimal 675 (base 10). 677 All header data is aligned to its natural length, i.e., 16-bit fields 678 are aligned on even offsets, 32-bit fields are aligned at offsets 679 divisible by four, etc. Octets designated as padding have the value 680 zero. 682 2.2. Securing RAQMON session 684 The RAQMON session, initiated over TCP transport, between an RDS and 685 an RRC carries monitoring information from an RDS client to the RRC, 686 the collector. The RRC distinguishes between clients based on 687 various identifiers used by the RDS to identify itself to the RRC 688 (Data Source Address and Data Source Name) and the RRC (Receiver's 689 Address and Receiver's Name). 691 In order to ensure integrity of the claimed identities of RDS and RRC 692 to each other authentication services are required. 694 Subsequently, where protection from unauthorized modification and 695 unauthorized disclosure of RAQMON data in transit from RDS to RRC is 696 needed, data confidentiality and message integrity services will be 697 required. In order to prevent monitoring-misinformation due to 698 session-recording and replay by unauthorized sources, replay 699 protection services may be required. 701 TLS provides, at the transport layer, the required authentication 702 services through the handshake protocol and subequent data 703 confidentiality, message integrity and replay protection of the 704 application protocol using ciphersuite negotiated during 705 authentication. 707 The RDS client authenticates the RRC in session. The RRC optionally 708 authenticates the RDS. 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 |PDT = 1 |B| T |P|S|R| RC | Length | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | DSRC | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | SMI Enterprise Code = 0 |Report Type = | RC_N | 718 | | TLS_REQ| | 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 721 RAQMON StartTLS Request - TLS_REQ 723 Figure 2 725 The protection of RAQMON session starts with the RDS client StartTLS 726 request upon successful establishment of the TCP session. The RDS 727 sends the StartTLS request by transmitting the TLS_REQ PDU as in 728 Figure 2. This PDU is distinguished by TLS_REQ Report Type. 730 The client MUST NOT send any PDUs on this connection following this 731 request until it receives a StartTLS response. 733 Other fields of the PDU are as specified in Figure 1. 735 The flags field do not carry any significance and exist for 736 compatibility with the generic RAQMON PDU. The flags field in this 737 version MUST be ignored. 739 When a StartTLS request is made, the target server, RRC, MUST return 740 a RAQMON PDU containing a StartTLS response, TLS_RESP. A RAQMON 741 TLS_RESP is defined as follows: 743 0 1 2 3 744 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 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 |PDT = 1 |B| T |P|S|R| RC | Length | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | DSRC | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | SMI Enterprise Code = 0 |Report Type = | Result | 751 | | TLS_RESP| | 752 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 RAQMON StartTLS Response - TLS_RESP 756 Figure 3 757 The RRC responds to the StartTLS request by transmitting the TLS_RESP 758 PDU as in Figure 3. This PDU is distinguished by TLS_RESP Report 759 Type. 761 The Result field is an octet containing the result of the request. 762 This field can carry one of the following values: 764 +-------+------------------+----------------------------------------+ 765 | Value | Mnemonic | Result | 766 +-------+------------------+----------------------------------------+ 767 | 0 | OK | Success. The server is willing and | 768 | | | able to negotiate TLS. | 769 | | | | 770 | 1 | OP_ERR | Sequencing Error (e.g., TLS already | 771 | | | established). | 772 | | | | 773 | 2 | PROTO_ERR | TLS not supported or incorrect PDU | 774 | | | format. | 775 | | | | 776 | 3 | UNAVAIL | TLS service problem or RRC server | 777 | | | going down. | 778 | | | | 779 | 4 | CONF_REQD | Confidentiality Service Required. | 780 | | | | 781 | 5 | STRONG_AUTH_REQD | Strong Authentication Service | 782 | | | Required. | 783 | | | | 784 | 6 | REFERRAL | Referral to a RRC Server supporting | 785 | | | TLS. | 786 +-------+------------------+----------------------------------------+ 788 Table 2 790 Other fields of the PDU are as specified in Figure 1. 792 The server MUST return OP_ERR if the client violates any of the 793 StartTLS operation sequencing requirements described in section 794 below. 796 If the server does not support TLS (whether by design or by current 797 configuration), it MUST set the resultCode to PROTO_ERR or to 798 REFERRAL. The server MUST include an actual referral value in the 799 RAQMON REFER field if it returns a resultCode of referral. The 800 client's current session is unaffected if the server does not support 801 TLS. The client MAY proceed with RAQMON session, or it MAY close the 802 connection. 804 The server MUST return UNAVAIL if it supports TLS but cannot 805 establish a TLS connection for some reason, e.g. the certificate 806 server not responding, it cannot contact its TLS implementation, or 807 if the server is in process of shutting down. The client MAY retry 808 the StartTLS operation, or it MAY proceed with RAQMON session, or it 809 MAY close the connection. 811 2.2.1. Sequencing of the Start TLS Operation 813 This section describes the overall procedures clients and servers 814 MUST follow for TLS establishment. These procedures take into 815 consideration various aspects of the overall security of the RAQMON 816 connection including discovery of resulting security level. 818 2.2.1.1. Requesting to Start TLS on a RAQMON Association 820 The client MAY send the StartTLS request at any time after 821 establishing an RAQMON (TCP) connection, except that in the following 822 cases the client MUST NOT send a StartTLS request: 824 o if TLS is currently established on the connection, or 826 o if RAQMON traffic is in progress on the connection. 828 The result of violating any of these requirements is a Result of 829 OP_ERR, as described above in Table 2. 831 If the client did not establish a TLS connection before sending any 832 other requests, and the server requires the client to establish a TLS 833 connection before performing a particular request, the server MUST 834 reject that request with a CONF_REQD or STRONG_AUTH_REQD result. The 835 client MAY send a Start TLS extended request, or it MAY choose to 836 close the connection. 838 2.2.1.2. Starting TLS 840 The server will return an extended response with the resultCode of 841 success if it is willing and able to negotiate TLS. It will return 842 other resultCodes, documented above, if it is unable. 844 In the successful case, the client, which has ceased to transfer 845 PAQMON PDUs on the connection, MUST either begin a TLS negotiation or 846 close the connection. The client will send PDUs in the TLS Record 847 Protocol directly over the underlying transport connection to the 848 server to initiate TLS negotiation [TLS]. 850 2.2.1.3. TLS Version Negotiation 852 Negotiating the version of TLS or SSL to be used is a part of the TLS 853 Handshake Protocol, as documented in [TLS]. The reader is referred 854 to that document for details. 856 2.2.1.4. Discovery of Resultant Security Level 858 After a TLS connection is established on an RAQMON connection, both 859 parties MUST individually decide whether or not to continue based on 860 the security assurance level achieved. Ascertaining the TLS 861 connection's assurance level is implementation dependent, and 862 accomplished by communicating with one's respective local TLS 863 implementation. 865 If the client or server decides that the level of authentication or 866 confidentiality is not high enough for it to continue, it SHOULD 867 gracefully close the TLS connection immediately after the TLS 868 negotiation has completed Section 2.2.2.1. 870 The client MAY attempt to Start TLS again, or MAY disconnect or 871 proceed to send RAQMON session data, if RRC policy permits. 873 2.2.1.5. Server Identity Check 875 The client MUST check its understanding of the server's hostname 876 against the server's identity as presented in the server's 877 Certificate message, in order to prevent man-in-the-middle attacks. 879 Matching is performed according to these rules: 881 o The client MUST use the server address it used to open the RAQMON 882 connection as the value to compare against the server name as 883 expressed in the Subject Name field of server's certificate as a 884 X.500 Distinsuished Name. The client MUST NOT use the server's 885 canonical DNS name or any other derived form of name. 887 o Matching is case-insensitive. 889 o The "*" wildcard character is allowed. If present, it applies 890 only to the left-most name component. 892 E.g. *.example.com would match a.example.com, b.example.com, etc. 893 but not example.com. If more than one identity of a given type is 894 present in the certificate (e.g. more than one dNSName name), a 895 match in any one of the set is considered acceptable. 897 If the hostname does not match the dNSName-based identity in the 898 certificate per the above check, automated clients SHOULD close the 899 connection, returning and/or logging an error indicating that the 900 server's identity is suspect. 902 Beyond the server identity checks described in this section, clients 903 SHOULD be prepared to do further checking to ensure that the server 904 is authorized to provide the service it is observed to provide. The 905 client MAY need to make use of local policy information. 907 We also refer readers to similar guidelines as applied for LDAP over 908 TLS [LDAP-TLS] 910 2.2.1.6. Client Identity Check 912 Anonomyous TLS authentication helps establish a TLS RAQMON session 913 that offers 915 o server-authentication in course of TLS establishment 917 o confidentiality and replay protection of RAQMON traffic, but 919 o no protection against man-in-the-middle attacks during session 920 establishment. 922 o no protection from spoofing attacks by unauthorized clients 924 The server MUST authenticate the RDS client when deployment is 925 susceptible to above threats. This is done by requiring client 926 authentication during TLS session establishment. 928 In the TLS negotiation, the server MUST request a certificate. The 929 client will provide its certificate to the server, and MUST perform a 930 private key-based encryption, proving it has the private key 931 associated with the certificate. 933 As deployments will require protection of sensitive data in transit, 934 the client and server MUST negotiate a ciphersuite which contains a 935 bulk encryption algorithm of appropriate strength. 937 The server MUST verify that the client's certificate is valid. The 938 server will normally check that the certificate is issued by a known 939 CA, and that none of the certificates on the client's certificate 940 chain are invalid or revoked. There are several procedures by which 941 the server can perform these checks. 943 The server validates the certificate by the Distinguished Name of the 944 RDS client entity in the Subject field of the certificate. 946 A corresponding set of guidelines will apply to use of TLS-PSK modes 947 [TLS-PSK] using pre-shared keys instead of client certificates. 949 2.2.1.7. Refresh of Server Capabilities Information 951 The client MUST refresh any cached server capabilities information 952 upon TLS session establishment, such as prior RRC state related to a 953 previous RAQMON session based on another DSRC. This is necessary to 954 protect against active-intermediary attacks which may have altered 955 any server capabilities information retrieved prior to TLS 956 establishment. The server MAY advertise different capabilities after 957 TLS establishment. 959 2.2.2. Closing a TLS Connection 961 2.2.2.1. Graceful Closure 963 Either the client or server MAY terminate the TLS connection on an 964 RAQMON session by sending a TLS closure alert. This will leave the 965 RAQMON connection intact. 967 Before closing a TLS connection, the client MUST either wait for any 968 outstanding RAQMON transmissions to complete. This happens naturally 969 when the RAQMON client is single-threaded and synchronous. 971 After the initiator of a close has sent a closure alert, it MUST 972 discard any TLS messages until it has received an alert from the 973 other party. It will cease to send TLS Record Protocol PDUs, and 974 following the receipt of the alert, MAY send and receive RAQMON PDUs. 976 The other party, if it receives a closure alert, MUST immediately 977 transmit a TLS closure alert. It will subsequently cease to send TLS 978 Record Protocol PDUs, and MAY send and receive RAQMON PDUs. 980 2.2.2.2. Abrupt Closure 982 Either the client or server MAY abruptly close the entire RAQMON 983 session and any TLS connection established on it by dropping the 984 underlying TCP connection. It MAY be possible for RRC to send RDS a 985 message notifying disconnect - allowing the client to know the 986 connectivity to be due to other than network failure. However, this 987 message is not defined in this version. 989 2.3. SNMP Notifications as an RDS/RRC Network Transport Protocol 991 It was an inherent objective of the RAQMON Framework to re-use 992 existing application level transport protocols to maximize the usage 993 of existing installations as well as to avoid transport protocol 994 level complexities in the design process. Choice of SNMP as a means 995 to transport RAQMON PDU was motivated by the intent of using existing 996 installed based of devices implementing SNMP agents as RAQMON Data 997 Sources (RDS). 999 There are some potential problems with the usage of SNMP as a 1000 transport mapping protocol: 1002 o The potential of congestion is higher than with the TCP transport, 1003 because of the usage of UDP at the transport layer. 1005 o The encoding of the information is less efficient and this results 1006 in bigger message size, which again may impact negatively 1007 congestion conditions and memory size requirements in the devices. 1009 In order to avoid these potential problems, the following 1010 recommendations are made: 1012 o Usage of the TCP transport is RECOMMENDED in deployment over the 1013 SNMP transport wherever available for a pair of RDS/RRC. 1015 o The usage of Inform PDUs is RECOMMENDED. 1017 o The usage of Traps PDU is NOT RECOMMENDED. 1019 o It is RECOMMENDED that information carried by notifications be 1020 maintained within the limits of the MTU size in order to avoid 1021 fragmentation. 1023 If SNMP is chosen as a mechanism to transport RAQMON PDUs, the 1024 following specification applies to RAQMON related usage of SNMP: 1026 o RDSs implement the capability of embedding RAQMON parameters in 1027 SNMP Notifications, re-using well known SNMP mechanisms to report 1028 RAQMON Statistics. The RAQMON RDS MIB module as specified in 1029 2.1.1 MUST be used in order to map the RAQMON PDUs onto the SNMP 1030 Notifications transport. 1032 o Since RDSs are not computationally rich and to keep the RDS 1033 realization as lightweight as possible, RDSs MAY fail to respond 1034 to SNMP requests like GET, SET, etc., with the exception of the 1035 GET and SET commands required to implement the User-Based Security 1036 Model (USM) defined by [RFC3414]. 1038 o In order to meet congestion safety requirements, SNMP INFORM PDUs 1039 SHOULD be used. In case INFORM PDUs are used, RDSs MUST process 1040 the SNMP INFORM responses from RRCs, and MUST serialize the PDU 1041 transmission rate, i.e. limit the number of PDUS sent in a 1042 specific time interval. 1044 o Standard UDP port 162 SHOULD be used for SNMP Notifications. 1046 2.3.1. Encoding RAQMON using the RAQMON RDS MIB module 1048 The RAQMON RDS MIB module is used to map RAQMON PDUs onto SNMP 1049 Notifications for transport purposes. The MIB module defines the 1050 objects needed for mapping the Basic part of RAQMON PDU defined in 1051 [RAQMON-FRAMEWORK] as well as the Notifications themselves. In order 1052 to incorporate any application-specific extensions in the Application 1053 (APP) part of RAQMON PDU as defined in [RAQMON-FRAMEWORK], additional 1054 variable bindings MAY be included in RAQMON notifications as 1055 described in the MIB module. 1057 For a detailed overview of the documents that describe the current 1058 Internet-Standard Management Framework, please refer to section 7 of 1059 [RFC3410]. 1061 Managed objects are accessed via a virtual information store, termed 1062 the Management Information Base or MIB. MIB objects are generally 1063 accessed through the Simple Network Management Protocol (SNMP). 1064 Objects in the MIB are defined using the mechanisms defined in the 1065 Structure of Management Information (SMI). This memo specifies a MIB 1066 module that is compliant to the SMIv2, which is described in STD 58, 1067 [RFC2578], STD 58, [RFC2579] and STD 58, [RFC2580]. 1069 The following MIB module IMPORTS definitions from the following: 1071 SNMPv2-SMI [RFC2578] 1072 SNMPv2-TC [RFC2579] 1073 SNMPv2-CONF [RFC2580] 1074 RMON-MIB [RFC2819] 1075 DIFFSERV-DSCP-TC [RFC3289] 1076 SNMP-FRAMEWORK-MIB [RFC3411] 1077 INET-ADDRESS-MIB [RFC4001] 1079 It also uses REFERENCE clauses to refer to [RAQMON-FRAMEWORK]. 1081 RAQMON-RDS-MIB DEFINITIONS ::= BEGIN 1083 IMPORTS 1084 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, 1085 Counter32, Unsigned32 1086 FROM SNMPv2-SMI 1088 DateAndTime 1089 FROM SNMPv2-TC 1091 rmon 1092 FROM RMON-MIB 1094 SnmpAdminString 1095 FROM SNMP-FRAMEWORK-MIB 1097 InetAddressType, InetAddress, InetPortNumber 1098 FROM INET-ADDRESS-MIB 1100 Dscp 1101 FROM DIFFSERV-DSCP-TC 1103 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 1104 FROM SNMPv2-CONF; 1106 raqmonDsMIB MODULE-IDENTITY 1107 LAST-UPDATED "200601230000Z" -- January 23, 2006 1108 ORGANIZATION "RMON Working Group" 1109 CONTACT-INFO 1110 "WG EMail: rmonmib@ietf.org 1111 Subscribe: rmonmib-request@ietf.org 1113 MIB Editor: 1114 Eugene Golovinsky 1115 Postal: BMC Software, Inc. 1116 2101 CityWest Boulevard, 1117 Houston, TX, 77094 1118 USA 1119 Tel: +713-918-1816 1120 Email: egolovin@bmc.com 1121 " 1122 DESCRIPTION 1123 " This is the RAQMON Data Source notification MIB Module. 1124 It provides a mapping of RAQMON PDUs to SNMP 1125 notifications. 1127 Ds stands for data source. 1129 Note that all of the object types defined in this module 1130 are accessible-for-notify, and would consequently not be 1131 available to a browser using simple Get, GetNext, or 1132 GetBulk requests. 1134 Copyright (c) The Internet Society (2006). 1136 -- RFC EDITOR: please replace yyyy with actual number 1137 This version of this MIB module is part of RFC yyyy; 1138 See the RFC itself for full legal notices. 1139 " 1141 REVISION "200601230000Z" -- January 23, 2006 1142 DESCRIPTION 1143 "Initial version, published as RFCyyyy." 1144 -- RFC Editor: Please fill in RFCyyyy 1146 ::= { rmon 32 } 1148 -- This OID allocation conforms to [RFC3737] 1150 raqmonDsNotifications OBJECT IDENTIFIER ::= { raqmonDsMIB 0 } 1151 raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDsMIB 1 } 1152 raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDsMIB 2 } 1154 raqmonDsNotificationTable OBJECT-TYPE 1155 SYNTAX SEQUENCE OF RaqmonDsNotificationEntry 1156 MAX-ACCESS not-accessible 1157 STATUS current 1158 DESCRIPTION 1159 " This conceptual table provides the SNMP mapping of 1160 the RAQMON Basic PDU. It is indexed by the RAQMON 1161 Data Source, sub-session, and address of the peer 1162 entity. 1164 Note that there is no concern about the indexation of 1165 this table exceeding the limits defined by RFC 2578 1166 Section 3.5. According to 1167 [RAQMON-FRAMEWORK] 1168 , Section 1169 5.1, only IPv4 and IPv6 addresses can be reported as 1170 participant addresses. 1171 " 1172 ::= { raqmonDsMIBObjects 1 } 1174 raqmonDsNotificationEntry OBJECT-TYPE 1175 SYNTAX RaqmonDsNotificationEntry 1176 MAX-ACCESS not-accessible 1177 STATUS current 1178 DESCRIPTION 1179 "The entry (row) is not retrievable and is not kept by 1180 RDSs. It serves data organization purpose only. 1181 " 1182 INDEX { raqmonDsDSRC, raqmonDsRCN, raqmonDsPeerAddrType, 1183 raqmonDsPeerAddr } 1184 ::= { raqmonDsNotificationTable 1 } 1186 RaqmonDsNotificationEntry ::= SEQUENCE { 1187 raqmonDsDSRC Unsigned32, 1188 raqmonDsRCN Unsigned32, 1189 raqmonDsPeerAddrType InetAddressType, 1190 raqmonDsPeerAddr InetAddress, 1191 raqmonDsAppName SnmpAdminString, 1192 raqmonDsDataSourceDevicePort InetPortNumber, 1193 raqmonDsReceiverDevicePort InetPortNumber, 1194 raqmonDsSessionSetupDateTime DateAndTime, 1195 raqmonDsSessionSetupDelay Unsigned32, 1196 raqmonDsSessionDuration Unsigned32, 1197 raqmonDsSessionSetupStatus SnmpAdminString, 1198 raqmonDsRoundTripEndToEndNetDelay Unsigned32, 1199 raqmonDsOneWayEndToEndNetDelay Unsigned32, 1200 raqmonDsApplicationDelay Unsigned32, 1201 raqmonDsInterArrivalJitter Unsigned32, 1202 raqmonDsIPPacketDelayVariation Unsigned32, 1203 raqmonDsTotalPacketsReceived Counter32, 1204 raqmonDsTotalPacketsSent Counter32, 1205 raqmonDsTotalOctetsReceived Counter32, 1206 raqmonDsTotalOctetsSent Counter32, 1207 raqmonDsCumulativePacketLoss Counter32, 1208 raqmonDsPacketLossFraction Unsigned32, 1209 raqmonDsCumulativeDiscards Counter32, 1210 raqmonDsDiscardsFraction Unsigned32, 1211 raqmonDsSourcePayloadType Unsigned32, 1212 raqmonDsReceiverPayloadType Unsigned32, 1213 raqmonDsSourceLayer2Priority Unsigned32, 1214 raqmonDsSourceDscp Dscp, 1215 raqmonDsDestinationLayer2Priority Unsigned32, 1216 raqmonDsDestinationDscp Dscp, 1217 raqmonDsCpuUtilization Unsigned32, 1218 raqmonDsMemoryUtilization Unsigned32 } 1220 raqmonDsDSRC OBJECT-TYPE 1221 SYNTAX Unsigned32 1222 MAX-ACCESS not-accessible 1223 STATUS current 1224 DESCRIPTION 1225 "Data Source identifier represents a unique session 1226 descriptor that points to a specific session 1227 between communicating entities. Identifiers unique for 1228 sessions conducted between two entities are 1229 generated by the communicating entities. Zero is a 1230 valid value, with no special semantics." 1231 ::= { raqmonDsNotificationEntry 1 } 1233 raqmonDsRCN OBJECT-TYPE 1234 SYNTAX Unsigned32 (0..15) 1235 MAX-ACCESS not-accessible 1236 STATUS current 1237 DESCRIPTION 1238 "The Record Count Number indicates a sub-session 1239 within a communication session. A maximum number of 16 1240 sub-sessions are supported - this limitation is 1241 dictated by reasons of compatibility with other 1242 transport protocols." 1243 ::= { raqmonDsNotificationEntry 2 } 1245 raqmonDsPeerAddrType OBJECT-TYPE 1246 SYNTAX InetAddressType 1247 MAX-ACCESS not-accessible 1248 STATUS current 1249 DESCRIPTION 1250 "The type of the Internet address of the peer participant 1251 for this session." 1252 REFERENCE 1253 "Section 5.2 of 1254 [RAQMON-FRAMEWORK] 1255 " 1256 ::= { raqmonDsNotificationEntry 3 } 1258 raqmonDsPeerAddr OBJECT-TYPE 1259 SYNTAX InetAddress 1260 MAX-ACCESS not-accessible 1261 STATUS current 1262 DESCRIPTION 1263 "The Internet Address of the peer participant for this 1264 session." 1265 REFERENCE 1266 "Section 5.2 of 1267 [RAQMON-FRAMEWORK] 1268 " 1269 ::= { raqmonDsNotificationEntry 4 } 1271 raqmonDsAppName OBJECT-TYPE 1272 SYNTAX SnmpAdminString 1273 MAX-ACCESS accessible-for-notify 1274 STATUS current 1275 DESCRIPTION 1276 "This is a text string giving the name and possibly 1277 version of the application associated with that session, 1278 e.g., 'XYZ VoIP Agent 1.2'." 1279 REFERENCE 1280 "Section 5.28 of 1281 [RAQMON-FRAMEWORK] 1282 " 1283 ::= { raqmonDsNotificationEntry 5 } 1285 raqmonDsDataSourceDevicePort OBJECT-TYPE 1286 SYNTAX InetPortNumber 1287 MAX-ACCESS accessible-for-notify 1288 STATUS current 1289 DESCRIPTION 1290 "The port number from which data for this session was sent 1291 by the Data Source device." 1292 REFERENCE 1293 "Section 5.5 of 1294 [RAQMON-FRAMEWORK] 1295 " 1296 ::= { raqmonDsNotificationEntry 6 } 1298 raqmonDsReceiverDevicePort OBJECT-TYPE 1299 SYNTAX InetPortNumber 1300 MAX-ACCESS accessible-for-notify 1301 STATUS current 1302 DESCRIPTION 1303 "The port number where the data for this session was 1304 received." 1305 REFERENCE 1306 "Section 5.6 of 1307 [RAQMON-FRAMEWORK] 1308 " 1309 ::= { raqmonDsNotificationEntry 7 } 1311 raqmonDsSessionSetupDateTime OBJECT-TYPE 1312 SYNTAX DateAndTime 1313 MAX-ACCESS accessible-for-notify 1314 STATUS current 1315 DESCRIPTION 1316 "The time when session was initiated." 1317 REFERENCE 1318 "Section 5.7 of 1319 [RAQMON-FRAMEWORK] 1320 " 1321 ::= { raqmonDsNotificationEntry 8 } 1323 raqmonDsSessionSetupDelay OBJECT-TYPE 1324 SYNTAX Unsigned32 (0..65535) 1325 UNITS "milliseconds" 1326 MAX-ACCESS accessible-for-notify 1327 STATUS current 1328 DESCRIPTION 1329 "Session setup time." 1330 REFERENCE 1331 "Section 5.8 of 1332 [RAQMON-FRAMEWORK] 1333 " 1334 ::= { raqmonDsNotificationEntry 9 } 1336 raqmonDsSessionDuration OBJECT-TYPE 1337 SYNTAX Unsigned32 1338 UNITS "seconds" 1339 MAX-ACCESS accessible-for-notify 1340 STATUS current 1341 DESCRIPTION 1342 "Session duration, including setup time. The SYNTAX of 1343 this object allows to express the duration of sessions 1344 that do not exceed 4660 hours and 20 minutes." 1345 REFERENCE 1346 "Section 5.9 of 1347 [RAQMON-FRAMEWORK] 1348 " 1349 ::= { raqmonDsNotificationEntry 10 } 1351 raqmonDsSessionSetupStatus OBJECT-TYPE 1352 SYNTAX SnmpAdminString 1353 MAX-ACCESS accessible-for-notify 1354 STATUS current 1355 DESCRIPTION 1356 "Describes appropriate communication session states e.g. 1357 Call Established successfully, RSVP reservation 1358 failed etc." 1359 REFERENCE 1360 "Section 5.10 of 1361 [RAQMON-FRAMEWORK] 1362 " 1363 ::= { raqmonDsNotificationEntry 11 } 1365 raqmonDsRoundTripEndToEndNetDelay OBJECT-TYPE 1366 SYNTAX Unsigned32 1367 UNITS "milliseconds" 1368 MAX-ACCESS accessible-for-notify 1369 STATUS current 1370 DESCRIPTION 1371 "Most recent available information about the 1372 round trip end to end network delay." 1373 REFERENCE 1374 "Section 5.11 of 1375 [RAQMON-FRAMEWORK] 1376 " 1377 ::= { raqmonDsNotificationEntry 12} 1379 raqmonDsOneWayEndToEndNetDelay OBJECT-TYPE 1380 SYNTAX Unsigned32 1381 UNITS "milliseconds" 1382 MAX-ACCESS accessible-for-notify 1383 STATUS current 1384 DESCRIPTION 1385 " Most recent available information about the 1386 one way end to end network delay." 1387 REFERENCE 1388 "Section 5.12 of 1389 [RAQMON-FRAMEWORK] 1390 " 1391 ::= { raqmonDsNotificationEntry 13} 1393 raqmonDsApplicationDelay OBJECT-TYPE 1394 SYNTAX Unsigned32 (0..65535) 1395 UNITS "milliseconds" 1396 MAX-ACCESS accessible-for-notify 1397 STATUS current 1398 DESCRIPTION 1399 " Most recent available information about the 1400 application delay." 1401 REFERENCE 1402 "Section 5.13 of 1403 [RAQMON-FRAMEWORK] 1404 " 1405 ::= { raqmonDsNotificationEntry 14} 1407 raqmonDsInterArrivalJitter OBJECT-TYPE 1408 SYNTAX Unsigned32 (0..65535) 1409 UNITS "milliseconds" 1410 MAX-ACCESS accessible-for-notify 1411 STATUS current 1412 DESCRIPTION 1413 "An estimate of the inter-arrival jitter." 1414 REFERENCE 1415 "Section 5.14 of 1417 [RAQMON-FRAMEWORK] 1418 " 1419 ::= { raqmonDsNotificationEntry 15} 1421 raqmonDsIPPacketDelayVariation OBJECT-TYPE 1422 SYNTAX Unsigned32 (0..65535) 1423 UNITS "milliseconds" 1424 MAX-ACCESS accessible-for-notify 1425 STATUS current 1426 DESCRIPTION 1427 "An estimate of the inter-arrival delay variation." 1428 REFERENCE 1429 "Section 5.15 of 1430 [RAQMON-FRAMEWORK] 1431 " 1432 ::= { raqmonDsNotificationEntry 16} 1434 raqmonDsTotalPacketsReceived OBJECT-TYPE 1435 SYNTAX Counter32 1436 UNITS "packets" 1437 MAX-ACCESS accessible-for-notify 1438 STATUS current 1439 DESCRIPTION 1440 "The number of packets transmitted within a communication 1441 session by the receiver since the start of the session." 1442 REFERENCE 1443 "Section 5.16 of 1444 [RAQMON-FRAMEWORK] 1445 " 1446 ::= { raqmonDsNotificationEntry 17 } 1448 raqmonDsTotalPacketsSent OBJECT-TYPE 1449 SYNTAX Counter32 1450 UNITS "packets" 1451 MAX-ACCESS accessible-for-notify 1452 STATUS current 1453 DESCRIPTION 1454 "The number of packets transmitted within a communication 1455 session by the sender since the start of the session." 1456 REFERENCE 1457 "Section 5.17 of 1458 [RAQMON-FRAMEWORK] 1459 " 1460 ::= { raqmonDsNotificationEntry 18 } 1462 raqmonDsTotalOctetsReceived OBJECT-TYPE 1463 SYNTAX Counter32 1464 UNITS "octets" 1465 MAX-ACCESS accessible-for-notify 1466 STATUS current 1467 DESCRIPTION 1468 "The total number of payload octets (i.e., not including 1469 header or padding octets) transmitted in packets by the 1470 receiver within a communication session since the start 1471 of the session." 1472 REFERENCE 1473 "Section 5.18 of 1474 [RAQMON-FRAMEWORK] 1475 " 1476 ::= { raqmonDsNotificationEntry 19 } 1478 raqmonDsTotalOctetsSent OBJECT-TYPE 1479 SYNTAX Counter32 1480 UNITS "octets" 1481 MAX-ACCESS accessible-for-notify 1482 STATUS current 1483 DESCRIPTION 1484 "The number of payload octets (i.e., not including headers 1485 or padding) transmitted in packets by the sender within 1486 a communication sub-session since the start of the 1487 session." 1488 REFERENCE 1489 "Section 5.19 of 1490 [RAQMON-FRAMEWORK] 1491 " 1492 ::= { raqmonDsNotificationEntry 20 } 1494 raqmonDsCumulativePacketLoss OBJECT-TYPE 1495 SYNTAX Counter32 1496 UNITS "packets" 1497 MAX-ACCESS accessible-for-notify 1498 STATUS current 1499 DESCRIPTION 1500 "The number of packets from this session whose loss 1501 had been detected since the start of the session." 1502 REFERENCE 1503 "Section 5.20 of 1504 [RAQMON-FRAMEWORK] 1505 " 1506 ::= { raqmonDsNotificationEntry 21 } 1508 raqmonDsPacketLossFraction OBJECT-TYPE 1509 SYNTAX Unsigned32 (0..100) 1510 UNITS "percentage of packets sent" 1511 MAX-ACCESS accessible-for-notify 1512 STATUS current 1513 DESCRIPTION 1514 "The percentage of lost packets with respect to the 1515 overall packets sent. This is defined to be 100 times 1516 the number of packets lost divided by the number of 1517 packets expected." 1518 REFERENCE 1519 "Section 5.21 of 1520 [RAQMON-FRAMEWORK] 1521 " 1522 ::= { raqmonDsNotificationEntry 22 } 1524 raqmonDsCumulativeDiscards OBJECT-TYPE 1525 SYNTAX Counter32 1526 UNITS "packets" 1527 MAX-ACCESS accessible-for-notify 1528 STATUS current 1529 DESCRIPTION 1530 "The number of packet discards 1531 detected since the start of the session." 1532 REFERENCE 1533 "Section 5.22 of 1534 [RAQMON-FRAMEWORK] 1535 " 1536 ::= { raqmonDsNotificationEntry 23 } 1538 raqmonDsDiscardsFraction OBJECT-TYPE 1539 SYNTAX Unsigned32 (0..100) 1540 UNITS "percentage of packets sent" 1541 MAX-ACCESS accessible-for-notify 1542 STATUS current 1543 DESCRIPTION 1544 "The percentage of discards with respect to the overall 1545 packets sent. This is defined to be 100 times the number 1546 of discards divided by the number of packets expected." 1547 REFERENCE 1548 "Section 5.23 of 1549 [RAQMON-FRAMEWORK] 1550 " 1551 ::= { raqmonDsNotificationEntry 24 } 1553 raqmonDsSourcePayloadType OBJECT-TYPE 1554 SYNTAX Unsigned32 (0..127) 1555 MAX-ACCESS accessible-for-notify 1556 STATUS current 1557 DESCRIPTION 1558 "The payload type of the packet sent by this RDS." 1559 REFERENCE 1560 "RFC 1890, Section 5.24 of 1562 [RAQMON-FRAMEWORK] 1563 " 1564 ::= { raqmonDsNotificationEntry 25 } 1566 raqmonDsReceiverPayloadType OBJECT-TYPE 1567 SYNTAX Unsigned32 (0..127) 1568 MAX-ACCESS accessible-for-notify 1569 STATUS current 1570 DESCRIPTION 1571 "The payload type of the packet received by this RDS." 1572 REFERENCE 1573 "RFC 1890, Section 5.25 of 1574 [RAQMON-FRAMEWORK] 1575 " 1576 ::= { raqmonDsNotificationEntry 26 } 1578 raqmonDsSourceLayer2Priority OBJECT-TYPE 1579 SYNTAX Unsigned32 (0..7) 1580 MAX-ACCESS accessible-for-notify 1581 STATUS current 1582 DESCRIPTION 1583 "Source Layer 2 priority used by the sata source to send 1584 packets to the receiver by this data source during this 1585 communication session. 1586 " 1587 REFERENCE 1588 "Section 5.26 of 1589 [RAQMON-FRAMEWORK] 1590 " 1591 ::= { raqmonDsNotificationEntry 27 } 1593 raqmonDsSourceDscp OBJECT-TYPE 1594 SYNTAX Dscp 1595 MAX-ACCESS accessible-for-notify 1596 STATUS current 1597 DESCRIPTION 1598 "Layer 3 TOS/DSCP values used by the Data Source to 1599 prioritize traffic sent." 1600 REFERENCE 1601 "Section 5.27 of 1602 [RAQMON-FRAMEWORK] 1603 " 1604 ::= { raqmonDsNotificationEntry 28 } 1606 raqmonDsDestinationLayer2Priority OBJECT-TYPE 1607 SYNTAX Unsigned32 (0..7) 1608 MAX-ACCESS accessible-for-notify 1609 STATUS current 1610 DESCRIPTION 1611 "Destination Layer 2 priority. This is the priority used 1612 by the peer communicating entity to send packets to the 1613 data source. 1614 " 1615 REFERENCE 1616 "Section 5.28 of 1617 [RAQMON-FRAMEWORK] 1618 " 1619 ::= { raqmonDsNotificationEntry 29 } 1621 raqmonDsDestinationDscp OBJECT-TYPE 1622 SYNTAX Dscp 1623 MAX-ACCESS accessible-for-notify 1624 STATUS current 1625 DESCRIPTION 1626 "Layer 3 TOS/DSCP values used by the 1627 peer communicating entiy to prioritize traffic 1628 sent to the source." 1629 REFERENCE 1630 "Section 5.29 of 1631 [RAQMON-FRAMEWORK] 1632 " 1633 ::= { raqmonDsNotificationEntry 30 } 1635 raqmonDsCpuUtilization OBJECT-TYPE 1636 SYNTAX Unsigned32 (0..100) 1637 UNITS "percent" 1638 MAX-ACCESS accessible-for-notify 1639 STATUS current 1640 DESCRIPTION 1641 "Latest available information about the total CPU 1642 utilization." 1643 REFERENCE 1644 "Section 5.30 of 1645 [RAQMON-FRAMEWORK] 1646 " 1647 ::= { raqmonDsNotificationEntry 31 } 1649 raqmonDsMemoryUtilization OBJECT-TYPE 1650 SYNTAX Unsigned32 (0..100) 1651 UNITS "percent" 1652 MAX-ACCESS accessible-for-notify 1653 STATUS current 1654 DESCRIPTION 1655 "Latest available information about the total memory 1656 utilization." 1657 REFERENCE 1658 "Section 5.31 of 1659 [RAQMON-FRAMEWORK] 1660 " 1661 ::= { raqmonDsNotificationEntry 32 } 1663 -- definitions of the notifications 1664 -- 1665 -- raqmonDsAppName is the only object that MUST be sent by an 1666 -- RDS every time the static notification is generated. 1668 -- raqmonDsTotalPacketsReceived is the only object that MUST be 1669 -- sent by an RD every time the dynamic notification is generated. 1671 -- Other objects from the raqmonDsNotificationTable may be 1672 -- included in the variable binding list. Specifically, a raqmon 1673 -- notification will include MIB objects that provide information 1674 -- about metrics that characterize the application session 1676 raqmonDsStaticNotification NOTIFICATION-TYPE 1677 OBJECTS { raqmonDsAppName } 1678 STATUS current 1679 DESCRIPTION 1680 "This notification maps the static parameters in the 1681 Basic RAQMON PDU onto an SNMP transport. 1682 This notification is expected to be sent once per 1683 session, or when a new sub-session is initiated. 1684 The following objects MAY be carried by the 1685 raqmonDsStaticNotification: 1687 raqmonDsDataSourceDevicePort, 1688 raqmonDsReceiverDevicePort, 1689 raqmonDsSessionSetupDateTime, 1690 raqmonDsSessionSetupDelay, 1691 raqmonDsSessionDuration, 1692 raqmonDsSourcePayloadType, 1693 raqmonDsReceiverPayloadType, 1694 raqmonDsSourceLayer2Priority, 1695 raqmonDsSourceDscp, 1696 raqmonDsDestinationLayer2Priority, 1697 raqmonDsDestinationDscp 1699 It is RECOMMENDED to keep the size of a notification 1700 within the MTU size limits in order to avoid 1701 fragmentation." 1702 ::= { raqmonDsNotifications 1 } 1704 raqmonDsDynamicNotification NOTIFICATION-TYPE 1705 OBJECTS { raqmonDsTotalPacketsReceived } 1706 STATUS current 1707 DESCRIPTION 1708 "This notification maps the dynamic parameters in the 1709 Basic RAQMON PDU onto an SNMP transport. 1711 The following objects MAY be carried by the 1712 raqmonDsDynamicNotification: 1714 raqmonDsRoundTripEndToEndNetDelay, 1715 raqmonDsOneWayEndToEndNetDelay, 1716 raqmonDsApplicationDelay, 1717 raqmonDsInterArrivalJitter, 1718 raqmonDsIPPacketDelayVariation, 1719 raqmonDsTotalPacketsSent, 1720 raqmonDsTotalOctetsReceived, 1721 raqmonDsTotalOctetsSent, 1722 raqmonDsCumulativePacketLoss, 1723 raqmonDsPacketLossFraction, 1724 raqmonDsCumulativeDiscards, 1725 raqmonDsDiscardsFraction, 1726 raqmonDsCpuUtilization, 1727 raqmonDsMemoryUtilization 1729 It is RECOMMENDED to keep the size of a notification 1730 within the MTU size limits in order to avoid 1731 fragmentation." 1733 ::= { raqmonDsNotifications 2 } 1735 raqmonDsByeNotification NOTIFICATION-TYPE 1736 OBJECTS { raqmonDsAppName } 1737 STATUS current 1738 DESCRIPTION 1739 "The BYE Notification. This Notification is the equivalent 1740 of the RAQMON NULL PDU, which signals the end of a RAQMON 1741 session. 1742 " 1743 ::= { raqmonDsNotifications 3 } 1745 -- 1746 -- conformance information 1747 raqmonDsCompliance OBJECT IDENTIFIER ::= 1748 { raqmonDsConformance 1 } 1749 raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } 1751 raqmonDsBasicCompliance MODULE-COMPLIANCE 1752 STATUS current 1753 DESCRIPTION 1754 "The compliance statement for SNMP entities which 1755 implement this MIB module. 1757 There are a number of INDEX objects that cannot be 1758 represented in the form of OBJECT clauses in SMIv2, but 1759 for which we have the following compliance requirements, 1760 expressed in OBJECT clause form in this description 1761 clause: 1763 -- OBJECT raqmonDsPeerAddrType 1764 -- SYNTAX InetAddressType { ipv4(1), ipv6(2) } 1765 -- DESCRIPTION 1766 -- This MIB requires support for only global IPv4 1767 -- and IPv6 address types. 1768 -- 1769 -- OBJECT raqmonDsPeerAddr 1770 -- SYNTAX InetAddress (SIZE(4|16)) 1771 -- DESCRIPTION 1772 -- This MIB requires support for only global IPv4 1773 -- and IPv6 address types. 1774 -- 1775 " 1776 MODULE -- this module 1777 MANDATORY-GROUPS { raqmonDsNotificationGroup, 1778 raqmonDsPayloadGroup } 1779 ::= { raqmonDsCompliance 1 } 1781 raqmonDsNotificationGroup NOTIFICATION-GROUP 1782 NOTIFICATIONS { raqmonDsStaticNotification, 1783 raqmonDsDynamicNotification, 1784 raqmonDsByeNotification } 1785 STATUS current 1786 DESCRIPTION 1787 "Standard RAQMON Data Source Notification group." 1788 ::= { raqmonDsGroups 1 } 1790 raqmonDsPayloadGroup OBJECT-GROUP 1791 OBJECTS { raqmonDsAppName, 1792 raqmonDsDataSourceDevicePort, 1793 raqmonDsReceiverDevicePort, 1794 raqmonDsSessionSetupDateTime, 1795 raqmonDsSessionSetupDelay, 1796 raqmonDsSessionDuration, 1797 raqmonDsSessionSetupStatus, 1798 raqmonDsRoundTripEndToEndNetDelay, 1799 raqmonDsOneWayEndToEndNetDelay, 1800 raqmonDsApplicationDelay, 1801 raqmonDsInterArrivalJitter, 1802 raqmonDsIPPacketDelayVariation, 1803 raqmonDsTotalPacketsReceived, 1804 raqmonDsTotalPacketsSent, 1805 raqmonDsTotalOctetsReceived, 1806 raqmonDsTotalOctetsSent, 1807 raqmonDsCumulativePacketLoss, 1808 raqmonDsPacketLossFraction, 1809 raqmonDsCumulativeDiscards, 1810 raqmonDsDiscardsFraction, 1811 raqmonDsSourcePayloadType, 1812 raqmonDsReceiverPayloadType, 1813 raqmonDsSourceLayer2Priority, 1814 raqmonDsSourceDscp, 1815 raqmonDsDestinationLayer2Priority, 1816 raqmonDsDestinationDscp, 1817 raqmonDsCpuUtilization, 1818 raqmonDsMemoryUtilization } 1819 STATUS current 1820 DESCRIPTION 1821 "Standard RAQMON Data Source payload MIB objects group." 1822 ::= { raqmonDsGroups 2 } 1824 END 1826 3. IANA Considerations 1828 Applications using RAQMON Framework requires a single fixed port. 1829 Port number 7XXX is registered with IANA for use as the default port 1830 for RAQMON PDUs over TCP. Hosts that run multiple applications may 1831 use this port as an indication to have used RAQMON or provision a 1832 separate TCP port as part of provisioning RAQMON RDS and RAQMON 1833 Collector. 1835 [editor note we are requiring that 7XXX be allocated by IANA, and 1836 this note to be removed] 1838 The particular port number was chosen to lie in the range above 5000 1839 to accommodate port number allocation practice within the Unix 1840 operating system, where privileged processes can only use port 1841 numbers below 1024 and port numbers between 1024 and 5000 are 1842 automatically assigned by the operating systems. 1844 The OID assignment for the raqmonDsMIB MODULE-IDENTITY is made 1845 according to [RFC3737] and there is no need for any IANA action on 1846 this respect. 1848 4. Congestion-safe RAQMON Operation 1850 As outlined in earlier sections, TCP congestion control mechanism 1851 provides inherent congestion safety features when TCP is implemented 1852 as transport to carry RAQMON PDU. 1854 To ensure congestion safety, clearly the best thing to do is to use a 1855 congestion-safe transport protocol such as TCP. If this is not 1856 feasible, it may be necessary to fall back to UDP since SNMP over UDP 1857 is a widely deployed transport protocol. 1859 When SNMP is chosen as RAQMON PDU Transport, implementers MUST follow 1860 section 3.0 of [RAQMON-FRAMEWORK] guidelines that outlines measures 1861 that MUST be taken to use RAQMON in congestion safe manner. 1862 Congestion safety requirements in section 3.0 of [RAQMON-FRAMEWORK] 1863 would ensure that a RAQMON implementation using SNMP over UDP does 1864 not lead to congestion under heavy network load. 1866 5. Acknowledgements 1868 The authors would like to thank Bill Walker and Joseph Mastroguilio 1869 from Avaya and Bin Hu from Motorola for their discussions. The 1870 authors would also like to extend special thanks to Randy Presuhn, 1871 who reviewed this document for spelling and formatting purposes, as 1872 well as for a deep review of the technical content. We also would 1873 like to thank Bert Wijnen for the permanent coaching during the 1874 evolution of this document and the detailed review of its final 1875 versions. The Security Considerations section was reviewed by Sam 1876 Hartman and Kurt D. Zeilenga; and almost completely re-written by 1877 Mahalingam Mani. 1879 6. Security Considerations 1881 [RAQMON-FRAMEWORK] outlines a threat model associated with RAQMON and 1882 security considerations to be taken into account in the RAQMON 1883 specification to mitigate against those threats. It is imperative 1884 that RAQMON PDU implementations be able to provide the following 1885 protection mechanisms in order to attain end-to-end security: 1887 1. Authentication - the RRC SHOULD be able to verify that a RAQMON 1888 report was originated by the RDS claiming to have sent it. At 1889 minimum, an RDS/RRC pair MUST use a digest-based authentication 1890 procedure to authenticate, like the one defined in [RFC1321]. 1892 2. Privacy - RAQMON information includes identification of the 1893 parties participating in a communication session. RAQMON 1894 deployments SHOULD be able to provide protection from 1895 eavesdropping, and to prevent an unauthorized third party from 1896 gathering potentially sensitive information. This can be 1897 achieved by using secure transport protocols supporting 1898 confidentiality based on encryption technologies such as DES 1899 (Data Encryption Standard), [3DES], and AES (Advanced Encryption 1900 Standard) [AES]. 1902 3. Protection from Denial of Service attacks directed at the RRC - 1903 RDSs send RAQMON reports as a side effect of external events (for 1904 example, receipt of a phone call). An attacker can try to 1905 overwhelm the RRC (or the network) by initiating a large number 1906 of events in order to swamp the RRC with excessive numbers of 1907 RAQMON PDUs. 1909 To prevent DoS (denial-of-service) attacks against the RRC, the 1910 RDS will send the first report for a session only after the 1911 session has been established, so that the session set-up process 1912 is not affected. 1914 4. NAT and Firewall Friendly Design: the presence of IP addresses 1915 and TCP/UDP port information in RAQMON PDUs may be NAT 1916 unfriendly. Where NAT-friendliness is a requirement, the RDS MAY 1917 omit IP address information from the RAQMON PDU. Another way to 1918 avoid this problem is by using NAT-Aware Application Layer 1919 Gateways (ALGs) to ensure that correct IP addresses appear in 1920 RAQMON PDUs. 1922 For the usage of TCP, TLS MUST be used to provide transport layer 1923 security. Section 6.1 describes the usage of TLS with RAQMON. 1925 This memo also defines the RAQMON-RDS-MIB module with the purpose of 1926 mapping the RAQMON PDUs into SNMP Notifications. To attain end-to- 1927 end security the following measures have been taken in the RAQMON- 1928 RDS-MIB module design: 1930 There are no management objects defined in this MIB module that have 1931 a MAX-ACCESS clause of read-write and/or read-create. Consequently, 1932 if this MIB module is implemented correctly, there is no risk that an 1933 intruder can alter or create any management objects of this MIB 1934 module via direct SNMP SET operations. 1936 Some of the readable objects in this MIB module (i.e., objects with a 1937 MAX-ACCESS other than not-accessible) may be considered sensitive or 1938 vulnerable in some network environments. It is thus important to 1939 control even GET and/or NOTIFY access to these objects and possibly 1940 to even encrypt the values of these objects when sending them over 1941 the network via SNMP. These are the tables and objects and their 1942 sensitivity/vulnerability: 1944 raqmonDsNotificationTable 1946 The objects in this table contain user session information, and their 1947 disclosure may be sensitive in some environments. 1949 SNMP versions prior to SNMPv3 did not include adequate security. 1950 Even if the network itself is secure (for example by using IPSec), 1951 even then, there is no control as to who on the secure network is 1952 allowed to access and GET/SET (read/change/create/delete) the objects 1953 in this MIB module. 1955 It is RECOMMENDED that implementers consider the security features as 1956 provided by the SNMPv3 framework (see [RFC3410], section 8), 1957 including full support for the SNMPv3 cryptographic mechanisms (for 1958 authentication and confidentiality). 1960 It is a customer/operator responsibility to ensure that the SNMP 1961 entity giving access to an instance of this MIB module is properly 1962 configured to give access to the objects only to those principals 1963 (users) that have legitimate rights to indeed GET or SET (change/ 1964 create/delete) them. 1966 6.1. Usage of TLS with RAQMON 1968 6.1.1. Confidentiality & Message Integrity 1970 The subsequently authorized RAQMON data flow itself is protected by 1971 the same TLS security association that protects the client-side 1972 exchange. This standard TLS channel is now bound to the server 1973 through the above client-side authentication. The session itself is 1974 identified by the tuple {RDS ip-address:RDS_port / RRC ip-address: 1976 RRC port}. 1978 6.1.2. TLS CipherSuites 1980 Several issues should be considered when selecting TLS ciphersuites 1981 that are appropriate for use in a given circumstance. These issues 1982 include the following: 1984 The ciphersuite's ability to provide adequate confidentiality 1985 protection for passwords and other data sent over the transport 1986 connection. Client and server implementers should recognize that 1987 some TLS ciphersuites provide no confidentiality protection while 1988 other ciphersuites that do provide confidentiality protection may be 1989 vulnerable to being cracked using brute force methods, especially in 1990 light of ever-increasing CPU speeds that reduce the time needed to 1991 successfully mount such attacks. 1993 Client and server implementers should carefully consider the value of 1994 the password or data being protected versus the level of 1995 confidentiality protection provided by the ciphersuite to ensure that 1996 the level of protection afforded by the ciphersuite is appropriate. 1998 The ciphersuite's vulnerability (or lack thereof) to man-in-the- 1999 middle attacks. Ciphersuites vulnerable to man-in-the-middle attacks 2000 SHOULD NOT be used to protect passwords or sensitive data, unless the 2001 network configuration is such that the danger of a man-in-the-middle 2002 attack is negligible. 2004 After a TLS negotiation (either initial or subsequent) is completed, 2005 both protocol peers should independently verify that the security 2006 services provided by the negotiated ciphersuite are adequate for the 2007 intended use of the RAQMON session. If not, the TLS layer should be 2008 closed. 2010 Spoofing Attacks: When anonymous TLS alone is negotiated without 2011 client authentication, client's identity is never established. This 2012 easily allows any end-entity to establish a TLS-secured RAQMON 2013 connection to the RRC. Not only does this offer an opportunity to 2014 spoof legitimate RDS clients and hence compromise the integrity of 2015 RRC monitoring data but also opens the RRC up to unauthorized clients 2016 posing as genuine RDS entities to launch a DoS by flooding data. 2017 RAQMON deployment policy MUST consider requiring RDS client 2018 authentication during TLS session establishment - especially when RDS 2019 clients communicate across unprotected internet. 2021 Insider attacks: Even client-authenticated TLS connections is open to 2022 spoofing attacks by one trusted client on another. Validation of RDS 2023 source address against RDS TLS-session source address SHOULD be 2024 performed to detect such attempts. 2026 6.1.3. RAQMON Authorization State 2028 Every RAQMON session (between RDS and RRC) has an associated 2029 authorization state. This state is comprised of numerous factors 2030 such as what (if any) authorization state has been established, how 2031 it was established, and what security services are in place. Some 2032 factors may be determined and/or affected by protocol events (e.g., 2033 StartTLS, or TLS closure), and some factors may be determined by 2034 external events (e.g., time of day or server load). 2036 While it is often convenient to view authorization state in 2037 simplistic terms (as we often do in this technical specification) 2038 such as "an anonymous state", it is noted that authorization systems 2039 in RAQMON implementations commonly involve many factors which 2040 interrelate. 2042 Authorization in RAQMON is a local matter. One of the key factors in 2043 making authorization decisions is authorization identity. The 2044 initial session establishment defined in Section 2.2 allows 2045 information to be exchanged between the client and server to 2046 establish an authorization identity for the RAQMON session. The RRC 2047 is not to allow any RDS transactions-related traffic through for 2048 processing until the client authentication is complete unless 2049 anonymous authentication mode is negotiated. 2051 Upon initial establishment of the RAQMON session, the session has an 2052 anonymous authorization identity. Among other things this implies 2053 that the client need not send a TLSStartRequired in the first PDU of 2054 the RAQMON message. The client may send any operation request prior 2055 to binding RDS to any authentication, and the RRC MUST treat it as if 2056 it had been performed after an anonymous RAQMON session start. 2058 The RDS automatically is placed in an unauthorized state upon RRC 2059 sending a TLSstart request to the RRC. 2061 It is noted that other events both internal and external to RAQMON 2062 may result in the authentication and authorization states being moved 2063 to an anonymous one. For instance, the establishment, change or 2064 closure of data security services may result in a move to an 2065 anonymous state, or the user's credential information (e.g., 2066 certificate) may have expired. The former is an example of an event 2067 internal to RAQMON whereas the latter is an example of an event 2068 external to RAQMON. 2070 7. References 2072 7.1. Normative References 2074 [RAQMON-FRAMEWORK] 2075 Siddiqui, A., Romascanu, D., and E. Golovinsky, "Framework 2076 for Real-time Application Quality of Service Monitoring 2077 (RAQMON)", draft-ietf-raqmon-framework-15.txt (work in 2078 progress), february 2006. 2080 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 2081 Requirement Levels", BCP 14, RFC 2119, March 1997. 2083 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 2084 Rose, M., and S. Waldbusser, "Structure of Management 2085 Information Version 2 (SMIv2)", STD 58, RFC 2578, 2086 April 1999. 2088 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 2089 Rose, M., and S. Waldbusser, "Textual Conventions for 2090 SMIv2", STD 58, RFC 2579, April 1999. 2092 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 2093 Rose, M., and S. Waldbusser, "Conformance Statements for 2094 SMIv2", STD 58, RFC 2580, April 1999. 2096 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 2097 Information Base", STD 59, RFC 2819, May 2000. 2099 [RFC3289] Baker, F., Chan, K., and A. Smith, "Management Information 2100 Base for the Differentiated Services Architecture", 2101 RFC 3289, May 2002. 2103 [RFC3411] Harrington, D., Preshun, R., and B. Wijnen, "An 2104 Architecture for Describing Simple Network Management 2105 Protocol (SNMP) Management Frameworks", STD 62, RFC 3411, 2106 December 2002. 2108 [RFC4001] Daniele, M., Haberman, B., Routhier, S., and J. 2109 Schoenwalder, "Textual Conventions for Internet Network 2110 Addresses", RFC 4001, February 2005. 2112 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, 2113 September 1981. 2115 [RFC793] Postel, J., "Transmission Control Protocol", STD 7, 2116 RFC 793, September 1981. 2118 [TLS] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", 2119 RFC 2246, January 1999. 2121 7.2. Informative References 2123 [3DES] Americation National Standards Institute, "Triple Data 2124 Encryption Algorithm Modes of Operation", ANSI X9.52-1998. 2126 [AES] Federal Information Processing Standard (FIPS), 2127 "Specifications for the ADVANCED ENCRYPTION 2128 STANDARD(AES)", Publication 197, November 2001. 2130 [IEEE802.1D] 2131 "Information technology-Telecommunications and information 2132 exchange between systems--Local and metropolitan area 2133 networks-Common Specification a--Media access control 2134 (MAC) bridges:15802-3: 1998(ISO/IEC)", [ANSI/IEEE 2135 Std 802.1D Edition], 1998. 2137 [LDAP-TLS] 2138 Hodges, J. and R. Morgan, "Lightweight Directory Access 2139 Protocol (v3): Extension for Transport Layer Security", 2140 RFC 2830, May 2000. 2142 [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, 2143 March 1992. 2145 [RFC1321] Rivest, R., "Message Digest Algorithm MD5", RFC 1321, 2146 April 1992. 2148 [RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart, 2149 "Introduction and Applicability Statements for Internet- 2150 Standard Management Framework", RFC 3410, December 2002. 2152 [RFC3414] Blumenthal, U. and B. Wijnen, "User-based Security Model 2153 (USM) for version 3 of the Simple Network Management 2154 Protocol (SNMPv3)", RFC 3414, December 2002. 2156 [RFC3550] Schulzrinne, H., Casner, S., Frederick, R., and V. 2157 Jacobson, "RTP: A Transport Protocol for Real-Time 2158 Applications", RFC 3550, July 2003. 2160 [RFC3551] Schulzrinne, H. and S. Casner, "RTP Profile for Audio and 2161 Video Conferences with Minimal Control", STD 65, RFC 3551, 2162 July 2003. 2164 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 2165 10646", STD 63, RFC 3629, November 2003. 2167 [RFC3737] Wijnen, B. and A. Bierman, "IANA Guidelines for the 2168 Registry of Remote Monitoring (RMON) MIB modules", 2169 RFC 3737, April 2004. 2171 [TLS-PSK] Eronen, P. and H. Tschofenig, "Pre-Shared Key Ciphersuites 2172 for Transport Layer Security (TLS)", RFC 4279, 2173 December 2005. 2175 Appendix A. Pseudo-code 2177 The implementation notes included in Appendix are for informational 2178 purposes only and are meant to clarify the RAQMON specification. 2180 Pseudo code for RDS & RRC 2182 We provide examples of Psuedo code for aspects of RDS and RRC. There 2183 may be other implementation methods that are faster in particular 2184 operating environments or have other advantages. 2186 RDS: 2187 when (session starts} { 2188 report.identifier = session.endpoints, session.starttime; 2189 report.timestamp = 0; 2190 while (session in progress) { 2191 wait interval; 2192 report.statistics = update statistics; 2193 report.curtimestamp += interval; 2194 if encryption required 2195 report_data = encrypt(report, encrypt parameters); 2196 else 2197 report_data = report; 2198 raqmon_pdu = header, report_data; 2199 send raqmon-pdu; 2200 } 2201 } 2203 RRC: 2204 listen on raqmon port 2205 when ( raqmon_pdu received ) { 2206 decrypt raqmon_pdu.data if needed 2208 if report.identifier in database 2209 if report.current_time_stamp > last update 2210 update session statistics from report.statistics 2211 else 2212 discard report 2213 } 2215 Authors' Addresses 2217 Anwar Siddiqui 2218 Avaya Labs 2219 307 Middletown Lincroft Road 2220 Lincroft, NJ 80302 2221 USA 2223 Phone: +1 732 852-3200 2224 Email: anwars@avaya.com 2226 Dan Romascanu 2227 Avaya Inc. 2228 Atidim Technology Park, Bldg #3 2229 Tel Aviv, 61131 2230 Israel 2232 Phone: +972-3-645-8414 2233 Email: dromasca@avaya.com 2235 Eugene Golovinsky 2236 BMC Software 2237 2101 Citywest Blvd 2238 Houston, TX 77042 2239 USA 2241 Phone: +1 713 918-1816 2242 Email: eugene_golovinsky@bmc.com 2244 Mahfuzur Rahman 2245 Samsung Information Systems America 2246 75 West Plumeria Drive 2247 San Jose, CA 95134 2248 USA 2250 Phone: +1 408 544-5559 2251 Email: 2253 Yongbum Yong Kim 2254 Broadcom 2255 3151 Zanker Road 2256 San Jose, CA 95134 2257 USA 2259 Phone: +1 408 501-7800 2260 Email: ybkim@broadcom.com 2262 Intellectual Property Statement 2264 The IETF takes no position regarding the validity or scope of any 2265 Intellectual Property Rights or other rights that might be claimed to 2266 pertain to the implementation or use of the technology described in 2267 this document or the extent to which any license under such rights 2268 might or might not be available; nor does it represent that it has 2269 made any independent effort to identify any such rights. Information 2270 on the procedures with respect to rights in RFC documents can be 2271 found in BCP 78 and BCP 79. 2273 Copies of IPR disclosures made to the IETF Secretariat and any 2274 assurances of licenses to be made available, or the result of an 2275 attempt made to obtain a general license or permission for the use of 2276 such proprietary rights by implementers or users of this 2277 specification can be obtained from the IETF on-line IPR repository at 2278 http://www.ietf.org/ipr. 2280 The IETF invites any interested party to bring to its attention any 2281 copyrights, patents or patent applications, or other proprietary 2282 rights that may cover technology that may be required to implement 2283 this standard. Please address the information to the IETF at 2284 ietf-ipr@ietf.org. 2286 Disclaimer of Validity 2288 This document and the information contained herein are provided on an 2289 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 2290 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 2291 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 2292 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 2293 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 2294 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 2296 Copyright Statement 2298 Copyright (C) The Internet Society (2006). This document is subject 2299 to the rights, licenses and restrictions contained in BCP 78, and 2300 except as set forth therein, the authors retain all their rights. 2302 Acknowledgment 2304 Funding for the RFC Editor function is currently provided by the 2305 Internet Society.