Audio/Video Working Group Alan Clark Internet-Draft Telchemy Expires: March 15, 2005 Amy Pendleton Nortel Networks Proposed RTP Control Protocol Extended Reports (RTCP XR) VoIP Metrics Management Information Base draft-clark-avt-rtcpxrmib-00.txt Status of this Memo This document is an Internet-Draft and is subject to all provisions of section 3 of RFC 3667. By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she become aware will be disclosed, in accordance with RFC 3668. 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 and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http:// www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on March 15, 2005. Copyright Notice Copyright (C) The Internet Society (2004). All Rights Reserved. Abstract This memo defines a portion of the Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it defines objects for managing Real-Time Transport Control Protocol Extended Reports (RTCP XR) VoIP Metrics (RFC3611). Clark Expires March 2005 [Page 1] draft-clark-avt-rtcpxrmib-00.txt September 2004 Table of Contents 1. The Network Management Framework ............................. 2 2. Overview ..................................................... 3 2.1 Components .................................................. 3 2.2 Applicability of the MIB to RTP System Implementations ...... 4 2.3 The Structure of the RTCP XR MIB ............................ 4 3 Definitions ................................................... 4 4. Security Considerations ...................................... 14 5. Acknowledgements ............................................. 14 6. Intellectual Property ........................................ 14 7. References ................................................... 15 8. Authors' Addresses ........................................... 17 9. Full Copyright Statement ..................................... 17 1. The Internet-Standard Management Framework For a detailed overview of the documents that describe the current Internet-Standard Management Framework, please refer to section 7 of RFC 3410 [RFC3410]. Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. MIB objects are generally accessed through the Simple Network Management Protocol (SNMP). Objects in the MIB are defined using the mechanisms defined in the Structure of Management Information (SMI). This memo specifies a MIB module that is compliant to the SMIv2, which is described in STD 58, RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580 [RFC2580]. Clark Expires March 2005 [Page 2] draft-clark-avt-rtcpxrmib-00.txt September 2004 2. 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 [RFC3550]. RTP monitors may collect RTCP information on senders and receivers to and from an RTP host or intermediate-system. The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119. 2.1 Components The RTCP XR MIB is structured around "Session," "Receiver" and "Sender" conceptual abstractions. 2.1.1 An RTP Session is an association of two or more 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 [RFC3550]. 2.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 [RFC3550]. The sender is also a source of RTCP Sender Report packets as specified in section 6 of [RFC3550]. 2.1.3 A "Receiver" of a "stream of RTP packets" can be a unicast or multicast Receiver as described in 2.1.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 [RFC3550]. Clark Expires March 2005 [Page 3] draft-clark-avt-rtcpxrmib-00.txt September 2004 2.2 Applicability of the MIB to RTP System Implementations The RTCP XR MIB may be used in RTP Host Systems (end systems), see section 3 of [RFC3550] that are supporting Voice over IP (VoIP host systems). 2.2.1 VoIP host Systems are end-systems that may use the RTCP XR MIB to collect RTP Voice over IP session 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 lifetime of a VoIP session as in a "help-desk" scenario. 2.2.2 Monitors of RTP Voice over IP sessions may be third-party or may be located in the RTP host. Monitors may use the RTCP XR MIB to collect Voice over IP session statistical data; these data may be used by a network manager for capacity planning and other network- management purposes. A Monitor may use the RTCP XR MIB to collect data to permit a network manager to detect and diagnose faults in VoIP sessions. 2.2.3 Many host systems will want to keep track of streams beyond what they are sending and receiving. In a host monitor system, a host agent would use RTP data from the host to maintain data about streams it is sending and receiving, and RTCP data to collect data about other hosts in the session. 2.3 The Structure of the RTCP XR MIB There is one table in the RTCP XR MIB. The rtpXrVoipTable contains objects that describe completed sessions at the host or monitor. rtpXrVoipIndex 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. 3. Definitions RTCPXR-MIB DEFINITIONS ::= BEGIN IMPORTS Counter32, Counter64, Gauge32, mib-2, Integer32, MODULE-IDENTITY, OBJECT-TYPE, Unsigned32 FROM SNMPv2-SMI OBJECT-GROUP, MODULE-COMPLIANCE FROM SNMPv2-CONF InterfaceIndex FROM IF-MIB ItuPerceivedSeverity FROM ITU-ALARM-TC; Clark Expires March 2005 [Page 4] draft-clark-avt-rtcpxrmib-00.txt September 2004 rtcpXrMIB MODULE-IDENTITY LAST-UPDATED "200409120000Z" ORGANIZATION "IETF AVT Working Group" DESCRIPTION "The managed objects of RTCP XR systems. Refer to RFC 3611, Real Time Control Protocol Extended Reports (RTCP XR) Section 4.7 VoIP Metrics" REVISION "200409120000Z" DESCRIPTION "Initial version of this MIB. Published as draft-clark-avt-rtcpxrmib-00.txt." ::= { mib-2 TBD } -- -- OBJECTS -- rtcpXrMIBObjects OBJECT IDENTIFIER ::= { rtcpXrMIB 1 } rtcpXrConformance OBJECT IDENTIFIER ::= { rtcpXrMIB 2 } rtcpXrEvents OBJECT IDENTIFIER ::= { rtcpXrMIB 3 } -- -- RTCP Extended Reports - Voice over IP Metrics -- -- Description -- This MIB provides basic voice quality monitoring capabilities -- for Voice-over-packet systems. The MIB contains 5 tables of -- information:- -- a table with one entry for each voice terminationPoint -- a table that defines the parameters associated with voice -- coders -- a table of call records with call identifying and quality -- information -- a table of extended call records with additional metrics -- a table of Termination Point groups with one entry per -- logical group rtcpXrVoipTable OBJECT-TYPE SYNTAX SEQUENCE OF rtcpXrVoipEntry ACCESS not-accessible STATUS current DESCRIPTION "Table of information about a receiver or receivers of RTCP XR session data. RTP hosts that receive RTCP XR session packets MUST create an entry in this table for that receiver/sender pair. RTP hosts that send RTCP XR session packets MAY create an entry in this table for each receiver to their stream using RTCP XR feedback from the RTP group. " ::= { rtcpXrMIBObjects 1 } Clark Expires March 2005 [Page 5] draft-clark-avt-rtcpxrmib-00.txt September 2004 rtcpXrVoipEntry OBJECT-TYPE SYNTAX rtcpXrVoipEntry STATUS current DESCRIPTION "An entry in the table of call records. A row in this table is created for each RTP session endpoint participating." INDEX { rtcpXrVoipIndex } ::= { rtcpXrVoipTable 1 } rtcpXrVoipEntry ::= SEQUENCE { rtcpXrVoipIndex INTEGER, rtcpXrVoipCallIdentifier OCTET STRING, rtcpXrVoipSessionIdentifier OCTET STRING, rtcpXrVoipSourceIPaddress OCTET STRING, rtcpXrVoipSourceIdentifier OCTET STRING, rtcpXrVoipDestinationIPaddress OCTET STRING, rtcpXrVoipDestinationIdentifier OCTET STRING, rtcpXrVoipVocoderType OCTET STRING, rtcpXrVoipFrameSize INTEGER, rtcpXrVoipSmapleRate INTEGER, rtcpXrVoipCallDurationMs INTEGER, rtcpXrVoipNetworkLossRate INTEGER, rtcpXrVoipAverageDiscardRate INTEGER, rtcpXrVoipBurstLossDensity INTEGER, rtcpXrVoipBurstLenMs INTEGER, rtcpXrVoipGapLossDensity INTEGER, rtcpXrVoipGapLenMs INTEGER, rtcpXrVoipAverageOneWayDelay INTEGER, rtcpXrVoipEndSystemDelay INTEGER, rtcpXrVoipNoiseLeveldBm INTEGER, rtcpXrVoipSignalLeveldBm INTEGER, rtcpXrVoipLocalRERLdB INTEGER, rtcpXrVoipConversationalR INTEGER, rtcpXrVoipListeningR INTEGER, rtcpXrVoipListeningMOSLQ INTEGER, rtcpXrVoipConversationalMOSCQ INTEGER, rtcpXrVoipPlcType INTEGER, rtcpXrVoipJitterBufferAdaptationMode INTEGER, rtcpXrVoipJitterBufferAdaptationRate INTEGER, rtcpXrVoipJitterBufferAverageDelay INTEGER, rtcpXrVoipJitterBufferMaximumDelay INTEGER, rtcpXrVoipJitterBufferSize INTEGER } rtcpXrVoipIndex OBJECT-TYPE SYNTAX INTEGER (0..65535) STATUS current DESCRIPTION "Index for this call." ::= { rtcpXrVoipEntry 1 } Clark Expires March 2005 [Page 6] draft-clark-avt-rtcpxrmib-00.txt September 2004 rtcpXrVoipCallIdentifier OBJECT-TYPE SYNTAX OCTET STRING STATUS optional DESCRIPTION "Call identifier for this call." ::= { rtcpXrVoipEntry 2 } rtcpXrVoipSessionIdentifier OBJECT-TYPE SYNTAX OCTET STRING STATUS optional DESCRIPTION "Unique identifier for this session. Where a billing record correlation identifer is not available for a particular call, another identifier such as SSRC can be used." ::= { rtcpXrVoipEntry 3 } rtcpXrVoipSourceIPaddress OBJECT-TYPE SYNTAX OCTET STRING STATUS optional DESCRIPTION "Source IP address for this session." ::= { rtcpXrVoipEntry 4 } rtcpXrVoipSourceIdentifierType OBJECT-TYPE SYNTAX INTEGER { dialedNumber(0), urlId (1) } DESCRIPTION "Defines the type of address in parameter rtcpXrVoipSourceIdentifier" ::= { rtcpXrVoipEntry 5 } rtcpXrVoipSourceIdentifier OBJECT-TYPE SYNTAX OCTET STRING STATUS optional DESCRIPTION "Alternate identifier to the IP address. This can be E.164, DN,or URL." ::= { rtcpXrVoipEntry 6 } rtcpXrVoipDestinationIPaddress OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "Source IP address for this session." ::= { rtcpXrVoipEntry 7 } Clark Expires March 2005 [Page 7] draft-clark-avt-rtcpxrmib-00.txt September 2004 rtcpXrVoipDestinationIdentifierType OBJECT-TYPE SYNTAX INTEGER { dialedNumber(0), urlId (1) } DESCRIPTION "Defines the type of address in parameter rtcpXrVoipDestinationIdentifier" ::= { rtcpXrVoipEntry 8 } rtcpXrVoipDestinationIdentifier OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "Alternate identifier to the IP address. This can be E.164, DN, or URL." ::= { rtcpXrVoipEntry 9 } rtcpXrVoipVocoderType OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "Vocoder type used on this call." ::= { rtcpXrVoipEntry 10 } rtcpXrVoipFrameSize OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Companion information to vocoder type. This represents the size of the frames within the RTP packets at the time the information is capture." ::= { rtcpXrVoipEntry 11 } rtcpXrVoipSampleRate OBJECT-TYPE SYNTAX OCTET STRING STATUS current DESCRIPTION "Companion information to vocoder type. This represents the rate at which the frames where sampled. ::= { rtcpXrVoipEntry 12 } rtcpXrVoipCallDurationMs OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Duration of call in milliseconds." ::= { rtcpXrVoipEntry 13 } Clark Expires March 2005 [Page 8] draft-clark-avt-rtcpxrmib-00.txt September 2004 rtcpXrVoipStartTimestamp OBJECT-TYPE SYNTAX INTEGER ACCESS read-only STATUS mandatory DESCRIPTION "The timestamp captured at the start of the session." ::= { rtcpXrVoipEntry 14 } rtcpXrVoipEndTimestamp OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "The timestamp captured at the end of the session." ::= { rtcpXrVoipEntry 15 } rtcpXrVoipNetworkLossRate OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Average rate of network packet loss (RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 16 } rtcpXrVoipAverageDiscardRate OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Average rate of discards due to jitter(RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 17 } rtcpXrVoipBurstLossDensity OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Density of loss and discarded packets during burst periods. (see RFC3611 Section 4.7)" ::= { rtcpXrVoipEntry 18 } rtcpXrVoipBurstLenMs OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Average length of bursts in milliseconds (RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 19 } rtcpXrVoipGapLossDensity OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Density of loss and discarded packets during gap periods (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 20 } Clark Expires March 2005 [Page 9] draft-clark-avt-rtcpxrmib-00.txt September 2004 rtcpXrVoipGapLenMs OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Average length of gaps in milliseconds (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 21 } rtcpXrVoipAverageOneWayDelay OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Average (symmetric) one way RTCP delay on call. A value of zero may indicate that this value has not yet been determined. (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 22 } rtcpXrVoipEndSystemDelay OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Average end system delay on call. A value of zero may indicate that this value has not yet been determined (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 23 } rtcpXrVoipNoiseLeveldBm OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Measured received silent period noise level in dBm (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 24 } rtcpXrVoipSignalLeveldBm OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Measured received signal level during talkspurts in dBm (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 25 } rtcpXrVoipLocalRERLdB OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Residual Echo Return Loss measured at this endpoint (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 26 } Clark Expires March 2005 [Page 10] draft-clark-avt-rtcpxrmib-00.txt September 2004 rtcpXrVoipConversationalRCQ OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Conversational quality R factor for this call (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 27 } rtcpXrVoipListeningMOSLQ OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Estimated listening quality MOS for this call (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 28 } rtcpXrVoipConversationalMOSCQ OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Estimated conversational quality MOS for this call (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 29 } rtcpXrVoipPlcType OBJECT-TYPE SYNTAX INTEGER { disabled(1), enhanced(2), standard(3), unspecified (4)} STATUS current DESCRIPTION "Defines type of packet loss concealment used on this call (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 30 } rtcpXrVoipJitterBufferAdaptationMode OBJECT-TYPE SYNTAX INTEGER { reserved (1), nonAdaptive (2), adaptive (3), unknown (4) } STATUS current DESCRIPTION "Defines if jitter buffer is in fixed or adaptive mode (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 31 } rtcpXrVoipJitterBufferAdaptationRate OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Estimated adaptation rate of jitter buffer (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 32 } Clark Expires March 2005 [Page 11] draft-clark-avt-rtcpxrmib-00.txt September 2004 rtcpXrVoipJitterBufferAverageDelay OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Average size of jitter buffer in mS (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 33 } rtcpXrVoipJitterBufferMaximumDelay OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Maximum delay through jitter buffer at current size in mS (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 34 } rtcpXrVoipJitterBufferSize OBJECT-TYPE SYNTAX INTEGER STATUS current DESCRIPTION "Absolute maximum size jitter buffer can reach in mS (see RFC3611 Section 4.7)." ::= { rtcpXrVoipEntry 35 } -- Notifications rtcpXrVoipNotifications OBJECT IDENTIFIER ::= { rtcpXrEvents 0 } -- -- RTCP XR Threshold Violation Notification -- -- RTCP XR issues event notification when two conditions are met: -- 1) The notification is enabled for a specified endpoint -- 2) The voice quality falls below the specified threshold -- rtcpXrVoipThresholdViolation TRAP-TYPE ENTERPRISE rtcpXrVoipNotifications VARIABLES { rtcpXrVoipAlertSeverity, rtcpXrVoipAlertType, rtcpXrVoipIndex} DESCRIPTION "Notification that voice quality has changed Sent immediately when the condition is detected." ::= 1 Clark Expires March 2005 [Page 12] draft-clark-avt-rtcpxrmib-00.txt September 2004 -- -- Definition of Alert Severity: import from Alarm MIB -- rtcpXrVoipAlertSeverity OBJECT-TYPE SYNTAX ItuPerceivedSeverity STATUS current DESCRIPTION "The severity of the alert as defined in ITU-T X.733." ::= { rtcpXrVoipEntry 36 } -- -- -- The definition of the syntax is as follows: -- -- ItuPerceivedSeverity ::= TEXTUAL-CONVENTION -- STATUS current -- DESCRIPTION -- "ITU perceived severity values" -- REFERENCE -- "ITU Recommendation M.3100, 'Generic Network -- Information Model', 1995 -- ITU Recommendation X.733, 'Information Technology -- - Open Systems Interconnection - System Management: -- Alarm Reporting Function', 1992" -- SYNTAX INTEGER -- { -- cleared (1), -- indeterminate (2), -- critical (3), -- major (4), -- minor (5), -- warning (6) -- } -- -- -- In use with these alarms, the cleared value will not be used -- due the size of alarms. rtcpXrVoipAlertType OBJECT-TYPE SYNTAX OCTET STRING ACCESS read-only STATUS current DESCRIPTION "Text description of the type of alert. Where possible, this parameter should be populated with the correct rtcpXrVoipEventsEntry" ::= { rtcpXrVoipEntry 37 } Clark Expires March 2005 [Page 13] draft-clark-avt-rtcpxrmib-00.txt September 2004 4. Security Considerations 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 [RFC3550] items such as the CNAME [RFC3550], 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 attacker with information about a system's configuration and the services that that system is providing. Some enterprises view their network and system configurations, 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. Confidentiality of RTP and RTCP data packets is defined in section 9 of the RTP specification [RFC3550]. 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 [RFC3550]." SNMPv1 by itself is not a secure environment. Even if the network itself is secure (for example by using IPSec), there is no control as to who on the secure network is allowed to access and GET/SET (read/change/create/delete) the objects in this MIB. It is recommended that the implementers consider the security features as provided by the SNMPv3 framework. Specifically, the use of the User-based Security Model RFC 2574 [RFC2574] and the View-based Access Control Model RFC 2575 [RFC2575] is recommended. It is then a customer/user responsibility to ensure that the SNMP entity giving access to an instance of this MIB, is properly configured to give access to the objects only to those principals (users) that have legitimate rights to indeed GET or SET (change/create/delete) them. 5. Acknowledgements 6. Intellectual Property The IETF takes no position regarding the validity or scope of any intellectual property or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; neither does it represent that it has made any effort to identify any such rights. Information on the IETF's procedures with respect to rights in standards-track and Clark Expires March 2005 [Page 14] draft-clark-avt-rtcpxrmib-00.txt September 2004 standards-related documentation can be found in BCP-11. Copies of claims of rights made available for publication and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementors or users of this specification can be obtained from the IETF Secretariat. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director. 7. References [RFC3550] Shulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 3550, July 2003. [RFC3611] Friedman, T., Caceres, R., Clark, A., "RTP Control Protocol Reporting Extensions (RTCP XR)," RFC 3611, [October/November] 2003 [RFC2571] Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, December 1999. [RFC1155] Rose, M. and K. McCloghrie, "Structure and Identification of Management Information for TCP/IP-based Internets", STD 16, RFC 1155, May 1990. [RFC1212] Rose, M. and K. McCloghrie, "Concise MIB Definitions", STD 16, RFC 1212, March 1991. [RFC1215] Rose, M., "A Convention for Defining Traps for use with the SNMP", RFC 1215, March 1991. [RFC2578] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Structure of Management Information Version 2 (SMIv2)", STD 58, RFC 2578, December 1999. [RFC2579] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, December 1999. [RFC2580] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, December 1999. [RFC1157] Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990. Clark Expires March 2005 [Page 15] draft-clark-avt-rtcpxrmib-00.txt September 2004 [RFC1901] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, March 1996. [RFC1906] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1906, March 1996. [RFC2572] Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, December 1999. [RFC2574] Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, December 1999. [RFC1905] Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2)", RFC 1905, March 1996. [RFC2573] Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, December 1999. [RFC2575] Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, December 1999. [RFC2570] Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network Management Framework", RFC 2570, December 1999. Clark Expires March 2005 [Page 16] draft-clark-avt-rtcpxrmib-00.txt September 2004 8. Authors' Addresses Alan Clark Telchemy Incorporated 3360 Martins Farm Road, Ste 200 Suwanee, Georgia 30024 U.S.A. Email: alan@telchemy.com Amy Pendleton Nortel Networks 2380 Performance Drive Richardson, Texas 75081 U.S.A. Email: aspen@nortelnetworks.com 9. Full Copyright Statement Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Clark Expires March 2005 [Page 17]