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