Internet Draft RTP MIB August 7, 1998 Real-Time Transport Protocol Management Information Base August 7, 1998 Mark Baugher Intel Corporation 2111 N.E.25th Avenue Hillsboro, Oregon 97124 mbaugher@intel.com John Du Intel Corporation 2111 N.E.25th Avenue Hillsboro, Oregon 97124 John.Du@intel.com Stan Naudus 3Com Corporation 2070 Chain Bridge Road Vienna, Virginia 22182 Stan_Naudus@3Com.com Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or made obsolete by other documents at any time. It is not appropriate to use Internet-Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet- Drafts Shadow Directories on ds.internic.net, nic.nordu.net, venera.isi.edu, or munnari.oz.au. Baugher, Du, Naudus Expires February 7, 1999 [Page 1] Internet Draft RTP MIB August 7, 1998 1. Changes from Previous Draft There is a large change introduced in this draft from the previous draft: The tables for the RTP host and the RTP monitor have been merged. The rtpInTable and rtpEgTable have been removed and their objects are subsumed by the rtpRcvrTable and rtpSenderTable, respectively. The rtpRRTable and the rtpSRTable for RTP monitors are removed and their objects are subsumed by the rtpRcvrTable and rtpSenderTable respectively. rtpSessionMonitor has been added to the rtpSessionTable to distinguish between sessions that are being sourced or received by the local RTP System and sessions that are being monitored by a third-party monitor or by a local RTP System that may also be sending or receiving RTP Session data. For clarity an explicit address pair, rtpSessionLocAddr and rtpSessionRemAddr have been added to the rtpSessionTable to identify an RTP Session and replace the rtpEgDstAddr and rtpInDstAddr objects. rtpSessionRemAddr replaces (renames) rtpSessionAddr. Finally, rtpRRFracLost has been removed as an object used by RTP monitors in favor of polling and computing loss statistics in the network management application. 2. Abstract This memo defines an experimental Management Information Base (MIB) for use with network management protocols in TCP/IP-based internets. In particular, it defines objects for managing Real-Time Transport Protocol systems [1]. Comments should be made to the IETF Audio/Video Transport Working Group at rem-conf@es.net. This memo does not specify a standard for the Internet community. 3. The Network Management Framework The SNMPv2 Network Management Framework consists of the following major components: Baugher, Du, Naudus Expires February 7, 1999 [Page 2] Internet Draft RTP MIB August 7, 1998 RFC 1902 which defines the SMI, the mechanisms used for describing and naming objects for the purpose of management. RFC 1903 Textual Conventions for Version 2 of the Simple Network Management Protocol (SNMPv2). RFC 1904 Conformance Statements for Version 2 of the Simple Network Management Protocol (SNMPv2). RFC 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2). RFC 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2). RFC 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2). RFC 1908 Coexistence between Version 1 and Version 2 of the Internet-standard Network Management Framework. The Framework permits new objects to be defined for the purpose of experimentation and evaluation. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Within a given MIB module, objects are defined using the SMI's OBJECT-TYPE macro[2]. At a minimum, each object has a name, a syntax, an access-level, and an implementation-status. The name is an object identifier, an administratively assigned name, which specifies an object type. The object type together with an object instance serves to uniquely identify a specific instantiation of the object. For human convenience, we often use a textual string, termed the object descriptor, to also refer to the object type. The syntax of an object type defines the abstract data structure corresponding to that object type. The ASN.1[3] language is used for this purpose. However, RFC 1902 purposely restricts the ASN.1 constructs which may be used. These restrictions are made for simplicity. The access-level of an object type defines whether it makes "protocol sense" to read and/or write the value of an instance of the object type. (This access-level is independent of any administrative authorization policy.) The implementation-status of an object type indicates whether the object is mandatory, optional, obsolete, or deprecated. Baugher, Du, Naudus Expires February 7, 1999 [Page 3] Internet Draft RTP MIB August 7, 1998 4. Overview An "RTP System" may be a host end-system that runs an application program that sends or receives RTP data packets, or it may be an intermediate-system that forwards RTP packets. RTP Control Protocol (RTCP) packets are sent by senders and receivers to convey information about RTP packet transmission and reception [1]. RTP monitors may collect RTCP information on senders and receivers to and from an RTP host or intermediate-system. 4.1 Components The RTP MIB is structured around "Session," "Receiver" and "Sender" conceptual abstractions. 4.1.1 An "RTP Session" is the "...association of participants communicating with RTP. For each participant, the session is defined by a particular pair of destination transport addresses (one network address plus a port pair for RTP and RTCP). The destination transport addresses may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast addresses plus a common port pair," as defined in section 3 of [1]. 4.1.2 A "Sender" is identified within an RTP Session by a 32-bit numeric "Synchronization Source," or "SSRC", value and is "...the source of a stream of RTP packets" as defined in section 3 of [1]. The Sender is also a source of RTCP Sender Report packets as specified in section 6 of [1]. 4.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or multicast Receiver as described in 4.2.1, above. An RTP Receiver has an SSRC value that is unique to the session. An RTP Receiver is a source of RTCP Receiver Reports as specified in section 6 of [1]. 4.2 Textual Conventions A new data type, InterfaceIndex, is introduced as a textual convention in this MIB document. Textual conventions enhance the readability of the specification and can ease comparison with other specifications if appropriate. It should be noted that the introduction of the textual conventions has no effect on either the syntax nor the semantics of any managed objects. The use of these is merely an artifact of the explanatory method used. Objects defined in terms of one of these methods are always encoded by means of the rules that define the primitive type. Hence, no changes to the SMI or the SNMP are necessary to accommodate these textual conventions which are adopted merely for the convenience of readers and writers. Baugher, Du, Naudus Expires February 7, 1999 [Page 4] Internet Draft RTP MIB August 7, 1998 4.3 Applicability of the MIB to RTP System Implementations The RTP MIB may be used in two types of RTP implementations, RTP Host Systems (end systems) and RTP Monitors, see section 3 of [1]. Use of the RTP MIB for RTP Translators and Mixers, as defined in section 7 of [1], is for further study. 4.3.1 RTP Host Systems are end-systems that may use the RTP MIB to collect RTP Session and Stream data that the host is sending or receiving; these data may be used by a network manager to detect and diagnose faults that occur over the life time of an RTP Session as in a "help-desk" scenario. 4.3.2 RTP Monitors of multicast RTP sessions may be third-party, or may be located in an RTP intermediate-system or in the host. RTP Monitors may use the RTP MIB to collect RTP Session and Stream statistical data; these data may be used by a network manager for capacity planning and other network-management purposes. An RTP Monitor may use the RTP MIB to collect data to permit a network manager to detect and diagnose faults in RTP sessions, or to permit a network manger to configure its operation. 4.4 The Structure of the RTP MIB There are three tables in the RTP MIB. The rtpSessionTable contains objects that describe active sessions at the host, intermediate system, or monitor. The rtpSenderTable contains information about senders to the RTP Session. The rtpRcvrTable contains information about receivers of RTP Session data. For any particular RTP Session, the rtpSessionMonitor object indicates whether information about remote senders or receivers to the RTP Session are to be monitored. RTP Sessions are monitored by the sub-agent that updates rtpSenderTable and rtpRcvrTable objects with information from RTCP reports from remote senders or remote receivers respectively. rtpSessionNewIndex is a global object that permits a network-management application to obtain a unique index for conceptual row creation in the rtpSessionTable. In this way the SNMP Set operation may be used to configure a monitor. Baugher, Du, Naudus Expires February 7, 1999 [Page 5] Internet Draft RTP MIB August 7, 1998 4.5 SNMP Implementations An RTP System that runs either a single application or multiple applications with a single management-entity may be a practical configuration for monitoring, translating or mixing. Host end- -systems are the vast majority of RTP implementations, however, a "monolithic" solution may be inadequate if management of RTP end-systems proves to be truly useful. The RTP MIB contains tables that may be shared among RTP application programs that run concurrently on the same device - as many or most do. Sharing occurs on a table basis. Table sharing may be a problem for SNMP management entities on some host operting systems: All SNMP management requests are sent to UDP Port 161, and an Application Programming Interface (API) is needed to facilitate this sharing. The API is specific to the host operating system, and there are solutions provided by host operating system vendors and by independent software vendors. There is also a standardization effort within the IETF to at least define a standard system-interface protocol that may be implemented in an API to permit multiple management entities to share the object name space[4]. Whether or not independent RTP application programs can cooperatively and concurrently support the RTP MIB is outside the scope of this draft document and will depend upon the operating system in question. Baugher, Du, Naudus Expires February 7, 1999 [Page 6] Internet Draft RTP MIB August 7, 1998 5. Definitions RTP DEFINITIONS ::= BEGIN IMPORTS Counter32, Gauge32, experimental, Integer32, IpAddress, MODULE-IDENTITY, OBJECT-IDENTITY, OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI DisplayString, RowStatus, TAddress, TDomain, TestAndIncr, TEXTUAL-CONVENTION, TimeStamp, TruthValue FROM SNMPv2-TC OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF; rtp MODULE-IDENTITY LAST-UPDATED "9807212000Z" ORGANIZATION "IETF AVT Working Group" CONTACT-INFO "Mark Baugher Postal: Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 United States Tel: +1 503 264 3849 Email: mbaugher@intel.com John Du Postal: Intel Corporation 2111 NE 25th Avenue Hillsboro, OR 97124 United States Tel: +1 503 264 0636 Email: John.Du@intel.com Stan Naudus Postal: 3Com Corporation 2070 Chain Bridge Road Vienna, VA United States Tel: +1 703 848 7710 Email: Stan_Naudus@3Com.com" DESCRIPTION "The managed objects of RTP systems. The MIB is structured around three types of information. 1. General information about RTP Sessions such as the Session Address. 2. Information about RTP streams being sent to an RTP Session by a particular source. 3. Information about RTP streams received on an RTP Session by a particular receiver from a particular sender. Baugher, Du, Naudus Expires February 7, 1999 [Page 7] Internet Draft RTP MIB August 7, 1998 There are two types of RTP Systems, RTP hosts and RTP monitors. As described below, certain objects are unique to a particular type of RTP System. An RTP host may also function as an RTP monitor. Refer to RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' section 3.0, for definitions." ::= { experimental 77 } InterfaceIndex ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "The range of ifIndex. This is defined here since zero is used to define an unnumbered interface." SYNTAX Integer32 -- -- OBJECTS -- rtpGlobals OBJECT IDENTIFIER ::= { rtp 1 } rtpDomains OBJECT IDENTIFIER ::= { rtpGlobals 1 } rtpUDPDomain OBJECT-IDENTITY STATUS current DESCRIPTION "RTP over UDP transport domain over IPv4. This definition uses the transport address type, snmpUDPAddress, which is defined in SNMPv2-TM, 'Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)'." REFERENCE "RFC 1906, sec. 2 " ::= { rtpDomains 1 } Baugher, Du, Naudus Expires February 7, 1999 [Page 8] Internet Draft RTP MIB August 7, 1998 -- -- SESSION TABLE -- rtpSessionNewIndex OBJECT-TYPE SYNTAX TestAndIncr MAX-ACCESS read-write STATUS current DESCRIPTION "This object is used to assign values to rtpSessionIndex as described in 'Textual Conventions for SNMPv2'. For an RTP monitor system, the network manager would read the object, and then write the value back in the Set that creates a new instance of rtpSessionEntry. If the Set fails with the code 'inconsistentValue,' then the process must be repeated; If the Set succeeds, then the object is incremented, and the new instance is created according to the manager's directions. However, if the RTP system is not a monitor, only the RTP sub-agent may create conceptual rows in the RTP session table." ::= { rtpGlobals 2 } rtpSessionTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "There's one entry in the SessionTable for each RTP Session on which packets are being sent, received, and/or monitored." ::= { rtp 2 } Baugher, Du, Naudus Expires February 7, 1999 [Page 9] Internet Draft RTP MIB August 7, 1998 rtpSessionEntry OBJECT-TYPE SYNTAX RtpSessionEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Data in rtpSessionTable uniquely identify an RTP Session. A host sub-agent will create a read-only row for each session to which packets are being sent or received. An RTP Session can be monitored to create management information on all RTP streams being sent or received when the rtpSessionMonitor has the TruthValue of 'true(1)'. A monitor sub-agent may permit row creation with the side effect of causing the RTP System to join the session for the purposes of gathering management information (thus additional conceptual rows are created in the rtpRcvrTable and rtpSenderTable). rtpSessionTable rows can be created for RTP Session monitoring purposes. Rows created by a management application may be deleted via SNMP operations." INDEX { rtpSessionIndex } ::= { rtpSessionTable 1 } RtpSessionEntry ::= SEQUENCE { rtpSessionIndex Integer32, rtpSessionDomain TDomain, rtpSessionRemAddr TAddress, rtpSessionLocAddr TAddress, rtpSessionIfIndex InterfaceIndex, rtpSessionIfAddr IpAddress, rtpSessionSenders Counter32, rtpSessionReceivers Counter32, rtpSessionByes Counter32, rtpSessionStartTime TimeStamp, rtpSessionMonitor TruthValue, rtpSessionRowStatus RowStatus } rtpSessionIndex OBJECT-TYPE SYNTAX Integer32 (1..65535) MAX-ACCESS not-accessible STATUS current DESCRIPTION "The index of the conceptual row which is for SNMP purposes only and has no relation to any protocol value." ::= { rtpSessionEntry 1} Baugher, Du, Naudus Expires February 7, 1999 [Page 10] Internet Draft RTP MIB August 7, 1998 rtpSessionDomain OBJECT-TYPE SYNTAX TDomain MAX-ACCESS read-create STATUS current DESCRIPTION "The transport-layer protocol used for sending or receiving the stream of RTP data packets on this session. Cannot be changed after rtpSessionRowStatus is 'active'." DEFVAL { rtpUDPDomain } ::= { rtpSessionEntry 2 } rtpSessionRemAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The remote destination transport address on which the stream of RTP data packets is being sent and/or received. An RTP Session is defined by a pair of destination transport addresses. 'The destination address pair may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network address pairs.' See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications, sec. 3. The transport service is identified by rtpSessionDomain. For rtpUDPDomain, this is an IP address and an even-numbered UDP Port with the RTCP being sent on the next higher odd-numbered port, see RFC 1889, sec. 5. Cannot be changed after rtpSessionRowStatus is 'active'." ::= { rtpSessionEntry 3 } rtpSessionLocAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The local destination transport address on which the stream of data packets is being sent and/or received. For unicast RTP Sessions, this is the local address of the RTP Session. For IP multicast RTP Sessions, this object should have the same value as rtpSessionRemoteAddr. See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications, sec. 3. The transport service is identified by rtpSessionDomain. For rtpUDPDomain, this is an IP address and an even-numbered UDP Port with the RTCP being sent on the next higher odd-numbered port, see RFC 1889, sec. 5." ::= { rtpSessionEntry 4 } Baugher, Du, Naudus Expires February 7, 1999 [Page 11] Internet Draft RTP MIB August 7, 1998 rtpSessionIfIndex OBJECT-TYPE SYNTAX InterfaceIndex MAX-ACCESS read-create STATUS current DESCRIPTION "The ifIndex value is zero for interfaces that have an IP address defined for the interface on which RTP data packets are sent or received for this session. Otherwise this object is set to the corresponding value from the Internet Standard MIB. Cannot be changed after rtpSessionRowStatus is 'active'. A zero value for both rtpSessionIfIndex and rtpSessionIfAddr indicates that the default interface be used." DEFVAL { 0 } ::= { rtpSessionEntry 5 } rtpSessionIfAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The IP Address of the interface on which the stream of RTP data packets is being sent and/or received for interfaces that have an IP Address. If rtpSessionIfIndex is non-zero, this object should have the value 0.0.0.0. Cannot be changed after rtpSessionRowStatus has become 'active'. A zero value for both rtpSessionIfIndex and rtpSessionIfAddr indicates that the default interface be used." DEFVAL { 0 } ::= { rtpSessionEntry 6 } rtpSessionSenders OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of senders observed by the monitor since this conceptual row was created (rtpSessionStartTime). Senders that leave and then re-join following an RTCP BYE (See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 6.6) or session timeout may be counted twice." ::= { rtpSessionEntry 7 } Baugher, Du, Naudus Expires February 7, 1999 [Page 12] Internet Draft RTP MIB August 7, 1998 rtpSessionReceivers OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "The maximum number of receivers that are observed since this conceptual row was created (rtpSessionStartTime). Receivers that leave and then re-join following an RTCP BYE (See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 6.6)or session timeout may be counted twice." ::= { rtpSessionEntry 8 } rtpSessionByes OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of RTCP BYE (See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 6.6) messages received by this entity." ::= { rtpSessionEntry 9 } rtpSessionStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpSessionEntry 10 } rtpSessionMonitor OBJECT-TYPE SYNTAX TruthValue MAX-ACCESS read-only STATUS current DESCRIPTION "Boolean, Set to 'true(1)' if senders or receivers in addition to the local RTP System are to be monitored. RTP Host Systems MUST initialize this to 'false(2)'. RTP Monitors MUST initialize to 'true(1)' and RTP Hosts MUST initialize this 'false(2)'." ::= { rtpSessionEntry 11 } Baugher, Du, Naudus Expires February 7, 1999 [Page 13] Internet Draft RTP MIB August 7, 1998 rtpSessionRowStatus OBJECT-TYPE SYNTAX RowStatus MAX-ACCESS read-create STATUS current DESCRIPTION "Value of 'active' when RTP or RTCP messages being sent or received by an RTP System are being monitored. A manager- created conceptual row must have the rtpSessionAddr initialized by the manager before becoming 'active' A conceptual row that is in the 'notReady' or 'notInService' state MAY be removed after 5 minutes." ::= { rtpSessionEntry 12 } -- -- SENDERS TABLE -- rtpSenderTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpSenderEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of information about a sender or senders to an RTP Session. Sub-agents for RTP sending hosts MUST create an entry in this table for each stream being sent. Sub-agents for RTP monitors create an entry for each observed RTP Session sender as a side-effect when a conceptual row in the rtpSessionTable is made 'active' by a manager." ::= { rtp 3 } rtpSenderEntry OBJECT-TYPE SYNTAX RtpSenderEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains monitoring information from a single RTP Synchronization Source (SSRC, see RFC 1889 'RTP: A Transport Protocol for Real-Time Applications' sec.6). The session is identified to the the SNMP entity by rtpSessionIndex." INDEX { rtpSessionIndex, rtpSenderSSRC } ::= { rtpSenderTable 1 } Baugher, Du, Naudus Expires February 7, 1999 [Page 14] Internet Draft RTP MIB August 7, 1998 RtpSenderEntry ::= SEQUENCE { rtpSenderSSRC Unsigned32, rtpSenderCNAME DisplayString, rtpSenderAddr TAddress, rtpSenderPackets Counter32, rtpSenderOctets Counter32, rtpSenderTool DisplayString, rtpSenderSRs Counter32, rtpSenderSRTime TimeStamp, rtpSenderPT INTEGER, rtpSenderStartTime TimeStamp } rtpSenderSSRC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RTP SSRC, or synchronization source identifier of the sender. The RTP Session Address plus an SSRC uniquely identify a sender or receiver of an RTP stream (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.3)." ::= { rtpSenderEntry 1 } rtpSenderCNAME OBJECT-TYPE SYNTAX DisplayString (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The RTP canonical name of the sender." ::= { rtpSenderEntry 2 } rtpSenderAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The unicast transport source address of the sender." ::= { rtpSenderEntry 3 } rtpSenderPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of RTP packets sent by this sender, or observed by an RTP monitor from RTCP Reports, since rtpSenderStartTime." ::= { rtpSenderEntry 4 } Baugher, Du, Naudus Expires February 7, 1999 [Page 15] Internet Draft RTP MIB August 7, 1998 rtpSenderOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of RTP octets sent by this sender, or observed by an RTP monitor from RTCP Reports, since rtpSenderStartTime." ::= { rtpSenderEntry 5 } rtpSenderTool OBJECT-TYPE SYNTAX DisplayString (SIZE(0..127)) MAX-ACCESS read-only STATUS current DESCRIPTION "Name of the application program that's the stream source." DEFVAL { ''H } -- Null if not available ::= { rtpSenderEntry 6 } rtpSenderSRs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of the number of RTCP Sender Reports that have been sent from this sender, or observed if the RTP entity is a monitor, since rtpSenderStartTime." ::= { rtpSenderEntry 7 } rtpSenderSRTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value is always zero if the source of the RTP Stream is the local RTP System. Otherwise, rtpSenderSRTime is the value of SysUpTime at the time that the last SR was received from this sender, in the case of a monitor." ::= { rtpSenderEntry 8 } rtpSenderPT OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Static or dynamic payload type from the RTP header (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec. 5)." ::= { rtpSenderEntry 9 } Baugher, Du, Naudus Expires February 7, 1999 [Page 16] Internet Draft RTP MIB August 7, 1998 rtpSenderStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpSenderEntry 10 } -- -- RECEIVERS TABLE -- rtpRcvrTable OBJECT-TYPE SYNTAX SEQUENCE OF RtpRcvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Table of information about a receiver or receivers of RTP Session data. Sub-agents for RTP hosts that receive RTP Session packets create an entry in this table for that receiver/sender pair Sub-agents for RTP monitors create an entry for each observed RTP Session receiver as a side- effect when a conceptual row in the rtpSessionTable is made 'active' by a manager." ::= { rtp 4 } rtpRcvrEntry OBJECT-TYPE SYNTAX RtpRcvrEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "Each entry contains monitoring information from a single RTP Synchronization Source (SSRC, see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.6). The session is identified to the the SNMP entity by rtpSessionIndex." INDEX { rtpSessionIndex, rtpRcvrRemSSRC, rtpRcvrLocSSRC } ::= { rtpRcvrTable 1 } Baugher, Du, Naudus Expires February 7, 1999 [Page 17] Internet Draft RTP MIB August 7, 1998 RtpRcvrEntry ::= SEQUENCE { rtpRcvrRemSSRC Unsigned32, rtpRcvrLocSSRC Unsigned32, rtpRcvrCNAME DisplayString, rtpRcvrAddr TAddress, rtpRcvrRTT Gauge32, rtpRcvrLostPackets Counter32, rtpRcvrLostOctets Counter32, rtpRcvrJitter Gauge32, rtpRcvrTool DisplayString, rtpRcvrRRs Counter32, rtpRcvrRRTime TimeStamp, rtpRcvrPT INTEGER, rtpRcvrPackets Counter32, rtpRcvrOctets Counter32, rtpRcvrStartTime TimeStamp } rtpRcvrRemSSRC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RTP SSRC, or synchronization source identifier of the sender. The RTP Session Address plus an SSRC uniquely identify a sender or receiver of an RTP stream (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.3)." ::= { rtpRcvrEntry 1 } rtpRcvrLocSSRC OBJECT-TYPE SYNTAX Unsigned32 MAX-ACCESS not-accessible STATUS current DESCRIPTION "The RTP SSRC, or synchronization source identifier of the. receiver. The RTP Session Address plus an SSRC uniquely identify a sender or receiver of an RTP stream (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec.3)." ::= { rtpRcvrEntry 2 } rtpRcvrCNAME OBJECT-TYPE SYNTAX DisplayString (SIZE(0..255)) MAX-ACCESS read-only STATUS current DESCRIPTION "The RTP canonical name of the receiver." ::= { rtpRcvrEntry 3 } Baugher, Du, Naudus Expires February 7, 1999 [Page 18] Internet Draft RTP MIB August 7, 1998 rtpRcvrAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The unicast transport address of the receiver." ::= { rtpRcvrEntry 4 } rtpRcvrRTT OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "The round trip time measurement taken by the source of the RTP stream based on the algorithm described on sec. 6 of RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications.' This algorithm can produce meaningful results when the sub-agent has the same clock as the stream sender (when the RTP monitor is also a sending host for the particular reciever). Otherwise, the entity should return 'noSuchObject' in response to queries against rtpRcvrRTT." ::= { rtpRcvrEntry 5 } rtpRcvrLostPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of RTP packets lost as observed by this receiver since rtpRcvrStartTime." ::= { rtpRcvrEntry 6 } rtpRcvrLostOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of RTP octets lost as observed by this receiver since rtpRcvrStartTime." ::= { rtpRcvrEntry 7 } rtpRcvrJitter OBJECT-TYPE SYNTAX Gauge32 MAX-ACCESS read-only STATUS current DESCRIPTION "An estimate of delay variation as observed by this receiver." ::= { rtpRcvrEntry 8 } Baugher, Du, Naudus Expires February 7, 1999 [Page 19] Internet Draft RTP MIB August 7, 1998 rtpRcvrTool OBJECT-TYPE SYNTAX DisplayString (SIZE(0..127)) MAX-ACCESS read-only STATUS current DESCRIPTION "Name of the application program that's receiving the stream." DEFVAL { ''H } -- Null if not available ::= { rtpRcvrEntry 9 } rtpRcvrRRs OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "A count of Receiver Reports as observed by this receiver since rtpSessionStartTime." ::= { rtpRcvrEntry 10 } rtpRcvrRRTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value is always zero if the receiver of the RTP Stream is the local RTP System. Otherwise, rtpRcvrRRTime is the value of SysUpTime at the time that the last RTCP Receiver Report was received from this receiver, in the case of a monitor, or sent by this receiver, in the case of a receiving host." ::= { rtpRcvrEntry 11 } rtpRcvrPT OBJECT-TYPE SYNTAX INTEGER (0..127) MAX-ACCESS read-only STATUS current DESCRIPTION "Static or dynamic payload type from the RTP header (see RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications' sec. 5)." ::= { rtpRcvrEntry 12 } Baugher, Du, Naudus Expires February 7, 1999 [Page 20] Internet Draft RTP MIB August 7, 1998 rtpRcvrPackets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of RTP packets received by this RTP host receiver since rtpRcvrStartTime. RTP Sessions being monitored ('true(1)' value for rtpSessionMonitor) may not have this information." ::= { rtpRcvrEntry 13 } rtpRcvrOctets OBJECT-TYPE SYNTAX Counter32 MAX-ACCESS read-only STATUS current DESCRIPTION "Count of RTP octets received by this receiving RTP host since rtpRcvrStartTime. Monitored sessions (rtpSessionMonitor is 'false') may not have this information." ::= { rtpRcvrEntry 14 } rtpRcvrStartTime OBJECT-TYPE SYNTAX TimeStamp MAX-ACCESS read-only STATUS current DESCRIPTION "The value of SysUpTime at the time that this row was created." ::= { rtpRcvrEntry 15 } -- -- MODULE GROUPS -- Baugher, Du, Naudus Expires February 7, 1999 [Page 21] Internet Draft RTP MIB August 7, 1998 rtpSystemGroup OBJECT-GROUP OBJECTS { rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, rtpSessionIfAddr, rtpSessionSenders, rtpSessionReceivers, rtpSessionStartTime, rtpSessionRowStatus, rtpSessionByes, rtpSessionMonitor, rtpSenderCNAME, rtpSenderAddr, rtpSenderPackets, rtpSenderOctets, rtpSenderTool, rtpSenderSRs, rtpSenderSRTime, rtpSenderStartTime, rtpRcvrCNAME, rtpRcvrAddr, rtpRcvrLostPackets, rtpRcvrJitter, rtpRcvrTool, rtpRcvrRRs, rtpRcvrRRTime, rtpRcvrStartTime } STATUS current DESCRIPTION "Objects used by all RTP systems." ::= { rtp 5 } rtpHostGroup OBJECT-GROUP OBJECTS { rtpSessionLocAddr, rtpSenderPT, rtpRcvrPT, rtpRcvrRTT, rtpRcvrLostOctets, rtpRcvrOctets, rtpRcvrPackets } STATUS current DESCRIPTION "Objects used by RTP host systems." ::= { rtp 6 } Baugher, Du, Naudus Expires February 7, 1999 [Page 22] Internet Draft RTP MIB August 7, 1998 rtpMonitorGroup OBJECT-GROUP OBJECTS { rtpSessionNewIndex } STATUS current DESCRIPTION "Objects used by RTP monitor systems." ::= { rtp 7 } rtpCompliance MODULE-COMPLIANCE STATUS current DESCRIPTION "The management information of the objects in the rtpISGroup is taken from the IP, UDP, RTP headers and the required RTCP messages that are specified in RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications', 6.4. rtpRcvrTool and rtpSenderTool are not required fields in the RTCP SDES message so a DEFVAL is provided for these objects." MODULE RTP MANDATORY-GROUPS { rtpSystemGroup } GROUP rtpHostGroup DESCRIPTION "The objects in the rtpHostGroup MUST be implemented in RTP Host systems that are the source or the destination of RTP data packets." GROUP rtpMonitorGroup DESCRIPTION "The objects in the rtpMonitorGroup MUST be implemented in RTP monitors." OBJECT rtpSessionNewIndex MIN-ACCESS not-accessible DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionDomain MIN-ACCESS read-only DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionRemAddr MIN-ACCESS read-only DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." Baugher, Du, Naudus Expires February 7, 1999 [Page 23] Internet Draft RTP MIB August 7, 1998 OBJECT rtpSessionIfIndex MIN-ACCESS read-only DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionIfAddr MIN-ACCESS read-only DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionRowStatus MIN-ACCESS not-accessible DESCRIPTION "RTP host system implementations MAY NOT support row creation and deletion." OBJECT rtpSessionLocAddr MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT source RTP or RTCP data packets." OBJECT rtpRcvrPT MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support retrieval of the RTP Payload Type from the RTP header (and may receive RTCP messages only). When queried for the payload type information, the sub-agent MAY return 'noSuchObject'." OBJECT rtpSenderPT MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support retrieval of the RTP Payload Type from the RTP header (and may receive RTCP messages only). When queried for the payload type information, the sub-agent MAY return 'noSuchObject'." OBJECT rtpRcvrRTT MIN-ACCESS not-accessible DESCRIPTION "The round-trip time calculation presented on sec. 6 of RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications', may be accurately computed by a monitor that uses the same clock as a particular sender. In other cases, the monitor SHOULD return 'noSuchObject' in response to a Get that references rtpRcvrRTT." Baugher, Du, Naudus Expires February 7, 1999 [Page 24] Internet Draft RTP MIB August 7, 1998 OBJECT rtpRcvrLostOctets MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support monitoring of this object when rtpSessionMonitor is 'true' since it is not obtainable from RTCP reports." OBJECT rtpRcvrOctets MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support monitoring of this object when rtpSessionMonitor is 'true' since it is not obtainable from RTCP reports." OBJECT rtpRcvrPackets MIN-ACCESS not-accessible DESCRIPTION "RTP monitor system implementations MAY NOT support monitoring of this object when rtpSessionMonitor is 'true' since it is not obtainable from RTCP reports." ::= { rtp 8 } END 6. Security Issues In most cases, MIBs are not themselves security risks; if SNMP security is operating as intended, the use of a MIB to view information about a system, or to change some parameter at the system, is a tool, not a threat. None of the read-only objects in this MIB reports a password, though some SDES items such as the CNAME, the canonical name, may be deemed sensitive depending on the security policies of a particular enterprise. If access to these objects is not limited by an appropriate access control policy, these objects can provide an Baugher, Du, Naudus Expires February 7, 1999 [Page 25] Internet Draft RTP MIB August 7, 1998 attacker with information about a system's configuration and the services that that system is providing. Some enterprises view their network and system configurations themselves, as well as information about usage and performance, as corporate assets; such enterprises may wish to restrict SNMP access to most of the objects in the MIB. This MIB supports read-write operations against rtpSessionNewIndex which has the side effect of creating an entry in the rtpSessionTable when it is written to. Five objects in rtpSessionEntry have read-create access: rtpSessionDomain, rtpSessionRemAddr, rtpSessionIfIndex, rtpSessionRowStatus rtpSessionIfAddr identify an RTP Session to be monitored on a particular interface. The values of these objects are not to be changed once created, and initialization of these objects affects only the monitoring of an RTP Session and not the operation of an RTP Session on any host end-system. Since write operations to rtpSessionNewIndex and the five objects in rtpSessionEntry affect the operation of the monitor, write access to these objects should be subject to the appropriate access control policy. Confidentiality of RTP and RTCP data packets is defined in section 9 of the RTP specification [1]. Encryption may be performed on RTP packets, RTCP packets, or both. Encryption of RTCP packets may pose a problem for third-party monitors though "For RTCP, it is allowed to split a compound RTCP packet into two lower-layer packets, one to be encrypted and one to be sent in the clear. For example, SDES information might be encrypted while reception reports were sent in the clear to accommodate third-party monitors [1]." Baugher, Du, Naudus Expires February 7, 1999 [Page 26] Internet Draft RTP MIB August 7, 1998 7. Acknowledgements George Kajos and Irina Suconick from Videoserver recommended some changes in the structure and organization of the RTP MIB that are contained in this draft. Boris Bekkerman from 3Com identified some problems in clarity and consistency of RTP MIB definitions. Alan Batie and Bill Strahm from Intel have prototyped SNMP RTP Monitors on FreeBSD and Windows NT, respectively. The Windows implementation is being used at Intel. Bill Lewis from Intel has written an RTP management application that is available in binary form with the FreeBSD version of the SNMP RTP Monitor. 9. References [1] H. Shulzrinne, S. Casner, R. Frederick, and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 1889. [2] J. Case, K. McCloghrie, M. Rose, and S. Waldbusser, "Structure of Management Information for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1902, January, 1996. [3] Information processing systems -- Open Systems Interconnection -- Specification of Basic Encoding Rules for Abstract Notation One (ASN.1), International Organization for Standardization. International Standard 8825, (December, 1987). [4] M.Daniele, B. Wijnen, D. Francisco, "Agent Extensibility (AgentX) Protocol, Version 1," RFC 2257, January 1998. Baugher, Du, Naudus Expires February 7, 1999 [Page 27]