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