idnits 2.17.1 draft-ietf-rmonmib-raqmon-pdu-00.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 25 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 26 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 56 instances of too long lines in the document, the longest one being 105 characters in excess of 72. ** The abstract seems to contain references ([SIDDIQUI1], [SIDDIQUI2], [SIDDIQUI3], [RFC2819]), 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 == Line 550 has weird spacing: '...o/video clo...' == Line 732 has weird spacing: '... or, if bette...' -- The exact meaning of the all-uppercase expression 'NOT REQUIRED' is not defined in RFC 2119. If it is intended as a requirements expression, it should be rewritten using one of the combinations defined in RFC 2119; otherwise it should not be all-uppercase. -- 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 Jan 2003) is 7771 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) -- Looks like a reference, but probably isn't: '17' on line 304 == Missing Reference: 'RFC 1889' is mentioned on line 714, but not defined ** Obsolete undefined reference: RFC 1889 (Obsoleted by RFC 3550) == Missing Reference: 'RFC2274' is mentioned on line 1122, but not defined ** Obsolete undefined reference: RFC 2274 (Obsoleted by RFC 2574) == Missing Reference: 'RFC2275' is mentioned on line 1123, but not defined ** Obsolete undefined reference: RFC 2275 (Obsoleted by RFC 2575) == Unused Reference: 'RFC2578' is defined on line 917, but no explicit reference was found in the text == Unused Reference: 'RFC2579' is defined on line 922, but no explicit reference was found in the text == Unused Reference: 'RFC2580' is defined on line 926, but no explicit reference was found in the text == Unused Reference: 'RFC1889' is defined on line 933, but no explicit reference was found in the text == Unused Reference: 'RFC2571' is defined on line 941, but no explicit reference was found in the text == Unused Reference: 'RFC1155' is defined on line 945, but no explicit reference was found in the text == Unused Reference: 'RFC1212' is defined on line 949, but no explicit reference was found in the text == Unused Reference: 'RFC1215' is defined on line 952, but no explicit reference was found in the text == Unused Reference: 'RFC1157' is defined on line 955, but no explicit reference was found in the text == Unused Reference: 'RFC1901' is defined on line 958, but no explicit reference was found in the text == Unused Reference: 'RFC1906' is defined on line 962, but no explicit reference was found in the text == Unused Reference: 'RFC2572' is defined on line 966, but no explicit reference was found in the text == Unused Reference: 'RFC2574' is defined on line 970, but no explicit reference was found in the text == Unused Reference: 'RFC1905' is defined on line 974, but no explicit reference was found in the text == Unused Reference: 'RFC2573' is defined on line 978, but no explicit reference was found in the text == Unused Reference: 'RFC2575' is defined on line 981, but no explicit reference was found in the text == Unused Reference: 'RFC2570' is defined on line 985, but no explicit reference was found in the text == Unused Reference: 'RFC2613' is defined on line 992, but no explicit reference was found in the text == Unused Reference: 'RFC1213' is defined on line 996, but no explicit reference was found in the text == Unused Reference: 'RFC2863' is defined on line 1000, but no explicit reference was found in the text == Unused Reference: 'RFC1305' is defined on line 1006, but no explicit reference was found in the text == Unused Reference: 'RFC1034' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'RFC1035' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1015, but no explicit reference was found in the text == Unused Reference: 'RFC1597' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'RFC2679' is defined on line 1021, but no explicit reference was found in the text == Unused Reference: 'RFC2680' is defined on line 1024, but no explicit reference was found in the text == Unused Reference: 'RFC2681' is defined on line 1027, but no explicit reference was found in the text == Unused Reference: 'WALDBUSSER' is defined on line 1030, but no explicit reference was found in the text == Unused Reference: 'DIETZ' is defined on line 1033, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1D' is defined on line 1044, but no explicit reference was found in the text == Unused Reference: 'RFC1349' is defined on line 1049, but no explicit reference was found in the text == Unused Reference: 'RFC1812' is defined on line 1052, but no explicit reference was found in the text == Unused Reference: 'RFC2474' is defined on line 1055, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 1059, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1889 (Obsoleted by RFC 3550) -- Obsolete informational reference (is this intentional?): RFC 2571 (Obsoleted by RFC 3411) -- Obsolete informational reference (is this intentional?): RFC 1906 (Obsoleted by RFC 3417) -- Obsolete informational reference (is this intentional?): RFC 2572 (Obsoleted by RFC 3412) -- Obsolete informational reference (is this intentional?): RFC 2574 (Obsoleted by RFC 3414) -- Obsolete informational reference (is this intentional?): RFC 1905 (Obsoleted by RFC 3416) -- Obsolete informational reference (is this intentional?): RFC 2573 (Obsoleted by RFC 3413) -- Obsolete informational reference (is this intentional?): RFC 2575 (Obsoleted by RFC 3415) -- Obsolete informational reference (is this intentional?): RFC 2570 (Obsoleted by RFC 3410) -- 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) == Outdated reference: A later version (-12) exists of draft-ietf-rmonmib-apm-mib-04 == Outdated reference: A later version (-14) exists of draft-ietf-rmonmib-tpm-mib-03 -- Obsolete informational reference (is this intentional?): RFC 1349 (Obsoleted by RFC 2474) == Outdated reference: A later version (-12) exists of draft-ietf-rmonmib-raqmon-mib-00 -- No information found for draft-ietf-raqmon-framework - is the name correct? == Outdated reference: A later version (-02) exists of draft-siddiqui-rmonmib-raqmon-mib-01 Summary: 11 errors (**), 0 flaws (~~), 49 warnings (==), 19 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 Inc. 6 Eugene Golovinsky 7 BMC Software 8 15 Jan 2003 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 (2003). All Rights Reserved. 35 Abstract 37 This memo defines a common protocol data unit (PDU) used between 38 RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report 39 a QOS statistics using RTCP and SNMP as Transport Protocol. 41 The original RAQMON draft [SIDDIQUI3] was split into 3 parts to 42 identify the RAQMON Framework, RAQMON QOS PDU and RAQMON MIB. 44 This memo defined RAQMON QOS Protocol Data Unit (PDU). This memo also 45 outlines mechanisms to use Real Time Transport Control Protocol 46 (RTCP) and Simple Network Management Protocol (SNMP) to transport 47 these PDUs between RAQMON Data Source (RDS) and RAQMON Report 48 Collector (RRC) as outlined in RAQMON Charter of the RMON Workgroup. 50 The memo [SIDDIQUI2] defines a Real-Time Application QOS Monitoring 51 (RAQMON) Framework that extends the RMON Framework to allow Real-time 52 Application QoS information as outlined by RAQMON Charter of the RMON 53 Workgroup. 55 The memo [SIDDIQUI1] defines a portion of the Management Information 56 Base (MIB) for use with network management protocols in the Internet 57 community. The document proposes an extension to the Remote 58 Monitoring MIB [RFC2819] to accommodate RAQMON solution. 60 Distribution of this memo is unlimited. 62 Table of Contents 64 Status of this Memo 1 65 Abstract 1 66 1 Introduction 2 67 2 RAQMON Protocol Data Unit (PDU) Design Overview 3 68 3 Measurement Methodology 4 69 4 RAQMON PDU Format 5 70 5 Transporting RAQMON Protocol Data Units 15 71 6 Normative References 20 72 7 Normative References 20 73 8 Intellectual Property 23 74 9 Security Considerations 24 75 10 IANA Considerations 25 76 11 Authors' Addresses 25 77 A Full Copyright Statement 26 79 1. Introduction 81 This memo defines a common protocol data unit (PDU) used between 82 RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report 83 a QOS statistics using RTCP and SNMP as an underlying transport 84 protocol as outlined in RAQMON Framework draft. 86 The original RAQMON draft [SIDDIQUI3] was split into 3 parts to 87 identify the RAQMON framework, RAQMON PDU and RAQMON MIB. This memo 88 takes the portion of [SIDDIQUI3] that defined RAQMON QOS PDU and 89 describes how various PDUs can be transported over existing 90 Application level transport protocol like Real Time Control Protocol 91 (RTCP) and Simple Network Management Protocol (SNMP) to transport 92 application QOS statistics between RDS and RRC. 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. RAQMON Protocol Data Unit (PDU) Design Overview 100 This memo defines a common protocol data unit (PDU) used between 101 RAQMON Data Source (RDS) and RAQMON Report Collector (RRC) to report 102 a QOS statistics using RTCP and SNMP as an underlying transport 103 protocol as outlined in RAQMON Framework draft. RAQMON Protocol Data 104 Unit (PDU) provides a generic structure exchanged between RDS and RRC 105 to report QOS parameters in Real-time. 107 RAQMON continues the architecture created in the RMON[RFC2819] by 108 providing analysis of application performance as experienced by end- 109 users on a specific IP end point and correlating such performance to 110 its underlying transport network characteristics, application level 111 transactions and host performance. RAQMON protocol data units provide 112 a vehicle to these end points and applications to report such 113 statistics in real-time to a target collector within a specific 114 administrative domain. 116 RAQMON provides a framework to report QOS statistics for simplex 117 flows, i.e., it reports statistics only in one direction. Therefore, 118 within RAQMON Framework, a RAQMON PDU logically contains QOS 119 parameter information as perceived by the reporting end device or 120 applications. RAQMON operates on top of RTCP, SNMP, TCP, UDP, IPv4 or 121 IPv6 occupying the place of a payload specification at the 122 application layer in the protocol stack. However, RAQMON PDUs does 123 not transport application data but is rather uses existing internet 124 protocols like RTCP APP Packet and SNMP INFORM to be transported from 125 a RDS to RRC. Like the implementations of routing and management 126 protocols, an implementation of RAQMON will typically execute in the 127 background, not in the data forwarding path. RAQMON PDUs by itself is 128 not a transport protocol; RAQMON PDUs are designed to operate with 129 current and future internet transport protocols. 131 RAQMON Protocol Data Units (PDU) can be used by many Real-time as 132 well as Non-Real time Applications to report QOS statistics and 133 considered as an extension of RMON. Voice over IP, Fax over IP, Video 134 over IP, Instant Messaging, Email, ftp/tftp based downloads, e- 135 business style transactions, web access from handheld devices or cell 136 phones are few example application scenarios where such a framework 137 could be useful. 139 RAQMON PDUs are common data formats commonly understood by RDS and 140 RRC to exchange RAQMON Statistics (i.e. "Name" and "Value" pair). 141 RAQMON PDUs offer an entry (a.k.a. "Name") to be filled in by 142 application specific software which with a specific "value" in real- 143 time before an RDS emits such a PDU towards a RRC. 145 It is out of the scope of PDU specification to either recommend or 146 validate specific measurement methodology used to gather a "value" 147 for a specified "name". These PDUs are transmitted over Real Time 148 Control Protocol (RTCP) or Simple Network Management Control Protocol 149 (SNMP) to ensure reuse of existing internet standards. 151 There are 2 types of PDUs within the RAQMON Framework: 153 BASIC PDU: A BASIC PDU provides mechanisms to report some frequently 154 used parameters from a pre listed parameter suit defined in table 1. 155 Application developers have the flexibility to make an RDS report a 156 sub-set of these pre-set parameters to RRC appropriate for an 157 application context. For example, An IP Phone developer might want to 158 use RAQMON BASIC PDU to report End-to-End Delay, Jitter, packet loss 159 etc while the Instant Message client can use the same BASIC PDU to 160 report only Packet Loss and End-to-End Delay. 162 APP PDU: Since is difficult to design a BASIC PDU that meets the 163 needs of all applications, RAQMON provides APP PDUs for further 164 extension required to convey application, vendor, device etc. 165 specific parameters for future usage. Additional parameters can be 166 defined within payload of the APP PDU as Type length Value (TLV) 167 pairs and defined by the application developers or vendors. 169 RAQMON PDUs, provides RDSs the flexibility to decide the parameters, 170 an end device/application is willing to report. RAQMON PDUs also 171 provide the RRCs the flexibility to store the parameters an 172 administrative domain feel important for a domain. 174 Following sections of this memo contains detailed RAQMON PDU 175 specifications. 177 3. Measurement Methodology 179 It is not the intent of this document to recommend a methodology to 180 measure any of the QOS parameters defined in. However a complete list 181 of definitions of metrics used within RAQMON PDUs are defined in 182 through reference to 183 other appropriate existing IETF standards organizations' documents. 184 There are many different methodologies available for measuring 185 application performance (e.g., probe-based, client-based, synthetic- 186 transaction, etc.). This specification does not mandate a particular 187 methodology - it is open to any that meet the minimum requirements. 188 Conformance to this specification requires that the collected data be 189 presented appropriately to match the RAQMON PDU semantics described 190 herein. 192 4. RAQMON PDU Format 194 There are 2 types of RAQMON PDUs used by the RDS to report various 195 QOS parameters to RRC. 197 BASIC PDU: For reporting monitored data from an RDS to RRC which 198 includes QOS parameters defined in . BASIC PDU are identified by inspecting the PDT 200 field within the PDU. BASIC PDUs are marked as PDT = 1 202 APP PDU: APP PDUs are marked as PDT = 4 204 Following is various RAQMON PDU formats: 206 0 1 2 3 207 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 208 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 209 | V |P| RC | | | |X|PDT = 1| Length | 210 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 211 | DSRC | 212 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 213 |RC X |N| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 214 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 215 | Data Source Address {DA} | 216 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 217 | Receiver's Address (RA) | 218 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 219 | NTP Timestamp, most significant word | 220 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 221 | NTP Timestamp, least significant word | 222 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 223 | Length | Application Name (AN) ... | 224 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 225 | ... | 226 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 227 | Length | Data Source Name (DN) ... | 228 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 229 | ... | 230 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 231 | Length | Receiver's Name (RN) ... | 232 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 233 | ... | 234 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 | Length | Session State ... | 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 | ... | 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | Session Duration | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | End-to-End Delay | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Cumulative Packet Loss | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Total # Packets sent | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Total # Packets received | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Total # Octets sent | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | Total # Octets received | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 253 | Source Port Used | Receiver Port Used | 254 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 | S_Layer2 | S_Layer3 | S_Layer2 | S_Layer3 | 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 |Source Payload |Reciver Payload| CPU | Memory | 258 |Type | Type | Utilization | Utilization | 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 | Session Setup Delay | Inter arrival Jitter | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | Padding |x|x|x|x|x|x|x|x| Packet loss | 263 | |x|x|x|x|x|x|x|x| (In fraction)| 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 Figure 2 - Basic Protcol Data Unit 268 4.1 BASIC Protocol Data Unit (PDU) 270 version (V) : 3 bits - Identifies the version of RAQMON. This version 271 is 1. 273 padding (P): 1 bit - If the padding bit is set, this RAQMON packet 274 contains some additional padding octets at the end which are not part 275 of the monitoring information. The last octet of the padding is a 276 count of how many padding octets should be ignored. Padding may be 277 needed by some applications as reporting is based on the intent of 278 RDS to report certain parameters. 280 record count (RC): 4 bits - Total number of records contained in this 281 packet. A value of zero is valid but useless. 283 reserved bits: 3 bits - reserved for future extensions to the RAQMON 284 Packet. 286 IPversion Flag: 1 bit - While set to 1, IP Version Flag indicates 287 that IP addresses are IP version 6 compatible. 289 PDU Type (PDT): 4 bits - This indicates the type of RAQMON PDU being 290 sent. There are 2 types of RAQMON PDUs. BASIC PDU (PDT = 1) and APP 291 PDU (PDT =4). 293 length: 16 bits - The length of this RAQMON packet in 32-bit words 294 minus one which includes the header and any padding. 296 DSRC: 32 bits - Data Source identifier represents a unique session 297 descriptor that points to a specific communication session between 298 communicating entities. Uniqueness of DSRC is valid only within a 299 session. DSRC values should be randomly generated using vendor 300 chosen algorithms. It is not sufficient to obtain a DSRC simply by 301 calling random() without carefully initializing the state. It is 302 beyond the scope of this document define an algorithm to generate 303 DSRC. However one could very easily use an algorithm like the one 304 defined in Appendix A.6 in [17]. Depending on the choice of 305 algorithm, there is a finite probability that two DSRCS from two 306 different RDSs may be same. To further reduce the probability that 307 two RDSs pick the same DSRC, it is recommended that an RRC or an 308 application use Data Source Address (DA) and Data Source Name (DN) in 309 conjunction with a DSRC value to reduce that probability drastically. 311 Each RAQMON packet consists of a DSRC followed by RC_n and RAQMON 312 flags to indicate presence of appropriate RAQMON parameters as 313 defined in table 1. 315 RC_n: 4 bits - Record Count number to which the information in this 316 record pertains. Record Count number indicates a sub-session within a 317 communication session. A value of zero is a valid record number. 318 Maximum number of records that can be described in one RAQMON Packet 319 is 16 (i.e. 0000 - 1111). 321 RAQMON Parameter Presence Flags (RPPF): 28 bits 323 Each of these flags while set represent that this RAQMON packet 324 contains corresponding parameters as specified in table 2 326 0 1 2 3 327 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 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 | V |P| RC | | | |X|PDT = 1| Length | 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | DSRC | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 333 |RC N |8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1|0|9|8|7|6|5|4|3|2|1| 334 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 Sequence Number Presence/Absence of corresponding 337 Parameter within this RAQMON packet 339 1 Data Source Address (DA) 341 2 Receiver Address (RA) 343 3 NTP Timestamp 345 4 Application Name 347 5 Data Source Name (DN) 349 6 Receiver Name (RN) 351 7 Session Setup Status 353 8 Session Duration 355 9 End-to-End Delay 357 0 Cumulative Packet Loss 359 1 Total number of Packets sent 361 2 Total number of Packets received 363 3 Total number of Octets sent 365 4 Total number of Octets received 367 5 Source Port Used 369 6 Receiver Port Used 371 7 S_Layer2 373 8 S_Layer3 375 9 D_Layer2 377 0 D_Layer3 378 1 Source Payload Type 380 2 Receiver Payload Type 382 3 CPU Utilization 384 4 Memory Utilization 386 5 Session Setup Delay 388 6 Inter arrival Jitter 390 7 Packet loss (in fraction) 392 8 RAQMON Optional Flag (ROF) 394 Table 2: RAQMON Parameters and corresponding RPPF 396 Data Source Name: - Data Source Name field starts with an 8-bit octet 397 count describing the length of the text and the text itself. Note 398 that the text can be no longer than 255 octets. The text is encoded 399 according to the UTF-2 encoding specified in Annex F of ISO standard 400 10646 [ISO10646],[UNICODE]. This encoding is also known as UTF-8 or 401 UTF-FSS. It is described in "File System Safe UCS Transformation 402 Format (FSS_UTF)", X/Open Preliminary Specification, Document Number 403 P316 and Unicode Technical Report #4. US-ASCII is a subset of this 404 encoding and requires no additional encoding. The presence of multi- 405 octet encoding is indicated by setting the most significant bit of a 406 character to a value of one. Text is not null terminated because some 407 multi-octet encoding include null octets. Data Source Name is 408 terminated by one or more null octets, the first of which is 409 interpreted as to denote the end of the string and the remainder as 410 needed to pad until the next 32-bit boundary. Since the Data Source 411 Name is expected to remain constant for the duration of the session, 412 it is recommended that RDS report such field only once within a 413 communication session to ensure efficient usage of network and system 414 resources. 416 Receiver Name: - Same as Data Source Name. Data Source Name and 417 Receiver's Name are contiguous, i.e., items are not individually 418 padded to a 32-bit boundary. 420 Data Source Address: 32 bits - The standard ASCII representation of 421 the end device's numeric address on the interface used for the 422 communication session. The standard ASCII representation of an IP 423 Version 4 address is "dotted decimal", also known as dotted quad. 424 Other address types are expected to have ASCII representations that 425 are mutually unique. 135.8.45.178 is an example of a valid Data 426 Source Address. Since the Data Source Address is expected to remain 427 constant for the duration of the session, it is recommended that RDS 428 report such field only once within a communication session to ensure 429 efficient usage of network and system resources. 431 Issue: IP addresses, TCP/UDP ports information should be removed (NAT 432 un-friendly). One of the way to avoid this problem is to use 433 Application Layer Gateways (ALGs) to fill out IP Addresses on RDS's 434 behalf. 436 Receiver Address: 32 bits - Same as Data Source Address 438 Application Name: - Application Name field starts with an 8-bit octet 439 count describing the length of the text and the text itself. 440 Application name field has same format as Data Source Name. This is a 441 text string giving the name and possibly version of the application 442 associated to that session, e.g., "XYZ VoIP Agent 1.2". This 443 information may be useful for debugging purposes and is similar to 444 the Mailer or Mail-System-Version SMTP headers. Since the 445 Application Name is expected to remain constant for the duration of 446 the session, it is recommended that RDS report such field only once 447 within a communication session to ensure efficient usage of network 448 and system resources. 450 NTP timestamp: 64 bits - Indicates the wallclock time when the RAQMON 451 packet was sent so that it may be used by the RRC to store Date/Time. 452 A Data Source that has no notion of wallclock or time may set the NTP 453 timestamp to zero. However that will waste 32 bits in the packet. An 454 RDS should set the appropriate RAQMON flag to 0 to avoid such waste. 455 Since NTP time stamp is intended to provide Date/Time of a session, 456 it is recommended that the NTP Timestamp be used only in the first 457 RAQMON packet to use network resources efficiently. However such a 458 recommendation is context sensitive and should be enforced as deemed 459 necessary by each application environment. 461 The full resolution NTP timestamp is a 64-bit unsigned fixed-point 462 number with the integer part in the first 32 bits and the fractional 463 part in the last 32 bits. In some fields where a more compact 464 representation is appropriate, only the middle 32 bits are used; that 465 is, the low 16 bits of the integer part and the high 16 bits of the 466 fractional part. The high 16 bits of the integer part must be 467 determined independently. 469 Session Setup Status: - Session State field starts with an 8-bit 470 octet count describing the length of the text and the text itself. 471 This field is used to describe appropriate communication session 472 states e.g. Call Established successfully, RSVP reservation failed 473 etc. 475 Session Duration: 32 bits - Session Duration is an unsigned Integer 476 expressed in the order of seconds. 478 End-to-End Delay: 32 bits - End-to-End Delay is an unsigned Integer 479 expressed in the order of milliseconds. 481 Cumulative Packet Loss: 32 bits - The total number of packets from 482 session RC_n that have been lost while this RAQMON packet was 483 generated. This number is defined to be the number of packets 484 expected less the number of packets actually received. 486 Total number of Packets sent: 32 bits - The total number of packets 487 transmitted within a communication session by the sender since 488 starting transmission up until the time this RAQMON packet was 489 generated. This counter is reset if the DSRC identifier is changed as 490 it indicates a different session. 492 Total number of Packets received: 32 bits - The total number of 493 packets transmitted within a communication session by the receiver 494 since starting transmission up until the time this RAQMON packet was 495 generated. This counter is reset if the DSRC identifier is changed as 496 it indicates a different session. 498 Total number of Octets sent: 32 bits - The total number of payload 499 octets (i.e., not including header or padding) transmitted in packets 500 by the sender within a communication session since starting 501 transmission up until the time this RAQMON packet was generated. This 502 counter is reset if the DSRC identifier is changed as it indicates a 503 different session. 505 Total number of Octets received: 32 bits - The total number of 506 payload octets (i.e., not including header or padding) transmitted in 507 packets by the receiver within a communication session since starting 508 transmission up until the time this RAQMON packet was generated. This 509 counter is reset if the DSRC identifier is changed as it indicates a 510 different session. 512 Source Port Used: 16 bits - Port Number used by the Data Source as 513 used by the application while this RAQMON Packet was generated. 515 Receiver Port Used: 16 bits - Same as Source Port Used 517 S_Layer2: 8 bits - Source Layer 2 priorities used to send packets to 518 the receiver by this data source during this communication session. 519 For example priority bits associated to IEEE 802.1p values for 520 appropriate priorities. For example priority bits associated to IEEE 521 802.1p tags value of 5 reported via S_Layer2 parameter would indicate 522 Video over IP from this data source is prioritized by some Layer 2 523 switch. 525 S_Layer3: 8 bits - Layer 3 priorities used to send packets to the 526 receiver by this data source during this communication session. For 527 example priority bits associated to IP Precedence (i.e. 101XXXXX) or 528 DiffServ PHB values (i.e EF, AF41) etc reported via S_Layer3 529 parameter would indicate whether applications from this data source 530 is prioritized by some Layer 3 switch or not. 532 D_Layer2: 8 bits - Layer 2 priorities used by the receiver to send 533 packets to the data source during this communication session if the 534 Data Source can learn such information. 536 D_Layer3: 8 bits - Layer 3 priorities used by the receiver to send 537 packets to the data source during this communication session if the 538 Data Source can learn such information. 540 Source Payload Type: 8 bit - This document follows definition of 541 Payload Type (PT) as definition is in [RFC1890]. This 8 bit fields 542 specify the type of audio, video or data media used to send packets 543 to the receiver by this data source during a communication session. 544 Table 3 indicates a small list of various Payload types as defined in 545 [RFC1890] cited here for informational purposes. As this table 546 indicates, if an application ought to indicate that the Source Pay 547 Load Type used for a session were PCMA, Source Payload Field of the 548 BASIC RAQMON packet ought to be 8. 550 PT encoding audio/video clock rate channels 551 name (A/V) (Hz) (audio) 552 _______________________________________________________________ 553 0 PCMU A 8000 1 554 1 1016 A 8000 1 555 2 G721 A 8000 1 556 3 GSM A 8000 1 557 4 unassigned A 8000 1 558 5 DVI4 A 8000 1 559 6 DVI4 A 16000 1 560 7 LPC A 8000 1 561 8 PCMA A 8000 1 562 9 G722 A 8000 1 563 10 L16 A 44100 2 564 11 L16 A 44100 1 565 12 unassigned A 566 13 unassigned A 567 14 MPA A 90000 (see text) 568 15 G728 A 8000 1 569 16--23 unassigned A 570 24 unassigned V 571 25 CelB V 90000 572 26 JPEG V 90000 573 27 unassigned V 574 28 nv V 90000 575 29 unassigned V 576 30 unassigned V 577 31 H261 V 90000 578 32 MPV V 90000 579 33 MP2T AV 90000 580 34--71 unassigned ? 581 72--76 reserved N/A N/A N/A 582 77--95 unassigned ? 583 96--127 dynamic ? 585 Table 3: Payload types (PT) for standard audio and video encodings 587 Please refer to [RFC1890] for various other Audio, Video and Data 588 related payload types. 590 CPU Utilization: 8 bits - Percentage of CPU used over a time 591 duration. 593 Memory Utilization: 8 bits - Percentage of total memory over a time 594 duration. 596 Session Setup Delay: 16 bits - Indicates the duration of time 597 required by a network communication controller to set a media path 598 between the communicating entities or the end devices. This parameter 599 is expressed in milliseconds. 601 Inter-Arrival Jitter: 16 bits - An estimate of the statistical 602 variance of packets inter-arrival time expressed in milliseconds. 604 Packet Loss in Fraction: 8 bits - The fraction of packets from data 605 source lost since the previous RAQMON was dispatched, expressed as a 606 fixed point number with the binary point at the left edge of the 607 field. (That is equivalent to taking the integer part after 608 multiplying the loss fraction by 256.) This fraction is defined to be 609 the number of packets lost divided by the number of packets expected. 611 RAQMON Optional Flag: 8 bits - These bits are open to various vendors 612 to be used for application specific bit level signaling. These 8-bit 613 Optional Flags are interpreted by the application, not by the RRC and 614 usage of these left at the application developer's discretion. 616 4.2 Mapping of Basic RAQMON Packet to SNMP notification 618 The information carried by Basic RAQMON packet MAY be delivered by 619 SNMP notifications. This delivery mechanism works in conjunction with 620 RAQMON Notifications defined in [SIDDIQUI1]. As described in Section 621 5.1, the use of SNMP Informs is RECOEMDED. Full compliance with 622 RFC2273 to support Command Responder/Notification Originator 623 applications is NOT REQUIRED. This is to be left up to implementer. A 624 RAQMON device can implement either a full SNMP agent, or a subset 625 that sends RAQMON PDUs in a format similar to SNMP Informs. The 626 section of the draft defines mapping mechanism of information carried 627 by Basic RAQMON Packet to SNMP notification PDU(s). 629 4.3 APP Protocol Data Unit (PDU) 631 The APP PDU is intended for experimental use as new applications and 632 new features are developed, without requiring packet type value 633 registration. APP packets with unrecognized names should be ignored. 634 After testing and if wider use is justified, it is recommended that 635 each APP packet be redefined without the subtype and name fields and 636 registered with the Internet Assigned Numbers Authority (IANA). 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | V |P| RC | | | |X|PDT = 4| Length | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | DSRC | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | Data Source Address {DA} | 646 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 | APP packet name | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | application dependent data | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 Figure 3 - RAQMON APP Protcol Data Unit 656 version (V), padding (P), record count (RC): As defined for BASIC 657 Packet. 659 reserved bits: 3 bits - reserved for future extensions to the RAQMON 660 Packet. 662 IPversion Flag: As defined for BASIC Packet. 664 DSRC and DA: As defined for BASIC Packet. 666 subtype: 4 bits - May be used as a subtype to allow a set of APP PDUs 667 to be defined under one unique name, or for any application-dependent 668 data. 670 pdu type (PDT): 4 bits - Contains the constant 4 to identify this as 671 an RAQMON APP PDU. 673 name: 4 octets - A name chosen by the person defining the set of APP 674 PDUs to be unique with respect to other APP PDUs this application 675 might receive. The application creator might choose to use the 676 application name, and then coordinate the allocation of subtype 677 values to others who want to define new packet types for the 678 application. Alternatively, it is recommended that others choose a 679 name based on the entity they represent, then coordinate the use of 680 the name within that entity. The name is interpreted as a sequence of 681 four ASCII characters, with uppercase and lowercase characters 682 treated as distinct. 684 application-dependent data: variable length - Application-dependent 685 data may or may not appear in an APP packet. It is interpreted by the 686 application and not by the RRC itself. It must be a multiple of 32 687 bits long. 689 4.4 Byte Order, Alignment, and Time Format of RAQMON PDUs 691 All integer fields are carried in network byte order, that is, most 692 significant byte (octet) first. This byte order is commonly known as 693 big-endian. The transmission order is described in detail in 694 [RFC791]. Unless otherwise noted, numeric constants are in decimal 695 (base 10). 697 All header data is aligned to its natural length, i.e., 16-bit fields 698 are aligned on even offsets, 32-bit fields are aligned at offsets 699 divisible by four, etc. Octets designated as padding have the value 700 zero. 702 5. Transporting RAQMON Protocol Data Units 704 It is an inherent objective of the RAQMON Framework to re-use 705 existing application level transport protocols to maximize the usage 706 of existing installations as well as to avoid transport protocol 707 level complexities in the design process. As outlined in the RAQMON 708 framework document that both the Real-Time Transport Control Protocol 709 and Simple Network Management Protocol were suitable to meet the 710 criteria of a transport protocol as outlined in the RAQMON Charter. 712 Section 5. 1 reflects mechanisms that uses SNMP INFORM PDUs as 713 transport protocol and section 5.2 elaborates a protocol that uses 714 RTCP APP Packets [RFC 1889] to transport RAQMON PDUs between RDS and 715 RRC. 717 5.1 SNMP INFORM PDUs as RDS/RRC Network Transport Protocol The idea is 718 to re-use SNMP INFORM PDU. This proposal offers that: 720 + RDSs implement the capability of embedding RAQMON parameters in 721 SNMP INFORM Request and thus re-using well known SNMP mechanisms to 722 report RAQMON Statistics. 724 + To keep the RDS realization simple and keep the protocol 725 lightweight, the RDSs will not be REQUIRED to respond to SNMP 726 requests like get, set, etc., as an SNMP compliant responder would. 728 + If the RRC chooses to implement an SNMP manager, an SNMP INFORM 729 Response would be sent for each associated SNMP INFORM originated by 730 the RDS. 732 + The RDS may ignore the SNMP INFORM Responses, or, if better 733 reliability is required, will wait for the Inform response, 734 retransmitting the original Inform PDU every M seconds until it has 735 been sent N times. 737 + The SNMP INFORM transport for RAQMON PDUs can use one of the two 738 UDP ports assignments: 740 - Standard UDP port 162 used for SNMP Notifications, if full SNMP 741 entities implementations are present in the RRC and RDS 743 - IANA assigned UDP port 5YYYY for RAQMON PDUs carried over SNMP, for 744 the cases when at least one of the RRC and RDS does not support a 745 full implementation of the SNMP entities. 747 The benefits of using SNMP Informs are: - Using a well-known 748 protocol. - Privacy and authentication are covered by SNMPv3 - 749 Limited or no need for specific RAQMON-protocol code in the RRC, as 750 it can use an SNMP manager implementation to process Informs. 752 The drawback of this approach is the overhead SNMP puts on low- 753 powered RDSs, for instance - BER encoding. 755 5.1.1 Encoding RAQMON PDU format within a small set of MIB items. 757 The RAQMON PDU defined in Section 4.1 is encapsulated in the 758 raqmonPDUBasicPDU MIB object from the RAQMON MIB [SIDDIQUI1]. This 759 object has a SYNTAX of an OCTET STRING variable, which encodes the 760 content of the data fields described in figure 2. The Inform Request 761 will contain this object. 763 5.1.2 SNMP Inform PDU Related Issues as applied to RAQMON 765 Using SNMP INFORM PDUs for RAQMON has all the advantages offered by a 766 well known protocol like SNMP. Privacy and authentication issues 767 related to RAQMON are "mostly" covered by SNMPv3 769 However there are certain challenges in using SNMP for RAQMON too. 770 And they are: - The benefit is added flexibility of the proposed by 771 RAQMON Framework could be constrained. - Sending out 772 Acknowledgements from RRCs to RDSs can create bottleneck as 773 additional RDS load is created, specially when the RRCs will be 774 receving many Inform PDUs from many RRcs. - Sending ACKs also wastes 775 network bandwidth. In a reasonable sized Enterprise and Service 776 provider systems this can be a significant amount of load. 778 To get rid of the Ack as the RDS/RRC protocol which needs not be 779 acknowledgement oriented, SNMP Traps could be used instead of 780 Informs. This will allow one to use SNMP without avoiding 781 performance related issues as mentioned above, with the disadvantage 782 of loss of reliability in passing the information. 784 5.2 Mapping RAQMON PDUs to RTCP as RDS/RRC Network Transport Protocol 786 The RAQMON PDU Transfer is comprised of unidirectional exchange of 787 PDUs between RDSs and an RRC. The protocol data units are mapped to 788 a connectionless datagram service (UDP). 790 As outlined in RFC 1889, an RTCP APP packet allows Applications to 791 defined RTCP packets. Within RTCP framework, a RAQMON PDUs is 792 represented as an Application Specific Report and uses RTCP APP 793 Packets to transport RAQMON PDU. 795 Figure 4 below shows how RAQMON PDUs can use RTCP APP Packets to 796 transport RAQMON PDUs between RDS and RRC. 798 0 1 2 3 799 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 800 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 801 |V=2|P| subtype | PT=APP=204 | length | 802 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 803 | SSRC/CSRC | 804 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 805 | name (ASCII) = "RAQMON" | 806 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 807 | RAQMON BASIC PDU | 808 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 810 Figure 4 - Using RTCP APP Packets to transport RAQMON PDUs 812 The RTCP APP packets are intended for experimental use as new applications 813 and new features are developed, without requiring packet type value 814 registration. To be backward compatible RTCP APP packets used by RAQMON 815 SHOULD be Internet Assigned Numbers Authority (IANA) Registered. 817 version (V), padding (P), length: 818 As described for the SR packet (see Section 6.3.1). 820 subtype: 5 bits 821 subtype 1 in RAQMON Specific RTCP APP packet SHOULD be used by the BASIC 822 RAQMON PDU and subtype 2 should be preserved for RAQMON APP PDUs. 823 These unique definitions will be IANA registered. 825 packet type (PT): 8 bits 826 Contains the constant 204 to identify this as an RTCP APP packet. 828 name: 4 octets 829 The name chosen by the RMON WG defining the set of APP packets will be 830 unique with respect to other APP packets and will be IANA Registered as 831 "RAQMON" with all uppercase. The name field in RTCP APP Packet is 832 interpreted as a sequence of four ASCII characters. 834 application-dependent data: variable length 835 RAQMON PDUs sent by the RDS in the format specified in Figure 4 will 836 be interpreted by the RAQMON Report Collector (RRC) and not RTP itself. 837 RAQMON PDUs must be a multiple of 32 bits long. 839 + During a monitored real-time session, the RDS emits a Report PDU 840 every M seconds toward the RRC as provisioned by the RDS. 842 + The RRC collects the Report PDUs and correlate them with its 843 database. 845 Though this is a simple one-way send protocol, the RDSs will not be 846 capable of inferring whether a PDU was received by the RRC as Report 847 PDUs are transmitted over a lossy network. 849 So one uses proposed RTCP like protocol as RDS/RRC Network Transport 850 Protocol each Report PDU must contain enough information to uniquely 851 identify the PDUs and correlate to an ongoing session. RRCs could use 852 DSRC field and a unique device ID (i.e. like 6 Octet MAC address or IP 853 Address) to define a unique session. 855 However this will cause 6-octet overhead worth wasted bandwidth per 856 PDU. 858 5.2.1 - Pseudo code for RDS & RRC 860 RDS: 862 when (session starts} { 863 report.identifier = session.endpoints, session.starttime; 864 report.timestamp = 0; 865 while (session in progress) { 866 wait interval; 867 report.statistics = update statistics; 868 report.curtimestamp += interval; 869 if encryption required 870 report_data = encrypt(report, encrypt parameters); 871 else 872 report_data = report; 873 raqmon_pdu = header, report_data; 874 send raqmon-pdu; 875 } 876 } 877 RRC: 878 listen on raqmon port 879 when ( raqmon_pdu received ) { 880 decrypt raqmon_pdu.data if needed 882 if report.identifier in database 883 if report.current_time_stamp > last update 884 update session statistics from report.statistics 885 else 886 discard report 887 } 889 5.2.2 Port Assignment 891 As specified in the previous sections that Transport of RAQMON PDUs can be 892 performed using various underlying network transport protocol like TCP and 893 UDP. 895 Applications operating under RAQMON Framework may use any unreserved 896 UDP port. For example, a session management program can allocate the 897 port randomly. A single fixed port cannot be required because multiple 898 applications using RAQMON are likely to run on the same host, and 899 there are some operating systems that do not allow multiple processes 900 to use the same UDP port with different multicast addresses. 902 However, port numbers 5XXX have been registered with IANA for use with 903 those applications that choose to use them as the default port for RAQMON 904 PDUs over RTCP. Hosts that run multiple applications may use this port as an 905 indication to have used RAQMON if they are not subject to the constraint of the 906 previous paragraph. 908 Applications need not have a default and may require that the port be 909 explicitly specified. The particular port number was chosen to lie in 910 the range above 5000 to accommodate port number allocation practice 911 within the Unix operating system, where privileged processes can only 912 use port numbers below 1024 and port numbers between 1024 and 5000 are 913 automatically assigned by the operating systems. 915 6. Normative References 917 [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 918 Rose, M. and S. Waldbusser, "Structure of Management 919 Information Version 2 (SMIv2)", STD 58, RFC 2578, April 920 1999. 922 [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 923 Rose, M. and S. Waldbusser, "Textual Conventions for 924 SMIv2", STD 58, RFC 2579, April 1999. 926 [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 927 Rose, M. and S. Waldbusser, "Conformance Statements for 928 SMIv2", STD 58, RFC 2580, April 1999. 930 [RFC2819] Waldbusser, S., "Remote Network Monitoring Management 931 Information Base", STD 59, RFC 2819, May 2000 933 [RFC1889] Henning Schulzrinne, S. Casner, R. Frederick, and V. Jacobson, 934 "RTP: A Transport Protocol for Real-Time Applications" 935 RFC 1889, January 1996. 937 [RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. 939 7. Informative References 941 [RFC2571] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture 942 for Describing SNMP Management Frameworks", RFC 2571, April 943 1999. 945 [RFC1155] Rose, M., and K. McCloghrie, "Structure and Identification 946 of Management Information for TCP/IP-based Internets", STD 947 16, RFC 1155, May 1990. 949 [RFC1212] Rose, M., and K. McCloghrie, "Concise MIB Definitions", STD 950 16, RFC 1212, March 1991. 952 [RFC1215] M. Rose, "A Convention for Defining Traps for use with the 953 SNMP", RFC 1215, March 1991. 955 [RFC1157] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple 956 Network Management Protocol", STD 15, RFC 1157, May 1990. 958 [RFC1901] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 959 "Introduction to Community-based SNMPv2", RFC 1901, January 960 1996. 962 [RFC1906] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 963 "Transport Mappings for Version 2 of the Simple Network 964 Management Protocol (SNMPv2)", RFC 1906, January 1996. 966 [RFC2572] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 967 Processing and Dispatching for the Simple Network Management 968 Protocol (SNMP)", RFC 2572, April 1999. 970 [RFC2574] Blumenthal, U., and B. Wijnen, "User-based Security Model 971 (USM) for version 3 of the Simple Network Management 972 Protocol (SNMPv3)", RFC 2574, April 1999. 974 [RFC1905] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 975 "Protocol Operations for Version 2 of the Simple Network 976 Management Protocol (SNMPv2)", RFC 1905, January 1996. 978 [RFC2573] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", 979 RFC 2573, April 1999. 981 [RFC2575] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based 982 Access Control Model (VACM) for the Simple Network 983 Management Protocol (SNMP)", RFC 2575, April 1999. 985 [RFC2570] Case, J., Mundy, R., Partain, D., and B. Stewart, 986 "Introduction to Version 3 of the Internet-standard Network 987 Management Framework", RFC 2570, April 1999. 989 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 990 Requirement Levels", BCP 14, RFC 2119, March 1997. 992 [RFC2613] Waterman, R., Lahaye, B., Romascanu, D., and S. Waldbusser, 993 "Remote Network Monitoring MIB Extensions for Switched 994 Networks, Version 1.0", RFC 2613, June 1999 996 [RFC1213] McCloghrie, K., and M. Rose, Editors, "Management 997 Information Base for Network Management of TCP/IP-based 998 internets: MIB-II", STD 17, RFC 1213, March 1991. 1000 [RFC2863] McCloghrie, K., and Kastenholtz, F., "The Interfaces Group 1001 MIB", RFC 2863, June 2000. 1003 [RFC1890] H. Schulzrinne, "RTP Profile for Audio and Video Conferences 1004 with Minimal Control" RFC 1890, January 1996. 1006 [RFC1305] Mills, D., "Network Time Protocol Version 3", RFC 1305, 1007 March 1992. 1009 [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities", 1010 STD 13, RFC 1034, November 1987. 1012 [RFC1035] Mockapetris, P., "Domain Names - Implementation and 1013 Specification", STD 13, RFC 1035, November 1987. 1015 [RFC1123] Braden, R., "Requirements for Internet Hosts - Application 1016 and Support", STD 3, RFC 1123, October 1989. 1018 [RFC1597] Rekhter, Y., Moskowitz, R., Karrenberg, D., and G. de Groot, 1019 "Address Allocation for Private Internets", RFC 1597, March 1994. 1021 [RFC2679] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Delay 1022 Metric for IPPM", RFC 2679, September 1999 1024 [RFC2680] G. Almes, S.kalidindi and M.Zekauskas, "A One-way Packet 1025 Loss Metric for IPPM", RFC 2680, September 1999 1027 [RFC2681] G. Almes, S.kalidindi and M.Zekauskas, "A Round-Trip Delay 1028 Metric for IPPM", RFC 2681, September 1999 1030 [WALDBUSSER] Steven Waldbusser, "Application Performance Measurement MIB", 1031 draft-ietf-rmonmib-apm-mib-04.txt, July 2001 1033 [DIETZ] Russel Dietz, Robert Cole, "Transport Performance Metrics MIB", 1034 draft-ietf-rmonmib-tpm-mib-03.txt, July 2001 1036 [ISO10646] International Standards Organization, "ISO/IEC DIS 10646-1:1993 1037 information technology -- universal multiple-octet coded 1038 character set (UCS) -- part I: Architecture and basic 1039 multilingual plane," 1993. 1041 [UNICODE] The Unicode Consortium, The Unicode Standard New York, 1042 New York:Addison-Wesley, 1991. 1044 [IEEE802.1D] Information technology-Telecommunications and information 1045 exchange between systems--Local and metropolitan area networks- 1046 Common Specification a--Media access control (MAC) bridges: 1047 15802-3: 1998 (ISO/IEC) [ANSI/IEEE Std 802.1D, 1998 Edition] 1049 [RFC1349] P. Almquist, "Type of Service in the Internet Protocol Suite", 1050 RFC 1349, July 1992 1052 [RFC1812] F. Baker, "Requirements for IP Version 4 Routers" RFC1812, 1053 June 1995 1055 [RFC2474] K. Nicholas, S. Blake, F. Baker and D. Black, "Definition of the 1056 Differentiated Services Field (DS Field) in the IPv4 and IPv6 1057 Headers", RFC2474, December 1998 1059 [RFC2475] S. Blake, D. Black, M. Carlson, E.Davies, Z.Wang and W.Weiss, 1060 "An Architecture for Differentiated Services" RFC2475, 1061 December 1998 1063 [SIDDIQUI1] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith, 1064 "Real-time Application Quality of Service Monitoring (RAQMON) 1065 MIB", Internet-Draft, draft-ietf-rmonmib-raqmon-mib- 1066 00.txt, January 2003 1068 [SIDDIQUI2] A. Siddiqui, D.Romascanu, and E. Golovinsky, 1069 "Framework for Real-time Application Quality of Service 1070 Monitoring (RAQMON)", Internet-Draft, draft-ietf-raqmon- 1071 framework-00.txt, January 2003 1073 [SIDDIQUI3] A. Siddiqui, D.Romascanu, E. Golovinsky, and R. Smith, 1074 "Real-time Application Quality of Service Monitoring (RAQMON) 1075 MIB", Internet-Draft, draft-siddiqui-rmonmib-raqmon-mib- 1076 01.txt, March 2002 1078 8. Intellectual Property 1080 The IETF takes no position regarding the validity or scope of any 1081 intellectual property or other rights that might be claimed to 1082 pertain to the implementation or use of the technology described in 1083 this document or the extent to which any license under such rights 1084 might or might not be available; neither does it represent that it 1085 has made any effort to identify any such rights. Information on the 1086 IETF's procedures with respect to rights in standards-track and 1087 standards-related documentation can be found in BCP-11. Copies of 1088 claims of rights made available for publication and any assurances of 1089 licenses to be made available, or the result of an attempt made to 1090 obtain a general license or permission for the use of such 1091 proprietary rights by implementors or users of this specification can 1092 be obtained from the IETF Secretariat. 1094 The IETF invites any interested party to bring to its attention any 1095 copyrights, patents or patent applications, or other proprietary 1096 rights which may cover technology that may be required to practice 1097 this standard. Please address the information to the IETF Executive 1098 Director. 1100 9. Security Considerations 1102 There are a number of management objects defined in this MIB 1103 that have a MAX-ACCESS clause of read-write and/or read-create. 1104 Such objects may be considered sensitive or vulnerable in some 1105 network environments. The support for SET operations in a 1106 non-secure environment without proper protection can have a 1107 negative effect on network operations. 1109 It is thus important to control even GET access to these objects 1110 and possibly to even encrypt the values of these object when 1111 sending them over the network via SNMP. Not all versions of 1112 SNMP provide features for such a secure environment. 1114 SNMPv1 by itself is not a secure environment. Even if the 1115 network itself is secure (for example by using IPSec), even then, 1116 there is no control as to who on the secure network is allowed 1117 to access and GET/SET (read/change/create/delete) the objects in 1118 this MIB. 1120 It is RECOMMENDED that the implementers consider the security 1121 features as provided by the SNMPv3 framework. Specifically, the 1122 use of the User-based Security Model [RFC2274] and the 1123 View-based Access Control Model [RFC2275] is RECOMMENDED. 1125 It is then a customer/user responsibility to ensure that the SNMP 1126 entity giving access to an instance of this MIB, is properly 1127 configured to give access to the objects only to those 1128 principals (users) that have legitimate rights to indeed GET or 1129 SET (change/create/delete) them. 1131 It is also imperative that the RAQMON framework be able to provide the 1132 following protection mechanisms: 1134 1. Authentication - the RRC should be able to verify that a RAQMON 1135 report was originated by whom ever claims to have sent it. 1137 2. Privacy - RAQMON information include identification of the parties 1138 participating in a communication session. RAQMON framework should be 1139 able to provide protection from eavsdropping, to prevent an 1140 un-authorized third party from gathering potentially sensitive 1141 information. This can be achieved by using various payload encryption 1142 technologies like DES, 3-DES, AES 1144 3. Protection from Denial of Service attacks directed at the RRC - 1145 RDSs send RAQMON reports as a side effect of an external event (for 1146 example, a phone call is being received). An attacker can try and 1147 overwhelm the RRC (or the network) by initiating a large number of 1148 events (i.e., calls) for the purpose of swamping the RRC with too many 1149 RAQMON PDUs. 1151 To prevent DoS attacks against RRC, the RDS will send the first report 1152 for a session only after the session has been in progress for the TBD 1153 reporting interval. Sessions shorter than that will not be reported. 1155 4. NAT and Firewall Friendly Design: Presence for IP addresses, 1156 TCP/UDP ports information in RAQMON PDUs may be NAT un-friendly. In 1157 such a scenario, where NAT Friendliness is a requirement, the RDS may 1158 opt to not to provide IP Addresses in RAQMON PDU. Another way to avoid 1159 this problem is by using NAT Aware Application Layer Gateways (ALGs) 1160 to fill out IP Addresses in RAQMON PDUs. 1162 10. IANA Considerations 1164 This memo introduces 2 new ports for IANA registration and a "name" for specific RTCP APP name == "RAQMON", as specified in Section 5.2.2, at http://www.iana.org/numbers.html 1166 11. Authors' Addresses 1168 Anwar A. Siddiqui 1169 Avaya Labs 1170 307 Middletown Lincroft Road 1171 Lincroft, New Jersey 07738 1172 USA 1173 Tel: +1 732 852-3200 1174 Fax: +1 732 817-5922 1175 E-mail: anwars@avaya.com 1177 Dan Romascanu 1178 Avaya Inc. 1179 Atidim Technology Park, Bldg. #3 1180 Tel Aviv, 61131 1181 Israel 1182 Tel: +972-3-645-8414 1183 Email: dromasca@avaya.com 1185 Eugene Golovinsky 1186 BMC Software 1187 2101 CityWest Blvd. 1188 Houston, Texas 77042 1189 USA 1190 Tel: +1 713 918-1816 1191 Email: eugene_golovinsky@bmc.com 1193 A. Full Copyright Statement 1195 This document and translations of it may be copied and furnished to 1196 others, and derivative works that comment on or otherwise explain it 1197 or assist in its implementation may be prepared, copied, published 1198 and distributed, in whole or in part, without restriction of any 1199 kind, provided that the above copyright notice and this paragraph are 1200 included on all such copies and derivative works. However, this 1201 document itself may not be modified in any way, such as by removing 1202 the copyright notice or references to the Internet Society or other 1203 Internet organizations, except as needed for the purpose of 1204 developing Internet standards in which case the procedures for 1205 copyrights defined in the Internet Standards process must be 1206 followed, or as required to translate it into languages other than 1207 English. 1209 The limited permissions granted above are perpetual and will not be 1210 revoked by the Internet Society or its successors or assigns. 1212 This document and the information contained herein is provided on an 1213 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1214 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1215 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1216 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1217 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.