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