idnits 2.17.1 draft-ietf-avt-rtp-mib-04.txt: ** The Abstract section seems to be numbered 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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 7 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** There are 292 instances of lines with control characters in the document. ** The abstract seems to contain references ([1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 485: '... RTP Monitors MUST initialize to 't...' RFC 2119 keyword, line 486: '... Hosts MUST initialize this 'fal...' RFC 2119 keyword, line 499: '... state MAY be removed after 5 m...' RFC 2119 keyword, line 511: '...TP sending hosts MUST have an entry in...' RFC 2119 keyword, line 900: '...he objects in the rtpHostGroup MUST be...' (16 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 288 has weird spacing: '... "This objec...' == Line 289 has weird spacing: '...onIndex as de...' == Line 290 has weird spacing: '...entions for ...' == Line 291 has weird spacing: '...em, the netwo...' == Line 292 has weird spacing: '... the objec...' == (4 more instances...) -- 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 (February 26, 1998) is 9557 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 section? '1' on line 1027 looks like a reference -- Missing reference section? '2' on line 1030 looks like a reference -- Missing reference section? '3' on line 1035 looks like a reference -- Missing reference section? '4' on line 1039 looks like a reference -- Missing reference section? '5' on line 1042 looks like a reference -- Missing reference section? '6' on line 1045 looks like a reference -- Missing reference section? '7' on line 1051 looks like a reference -- Missing reference section? '8' on line 1057 looks like a reference -- Missing reference section? '9' on line 1063 looks like a reference -- Missing reference section? '10' on line 1068 looks like a reference -- Missing reference section? '11' on line 1073 looks like a reference -- Missing reference section? '12' on line 1079 looks like a reference -- Missing reference section? '13' on line 1084 looks like a reference -- Missing reference section? '14' on line 1088 looks like a reference -- Missing reference section? '15' on line 1094 looks like a reference -- Missing reference section? '16' on line 1098 looks like a reference Summary: 16 errors (**), 0 flaws (~~), 7 warnings (==), 18 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft RTP MIB February 26, 1998 3 Real-Time Transport Protocol 4 Management Information Base 5 7 February 26, 1998 9 Mark Baugher 10 Intel Corporation 11 2111 N.E.25th Avenue 12 Hillsboro, Oregon 97124 14 mbaugher@intel.com 16 Bill Strahm 17 Intel Corporation 18 2111 N.E.25th Avenue 19 Hillsboro, Oregon 97124 21 Bill.Strahm@intel.com 23 Irina Suconick 24 Videoserver Corporation 25 63 Third Street 26 Burlington, Massachusetts 01803 28 isuconick@videoserver.com 30 Status of this Memo 32 This document is an Internet-Draft and is in full conformance 33 with all provisions of Section 10 of RFC2026. 35 This document is an Internet-Draft. Internet-Drafts are 36 working documents of the Internet Engineering Task Force 37 (IETF), its areas, and its working groups. Note that other 38 groups may also distribute working documents as Internet-Drafts. 39 Internet-Drafts are draft documents valid for a maximum of six 40 months. Internet-Drafts may be updated, replaced, or made 41 obsolete by other documents at any time. It is not 42 appropriate to use Internet-Drafts as reference material or to 43 cite them other than as a ``working draft'' or ``work inprogress.'' 44 To learn the current status of any Internet-Draft, please 45 check the 1id-abstracts.txt listing contained in the Internet- 46 Drafts Shadow Directories on ftp.ietf.org, nic.nordu.net, 47 venera.isi.edu, or munnari.oz.au. 49 1. Changes from Previous Draft 51 There were three main changes to the draft. 53 Section 4.3.3 was added to clarify that host systems may include data 54 gathered from RTCP data on streams that they are involved with. 56 rtpSessionIndex was changed to allow 2^31-1 indexes and also a note saying 57 that sessions are not required to be sequential. This is from some 58 questions about subagents allocating indexes out of an internal "sub-pool" 59 and the need to renumber indexes after a row deletion. 61 rtpSessionIfAddr was removed and rtpSessionIfIndex was made into an 62 InterfaceIndex. It was determined that all addresses will go through 63 an indexed interface, therefor it was complicated and confusing 64 maintaining the two objects. 66 2. Abstract 68 This memo defines an experimental Management Information Base 69 (MIB) for use with network management protocols in 70 TCP/IP-based internets. In particular, it defines objects for 71 managing Real-Time Transport Protocol systems [1]. Comments 72 should be made to the IETF Audio/Video Transport Working Group 73 at rem-conf@es.net.This memo does not specify a standard for the Internet 74 community. 76 3. The Network Management Framework 78 The SNMP Management Framework presently consists of five major 79 components: 81 o An overall architecture, described in RFC 2271 [2]. 83 o Mechanisms for describing and naming objects and events for the 84 purpose of management. The first version of this Structure of 85 Management Information (SMI) is called SMIv1 and described in 86 RFC 1155 [3], RFC 1212 [4] and RFC 1215 [5]. The second version, 87 called SMIv2, is described in RFC 1902 [6], RFC 1903 [7] and RFC 88 1904 [8]. 90 o Message protocols for transferring management information. The 91 first version of the SNMP message protocol is called SNMPv1 and 92 described in RFC 1157 [9]. A second version of the SNMP message 93 protocol, which is not an Internet standards track protocol, is 94 called SNMPv2c and described in RFC 1901 [10] and RFC 1906 [11]. 95 The third version of the message protocol is called SNMPv3 and 96 described in RFC 1906 [11], RFC 2272 [12] and RFC 2274 [13]. 98 o Protocol operations for accessing management information. The 99 first set of protocol operations and associated PDU formats is 100 described in RFC 1157 [9]. A second set of protocol operations 101 and associated PDU formats is described in RFC 1905 [14]. 103 o A set of fundamental applications described in RFC 2273 [15] and 104 the view-based access control mechanism described in RFC 2275 105 [16]. 107 Managed objects are accessed via a virtual information store, termed 108 the Management Information Base or MIB. Objects in the MIB are 109 defined using the mechanisms defined in the SMI. 111 This memo specifies a MIB module that is compliant to the SMIv2. A 112 MIB conforming to the SMIv1 can be produced through the appropriate 113 translations. The resulting translated MIB must be semantically 114 equivalent, except where objects or events are omitted because no 115 translation is possible (use of Counter64). Some machine readable 116 information in SMIv2 will be converted into textual descriptions in 117 SMIv1 during the translation process. However, this loss of machine 118 readable information is not considered to change the semantics of theMIB. 120 4. Overview 122 An "RTP System" may be a host end-system that runs an application 123 program that sends or receives RTP data packets, or it may be an 124 intermediate-system that forwards RTP packets. RTP Control 125 Protocol (RTCP) packets are sent by senders and receivers to 126 convey information about RTP packet transmission and reception [1]. 127 RTP monitors may collect RTCP information on senders and receivers 128 to and from an RTP host or intermediate-system. 130 4.1 Components 132 The RTP MIB is structured around "session," "Receiver" and "Sender" 133 conceptual abstractions. 135 4.1.1 An "RTP session" is the "...association of participants 136 communicating with RTP. For each participant, the session is 137 defined by a particular pair of destination transport addresses 138 (one network address plus a port pair for RTP and RTCP). The 139 destination transport addresses may be common for all participants, 140 as in the case of IP multicast, or may be different for each, as in 141 the case of individual unicast addresses plus a common port pair," 142 as defined in section 3 of [1]. 144 4.1.2 A "Sender" is identified within an RTP session by a 32-bit numeric 145 "Synchronization Source," or "SSRC", value and is "...the source of a 146 stream of RTP packets" as defined in section 3 of [1]. The sender is 147 also a source of RTCP Sender Report packets as specified in section 6 of [1]. 149 4.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or 150 multicast Receiver as described in 4.2.1, above. An RTP Receiver has 151 an SSRC value that is unique to the session. An RTP Receiver is a 152 source of RTCP Receiver Reports as specified in section 6 of [1]. 154 4.2 Applicability of the MIB to RTP System Implementations 156 The RTP MIB may be used in two types of RTP implementations, RTP Host 157 Systems (end systems) and RTP Monitors, see section 3 of [1]. 158 Use of the RTP MIB for RTP Translators and Mixers, as defined in 159 section 7 of [1], is for further study. 161 4.2.1 RTP host Systems are end-systems that may use the RTP MIB 162 to collect RTP session and stream data that the host is sending or 163 receiving; these data may be used by a network manager to detect and 164 diagnose faults that occur over the life time of an RTP session as 165 in a "help-desk" scenario. 167 4.2.2 RTP Monitors of multicast RTP sessions may be third-party, or 168 may be located in an RTP intermediate-system or in the host. RTP 169 Monitors may use the RTP MIB to collect RTP session and stream 170 statistical data; these data may be used by a network manager for 171 capacity planning and other network-management purposes. An RTP 172 Monitor may use the RTP MIB to collect data to permit a network 173 manager to detect and diagnose faults in RTP sessions, or to permit 174 a network manger to configure its operation. 176 4.2.3 Many host systems will want to keep track of streams beyond what 177 they are sending and receiving. In this mode a host system would use 178 RTP data from the host to maintain data about streams it is sending and 179 receiving, and RTCP data to collect data about other hosts in the session. 180 For example an RTP host that is sending a stream would use data from 181 its RTP stack to maintain the rtpSenderTable, however it may want to 182 maintain a rtpReceiverTable for endpoints that are receiving its stream. 183 To do this the host will collect RTCP data from the receivers of its 184 stream to build the rtpReceiverTable. 186 4.3 The Structure of the RTP MIB 188 There are three tables in the RTP MIB. The rtpSessionTable contains 189 objects that describe active sessions at the host, intermediate system, 190 or monitor. The rtpSenderTable contains information about senders 191 to the RTP session. The rtpRcvrTable contains information about 192 receivers of RTP session data. 194 For any particular RTP session, the rtpSessionMonitor object indicates 195 whether information about remote senders or receivers to the RTP 196 session are to be monitored. RTP sessions are monitored by the 197 RTP agent that updates rtpSenderTable and rtpRcvrTable objects with 198 information from RTCP reports from remote senders or remote receivers 199 respectively. 201 rtpSessionNewIndex is a global object that permits a network-management 202 application to obtain a unique index for conceptual row creation 203 in the rtpSessionTable. In this way the SNMP Set operation may 204 be used to configure a monitor. 206 5. DefinitionsRTP-MIB DEFINITIONS ::= BEGIN 207 IMPORTS 208 Counter32, Counter64, Gauge32, experimental, Integer32, 209 MODULE-IDENTITY, OBJECT-IDENTITY, 210 OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI 211 DisplayString, RowStatus, TAddress, 212 TDomain, TestAndIncr, TEXTUAL-CONVENTION, 213 TimeStamp, TruthValue FROM SNMPv2-TC 214 OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; 215 InterfaceIndex FROM IF-MIB; 217 rtpMIB MODULE-IDENTITY 218 LAST-UPDATED "990222000Z" 219 ORGANIZATION "IETF AVT Working Group" 220 CONTACT-INFO 221 "Mark Baugher 222 Postal: Intel Corporation 223 2111 NE 25th Avenue 224 Hillsboro, OR 97124 225 United States 226 Tel: +1 503 264 3849 227 Email: mbaugher@intel.com 229 Bill Strahm 230 Postal: Intel Corporation 231 2111 NE 25th Avenue 232 Hillsboro, OR 97124 233 United States 234 Tel: +1 503 264 4632 235 Email: bill.strahm@intel.com 237 Irina Suconick 238 Postal: Videoserver Corporation 239 63 Third Street 240 Burlington, MA 01803 241 United States 242 Tel: +1 781-505-2155 243 Email: isuconick@videoserver.com" 244 DESCRIPTION 245 "The managed objects of RTP systems. The MIB is 246 structured around three types of information. 247 1. General information about RTP sessions such 248 as the session address. 249 2. Information about RTP streams being sent to 250 an RTP session by a particular source. 251 3. Information about RTP streams received on an 252 RTP session by a particular receiver from a 253 particular sender. 254 There are two types of RTP Systems, RTP hosts and 255 RTP monitors. As described below, certain objects 256 are unique to a particular type of RTP System. An 257 RTP host may also function as an RTP monitor. 258 Refer to RFC 1889, 'RTP: A Transport Protocol for 259 Real-Time Applications,' section 3.0, for definitions." 260 ::= { experimental 77 } 261 -- ::== { mib-2 xx } to be assigned by IANA when going to Proposed 263 -- 264 -- OBJECTS 265 -- 266 rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 } 267 rtpAdmin OBJECT IDENTIFIER ::= { rtpMIB 2 } 268 rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 3 } 269 rtpDomains OBJECT IDENTIFIER ::= { rtpMIB 4 } 271 rtpUDPDomain OBJECT-IDENTITY 272 STATUS current 273 DESCRIPTION 274 "RTP over UDP transport domain over IPv4. This definition 275 uses the transport address type, snmpUDPAddress, which is 276 defined in SNMPv2-TM, 'Transport Mappings for Version 2 of 277 the Simple Network Management Protocol (SNMPv2)'." 278 REFERENCE "RFC 1906, sec. 2 " ::= { rtpDomains 1 } 280 -- 281 -- SESSION TABLE 282 -- 283 rtpSessionNewIndex OBJECT-TYPE 284 SYNTAX TestAndIncr 285 MAX-ACCESS read-write 286 STATUS current 287 DESCRIPTION 288 "This object is used to assign values to 289 rtpSessionIndex as described in 'Textual 290 Conventions for SNMPv2'. For an RTP monitor 291 system, the network manager would read 292 the object, and then write the value back in 293 the Set that creates a new instance of 294 rtpSessionEntry. If the Set fails with the code 295 'inconsistentValue,' then the process must be 296 repeated; If the Set succeeds, then the object 297 is incremented, and the new instance is 298 created according to the manager's directions. 299 However, if the RTP agent is not acting as a monitor, 300 only the RTP agent may create conceptual rows in the 301 RTP session table. The RTP agent is a monitor for a 302 paricular session only if rtpSessionMonitor is set to 303 'true(1)'." 304 ::= { rtpMIBObjects 1 } 306 rtpSessionTable OBJECT-TYPE 307 SYNTAX SEQUENCE OF RtpSessionEntry 308 MAX-ACCESS not-accessible 309 STATUS current 310 DESCRIPTION 311 "There's one entry in rtpSessionTable for each RTP session 312 on which packets are being sent, received, and/or 313 monitored." 314 ::= { rtpMIBObjects 2 } 316 rtpSessionEntry OBJECT-TYPE 317 SYNTAX RtpSessionEntry 318 MAX-ACCESS not-accessible 319 STATUS current 320 DESCRIPTION 321 "Data in rtpSessionTable uniquely identify an RTP 322 session. A host RTP agent will create a read-only row for 323 each session to which packets are being sent or received. 324 An RTP session can be monitored to create management 325 information on all RTP streams being sent or received when 326 the rtpSessionMonitor has the TruthValue of 'true(1)'. An 327 RTP monitor may permit row creation with the side 328 effect of causing the RTP System to join the session for 329 the purposes of gathering management information (thus 330 additional conceptual rows are created in the rtpRcvrTable 331 and rtpSenderTable). rtpSessionTable rows can be created 332 for RTP session monitoring purposes. Rows created by a 333 management application may be deleted via SNMP operations. 334 Rows created by a management application (rtSessionMonitor 335 is 'true(1)') are deleted by the management application. 336 When rtpSessionMonitor is 'false(2), rows are created by the 337 RTP Agent at the start of a session when one or more or more 338 senders or receivers are observed. Rows created by an RTP 339 agent are deleted when the session is over and there are no 340 rtpRcvrEntry and no rtpSenderEntry for this session." 341 INDEX { rtpSessionIndex } 342 ::= { rtpSessionTable 1 } 344 RtpSessionEntry ::= SEQUENCE { 345 rtpSessionIndex Integer32, 346 rtpSessionDomain TDomain, 347 rtpSessionRemAddr TAddress, 348 rtpSessionLocAddr TAddress, 349 rtpSessionIfIndex InterfaceIndex, 350 rtpSessionSenderJoins Counter32, 351 rtpSessionReceiverJoins Counter32, 352 rtpSessionByes Counter32, 353 rtpSessionStartTime TimeStamp, 354 rtpSessionMonitor TruthValue, 355 rtpSessionRowStatus RowStatus 356 } 357 rtpSessionIndex OBJECT-TYPE 358 SYNTAX Integer32 (1..2147483647) 359 MAX-ACCESS not-accessible 360 STATUS current 361 DESCRIPTION 362 "The index of the conceptual row which is for SNMP purposes 363 only and has no relation to any protocol value. There is 364 no requirement that these rows are created or maintained 365 sequentially." 366 ::= { rtpSessionEntry 1} 368 rtpSessionDomain OBJECT-TYPE 369 SYNTAX TDomain 370 MAX-ACCESS read-create 371 STATUS current 372 DESCRIPTION 373 "The transport-layer protocol used for sending or receiving 374 the stream of RTP data packets on this session. 375 Cannot be changed if rtpSessionRowStatus is 'active'." 376 DEFVAL { rtpUDPDomain } 377 ::= { rtpSessionEntry 2 } 379 rtpSessionRemAddr OBJECT-TYPE 380 SYNTAX TAddress 381 MAX-ACCESS read-create 382 STATUS current 383 DESCRIPTION 384 "The remote destination transport address on which the 385 RTP data packet stream is sent and/or received. An RTP 386 Session is defined by a pair of destination transport 387 addresses. 'The destination address pair may be common for 388 all participants, as in the case of IP multicast, or may be 389 different for each, as in the case of individual unicast 390 network address pairs.' See RFC 1889, 'RTP: A Transport 391 Protocol for Real-Time Applications,' sec. 3. The transport 392 service is identified by rtpSessionDomain. For rtpUDPDomain, 393 this is an IP address and even-numbered UDP Port with the 394 RTCP being sent on the next higher odd-numbered port, see 395 RFC 1889, sec. 5. Cannot be changed if rtpSessionRowStatus 396 is 'active'." 397 ::= { rtpSessionEntry 3 } 399 rtpSessionLocAddr OBJECT-TYPE 400 SYNTAX TAddress 401 MAX-ACCESS read-only 402 STATUS current 403 DESCRIPTION 404 "The local destination transport address on which the stream 405 of data packets is being sent and/or received. For unicast 406 RTP sessions, this is the local address of the 407 RTP session. For multicast RTP sessions, this object should 408 have the same value as rtpSessionRemoteAddr. See RFC 1889, 409 'RTP: A Transport Protocol for Real-Time Applications,' sec. 410 3. The transport service is identified by rtpSessionDomain. 411 For rtpUDPDomain, this is an IP address and even-numbered 412 UDP Port with the RTCP being sent on the next higher 413 odd-numbered port, see RFC 1889, sec. 5." 414 ::= { rtpSessionEntry 4 } 416 rtpSessionIfIndex OBJECT-TYPE 417 SYNTAX InterfaceIndex 418 MAX-ACCESS read-create 419 STATUS current 420 DESCRIPTION 421 "The ifIndex value is set to the corresponding value 422 from the Internet Standard MIB. This is the interface 423 that the RTP stream is being sent to or received from, 424 or in the case of an RTP Monitor the interface that RTCP 425 packets will be received on. Cannot be changed if 426 rtpSessionRowStatus is 'active'." 427 DEFVAL { 0 } 428 ::= { rtpSessionEntry 5 } 429 rtpSessionSenderJoins OBJECT-TYPE 430 SYNTAX Counter32 431 MAX-ACCESS read-only 432 STATUS current 433 DESCRIPTION 434 "The number of senders that have been observed to have 435 joined the session since this conceptual row was created 436 (rtpSessionStartTime). A sender 'joins' an RTP 437 session by sending to it. Senders that leave and then 438 re-join following an RTCP BYE (See RFC 1889, 'RTP: A 439 Transport Protocol for Real-Time Applications,' sec. 6.6) 440 or session timeout may be counted twice. Every time an 441 rtpSenderEntry is created for this session, this counter 442 is incremented." 443 ::= { rtpSessionEntry 6 } 445 rtpSessionReceiverJoins OBJECT-TYPE 446 SYNTAX Counter32 447 MAX-ACCESS read-only 448 STATUS current 449 DESCRIPTION 450 "The number of receivers that have been been observed to 451 to have joined this session since this conceptual row was 452 created (rtpSessionStartTime). Receivers that leave and 453 then re-join following an RTCP BYE (See RFC 1889, 'RTP: A 454 Transport Protocol for Real-Time Applications,' sec. 6.6) 455 or session timeout may be counted twice. Every time an 456 rtpRcvrEntry is created for this session, this counter 457 is incremented." 458 ::= { rtpSessionEntry 7 } 459 rtpSessionByes OBJECT-TYPE 460 SYNTAX Counter32 461 MAX-ACCESS read-only 462 STATUS current 463 DESCRIPTION 464 "A count of RTCP BYE (See RFC 1889, 'RTP: A Transport 465 Protocol for Real-Time Applications,' sec. 6.6) messages 466 received by this entity." 467 ::= { rtpSessionEntry 8 } 469 rtpSessionStartTime OBJECT-TYPE 470 SYNTAX TimeStamp 471 MAX-ACCESS read-only 472 STATUS current 473 DESCRIPTION 474 "The value of SysUpTime at the time that this row was 475 created." 476 ::= { rtpSessionEntry 9 } 478 rtpSessionMonitor OBJECT-TYPE 479 SYNTAX TruthValue 480 MAX-ACCESS read-only 481 STATUS current 482 DESCRIPTION 483 "Boolean, Set to 'true(1)' if senders or receivers in 484 addition to the local RTP System are to be monitored. 485 RTP Monitors MUST initialize to 'true(1)' and RTP 486 Hosts MUST initialize this 'false(2)'." 487 ::= { rtpSessionEntry 10 } 489 rtpSessionRowStatus OBJECT-TYPE 490 SYNTAX RowStatus 491 MAX-ACCESS read-create 492 STATUS current 493 DESCRIPTION 494 "Value of 'active' when RTP or RTCP messages are being 495 sent or received by an RTP System. A newly-created 496 conceptual row must have the rtpSessionRemAddr and 497 rtpSessionLocAddr initialized before becoming 'active'. 498 A conceptual row that is in the 'notReady' or 'notInService' 499 state MAY be removed after 5 minutes." 500 ::= { rtpSessionEntry 11 } 502 -- 503 -- SENDERS TABLE 504 -- 505 rtpSenderTable OBJECT-TYPE 506 SYNTAX SEQUENCE OF RtpSenderEntry 507 MAX-ACCESS not-accessible 508 STATUS current 509 DESCRIPTION 510 "Table of information about a sender or senders to an RTP 511 Session. RTP sending hosts MUST have an entry in this table 512 for each stream being sent. RTP monitors create an entry 513 for each observed sender to an RTP Session as a side-effect 514 when a conceptual row in the rtpSessionTable is made 515 'active' by a manager." 516 ::= { rtpMIBObjects 3 } 518 rtpSenderEntry OBJECT-TYPE 519 SYNTAX RtpSenderEntry 520 MAX-ACCESS not-accessible 521 STATUS current 522 DESCRIPTION 523 "Each entry contains information from a single RTP Synch- 524 ronization Source (SSRC, see RFC 1889 'RTP: A Transport 525 Protocol for Real-Time Applications' sec.6). The session is 526 identified to the the SNMP entity by rtpSessionIndex. 527 Rows are removed by the RTP agent when a BYE is received 528 from the sender or when the sender times out (see RFC 529 1889, Sec. 6.2.1). Fate is shared with the rtpSessionIndex 530 conceptual row as well." 531 INDEX { rtpSessionIndex, rtpSenderSSRC } 532 ::= { rtpSenderTable 1 } 534 RtpSenderEntry ::= SEQUENCE { 535 rtpSenderSSRC Unsigned32, 536 rtpSenderCNAME DisplayString, 537 rtpSenderAddr TAddress, 538 rtpSenderPackets Counter64, 539 rtpSenderOctets Counter64, 540 rtpSenderTool DisplayString, 541 rtpSRs Counter32, 542 rtpSenderSRTime TimeStamp, 543 rtpSenderPT INTEGER, 544 rtpSenderStartTime TimeStamp 545 } 546 rtpSenderSSRC OBJECT-TYPE 547 SYNTAX Unsigned32 548 MAX-ACCESS not-accessible 549 STATUS current 550 DESCRIPTION 551 "The RTP SSRC, or synchronization source identifier of the 552 sender. The RTP session address plus an SSRC uniquely 553 identify a sender or receiver of an RTP stream (see RFC 554 1889, 'RTP: A Transport Protocol for Real-Time 555 Applications' sec.3)." 556 ::= { rtpSenderEntry 1 } 558 rtpSenderCNAME OBJECT-TYPE 559 SYNTAX DisplayString (SIZE(0..255)) 560 MAX-ACCESS read-only 561 STATUS current 562 DESCRIPTION 563 "The RTP canonical name of the sender." 564 ::= { rtpSenderEntry 2 } 566 rtpSenderAddr OBJECT-TYPE 567 SYNTAX TAddress 568 MAX-ACCESS read-only 569 STATUS current 570 DESCRIPTION 571 "The unicast transport source address of the sender." 572 ::= { rtpSenderEntry 3 } 574 rtpSenderPackets OBJECT-TYPE 575 SYNTAX Counter64 576 MAX-ACCESS read-only 577 STATUS current 578 DESCRIPTION 579 "Count of RTP packets sent by this sender, or observed by 580 an RTP monitor, since rtpSenderStartTime." 581 ::= { rtpSenderEntry 4 } 583 rtpSenderOctets OBJECT-TYPE 584 SYNTAX Counter64 585 MAX-ACCESS read-only 586 STATUS current 587 DESCRIPTION 588 "Count of RTP octets sent by this sender, or observed by 589 an RTP monitor, since rtpSenderStartTime." 590 ::= { rtpSenderEntry 5 } 592 rtpSenderTool OBJECT-TYPE 593 SYNTAX DisplayString (SIZE(0..127)) 594 MAX-ACCESS read-only 595 STATUS current 596 DESCRIPTION 597 "Name of the application program source of the stream." 598 DEFVAL { ''H } -- Null if not available 599 ::= { rtpSenderEntry 6 } 601 rtpSRs OBJECT-TYPE 602 SYNTAX Counter32 603 MAX-ACCESS read-only 604 STATUS current 605 DESCRIPTION 606 "A count of the number of RTCP Sender Reports that have 607 been sent from this sender, or observed if the RTP entity 608 is a monitor, since rtpSenderStartTime." 609 ::= { rtpSenderEntry 7 } 611 rtpSenderSRTime OBJECT-TYPE 612 SYNTAX TimeStamp 613 MAX-ACCESS read-only 614 STATUS current 615 DESCRIPTION 616 "rtpSenderSRTime is the value of SysUpTime at the time that 617 the last SR was received from this sender, in the case of a 618 monitor or receiving host. Or sent by this sender, in the 619 case of a sending host." 620 ::= { rtpSenderEntry 8 } 621 rtpSenderPT OBJECT-TYPE 622 SYNTAX INTEGER (0..127) 623 MAX-ACCESS read-only 624 STATUS current 625 DESCRIPTION 626 "Static or dynamic payload type from the RTP header (see 627 RFC 1889, 'RTP: A Transport Protocol for Real-Time 628 Applications' sec. 5)." 629 ::= { rtpSenderEntry 9 } 631 rtpSenderStartTime OBJECT-TYPE 632 SYNTAX TimeStamp 633 MAX-ACCESS read-only 634 STATUS current 635 DESCRIPTION 636 "The value of SysUpTime at the time that this row was 637 created." 638 ::= { rtpSenderEntry 10 } 640 -- 641 -- RECEIVERS TABLE 642 -- 643 rtpRcvrTable OBJECT-TYPE 644 SYNTAX SEQUENCE OF RtpRcvrEntry 645 MAX-ACCESS not-accessible 646 STATUS current 647 DESCRIPTION 648 "Table of information about a receiver or receivers of RTP 649 session data. RTP hosts that receive RTP session packets 650 create an entry in this table for that receiver/sender 651 pair. RTP monitors create an entry for each observed RTP 652 session receiver as a side effect when a conceptual row 653 in the rtpSessionTable is made 'active' by a manager." 654 ::= { rtpMIBObjects 4 } 656 rtpRcvrEntry OBJECT-TYPE 657 SYNTAX RtpRcvrEntry 658 MAX-ACCESS not-accessible 659 STATUS current 660 DESCRIPTION 661 "Each entry contains information from a single RTP 662 Synchronization Source (SSRC, see RFC 1889, 'RTP: A 663 Transport Protocol for Real-Time Applications' sec.6). 664 The session is identified to the the SNMP entity by 665 rtpSessionIndex. Rows are removed by the RTP agent when 666 a BYE is received from the sender or when the sender times 667 out (see RFC 1889, Sec. 6.2.1). Fate is shared with the 668 rtpSessionIndex conceptual row as well." 669 INDEX { rtpSessionIndex, rtpRcvrSRCSSRC, rtpRcvrSSRC } 670 ::= { rtpRcvrTable 1 } 672 RtpRcvrEntry ::= SEQUENCE { 673 rtpRcvrSRCSSRC Unsigned32, 674 rtpRcvrSSRC Unsigned32, 675 rtpRcvrCNAME DisplayString, 676 rtpRcvrAddr TAddress, 677 rtpRcvrRTT Gauge32, 678 rtpRcvrLostPackets Counter64, 679 rtpRcvrJitter Gauge32, 680 rtpRRs Counter32, 681 rtpRcvrTool DisplayString, 682 rtpRcvrRRTime TimeStamp, 683 rtpRcvrPT INTEGER, 684 rtpRcvrPackets Counter64, 685 rtpRcvrOctets Counter64, 686 rtpRcvrStartTime TimeStamp 687 } 689 rtpRcvrSRCSSRC OBJECT-TYPE 690 SYNTAX Unsigned32 691 MAX-ACCESS not-accessible 692 STATUS current 693 DESCRIPTION 694 "The RTP SSRC, or synchronization source identifier of the 695 sender. The RTP session address plus an SSRC uniquely 696 identify a sender or receiver of an RTP stream (see RFC 697 1889, 'RTP: A Transport Protocol for Real-Time 698 Applications' sec.3)." 699 ::= { rtpRcvrEntry 1 } 700 rtpRcvrSSRC OBJECT-TYPE 701 SYNTAX Unsigned32 702 MAX-ACCESS not-accessible 703 STATUS current 704 DESCRIPTION 705 "The RTP SSRC, or synchronization source identifier of the 706 receiver. The RTP session address plus an SSRC uniquely 707 identify a sender or receiver of an RTP stream (see RFC 708 1889, 'RTP: A Transport Protocol for Real-Time 709 Applications' sec.3)." 710 ::= { rtpRcvrEntry 2 } 712 rtpRcvrCNAME OBJECT-TYPE 713 SYNTAX DisplayString (SIZE(0..255)) 714 MAX-ACCESS read-only 715 STATUS current 716 DESCRIPTION 717 "The RTP canonical name of the receiver." 718 ::= { rtpRcvrEntry 3 } 720 rtpRcvrAddr OBJECT-TYPE 721 SYNTAX TAddress 722 MAX-ACCESS read-only 723 STATUS current 724 DESCRIPTION 725 "The unicast transport address of the receiver." 726 ::= { rtpRcvrEntry 4 } 728 rtpRcvrRTT OBJECT-TYPE 729 SYNTAX Gauge32 730 MAX-ACCESS read-only 731 STATUS current 732 DESCRIPTION 733 "The round trip time measurement taken by the source of the 734 RTP stream based on the algorithm described on sec. 6 of 735 RFC 1889, 'RTP: A Transport Protocol for Real-Time 736 Applications.' This algorithm can produce meaningful 737 results when the RTP agent has the same clock as the stream 738 sender (when the RTP monitor is also a sending host for the 739 particular reciever). Otherwise, the entity should return 740 'noSuchInstance' in response to queries against rtpRcvrRTT." 741 ::= { rtpRcvrEntry 5 } 743 rtpRcvrLostPackets OBJECT-TYPE 744 SYNTAX Counter64 745 MAX-ACCESS read-only 746 STATUS current 747 DESCRIPTION 748 "A count of RTP packets lost as observed by this receiver 749 since rtpRcvrStartTime." 750 ::= { rtpRcvrEntry 6 } 752 rtpRcvrJitter OBJECT-TYPE 753 SYNTAX Gauge32 754 MAX-ACCESS read-only 755 STATUS current 756 DESCRIPTION 757 "An estimate of delay variation as observed by this 758 receiver." 759 ::= { rtpRcvrEntry 7 } 761 rtpRcvrTool OBJECT-TYPE 762 SYNTAX DisplayString (SIZE(0..127)) 763 MAX-ACCESS read-only 764 STATUS current 765 DESCRIPTION 766 "Name of the application program source of the stream." 767 DEFVAL { ''H } -- Null if not available 768 ::= { rtpRcvrEntry 8 } 770 rtpRRs OBJECT-TYPE 771 SYNTAX Counter32 772 MAX-ACCESS read-only 773 STATUS current 774 DESCRIPTION 775 "A count of Receiver Reports as observed by this receiver 776 since rtpSessionStartTime." 777 ::= { rtpRcvrEntry 9 } 778 rtpRcvrRRTime OBJECT-TYPE 779 SYNTAX TimeStamp 780 MAX-ACCESS read-only 781 STATUS current 782 DESCRIPTION 783 "rtpRcvrRRTime is the value of SysUpTime at the time that 784 the last RTCP Receiver Report was received from this 785 receiver, in the case of a monitor or RR receiver. It is the 786 value of SysUpTime at the time that the last RR was sent by 787 this receiver in the case of a receiver sending the RR." 788 ::= { rtpRcvrEntry 10 } 790 rtpRcvrPT OBJECT-TYPE 791 SYNTAX INTEGER (0..127) 792 MAX-ACCESS read-only 793 STATUS current 794 DESCRIPTION 795 "Static or dynamic payload type from the RTP header (see 796 RFC 1889, 'RTP: A Transport Protocol for Real-Time 797 Applications' sec. 5)." 798 ::= { rtpRcvrEntry 11 } 800 rtpRcvrPackets OBJECT-TYPE 801 SYNTAX Counter64 802 MAX-ACCESS read-only 803 STATUS current 804 DESCRIPTION 805 "Count of RTP packets received by this RTP host receiver 806 since rtpRcvrStartTime. RTP monitors may not have this 807 information and should return 'noSuchInstance.'" 808 ::= { rtpRcvrEntry 12 } 810 rtpRcvrOctets OBJECT-TYPE 811 SYNTAX Counter64 812 MAX-ACCESS read-only 813 STATUS current 814 DESCRIPTION 815 "Count of RTP octets received by this receiving RTP host 816 since rtpRcvrStartTime. RTP monitors may not have this 817 this information and should return 'noSuchInstance.'" 818 ::= { rtpRcvrEntry 13 } 820 rtpRcvrStartTime OBJECT-TYPE 821 SYNTAX TimeStamp 822 MAX-ACCESS read-only 823 STATUS current 824 DESCRIPTION 825 "The value of SysUpTime at the time that this row was 826 created." 827 ::= { rtpRcvrEntry 14 } 828 -- 829 -- MODULE GROUPS 830 -- 831 rtpGroups OBJECT IDENTIFIER ::= { rtpConformance 1 } 832 rtpSystemGroup OBJECT-GROUP 833 OBJECTS { 834 rtpSessionDomain, 835 rtpSessionRemAddr, 836 rtpSessionIfIndex, 837 rtpSessionSenderJoins, 838 rtpSessionReceiverJoins, 839 rtpSessionStartTime, 840 rtpSessionRowStatus, 841 rtpSessionByes, 842 rtpSessionMonitor, 843 rtpSenderCNAME, 844 rtpSenderAddr, 845 rtpSenderPackets, 846 rtpSenderOctets, 847 rtpSenderTool, 848 rtpSRs, 849 rtpSenderSRTime, 850 rtpSenderStartTime, 851 rtpRcvrCNAME, 852 rtpRcvrAddr, 853 rtpRcvrLostPackets, 854 rtpRcvrJitter, 855 rtpRcvrTool, 856 rtpRRs, 857 rtpRcvrRRTime, 858 rtpRcvrStartTime 859 } 860 STATUS current 861 DESCRIPTION 862 "Objects used by all RTP systems." 863 ::= { rtpGroups 1 } 864 rtpHostGroup OBJECT-GROUP 865 OBJECTS { 866 rtpSessionLocAddr, 867 rtpSenderPT, 868 rtpRcvrPT, 869 rtpRcvrRTT, 870 rtpRcvrOctets, 871 rtpRcvrPackets 872 } 873 STATUS current 874 DESCRIPTION 875 "Objects used by RTP host systems." 876 ::= { rtpGroups 2 } 878 rtpMonitorGroup OBJECT-GROUP 879 OBJECTS { 880 rtpSessionNewIndex 881 } 882 STATUS current 883 DESCRIPTION 884 "Objects used by RTP monitor systems." 885 ::= { rtpGroups 3 } 887 -- 888 -- Compliance 889 -- 890 rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 } 892 rtpHostCompliance MODULE-COMPLIANCE 893 STATUS current 894 DESCRIPTION 895 "Host implementations must comply." 896 MODULE RTP-MIB 897 MANDATORY-GROUPS { rtpSystemGroup } 898 GROUP rtpHostGroup 899 DESCRIPTION 900 "The objects in the rtpHostGroup MUST be 901 implemented in RTP host systems that are the source 902 or the destination of RTP data packets." 903 ::= { rtpCompliances 1 } 905 rtpMonitorCompliance MODULE-COMPLIANCE 906 STATUS current 907 DESCRIPTION 908 "Monitor implementations must comply." 909 MODULE RTP-MIB 910 MANDATORY-GROUPS { 911 rtpSystemGroup, 912 rtpHostGroup 913 } 914 GROUP rtpMonitorGroup 915 DESCRIPTION 916 "The objects in the rtpMonitorGroup MUST be 917 implemented in RTP monitors." 918 OBJECT rtpSessionNewIndex 919 MIN-ACCESS not-accessible 920 DESCRIPTION 921 "RTP host system implementations support of 922 row creation and deletion is OPTIONAL so 923 implementation of this object is OPTIONAL." 924 OBJECT rtpSessionDomain 925 MIN-ACCESS read-only 926 DESCRIPTION 927 "RTP host system implementation support of 928 row creation and deletion is OPTIONAL. When 929 it is not supported so write access is 930 OPTIONAL." 931 OBJECT rtpSessionRemAddr 932 MIN-ACCESS read-only 933 DESCRIPTION 934 "Row creation and deletion is OPTIONAL so 935 read-create access to this object is OPTIONAL." 936 OBJECT rtpSessionIfIndex 937 MIN-ACCESS read-only 938 DESCRIPTION 939 "Row creation and deletion is OPTIONAL so 940 read-create access to this object is OPTIONAL." 942 OBJECT rtpSessionRowStatus 943 MIN-ACCESS not-accessible 944 DESCRIPTION 945 "Row creation and deletion is OPTIONAL so 946 read-create access to this object is OPTIONAL." 947 OBJECT rtpSessionLocAddr 948 MIN-ACCESS not-accessible 949 DESCRIPTION 950 "RTP monitor sourcing of RTP or RTCP data packets 951 is OPTIONAL and implementation of this object is 952 OPTIONAL." 953 OBJECT rtpRcvrPT 954 MIN-ACCESS not-accessible 955 DESCRIPTION 956 "RTP monitor systems NEED NOT support 957 retrieval of the RTP Payload Type from the RTP 958 header (and may receive RTCP messages only). When 959 queried for the payload type information, the 960 RTP agent may return 'noSuchObject'." 961 OBJECT rtpSenderPT 962 MIN-ACCESS not-accessible 963 DESCRIPTION 964 "RTP monitor systems may recieve only the RTCP messages 965 and not the RTP messages that contain the payload type 966 information in the header. Thus implementation of this 967 object is OPTIONAL." 968 OBJECT rtpRcvrOctets 969 MIN-ACCESS not-accessible 970 DESCRIPTION 971 "RTP monitor systems may recieve only the RTCP messages 972 and not the RTP messages that contain the octet count 973 of the RTP message. Thus implementation of this 974 object is OPTIONAL." 975 OBJECT rtpRcvrPackets 976 MIN-ACCESS not-accessible 977 DESCRIPTION 978 "RTP monitor systems may recieve only the RTCP messages 979 and not the RTP messages that contain the octet count 980 of the RTP message. Thus implementation of this 981 object is OPTIONAL." 982 ::= { rtpCompliances 2 } 983 END 984 6. Security Issues 985 In most cases, MIBs are not themselves security risks; if SNMP security 986 is operating as intended, the use of a MIB to view information about a 987 system, or to change some parameter at the system, is a tool, not a threat. 988 None of the read-only objects in this MIB reports a password, though 989 some SDES items such as the CNAME, the canonical name, may be deemed 990 sensitive depending on the security policies of a particular 991 enterprise. If access to these objects is not limited by an 992 appropriate access control policy, these objects can provide an 993 attacker with information about a system's configuration and the 994 services that that system is providing. Some enterprises view their 995 network and system configurations themselves, as well as information 996 about usage and performance, as corporate assets; such enterprises may 997 wish to restrict SNMP access to most of the objects in the MIB. 998 This MIB supports read-write operations against rtpSessionNewIndex which 999 has the side effect of creating an entry in the rtpSessionTable when it 1000 is written to. Five objects in rtpSessionEntry have read-create access: 1001 rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, 1002 rtpSessionRowStatus rtpSessionIfAddr identify an RTP session to be 1003 monitored on a particular interface. The values of these objects are 1004 not to be changed once created, and initialization of these objects 1005 affects only the monitoring of an RTP session and not the operation of 1006 an RTP session on any host end-system. Since write operations to 1007 rtpSessionNewIndex and the five objects in rtpSessionEntry affect the 1008 operation of the monitor, write access to these objects should be 1009 subject to the appropriate access control policy. 1010 Confidentiality of RTP and RTCP data packets is defined in section 9 of 1011 the RTP specification [1]. Encryption may be performed on RTP packets, 1012 RTCP packets, or both. Encryption of RTCP packets may pose a problem 1013 for third-party monitors though "For RTCP, it is allowed to split a 1014 compound RTCP packet into two lower-layer packets, one to be encrypted 1015 and one to be sent in the clear. For example, SDES information might 1016 be encrypted while reception reports were sent in the clear to 1017 accommodate third-party monitors [1]." 1018 7. Acknowledgements 1019 The authors wish to thank Bert Wijnen and the participants from the 1020 ITU SG-16 management effort for their helpful comments. Alan Batie 1021 and Bill Lewis from Intel also contributed greatly to the RTP MIB 1022 through their review of various drafts of the MIB and their work 1023 on the implementation of an SNMP RTP Monitor. 1025 8. References 1027 [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: 1028 A Transport Protocol for real-time applications," RFC 1889. 1030 [2] Harrington, D., Presuhn, R., and B. Wijnen, "An Architecture for 1031 Describing SNMP Management Frameworks", RFC 2271, Cabletron 1032 Systems, Inc., BMC Software, Inc., IBM T. J. Watson Research, 1033 January 1998 1035 [3] Rose, M., and K. McCloghrie, "Structure and Identification of 1036 Management Information for TCP/IP-based Internets", RFC 1155, 1037 Performance Systems International, Hughes LAN Systems, May 1990 1039 [4] Rose, M., and K. McCloghrie, "Concise MIB Definitions", RFC 1212, 1040 Performance Systems International, Hughes LAN Systems, March 1991 1042 [5] M. Rose, "A Convention for Defining Traps for use with the SNMP", 1043 RFC 1215, Performance Systems International, March 1991 1045 [6] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Structure 1046 of Management Information for Version 2 of the Simple Network 1047 Management Protocol (SNMPv2)", RFC 1902, SNMP Research,Inc., Cisco 1048 Systems, Inc., Dover Beach Consulting, Inc., International Network 1049 Services, January 1996. 1051 [7] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Textual 1052 Conventions for Version 2 of the Simple Network Management Protocol 1053 (SNMPv2)", RFC 1903, SNMP Research, Inc., Cisco Systems, Inc., 1054 Dover Beach Consulting, Inc., International Network Services, 1055 January 1996. 1057 [8] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Conformance 1058 Statements for Version 2 of the Simple Network Management Protocol 1059 (SNMPv2)", RFC 1904, SNMP Research, Inc., Cisco Systems, Inc., 1060 Dover Beach Consulting, Inc., International Network Services, 1061 January 1996. 1063 [9] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "Simple Network 1064 Management Protocol", RFC 1157, SNMP Research, Performance Systems 1065 International, Performance Systems International, MIT Laboratory 1066 for Computer Science, May 1990. 1068 [10] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, 1069 "Introduction to Community-based SNMPv2", RFC 1901, SNMP Research, 1070 Inc., Cisco Systems, Inc., Dover Beach Consulting, Inc., 1071 International Network Services, January 1996. 1073 [11] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Transport 1074 Mappings for Version 2 of the Simple Network Management Protocol 1075 (SNMPv2)", RFC 1906, SNMP Research, Inc., Cisco Systems, Inc., 1076 Dover Beach Consulting, Inc., International Network Services, 1077 January 1996. 1079 [12] Case, J., Harrington D., Presuhn R., and B. Wijnen, "Message 1080 Processing and Dispatching for the Simple Network Management 1081 Protocol (SNMP)", RFC 2272, SNMP Research, Inc., Cabletron Systems, 1082 Inc., BMC Software, Inc., IBM T. J. Watson Research, January 1998. 1084 [13] Blumenthal, U., and B. Wijnen, "User-based Security Model (USM) for 1085 version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 1086 2274, IBM T. J. Watson Research, January 1998. 1088 [14] Case, J., McCloghrie, K., Rose, M., and S. Waldbusser, "Protocol 1089 Operations for Version 2 of the Simple Network Management Protocol 1090 (SNMPv2)", RFC 1905, SNMP Research, Inc., Cisco Systems, Inc., 1091 Dover Beach Consulting, Inc., International Network Services, 1092 January 1996. 1094 [15] Levi, D., Meyer, P., and B. Stewart, "SNMPv3 Applications", RFC 1095 2273, SNMP Research, Inc., Secure Computing Corporation, Cisco 1096 Systems, January 1998 1098 [16] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based Access 1099 Control Model (VACM) for the Simple Network Management Protocol 1100 (SNMP)", RFC 2275, IBM T. J. Watson Research, BMC Software, Inc., 1101 Cisco Systems, Inc., January 1998