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