idnits 2.17.1 draft-ietf-rmonmib-raqmon-pdu-05.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** 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 current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 35 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 36 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 104 instances of too long lines in the document, the longest one being 489 characters in excess of 72. == 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 == Line 1153 has weird spacing: '... by the recei...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: A value of ALL zeros is considered to be valid as it constitutes a NULL sub-session (i.e. nothing to report within sub-session RC_N). A RDS MUST send a NULL sub-session (i.e. RPPF = 0) to a RRC to indicate that reporting on a particular sub-session has ended. RRCs MUST not treat a NULL sub-session as end of a reporting session; rather an explicit Record Count = 0 is used to indicate end of a reporting session for a given DSRC. == The expression 'MAY NOT', while looking like RFC 2119 requirements text, is not defined in RFC 2119, and should not be used. Consider using 'MUST NOT' instead (if that is what you mean). Found 'MAY NOT' in this paragraph: + Since RDSs are not computationally rich and to keep the RDS realization lightweight, it is not required that RDSs fully implement an SNMP-based Internet Management framework. Specifically RDSs MAY NOT respond to SNMP requests like GET, SET, etc., as an SNMP compliant responder would. -- 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 (9 February 2004) is 7354 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: 'RFC3550' is mentioned on line 718, but not defined == Missing Reference: 'RFC 3291' is mentioned on line 385, but not defined ** Obsolete undefined reference: RFC 3291 (Obsoleted by RFC 4001) == Missing Reference: 'RFC 1305' is mentioned on line 457, but not defined ** Obsolete undefined reference: RFC 1305 (Obsoleted by RFC 5905) == Missing Reference: 'RFC 1890' is mentioned on line 546, but not defined ** Obsolete undefined reference: RFC 1890 (Obsoleted by RFC 3551) == Missing Reference: 'RAQMON FRAMEWORK' is mentioned on line 1215, but not defined == Unused Reference: 'RFC1890' is defined on line 1419, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 1422, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1425, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1428, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1431, but no explicit reference was found in the text == Unused Reference: 'RFC1597' is defined on line 1434, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 1438, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1441, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1444, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1D' is defined on line 1455, but no explicit reference was found in the text == Unused Reference: 'RFC1349' is defined on line 1461, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 1464, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1467, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 1471, but no explicit reference was found in the text -- No information found for draft-ietf-raqmon-framework - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RAQMON-FRAMEWORK' -- Obsolete informational reference (is this intentional?): RFC 1890 (Obsoleted by RFC 3551) -- 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) Summary: 9 errors (**), 0 flaws (~~), 27 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Anwar Siddiqui 3 Avaya Inc. 4 Dan Romascanu 5 Avaya 6 Eugene Golovinsky 7 BMC Software 8 9 February 2004 10 Real-time Application Quality of Service Monitoring (RAQMON) 11 Protocol Data Unit (PDU) 13 15 Status of this Memo 17 This document is an Internet-Draft and is in full conformance with 18 all provisions of Section 10 of RFC2026. Internet-Drafts are working 19 documents of the Internet Engineering Task Force (IETF), its areas, 20 and its working groups. Note that other groups may also distribute 21 working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet- Drafts as reference 26 material or to cite them other than as "work in progress." 28 To view the list Internet-Draft Shadow Directories, see 29 http://www.ietf.org/shadow.html. 31 Copyright Notice 33 Copyright (C) The Internet Society (2004). All Rights Reserved. 35 Abstract 37 This memo defines a common protocol data unit (PDU) used between a 38 Real-Time Application QoS Monitoring (RAQMON) Data Source (RDS) and a 39 RAQMON Report Collector (RRC) to report application level Quality of 40 Service (QOS) statistics which allows to monitoring of end devices 41 such as IP phones, pagers, Instant Messaging clients, mobile phones, 42 and various other hand-held computing devices within the Remote 43 Monitoring (RMON) family of specifications. 45 This memo also outlines mechanisms to use the Real Time Transport 46 Control Protocol (RTCP) and the Simple Network Management Protocol 47 (SNMP) to transport these PDUs between the RAQMON Data Source (RDS) 48 and the RAQMON Report Collector (RRC). 50 Distribution of this memo is unlimited. 52 Table of Contents 54 Status of this Memo 1 55 Abstract 1 56 1 Introduction 2 57 2 RAQMON PDU Format 3 58 3 Transporting RAQMON Protocol Data Units 15 59 4 Congestion Safe RAQMON Operation 29 60 5 Normative References 29 61 6 Informative References 30 62 7 Intellectual Property 31 63 8 Appendix 32 64 9 Security Considerations 33 65 10 IANA Considerations 34 66 11 Authors' Addresses 34 67 A Full Copyright Statement 35 69 1. Introduction 71 There is a need to add mechanisms within RMON [RFC2819] family of 72 specifications to monitor end devices such as IP phones, pagers, 73 Instant Messaging clients, mobile phones, and various other hand-held 74 computing devices. The Real-Time Application QoS Monitoring (RAQMON) 75 Framework as outlined by [RAQMON-FRAMEWORK] extends RMON by defining 76 entities such as RAQMON Data Source (RDS) and RAQMON Report Collector 77 (RRC) to perform various application monitoring in real time. This 78 memo defines a common protocol data unit (PDU) used between a RDS and 79 RRC to report QoS statistics. This memo contains a syntactical 80 description of the RAQMON PDU structure and of the usage of RTCP and 81 SNMP as underlying transport protocols to carry RAQMON PDUs. Either 82 RTCP or SNMP can be used to carry RAQMON PDUs between RDSs and RRCs. 84 The RAQMON Protocol Data Unit (PDU) utilizes a common data format 85 understood by the RDS and the RRC. A RAQMON PDU does not transport 86 application data but rather occupies the place of a payload 87 specification at the application layer of the protocol stack. 88 Mechanisms outlined in this draft can be used by many real-time and 89 non-real-time applications managed within the RMON family of 90 specifications which allows network appliances to report application 91 level QoS parameters in real time. Voice over IP, Fax over IP, Video 92 over IP, Instant Messaging (IM), Email, software download 93 applications, e-business style transactions, web access from 94 computing devices are a few examples of applications that can 95 potentially use the RAQMON Framework for monitoring purposes. 97 Though transmitted as one Protocol Data Unit, a RAQMON PDU is 98 functionally divided into two different parts, namely the basic part 99 and the application extensions required for vendor specific 100 extensions. Both functional parts trail SMI Network Management 101 Private Enterprise Codes that are currently maintained by IANA at 102 http://www.iana.org/assignments/enterprise-numbers. 104 The Basic Part of RAQMON PDU: The basic part of the RAQMON PDU trails 105 the SMI Network Management Private Enterprise Code 0 - reserved by 106 convention for use by the IETF RMON Working Group. The RAQMON PDU 107 basic part offers an entry-type (a.k.a. "Name") from a pre-defined 108 list of QoS parameters defined in table 1 and allows applications to 109 fill in appropriate values for those parameters. Application 110 developers also have the flexibility to report only a sub-set of the 111 parameters listed in table 1 as discussed in later sections. 113 The Application Part of RAQMON PDU: Application and vendor specific 114 extensibility of RAQMON PDU is provided by the application part of 115 the RAQMON PDU to convey application-, vendor-, and device- specific 116 parameters for future use. Additional parameters can be defined by 117 application developers within the payload of the APP part of the PDU 118 as Type Length Value (TLV) tuples. The Application part of the RAQMON 119 PDU trails behind the SMI Network Management Private Enterprise Codes 120 of the vendor found in http://www.iana.org/assignments/enterprise- 121 numbers. Such application-specific extensions should be maintained 122 and published by the application vendor. RAQMON PDUs are also capable 123 of carrying multiple application parts within a PDU that trails 124 multiple SMI Network Management Private Enterprise Codes of the 125 vendor. 127 Though RDS and RRC are designed to be stateless for RAQMON reporting 128 sessions, the framework requires a graceful termination of reporting 129 sessions between RDSs and RRCs. Such functionality is achieved by 130 NULL PDUs as defined within the RAQMON Framework [RAQMON-FRAMEWORK]. 131 A syntactical specification of the NULL PDUs is available in section 132 2 of this memo. 134 The following sections of this memo contain detailed RAQMON PDU 135 specifications and usage of RTCP and SNMP to carry a RAQMON PDU. 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in [RFC2119]. 141 2. RAQMON PDU Format 142 Parameters carried by RAQMON PDUs and their usages are defined in 143 Section 5 of [RAQMON-FRAMEWORK] by reference to existing IETF, ITU 144 and other standards organizations' documents. 146 The RAQMON PDU format specified in this memo provides syntax and 147 structure within a RAQMON PDU to report those parameters. A RAQMON 148 PDU in the current version is marked as PDU Type (PDT) = 1. 150 Vendors SHOULD use the basic part of the PDU to report statistics 151 pre-listed here in the specification, which will ensure basic 152 interoperability between multiple vendor and application developers. 153 Vendors SHOULD also use application specific extension to convey 154 application-, vendor-, device- etc. specific parameters not included 155 in the basic part of the specification and publish such data 156 externally to attain extended interoperability. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | DSRC | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | SMI Enterprise Code = 0 | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | V | RT = 0 | RC |I|P| Length | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 | RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Data Source Address {DA} | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Receiver's Address (RA) | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 | NTP Timestamp, most significant word | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | NTP Timestamp, least significant word | 176 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 177 | Length | Application Name (AN) ... | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 179 | ... | 180 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 181 | Length | Data Source Name (DN) ... | 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 | ... | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Length | Receiver's Name (RN) ... | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | ... | 188 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 189 | Length | Session State ... | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | ... | 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | Session Duration | 194 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 195 | Round Trip End-to-End Delay | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 197 | One Way End-to-End Delay | 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 | Cumulative Packet Loss | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | Total # Packets sent | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 | Total # Packets received | 204 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 205 | Total # Octets sent | 206 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 207 | Total # Octets received | 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | Source Port Used | Receiver Port Used | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |Source Payload |Reciver Payload| CPU | Memory | 214 |Type | Type | Utilization | Utilization | 215 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 216 | Session Setup Delay |j| Jitter | 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Padding | Packet loss | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | SMI Enterprise Code = "xxx" | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Report Type = "yyy" | Length of Application Part | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | application/vendor specific extension | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | ............ | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | ............... | 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | ............... | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | SMI Enterprise Code = "abc" | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Report Type = "zzz" | Length of Application Part | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | application/vendor specific extension | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | ............ | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Figure 1 - RAQMON Protocol Data Unit 243 DSRC: 32 bits - The data source identifier represents a unique RAQMON 244 reporting session descriptor that points to a specific reporting 245 session between the RDS and the RRC. The uniqueness of DSRC is valid 246 only within a reporting session between a RDS and RRC pair. DSRC 247 values should be randomly generated using vendor chosen algorithms 248 for each communication session. It is not sufficient to obtain a DSRC 249 simply by calling random() without carefully initializing the state. 250 One could use an algorithm like the one defined in Appendix A.6 in 251 [RFC3550] to create a DSRC. Depending on the choice of algorithm, 252 there is a finite probability that two DSRCs from two different RDSs 253 may be the same. To further reduce the probability that two RDSs pick 254 the same DSRC for two different reporting sessions, it is recommended 255 that an RRC use parameters like Data Source Address (DA), Data Source 256 Name (DN), and MAC Address in the PDU in conjunction with a DSRC 257 value. It is not mandatory for RDSs to send parameters like Data 258 Source Address (DA), Data Source Name (DN), MAC Address in every PDU 259 sent to an RRC, but sending these parameters occasionally will reduce 260 the probability of DSRC collision drastically. 262 2.1 The basic part of RAQMON Protocol Data Unit: 264 SMI Enterprise Code: 32 bits. A value of SMI Enterprise Code = 0 is 265 used to indicate the RMON WG compliant basic part of the RAQMON PDU 266 format. The basic part of the RAQMON PDU must trail behind the SMI 267 Enterprise Code = 0 to ensure interoperability. 269 version (V) : 2 bits - Identifies the version of RAQMON Basic Part 270 that follows SMI Enterprise Code = 0. The number of this version is 271 1. 273 Report Type(RT): 8 bits - Reserved by the RMON WG to define 274 appropriate Report type within RMON SMI Enterprise Code = 0. The 275 number of this report type is 0. 277 record count (RC): 4 bits - The total number of records contained in 278 the basic part of the PDU which reflects a sub-session within a 279 communication session. A value of zero is considered to be valid as 280 it constitutes a NULL PDU. 282 IP version (I): 1 bit - While set to 1, IP Version Flag indicates 283 that IP addresses contained in the PDU are IP version 6 compatible. A 284 value of 0 indicates that IP addresses contained in the PDU are IP 285 version 4 compatible. 287 padding (P): 1 bit - If the padding bit is set, the basic part of the 288 RAQMON PDU contains some additional padding octets at the end of the 289 basic part of the PDU which are not part of the monitoring 290 information as padding may be needed by some applications because 291 reporting is based on the intent of RDS to report certain parameters. 292 Also some parameters may be reported only once at the beginning of 293 the reporting session, e.g. Data Source Name, Receiver Name, Pay Load 294 type etc. Actual padding at the end of the Basic part of the PDU is 295 either 0,8, 16 or 24 bits to make the basic part of the PDU a 296 multiple of 32 bits long. 298 length: 16 bits - The length of the basic part of the RAQMON PDU in 299 32-bit words minus one which includes the header and any padding. 301 A RAQMON PDU MUST contain DSRC, SMI Enterprise Code = 0, V, RT, RC, 302 I, P and Length fields at all times. A value of zero for Record Count 303 (RC) constitutes a RAQMON NULL PDU (i.e. nothing to report). RDSs 304 MUST send a RAQMON NULL PDU to RRC to indicate the end of reporting 305 session for a given DSRC. All other header parameters listed in the 306 PDU described below are optionally used when RDSs have some 307 information to send to RRCs. 309 0 1 2 3 310 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 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | DSRC | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | SMI Enterprise Code = 0 | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 | V | RT = 0 | RC |I|P| Length | 317 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 318 | RC_N | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 319 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 321 Figure 2 - RAQMON Parameter Presence Flag in RAQMON PDU 323 The basic part of each RAQMON PDU that trails behind SMI Enterprise 324 Code = 0 consists of a Record Count Number (RC_N) and RAQMON 325 Parameter Presence Flags (RPPF) to indicate the presence of 326 appropriate RAQMON parameters within a record as defined in table 1. 328 RC_N: 4 bits - Record Count Number to which the information in this 329 record pertains. Since a report from a RDS to a RRC may contain 330 information about sub-sessions within a communication session (e.g. a 331 Multimedia Call), Record Count Number (RC_N) serves as a sub-session 332 index within a reporting session for a given DSRC. A value of zero is 333 a valid record number. The maximum number of records that can be 334 described in one RAQMON Packet is 16 (i.e. 0000 - 1111). 336 RAQMON Parameter Presence Flags (RPPF): 28 bits 338 Each of these flags while set means that sub-session RC_N contains 339 corresponding parameters as specified in table 1 within a sub- 340 session. 342 A value of ALL zeros is considered to be valid as it constitutes a 343 NULL sub-session (i.e. nothing to report within sub-session RC_N). A 344 RDS MUST send a NULL sub-session (i.e. RPPF = 0) to a RRC to indicate 345 that reporting on a particular sub-session has ended. RRCs MUST not 346 treat a NULL sub-session as end of a reporting session; rather an 347 explicit Record Count = 0 is used to indicate end of a reporting 348 session for a given DSRC. 350 Sequence Number Presence/Absence of corresponding 351 Parameter within this RAQMON PDU 353 1 Data Source Address (DA) 354 2 Receiver Address (RA) 355 3 NTP Timestamp 356 4 Application Name 357 5 Data Source Name (DN) 358 6 Receiver Name (RN) 359 7 Session Setup Status 360 8 Session Duration 361 9 End-to-End Delay (RTT) 362 0 End-to-End Delay (OWD) 363 1 Cumulative Packet Loss 364 2 Total number of Packets sent 365 3 Total number of Packets received 366 4 Total number of Octets sent 367 5 Total number of Octets received 368 6 Source Port Used 369 7 Receiver Port Used 370 8 S_Layer2 371 9 S_Layer3 372 0 D_Layer2 373 1 D_Layer3 374 2 Source Payload Type 375 3 Receiver Payload Type 376 4 CPU Utilization 377 5 Memory Utilization 378 6 Session Setup Delay 379 7 Jitter 380 8 Packet loss (in fraction) 382 Table 1: RAQMON Parameters and corresponding RPPF 384 Data Source Address (DA): 32 bits or 160 bits - This metrics is 385 defined in section 5.1 of [RAQMON-FRAMEWORK]. The standard [RFC 3291] 386 octet string representation is used to represent the end device's 387 numeric address on the interface used for the communication session. 388 The standard representation of an IP Version 4 address is "dotted 389 decimal", also known as dotted quad. 135.8.45.178 is an example of a 390 valid Data Source Address. IP version 6 addresses are incorporated in 391 Data Source Address by setting the IP version flag (I bit) of the 392 RAQMON PDU header to 1. Since the Data Source Address is expected to 393 remain constant during the entire reporting session, applications 394 should avoid sending these parameters too often to ensure efficient 395 usage of network resources. 397 Receiver Address (RA): 32 bits or 160 bits - This metrics is defined 398 in section 5.2 of [RAQMON-FRAMEWORK]. It follows the exact same 399 syntax as Data Source Address but is used to indicate a receiver's 400 address. Since the Receiver Address is expected to remain constant 401 during entire reporting sessions, applications should avoid sending 402 these parameters too often to ensure efficient usage of network 403 resources. 405 Data Source Name (DN): - This metrics is defined in section 5.3 of 406 [RAQMON-FRAMEWORK]. The Data Source Name field starts with an 8-bit 407 octet count describing the length of the text and the text itself. 408 Note that the text can be no longer than 255 octets. The text is 409 encoded according to the UTF-2 encoding specified in Annex F of ISO 410 standard 10646 [ISO10646], [UNICODE]. This encoding is also known as 411 UTF-8 or UTF-FSS. It is described in "File System Safe UCS 412 Transformation Format (FSS_UTF)", X/Open Preliminary Specification, 413 Document Number P316 and Unicode Technical Report #4. US-ASCII is a 414 subset of this encoding and requires no additional encoding. The 415 presence of multi-octet encoding is indicated by setting the most 416 significant bit of a character to a value of one. Text is not null- 417 terminated because some multi-octet encoding include null octets. 418 Data Source Name is terminated by one or more null octets, the first 419 of which is interpreted to denote the end of the string and the 420 remainder as needed to pad until the next 32-bit boundary. 421 Applications SHOULD instruct a RDS to send out parameters not too 422 frequently to ensure efficient usage of network resources as this 423 parameter is expected to remain constant for the duration of the 424 reporting session. 426 Receiver Name (RN): - This metrics is defined in section 5.4 of 427 [RAQMON-FRAMEWORK]. Like Data Source Name, the Receiver Name field 428 starts with an 8-bit octet count describing the length of the text 429 and the text itself. The Receiver Name is multiple of 32 bits. It 430 follows the same padding rules that apply to Data Source Name. As 431 Data Source Name and Receiver Name are contiguous, items are not 432 individually padded to a 32-bit boundary. Since the Receiver name is 433 expected to remain constant during entire reporting sessions, this 434 information SHOULD be sent out occasionally over random time 435 intervals to maximize the chances of reaching a RRC and also conserve 436 network bandwidth. 438 Source Port Used: 16 bits - This metrics is defined in section 5.5 of 439 [RAQMON-FRAMEWORK] and describes the port number used by the Data 440 Source as used by the application in the RC_N session while this 441 RAQMON PDU was generated. Since sometimes the Source Port Used will 442 remain constant during entire reporting sessions, applications in 443 that case SHOULD avoid sending these parameters too often to ensure 444 an efficient usage of network resources. 446 Receiver Port Used: 16 bits - This metrics is defined in section 5.6 447 of [RAQMON-FRAMEWORK] and describes the receiver port used by the 448 application to communicate to the receiver. It follows same syntax as 449 Source Port Used. Since sometimes the Receiver Port Used will remain 450 constant during entire reporting sessions, applications in that case 451 SHOULD avoid sending these parameters too often to ensure an 452 efficient usage of network resources. 454 Session Setup Date/Time (NTP timestamp): 64 bits - This metrics is 455 defined in section 5.7 of [RAQMON-FRAMEWORK] and is represented using 456 the timestamp format of the Network Time Protocol (NTP), which is in 457 seconds [RFC 1305]. The full resolution NTP timestamp is a 64-bit 458 unsigned fixed-point number with the integer part in the first 32 459 bits and the fractional part in the last 32 bits. In some fields 460 where a more compact representation is appropriate, only the middle 461 32 bits are used; that is, the low 16 bits of the integer part and 462 the high 16 bits of the fractional part. The high 16 bits of the 463 integer part MUST be determined independently. 465 A Data Source that has no notion of wallclock or time SHOULD set the 466 appropriate RAQMON flag to 0 to avoid wasting 64 bits in the PDU. 467 Since the NTP time stamp is intended to provide Date/Time of a 468 session, it is RECOMMENDED that the NTP time stamp be used only in 469 the first RAQMON pdu in order to use network resources efficiently. 470 However such a recommendation is context sensitive and should be 471 enforced as deemed necessary by each application environment. 473 Session Setup Delay: 16 bits - Session Setup Delay metrics is defined 474 in section 5.8 of [RAQMON-FRAMEWORK] and is expressed in 475 milliseconds. 477 Session Duration: 32 bits - Session Setup Delay metrics is defined in 478 section 5.9 of [RAQMON-FRAMEWORK]. Session Duration from sub-session 479 RC_N is an unsigned integer expressed in seconds. 481 Session Setup Status: - Session Setup Status is defined in section 482 5.10 of [RAQMON-FRAMEWORK]. This field starts with an 8-bit octet 483 count describing the length of the text and the text itself. Session 484 Setup Status is a multiple of 32 bits. Since the Session Setup Status 485 is expected to remain constant during entire reporting sessions, 486 applications SHOULD avoid sending these parameters too often to 487 ensure an efficient usage of network resources. 489 Round Trip End-to-End Delay: 32 bits - Round Trip End-to-End Delay is 490 defined in section 5.11 of [RAQMON-FRAMEWORK]. This field represents 491 the Round Trip End-to-End Delay of sub-session RC_N, which is an 492 unsigned integer, expressed in the order of milliseconds. 494 One Way End-to-End Delay: 32 bits - One Way End-to-End Delay is 495 defined in section 5.12 of [RAQMON-FRAMEWORK]. This field represents 496 the One Way End-to-End Delay of sub session RC_N, which is an 497 unsigned Integer, expressed in the order of milliseconds. 499 Jitter: 16 bits - Jitter is defined in section 5.13 of [RAQMON- 500 FRAMEWORK] and is expressed in milliseconds. Out of 16 bits, the 501 first 15 bits represent the value of jitter measured in the RDS. The 502 16th bit within the jitter field otherwise known as the j bit, while 503 set to 0 indicates that the jitter measurement within a PDU reflects 504 Inter-Arrival Jitter, and while set to 1 indicates that the jitter 505 measurement within a PDU reflects Absolute Jitter. 507 Total number of application packets received: 32 bits - This 508 parameter is defined in section 5.14 of [RAQMON-FRAMEWORK] as an 509 unsigned integer representing the total number of packets received 510 within sub session RC_N by the receiver. 512 Total number of application packets sent: 32 bits - This parameter is 513 defined in section 5.15 of [RAQMON-FRAMEWORK] as an unsigned integer 514 representing the total number of packets transmitted within sub 515 session RC_N by the sender. 517 Total number of application octets received: 32 bits - This parameter 518 is defined in section 5.16 of [RAQMON-FRAMEWORK] as an unsigned 519 integer representing total number of payload octets (i.e., not 520 including header or padding) received in packets by the receiver 521 within sub session RC_N. 523 Total number of application octets sent: 32 bits - This parameter is 524 defined in section 5.17 of [RAQMON-FRAMEWORK] as an unsigned integer 525 representing total number of payload octets (i.e., not including 526 header or padding) transmitted in packets by the sender within sub 527 session RC_N. 529 Cumulative application packet Loss: 32 bits - This parameter is 530 defined in section 5.18 of [RAQMON-FRAMEWORK] as an unsigned integer 531 representing the total number of packets that has been lost from the 532 beginning of sub-session RC_N till this RAQMON PDU was generated. 533 This counter reflects cumulative packet loss within a sub-session 534 RC_N. 536 Packet Loss in Fraction: 8 bits - This parameter is defined in 537 section 5.19 of [RAQMON-FRAMEWORK] expressed as a fixed point number 538 with the binary point at the left edge of the field. (That is 539 equivalent to taking the integer part after multiplying the loss 540 fraction by 256.) This metrics is defined to be the number of 541 packets lost divided by the number of packets expected. 543 Source Payload Type: 8 bit - This parameter is defined in section 544 5.20 of [RAQMON-FRAMEWORK]. It is an 8-bit field that specifies the 545 payload type of the data source of communication in sub session RC_N 546 as defined in [RFC 1890]. Since the Source Payload type does not vary 547 frequently during reporting sessions, applications SHOULD avoid 548 sending these parameters within RAQMON PDUs too often to ensure an 549 efficient usage of network resources. However applications such as 550 Voice over IP or Video over IP may go through various application 551 states as users activate features payload types may change. Example 552 of such scenario may include but not limited to call transferred to 553 another party, joining a conference bridge or even changing network 554 condition (i.e. a VoIP phone call using 64 kbps G.711 codec may have 555 to fall back to 8kbps G.729a codec as network bandwidth just became 556 scarce) etc. Changes in source payload type driven by various 557 application state MUST be reported within a RAQMON PDU. 559 Receiver Payload Type: 8 bit - This parameter is defined in section 560 5.21 of [RAQMON-FRAMEWORK]. This 8-bit field specifies receiver 561 payload type of communication sub session RC_N. Since the Receiver 562 Payload type does not vary frequently during reporting sessions, 563 applications SHOULD avoid sending these parameters within RAQMON PDU 564 too often to ensure an efficient usage of network resources. Changes 565 in receiver payload type driven by various application state as 566 described in earlier paragraph MUST be reported within a RAQMON PDU. 568 S_Layer2: 8 bits - This parameter defined in section 5.22 of [RAQMON- 569 FRAMEWORK] is an 8-bit field associated to the source's value of the 570 IEEE 802.1Q tag priority field in sub session RC_N. Since the 571 priority value is 3 bits, the first 3 bits of this parameter 572 represents priority value and the last 5 bits are padded to 0. Since 573 this parameter is expected to remain constant most of the time during 574 entire reporting sessions, applications SHOULD avoid sending these 575 parameters too often to ensure an efficient usage of network 576 resources. 578 S_Layer3: 8 bits - This parameter defined in section 5.23 of [RAQMON- 579 FRAMEWORK] is an 8-bit field that represents layer 3 QoS marking used 580 to send packets to the receiver by this data source during sub- 581 session RC_N. Since most of the time the Source Layer 3 used in sub 582 session RC_N will remain constant, applications SHOULD avoid sending 583 these parameters within a PDU too often to ensure an efficient usage 584 of network resources. 586 D_Layer2: 8 bits - This parameter defined in section 5.24 of [RAQMON- 587 FRAMEWORK] is an 8-bit field, which represents the value of the IEEE 588 802.1Q tag priority field used by the receiver to send packets to the 589 data source during sub session RC_N session if the Data Source can 590 learn such information. Since the priority value is 3 bits, the first 591 3 bits of this parameter represents priority value and the last 5 592 bits are padded to 0. Since most of the time the Destination Layer 2 593 used will remain constant during entire reporting sessions, 594 applications SHOULD avoid sending these parameters within a PDU too 595 often to ensure an efficient usage of network resources. 597 D_Layer3: 8 bits - This parameter defined in section 5.25 of [RAQMON- 598 FRAMEWORK] is an 8-bit field that represents layer 3 QoS marking used 599 by the receiver to send packets to the data source during sub session 600 RC_N if the Data Source can learn such information. Since most of the 601 time the Destination Layer 3 used will remain constant during entire 602 reporting sessions, applications SHOULD avoid sending these 603 parameters within a PDU too often to ensure an efficient usage of 604 network resources. 606 CPU Utilization: 8 bits - This parameter defined in section 5.26 of 607 [RAQMON-FRAMEWORK] represents total CPU usage by an end device while 608 sub-session RC_N is in progress. This parameter represent a time 609 average of total CPU utilization from the last RAQMON PDU was sent 610 until the time this RAQMON PDU was generated. CPU Utilization value 611 SHOULD NOT be limited to CPU utilization associated to sub-session 612 RC_N, rather it SHOULD represent total CPU Utilization of the end 613 device while sub-session RC_N is in progress. 615 Memory Utilization: 8 bits - This parameter defined in section 5.27 616 of [RAQMON-FRAMEWORK] represents the percentage of total memory used 617 during sub-session RC_N up until the time this RAQMON PDU was 618 generated. Memory Utilization value SHOULD NOT be limited to memory 619 utilization associated to sub-session RC_N, rather it SHOULD 620 represent total memory Utilization of the end device while sub- 621 session RC_N is in progress. 623 Application Name: - This parameter is defined in section 5.28 of 624 [RAQMON-FRAMEWORK]. The Application Name field starts with an 8-bit 625 octet count describing the length of the text and the text itself. 626 The Application Name field is multiple of 32 bits. Since the 627 Application Name is expected to remain constant during entire 628 reporting sessions, applications SHOULD avoid sending these 629 parameters within a PDU too often to ensure an efficient usage of 630 network resources. 632 padding: 0, 8, 16 or 24 bits - As described earlier in this section, 633 if the padding bit (P) is set , the actual padding at the end of the 634 Basic part of the PDU is either 0,8, 16 or 24 bits to make the basic 635 part of the PDU multiple of 32 bits long. 637 2.2 APP part of RAQMON Protocol Data Unit (PDU) 639 The APP part of the RAQMON PDU is intended for experimental use as 640 new applications and new features are developed, without requiring 641 PDU type value registration. 643 Vendors are responsible for designing RDSs with appropriate SMI 644 Enterprise Code and publishing application specific extensions. Any 645 RAQMON compliant RRC MUST be able to recognize vendors SMI Enterprise 646 Code and Report Type, and MUST recognize the presence of application 647 specific extensions that trail behind vendors specific SMI Enterprise 648 Code and Report Type. There is no need for the RRC to understand the 649 semantics of the Enterprise specific parts of the PDU. 651 SMI Enterprise Code: 32 bits - Vendors and Application developers 652 SHOULD fill in appropriate SMI Enterprise IDs available here 653 http://www.iana.org/assignments/enterprise-numbers. A Non-Zero SMI 654 Enterprise Code MUST be treated as a vendor or application specific 655 extension. 657 RAQMON PDUs are capable of carrying multiple Application Parts within 658 a PDU that trails multiple SMI Network Management Private Enterprise 659 Codes of the vendor. 661 Report Type: 16 bits - Vendors and Application developers SHOULD fill 662 in the appropriate Report type within a specified SMI Enterprise 663 Code. It is RECOMMENDED that vendors publish application specific 664 extensions and maintain such report types for better 665 interoperability. 667 Length of the Application Part: 16 bits - The length of the 668 Application Part of the RAQMON PDU is 32-bit words minus one, which 669 includes the header of the Application Part. 671 application-dependent data: variable length - Application/vendor- 672 dependent data to be defined by the application developers. It is 673 interpreted by the vendor specific application and not by the RRC 674 itself. It must be a multiple of 32 bits long. 676 2.3 Byte Order, Alignment, and Time Format of RAQMON PDUs 678 All integer fields are carried in network byte order, that is, with 679 the most significant byte (octet) first. This byte order is commonly 680 known as big-endian. The transmission order is described in detail in 681 [RFC791]. Unless otherwise noted, numeric constants are in decimal 682 (base 10). 684 All header data is aligned to its natural length, i.e., 16-bit fields 685 are aligned on even offsets, 32-bit fields are aligned at offsets 686 divisible by four, etc. Octets designated as padding have the value 687 zero. 689 3. Transporting RAQMON Protocol Data Units 691 It is an inherent objective of the RAQMON Framework to re-use 692 existing application level transport protocols to maximize the usage 693 of existing installations as well as to avoid transport protocol 694 level complexities in the design process. A RAQMON PDU does not 695 transport application data but rather occupies the place of a payload 696 specification at the application layer of the protocol stack. As 697 outlined in [RAQMON-FRAMEWORK] both the Real-Time Transport Control 698 Protocol (RTCP) and the Simple Network Management Protocol (SNMP) can 699 be used as a transport protocol. Section 3.1 specifies RTCP APP 700 Packets [RFC 3550] to carry RAQMON PDUs between RDS and RRC and 701 section 3.2.reflects usage of SNMP INFORM PDUs as transport protocol. 702 It is left upon the vendors to choose either RTCP or SNMP to 703 transport RAQMON PDU as it fits the deployment need. Guidance in the 704 form of pros and cons of using each protocol has been provided in 705 appropriate sections. 707 3.1 Mapping RAQMON PDUs to RTCP as Transport Protocol 709 The RAQMON PDU transfer is comprised of a unidirectional transfer of 710 a PDU from a RDS to a RRC. The protocol data units are mapped to an 711 APP Packet in Real-Time Transport Control Protocol (RTCP). The RTCP 712 APP packets are intended for use as new application layer protocols 713 such as RAQMON are developed. As recommended in RFC 3550, an RTCP APP 714 packet is redefined as follows for RAQMON usage and registered with 715 IANA using an RTCP packet type. The RAQMON Framework makes use of 716 such an extension to provide backward compatibility to existing 717 deployment. RTCP APP packets for the purpose of RAQMON usage do not 718 include the subtype and name fields as recommended in [RFC3550]. 720 Figure 3 below shows how RAQMON PDUs are mapped into RTCP APP 721 Packets. 723 0 1 2 3 724 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 725 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 726 |V=2|P| XXXXX | PT=RMON=20X | length | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 728 | SSRC = "DSRC" | 729 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 730 | "Part of RAQMON PDU that trails behind 32 bit DSRC" | 731 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 733 Figure 3 - Using RTCP APP Packets to transport RAQMON PDUs 735 version (V): 2 bits As described for the RTCP SR packet in RFC 3550. 737 padding (P): 1 bit If the padding bit is set, this RTCP APP packet 738 contains some additional padding octets at the end. The semantics of 739 this field are identical to the semantics of the padding field in the 740 SR packet, as defined by the RTP/RTCP specification [RFC 3550]. 742 reserved: 5 bits This field is reserved for future definition. In 743 the absence of such definition, the bits in this field MUST be set to 744 zero and MUST be ignored by the receiver. 746 packet type (PT): 8 bits Contains the constant 20X to identify this 747 as an RTCP Packet carrying RAQMON PDUs. This value is registered 748 with the Internet Assigned Numbers Authority (IANA). 750 length: 16 bits As described for the RTCP Sender Report (SR) packet. 751 It indicates the length of this RAQMON PDU contained within this RTCP 752 packet in 32-bit words minus one, including the RAQMON PDU header and 753 any padding. 755 SSRC: 32 bits As defined in RFC 3550 SR Packet. While mapping RAQMON 756 PDU to RTCP, further optimization MAY be accomplished by re-using 757 DSRC values as SSRC for RTCP session. 759 RAQMON PDU: variable length The RAQMON Report Collector (RRC) and not 760 RTP/RTCP stack will interpret RAQMON PDUs sent by the RDS in the 761 format specified in Figure 3. RAQMON PDUs must be a multiple of 32 762 bits long. 764 3.1.1 Port Assignment 765 As specified in the previous sections, RAQMON PDUs can be transported 766 using any underlying network transport protocols used by RTCP or 767 SNMP. Examples of such transport protocols are TCP, UDP and DCCP. 769 Applications using the RAQMON Framework may use any unreserved UDP 770 port. For example, a session management program can allocate the port 771 randomly. A single fixed port cannot be required because multiple 772 applications within a host sharing a RDS implementation may encounter 773 difficulties as there are some operating systems that do not allow 774 multiple processes to use the same UDP port with different multicast 775 addresses. 777 However, port number 5XXX has been registered with IANA for use as 778 the default port for RAQMON PDUs over RTCP. Hosts that run multiple 779 applications MAY use this port as an indication to have used RAQMON 780 if they are not subject to the constraint described in the previous 781 paragraph. RRCs MAY also use this port as a default to receive RAQMON 782 PDUs carried over RTCP, which will reduce the amount of configuration 783 for RDSs. 785 Applications need not have a default port and may require that the 786 port be explicitly specified. The particular port number was chosen 787 to lie in the range above 5000 to accommodate the port number 788 allocation practice within the Unix operating system, where 789 privileged processes can only use port numbers below 1024 and port 790 numbers between 1024 and 5000 are automatically assigned by the 791 operating systems. 793 3.2 SNMP INFORM PDUs as RDS/RRC Network Transport Protocol 795 If SNMP is chosen as a mechanism to transport RAQMON PDUs, the 796 following specification applies: 798 + RDSs implement the capability of embedding RAQMON parameters in 799 SNMP INFORM Requests, re-using well known SNMP mechanisms to report 800 RAQMON Statistics. The RAQMON RDS MIB as specified in 3.2.1 MUST be 801 used in order to map the RAQMON PDUs on the SNMP Notifications 802 transport. 804 Managed objects are accessed via a virtual information store, termed 805 the Management Information Base or MIB. MIB objects are generally 806 accessed through the Simple Network Management Protocol (SNMP). 807 Objects in the MIB are defined using the mechanisms defined in the 808 Structure of Management Information (SMI). For a detailed overview of 809 the documents that describe the current Internet-Standard Management 810 Framework, please refer to section 7 of RFC 3410 [RFC3410]. 812 + Since RDSs are not computationally rich and to keep the RDS 813 realization lightweight, it is not required that RDSs fully implement 814 an SNMP-based Internet Management framework. Specifically RDSs MAY 815 NOT respond to SNMP requests like GET, SET, etc., as an SNMP 816 compliant responder would. 818 + In order to meet congestion safety requirements, RDSs MUST process 819 the SNMP INFORM responses from RRCs, and MUST serialize the PDU 820 transmission rate. 822 + Standard UDP port 162 SHALL be used for SNMP Notifications. 824 3.2.1 Encoding RAQMON PDU by using the RAQMON RDS MIB 826 The RAQMON RDS MIB will be used in order to map the RAQMON PDUs on 827 SNMP Notifications transport. The MIB defines the objects needed for 828 the basic part of RAQMON PDU mapping, as well as the Notification. In 829 order to incorporate any application specific extensions in the APP 830 part of RAQMON PDU, varbinds may be included in the RAQMON 831 notifications described in the MIB. 833 This section specifies a MIB module that is compliant to the SMIv2, 834 which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 835 [RFC2579] and STD 58, RFC 2580 [RFC2580]. 837 RAQMON-RDS-MIB DEFINITIONS ::= BEGIN 839 IMPORTS 840 Unsigned32, 841 MODULE-IDENTITY, OBJECT-TYPE, NOTIFICATION-TYPE, Counter32, Integer32 842 FROM SNMPv2-SMI 843 DateAndTime 844 FROM SNMPv2-TC 845 rmon 846 FROM RMON-MIB 847 Utf8String 848 FROM SYSAPPL-MIB 849 Dscp 850 FROM DIFFSERV-DSCP-TC 852 MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP 853 FROM SNMPv2-CONF; 855 raqmonDs MODULE-IDENTITY 856 LAST-UPDATED "200311111150Z" -- November 11, 2003 857 ORGANIZATION "RMON Working Group" 858 CONTACT-INFO 859 " 860 WG EMail: rmonmib@ietf.org 861 Subscribe: rmonmib-request@ietf.org 862 MIB Editor: 863 Eugene Golovinsky 864 Postal: BMC Software, Inc. 865 2101 CityWest Blvd, 866 Houston, TX, 77094 867 USA 868 Tel: +713-918-1816 869 Email: egolovin@bmc.com 870 " 871 DESCRIPTION 872 "This is RAQMON Data Source notification Module. 873 It provides mapping of RAQMON PDU to SNMP Notification. 875 Ds is for data source. 877 Note that all of the object types defined in this 878 module are accessible-for-notify, and would consequently 879 not be available to a browser using simple Get, GetNext, 880 or GetBulk requests. 882 Copyright (c) The Internet Society (2003). This version of this MIB module is part of RFC yyyy; See the RFC itself for full legal notices. 883 " 885 REVISION "200311111150Z" -- November 11, 2003 887 DESCRIPTION 888 "Changes after the 58th IETF." 890 ::= { rmon 32 } 892 raqmonDsEvents OBJECT IDENTIFIER ::= { raqmonDs 0 } 894 raqmonDsMIBObjects OBJECT IDENTIFIER ::= { raqmonDs 1 } 896 raqmonDsConformance OBJECT IDENTIFIER ::= { raqmonDs 2 } 898 raqmonDsNotificationTable OBJECT-TYPE 899 SYNTAX SEQUENCE OF RaqmonDsNotificationEntry 900 MAX-ACCESS not-accessible 901 STATUS current 902 DESCRIPTION 903 "This conceptual table provides the SNMP mapping 904 of the RAQMON Basic PDU. 905 Indexed by RAQMON session 906 " 908 ::= { raqmonDsMIBObjects 1 } 910 raqmonDsNotificationEntry OBJECT-TYPE 911 SYNTAX RaqmonDsNotificationEntry 912 MAX-ACCESS not-accessible 913 STATUS current 914 DESCRIPTION 915 "The entry (row) is not retrievable and is not kept 916 by RDSs. 917 It serves data organization purpose only. 918 " 919 INDEX { raqmonDSRC, 920 raqmonRCN } 921 ::= { raqmonDsNotificationTable 1 } 923 RaqmonDsNotificationEntry ::= 924 SEQUENCE { 925 raqmonDSRC 926 Unsigned32, 927 raqmonRCN 928 Integer32, 929 raqmonAppName 930 Utf8String, 931 raqmonDataSourceDevicePort 932 Unsigned32, 933 raqmonReceiverDevicePort 934 Unsigned32, 935 raqmonSessionSetupDateTime 936 DateAndTime, 937 raqmonSessionSetupDelay 938 Unsigned32, 939 raqmonSessionDuration 940 Unsigned32, 941 raqmonSessionSetupStatus 942 Utf8String, 943 raqmonRoundTripEndtoEndDelay 944 Unsigned32, 945 raqmonOneWayEndtoEndDelay 946 Unsigned32, 947 raqmonJitterType 948 INTEGER, 949 raqmonJitterValue 950 Unsigned32, 951 raqmonTotalPacketsReceived 952 Counter32, 953 raqmonTotalPacketsSent 954 Counter32, 956 raqmonTotalOctetsReceived 957 Counter32, 958 raqmonTotalOctetsSent 959 Counter32, 960 raqmonCumulativePacketLoss 961 Counter32, 962 raqmonPacketLossFraction 963 Unsigned32, 964 raqmonSourcePayloadType 965 Unsigned32, 966 raqmonReceiverPayloadType 967 Unsigned32, 968 raqmonSourceLayer2Priority 969 Unsigned32, 970 raqmonDestinationLayer2Priority 971 Unsigned32, 972 raqmonSourceDscp 973 Dscp, 974 raqmonDestinationDscp 975 Dscp, 976 raqmonCpuUtilization 977 Unsigned32, 978 raqmonMemoryUtilization 979 Unsigned32 980 } 982 raqmonDSRC OBJECT-TYPE 983 SYNTAX Unsigned32 984 MAX-ACCESS accessible-for-notify 985 STATUS current 986 DESCRIPTION 987 "Data Source identifier represents a unique session 988 descriptor that points to a specific communication session 989 between communicating entities." 990 ::= { raqmonDsNotificationEntry 1 } 992 raqmonRCN OBJECT-TYPE 993 SYNTAX Integer32 (0..15) 994 MAX-ACCESS accessible-for-notify 995 STATUS current 996 DESCRIPTION 997 "The Record Count Number indicates a sub-session 998 within a communication session." 999 ::= { raqmonDsNotificationEntry 2 } 1001 raqmonAppName OBJECT-TYPE 1002 SYNTAX Utf8String 1003 MAX-ACCESS accessible-for-notify 1004 STATUS current 1005 DESCRIPTION 1006 "This is a text string giving the name and possibly version 1007 of the application associated to that session, 1008 e.g., --XYZ VoIP Agent 1.2." 1009 REFERENCE 1010 "Section 5.28 of the [RAQMON FRAMEWORK]" 1011 ::= { raqmonDsNotificationEntry 3 } 1013 raqmonDataSourceDevicePort OBJECT-TYPE 1014 SYNTAX Unsigned32 (0..65535) 1015 MAX-ACCESS accessible-for-notify 1016 STATUS current 1017 DESCRIPTION 1018 "The port number from which data for this session was sent." 1019 REFERENCE 1020 "Section 5.5 of the [RAQMON FRAMEWORK]" 1021 ::= { raqmonDsNotificationEntry 4 } 1023 raqmonReceiverDevicePort OBJECT-TYPE 1024 SYNTAX Unsigned32 (0..65535) 1025 MAX-ACCESS accessible-for-notify 1026 STATUS current 1027 DESCRIPTION 1028 "The port number where the data for this session was received." 1029 REFERENCE 1030 "Section 5.6 of the [RAQMON FRAMEWORK]" 1031 ::= { raqmonDsNotificationEntry 5 } 1033 raqmonSessionSetupDateTime OBJECT-TYPE 1034 SYNTAX DateAndTime 1035 MAX-ACCESS accessible-for-notify 1036 STATUS current 1037 DESCRIPTION 1038 "The time when session was initiated." 1039 REFERENCE 1040 "Section 5.7 of the [RAQMON FRAMEWORK]" 1041 ::= { raqmonDsNotificationEntry 6 } 1043 raqmonSessionSetupDelay OBJECT-TYPE 1044 SYNTAX Unsigned32 1045 MAX-ACCESS accessible-for-notify 1046 STATUS current 1047 DESCRIPTION 1048 "Session setup time in milliseconds." 1049 REFERENCE 1050 "Section 5.8 of the [RAQMON FRAMEWORK]" 1051 ::= { raqmonDsNotificationEntry 7 } 1053 raqmonSessionDuration OBJECT-TYPE 1054 SYNTAX Unsigned32 1055 MAX-ACCESS accessible-for-notify 1056 STATUS current 1057 DESCRIPTION 1058 "Session duration in seconds." 1059 REFERENCE 1060 "Section 5.9 of the [RAQMON FRAMEWORK]" 1061 ::= { raqmonDsNotificationEntry 8 } 1063 raqmonSessionSetupStatus OBJECT-TYPE 1064 SYNTAX Utf8String 1065 MAX-ACCESS accessible-for-notify 1066 STATUS current 1067 DESCRIPTION 1068 "Describes appropriate communication session states e.g. 1069 Call Established successfully, RSVP reservation 1070 failed etc." 1071 REFERENCE 1072 "Section 5.10 of the [RAQMON FRAMEWORK]" 1073 ::= { raqmonDsNotificationEntry 9 } 1075 raqmonRoundTripEndtoEndDelay OBJECT-TYPE 1076 SYNTAX Unsigned32 1077 MAX-ACCESS accessible-for-notify 1078 STATUS current 1079 DESCRIPTION 1080 "Round trip end to end delay in milliseconds." 1081 REFERENCE 1082 "Section 5.10 of the [RAQMON FRAMEWORK]" 1083 ::= { raqmonDsNotificationEntry 10} 1085 raqmonOneWayEndtoEndDelay OBJECT-TYPE 1086 SYNTAX Unsigned32 1087 MAX-ACCESS accessible-for-notify 1088 STATUS current 1089 DESCRIPTION 1090 "One way end to end delay in milliseconds." 1091 REFERENCE 1092 "Section 5.12 of the [RAQMON FRAMEWORK]" 1093 ::= { raqmonDsNotificationEntry 11} 1095 raqmonJitterType OBJECT-TYPE 1096 SYNTAX INTEGER 1097 { 1098 interArrival(1), 1099 absolute(2) 1100 } 1102 MAX-ACCESS accessible-for-notify 1103 STATUS current 1104 DESCRIPTION 1105 "The type of the jitter measurement as reported by the RDS." 1106 REFERENCE 1107 "Section 5.13 of the [RAQMON FRAMEWORK]" 1108 ::= { raqmonDsNotificationEntry 12} 1110 raqmonJitterValue OBJECT-TYPE 1111 SYNTAX Unsigned32 1112 MAX-ACCESS accessible-for-notify 1113 STATUS current 1114 DESCRIPTION 1115 "An estimate of the jitter expressed in milliseconds." 1116 REFERENCE 1117 "Section 5.13 of the [RAQMON FRAMEWORK]" 1118 ::= { raqmonDsNotificationEntry 13} 1120 raqmonTotalPacketsReceived OBJECT-TYPE 1121 SYNTAX Counter32 1122 MAX-ACCESS accessible-for-notify 1123 STATUS current 1124 DESCRIPTION 1125 "The total number of packets 1126 transmitted within a communication session by the receiver 1127 since starting transmission up until the time this RAQMON 1128 packet was generated." 1129 REFERENCE 1130 "Section 5.14 of the [RAQMON FRAMEWORK]" 1131 ::= { raqmonDsNotificationEntry 14 } 1133 raqmonTotalPacketsSent OBJECT-TYPE 1134 SYNTAX Counter32 1135 MAX-ACCESS accessible-for-notify 1136 STATUS current 1137 DESCRIPTION 1138 "The total number of packets 1139 transmitted within a communication session by the sender since 1140 starting transmission up until the time this RAQMON packet was 1141 generated." 1142 REFERENCE 1143 "Section 5.15 of the [RAQMON FRAMEWORK]" 1144 ::= { raqmonDsNotificationEntry 15 } 1146 raqmonTotalOctetsReceived OBJECT-TYPE 1147 SYNTAX Counter32 1148 MAX-ACCESS accessible-for-notify 1149 STATUS current 1150 DESCRIPTION 1151 "The total number of payload 1152 octets (i.e., not including header or padding) transmitted in 1153 packets by the receiver within a communication session since 1154 starting transmission up until the time this RAQMON packet 1155 was generated." 1156 REFERENCE 1157 "Section 5.16 of the [RAQMON FRAMEWORK]" 1158 ::= { raqmonDsNotificationEntry 16 } 1160 raqmonTotalOctetsSent OBJECT-TYPE 1161 SYNTAX Counter32 1162 MAX-ACCESS accessible-for-notify 1163 STATUS current 1164 DESCRIPTION 1165 "The total number of payload octets 1166 i.e., not including header or padding) transmitted in packets 1167 by the sender within a communication session since starting 1168 transmission up until the time this RAQMON packet was generated." 1169 REFERENCE 1170 "Section 5.17 of the [RAQMON FRAMEWORK]" 1171 ::= { raqmonDsNotificationEntry 17 } 1173 raqmonCumulativePacketLoss OBJECT-TYPE 1174 SYNTAX Counter32 1175 MAX-ACCESS accessible-for-notify 1176 STATUS current 1177 DESCRIPTION 1178 "The total number of packets from session 1179 those have been lost while this notification was generated. 1180 This number is expected to be less the number of packets 1181 actually received." 1182 REFERENCE 1183 "Section 5.18 of the [RAQMON FRAMEWORK]" 1184 ::= { raqmonDsNotificationEntry 18 } 1186 raqmonPacketLossFraction OBJECT-TYPE 1187 SYNTAX Unsigned32 (0..100) 1188 MAX-ACCESS accessible-for-notify 1189 STATUS current 1190 DESCRIPTION 1191 "The percentage of lost packets with respect to the overall packets 1192 sent. This fraction is defined to be the number of packets lost 1193 divided by the number of packets expected." 1194 REFERENCE 1195 "Section 5.19 of the [RAQMON FRAMEWORK]" 1196 ::= { raqmonDsNotificationEntry 19 } 1198 raqmonSourcePayloadType OBJECT-TYPE 1199 SYNTAX Unsigned32 (0..127) 1200 MAX-ACCESS accessible-for-notify 1201 STATUS current 1202 DESCRIPTION 1203 "The payload type of the packet sent by this RD." 1204 REFERENCE 1205 "RFC 1890, Section 5.20 of the [RAQMON FRAMEWORK] " 1206 ::= { raqmonDsNotificationEntry 20 } 1208 raqmonReceiverPayloadType OBJECT-TYPE 1209 SYNTAX Unsigned32 (0..127) 1210 MAX-ACCESS accessible-for-notify 1211 STATUS current 1212 DESCRIPTION 1213 "The payload type of the packet received by this RD." 1214 REFERENCE 1215 "RFC 1890, Section 5.21 of the [RAQMON FRAMEWORK] " 1216 ::= { raqmonDsNotificationEntry 21 } 1218 raqmonSourceLayer2Priority OBJECT-TYPE 1219 SYNTAX Unsigned32 (0..7) 1220 MAX-ACCESS accessible-for-notify 1221 STATUS current 1222 DESCRIPTION 1223 "Source Layer 2 priorities used to send packets to the 1224 receiver by this data source during this communication 1225 session." 1226 REFERENCE 1227 "Section 5.22 of the [RAQMON FRAMEWORK]" 1228 ::= { raqmonDsNotificationEntry 22 } 1230 raqmonDestinationLayer2Priority OBJECT-TYPE 1231 SYNTAX Unsigned32 (0..7) 1232 MAX-ACCESS accessible-for-notify 1233 STATUS current 1234 DESCRIPTION 1235 "Destination Layer 2 priority." 1236 REFERENCE 1237 "Section 5.24 of the [RAQMON FRAMEWORK]" 1238 ::= { raqmonDsNotificationEntry 23 } 1240 raqmonSourceDscp OBJECT-TYPE 1241 SYNTAX Dscp 1242 MAX-ACCESS accessible-for-notify 1243 STATUS current 1244 DESCRIPTION 1245 "Source DSCP value." 1247 REFERENCE 1248 "Section 5.23 of the [RAQMON FRAMEWORK]" 1249 ::= { raqmonDsNotificationEntry 24 } 1251 raqmonDestinationDscp OBJECT-TYPE 1252 SYNTAX Dscp 1253 MAX-ACCESS accessible-for-notify 1254 STATUS current 1255 DESCRIPTION 1256 "Destination DSCP value." 1257 REFERENCE 1258 "Section 5.25 of the [RAQMON FRAMEWORK]" 1259 ::= { raqmonDsNotificationEntry 25 } 1261 raqmonCpuUtilization OBJECT-TYPE 1262 SYNTAX Unsigned32 (0..100) 1263 MAX-ACCESS accessible-for-notify 1264 STATUS current 1265 DESCRIPTION 1266 "Percentage of total CPU utilization over a time duration." 1267 REFERENCE 1268 "Section 5.26 of the [RAQMON FRAMEWORK]" 1269 ::= { raqmonDsNotificationEntry 26 } 1271 raqmonMemoryUtilization OBJECT-TYPE 1272 SYNTAX Unsigned32 (0..100) 1273 MAX-ACCESS accessible-for-notify 1274 STATUS current 1275 DESCRIPTION 1276 "Percentage of total memory utilization over a time duration." 1277 REFERENCE 1278 "Section 5.27 of the [RAQMON FRAMEWORK]" 1279 ::= { raqmonDsNotificationEntry 27 } 1281 -- 1282 -- definitions of the notifications 1283 -- The object list includes only the OBJECTS that will be send by a 1284 -- RD in any notification. 1285 -- Other objects from the raqmonDsNotificationTable may be included 1286 -- in the varbind. 1288 raqmonDsNotification NOTIFICATION-TYPE 1289 OBJECTS { 1290 raqmonDSRC, 1291 raqmonRCN 1292 } 1293 STATUS current 1294 DESCRIPTION 1295 "This notification maps basic RAQMON PDU into SNMP transport." 1296 ::= { raqmonDsEvents 1 } 1298 raqmonDsByeNotification NOTIFICATION-TYPE 1299 OBJECTS { 1300 raqmonDSRC } 1301 STATUS current 1302 DESCRIPTION 1303 "The BYE Notification. This Notification is the equivalent 1304 of the RAQMON BYE PDU, which signals the end of a RAQMON 1305 session." 1306 ::= { raqmonDsEvents 2 } 1308 -- 1309 -- conformance information 1310 -- These don't show up on the wire, so they only need to be unique. 1311 -- 1312 raqmonDsCompliances OBJECT IDENTIFIER ::= { raqmonDsConformance 1 } 1313 raqmonDsGroups OBJECT IDENTIFIER ::= { raqmonDsConformance 2 } 1315 raqmonDsBasicCompliances MODULE-COMPLIANCE 1316 STATUS current 1317 DESCRIPTION 1318 "The compliance statement for SNMP entities which 1319 implement this MIB module." 1320 MODULE -- this module 1321 MANDATORY-GROUPS { raqmonDsNotificationGroup, 1322 raqmonDsPayloadGroup } 1323 ::= { raqmonDsCompliances 1 } 1325 raqmonDsNotificationGroup NOTIFICATION-GROUP 1326 NOTIFICATIONS { raqmonDsNotification, 1327 raqmonDsByeNotification } 1328 STATUS current 1329 DESCRIPTION 1330 "The notifications implemented by an SNMP entity 1331 claiming conformance to this MIB. 1332 " 1333 ::= { raqmonDsGroups 1 } 1335 raqmonDsPayloadGroup OBJECT-GROUP 1336 OBJECTS { 1337 raqmonDSRC, 1338 raqmonRCN, 1339 raqmonAppName, 1340 raqmonDataSourceDevicePort, 1341 raqmonReceiverDevicePort, 1342 raqmonSessionSetupDateTime, 1343 raqmonSessionSetupDelay, 1344 raqmonSessionDuration, 1345 raqmonSessionSetupStatus, 1346 raqmonRoundTripEndtoEndDelay, 1347 raqmonOneWayEndtoEndDelay, 1348 raqmonJitterType, 1349 raqmonJitterValue, 1350 raqmonTotalPacketsReceived, 1351 raqmonTotalPacketsSent, 1352 raqmonTotalOctetsReceived, 1353 raqmonTotalOctetsSent, 1354 raqmonCumulativePacketLoss, 1355 raqmonPacketLossFraction, 1356 raqmonSourcePayloadType, 1357 raqmonReceiverPayloadType, 1358 raqmonSourceLayer2Priority, 1359 raqmonDestinationLayer2Priority, 1360 raqmonSourceDscp, 1361 raqmonDestinationDscp, 1362 raqmonCpuUtilization, 1363 raqmonMemoryUtilization 1364 } 1365 STATUS current 1366 DESCRIPTION 1367 "These objects are required for entities 1368 claiming conformance to this MIB. 1369 " 1370 ::= { raqmonDsGroups 2 } 1372 END 1374 4.0 Congestion Safe RAQMON Operation: 1376 RAQMON PDU can be transmitted over multiple transport protocols. As specified in an earlier section, the transport of RAQMON PDUs can be performed using any underlying network transport protocols that is used by RTCP and SNMP. Examples of transport such protocols are TCP, UDP and DCCP. 1378 A RAQMON PDU allows the usage of UDP as transport, which might lead to network congestion under heavy network load. To ensure congestion safety clearly the best thing to do is to use a transport protocol like TCP or DCCP, etc. If this is not feasible, it may be necessary to fall back to UDP. Implementers MUST follow section 3.0 of [RAQMON-FRAMEWORK] guidelines that outlines measures that MUST be taken to use RAQMON in congestion safe manner specially when using UDP for network transport that lacks congestion safety functionality at the transport layer. 1380 5. Normative References 1382 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1383 Rose, M. and S. Waldbusser, "Structure of Management 1384 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 1385 1999. 1387 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1388 Rose, M. and S. Waldbusser, "Textual Conventions for 1389 SMIv2", STD 58, RFC 2579, April 1999. 1391 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1392 Rose, M. and S. Waldbusser, "Conformance Statements for 1393 SMIv2", STD 58, RFC 2580, April 1999. 1395 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 1396 Information Base", STD 59, RFC 2819, May 2000 1398 [RFC 3550] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 1399 "RTP: A Transport Protocol for Real-Time Applications" 1400 RFC 3550, July 2003. 1402 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1403 1981. 1405 [RAQMON-FRAMEWORK] A. Siddiqui, D.Romascanu, and E. Golovinsky, 1406 "Framework for Real-time Application Quality of Service 1407 Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon- 1408 framework-05.txt, February 2004 1410 6. Informative References 1412 [RFC3410] Case, J., Mundy, R., Partain, D. and B. Stewart, 1413 "Introduction and Applicability Statements for Internet- 1414 Standard Management Framework", RFC 3410, December 2002 1416 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1417 Requirement Levels", BCP 14, RFC 2119, March 1997. 1419 [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video 1420 Conferences with Minimal Control" RFC 1890, January 1996. 1422 [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, 1423 March 1992. 1425 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 1426 STD 13, RFC 1034, November 1987. 1428 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 1429 Specification", STD 13, RFC 1035, November 1987. 1431 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1432 and Support", STD 3, RFC 1123, October 1989. 1434 [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, 1435 "Address Allocation for Private Internets", RFC 1597, March 1436 1994. 1438 [RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay 1439 Metric for IPPM", RFC 2679, September 1999 1441 [RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet 1442 Loss Metric for IPPM", RFC 2680, September 1999 1444 [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay 1445 Metric for IPPM", RFC 2681, September 1999 1447 [ISO10646] International Standards Organization, "ISO/IEC DIS 1448 10646-1:1993information technology -- universal 1449 multiple-octet coded character set (UCS) -- part I: 1450 Architecture and basic multilingual plane," 1993. 1452 [UNICODE] The Unicode Consortium, The Unicode Standard New York, 1453 New York:Addison-Wesley, 1991. 1455 [IEEE802.1D] Information technology-Telecommunications and information 1456 exchange between systems--Local and metropolitan area 1457 networks-Common Specification a--Media access control (MAC) 1458 bridges:15802-3: 1998 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1459 1998 Edition] 1461 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite", 1462 RFC 1349, July 1992 1464 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812, 1465 June 1995 1467 [RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition of 1468 the Differentiated Services Field (DS Field) in the IPv4 and 1469 IPv6 Headers", RFC2474, December 1998 1471 [RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss, 1472 "An Architecture for Differentiated Services" RFC2475, 1473 December 1998 1475 7. Intellectual Property 1477 The IETF takes no position regarding the validity or scope of any 1478 intellectual property or other rights that might be claimed to 1479 pertain to the implementation or use of the technology described in 1480 this document or the extent to which any license under such rights 1481 might or might not be available; neither does it represent that it 1482 has made any effort to identify any such rights. Information on the 1483 IETF's procedures with respect to rights in standards-track and 1484 standards-related documentation can be found in BCP-11. Copies of 1485 claims of rights made available for publication and any assurances of 1486 licenses to be made available, or the result of an attempt made to 1487 obtain a general license or permission for the use of such 1488 proprietary rights by implementors or users of this specification can 1489 be obtained from the IETF Secretariat. 1491 The IETF invites any interested party to bring to its attention any 1492 copyrights, patents or patent applications, or other proprietary 1493 rights which may cover technology that may be required to practice 1494 this standard. Please address the information to the IETF Executive 1495 Director. 1497 8. Appendix 1499 The implementation notes included in this Appendix are for 1500 informational purposes only and are meant to clarify the RAQMON 1501 specification. 1503 Pseudo code for RDS & RRC 1505 We provide examples of Pseudo code for aspects of RDS and RRC. There 1506 may be other implementation methods that are faster in particular 1507 operating environments or have other advantages. 1509 RDS: 1510 when (session starts} { 1511 report.identifier = session.endpoints, session.starttime; 1512 report.timestamp = 0; 1513 while (session in progress) { 1514 wait interval; 1515 report.statistics = update statistics; 1516 report.curtimestamp += interval; 1517 if encryption required 1518 report_data = encrypt(report, encrypt parameters); 1519 else 1520 report_data = report; 1521 raqmon_pdu = header, report_data; 1522 send raqmon-pdu; 1523 } 1524 } RRC: 1525 listen on raqmon port 1526 when ( raqmon_pdu received ) { 1527 decrypt raqmon_pdu.data if needed 1529 if report.identifier in database 1530 if report.current_time_stamp > last update 1531 update session statistics from report.statistics 1532 else 1533 discard report 1535 } 1537 9. Security Considerations 1539 The [RAQMON-FRAMEWORK] memo outlines a threat model associated to 1540 RAQMON and some security considerations taken into account within the 1541 RAQMON specification to alleviate those threats. It is imperative 1542 that the RAQMON PDU implementations be able to provide the following 1543 protection mechanisms to attain end-to-end security: 1545 1. Authentication - the RRC SHOULD be able to verify that a RAQMON 1546 report was originated by the RDS who claims to have sent it. At 1547 minimum, a RDS/RRC pair MUST use a digest based authentication 1548 procedure to authenticate. 1550 2. Privacy - RAQMON information includes identification of the 1551 parties participating in a communication session. RAQMON deployment 1552 SHOULD be able to provide protection from eavesdropping, and to 1553 prevent an unauthorized third party from gathering potentially 1554 sensitive information. This can be achieved by using payload 1555 encryption technologies like DES, 3-DES, AES 1557 3. Protection from Denial of Service attacks directed at the RRC - 1558 RDSs send RAQMON reports as a side effect of an external event (for 1559 example, a phone call is being received). An attacker can try and 1560 overwhelm the RRC (or the network) by initiating a large number of 1561 events for the purpose of swamping the RRC with too many RAQMON PDUs. 1563 To prevent DoS attacks against RRC, the RDS will send the first 1564 report for a session only after the session has been in progress. 1566 4. NAT and Firewall Friendly Design: Presence for IP addresses, 1567 TCP/UDP ports information in RAQMON PDUs may be NAT un-friendly. In 1568 such a scenario, where NAT Friendliness is a requirement, the RDS may 1569 opt to not to provide IP Addresses in RAQMON PDU. Another way to 1570 avoid this problem is by using NAT Aware Application Layer Gateways 1571 (ALGs) to fill out IP Addresses in RAQMON PDUs. 1573 This memo also defines a RDS SNMP MIB with the purpose of mapping the 1574 RAQMON PDUs into SNMP Notifications. To attain end to end security 1575 The following measures have been taken in RDS MIB implementation: 1577 There are no management objects defined in this MIB module that have 1578 a MAX-ACCESS clause of read-write and/or read-create. So, if this 1579 MIB module is implemented correctly, then there is no risk that an 1580 intruder can alter or create any management objects of this MIB 1581 module via direct SNMP SET operations. 1583 Some of the readable objects in this MIB module (i.e., objects with a 1584 MAX-ACCESS other than not-accessible) may be considered sensitive or 1585 vulnerable in some network environments. It is thus important to 1586 control even GET and/or NOTIFY access to these objects and possibly 1587 to even encrypt the values of these objects when sending them over 1588 the network via SNMP. These are the tables and objects and their 1589 sensitivity/vulnerability: 1591 raqmonDsNotificationTable 1593 The objects in this table contain user sessions information, and 1594 their disclosure may be sensitive in some environments. 1596 SNMP versions prior to SNMPv3 did not include adequate security. Even 1597 if the network itself is secure (for example by using IPSec), even 1598 then, there is no control as to who on the secure network is allowed 1599 to access and GET/SET (read/change/create/delete) the objects in this 1600 MIB module. 1602 It is RECOMMENDED that implementers consider the security features as 1603 provided by the SNMPv3 framework (see [RFC3410], section 8), 1604 including full support for the SNMPv3 cryptographic mechanisms (for 1605 authentication and privacy). 1607 Though not mandatory for RAQMON compliance, it is RECOMMENDED to 1608 deploy SNMPv3 and to enable cryptographic security for RAQMON PDUs. 1609 It is a customer/operator responsibility to ensure that the SNMP 1610 entity giving access to an instance of this MIB module is properly 1611 configured to give access to the objects only to those principals 1612 (users) that have legitimate rights to indeed GET or SET 1613 (change/create/delete) them. 1615 10. IANA Considerations 1617 This document defines a new RTCP packet type, within the existing 1618 Internet Assigned Numbers Authority (IANA) registry of RTP RTCP 1619 Control Packet Types at http://www.iana.org/numbers.html. RTCP Packet 1620 constant PT=20X as specified in Section 3.1 is reserved for RAQMON 1621 usage. 1623 This document also introduces a port for RAQMON usage of RTCP as 1624 transport protocol. 1626 11. Authors' Addresses 1628 Anwar A. Siddiqui 1629 Avaya Labs 1630 307 Middletown Lincroft Road 1631 Lincroft, New Jersey 07738 1632 USA 1633 Tel: +1 732 852-3200 1634 E-mail: anwars@avaya.com 1636 Dan Romascanu 1637 Avaya 1638 Atidim Technology Park, Bldg. #3 1639 Tel Aviv, 61131 1640 Israel 1641 Tel: +972-3-645-8414 1642 Email: dromasca@avaya.com 1644 Eugene Golovinsky 1645 BMC Software 1646 2101 CityWest Blvd. 1647 Houston, Texas 77042 1648 USA 1649 Tel: +1 713 918-1816 1650 Email: eugene_golovinsky@bmc.com 1652 A. Full Copyright Statement 1654 This document and translations of it may be copied and furnished to 1655 others, and derivative works that comment on or otherwise explain it 1656 or assist in its implementation may be prepared, copied, published 1657 and distributed, in whole or in part, without restriction of any 1658 kind, provided that the above copyright notice and this paragraph are 1659 included on all such copies and derivative works. However, this 1660 document itself may not be modified in any way, such as by removing 1661 the copyright notice or references to the Internet Society or other 1662 Internet organizations, except as needed for the purpose of 1663 developing Internet standards in which case the procedures for 1664 copyrights defined in the Internet Standards process must be 1665 followed, or as required to translate it into languages other than 1666 English. 1668 The limited permissions granted above are perpetual and will not be 1669 revoked by the Internet Society or its successors or assigns. 1671 This document and the information contained herein is provided on an 1672 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1673 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1674 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1675 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1676 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.