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