Status of this Memo

This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

Copyright Notice

Copyright (C) The Internet Society (2000). 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 Protocol (RTP) systems (RFC1889).

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 RTP MIB ................................ 4

3 Definitions ................................................... 5
4. Security Considerations ...................................... 26
5. Acknowledgements ............................................. 27
6. Intellectual Property ........................................ 27
7. References ................................................... 28
8. Authors' Addresses ........................................... 30
9. Full Copyright Statement ..................................... 31

1. The SNMP Management Framework

The SNMP Management Framework presently consists of five major components:

• An overall architecture, described in RFC 2571 [RFC2571].
  
  
• Mechanisms for describing and naming objects and events for the purpose of management. The first version of this Structure of Management Information (SMI) is called SMIv1 and described in STD 16, RFC 1155 [RFC1155], STD 16, RFC 1212 [RFC1212] and RFC 1215 [RFC1215]. The second version, called SMIv2, is described in STD 58, RFC 2578 [RFC2578], RFC 2579 [RFC2579] and RFC 2580 [RFC2580].
  
  
• Message protocols for transferring management information. The first version of the SNMP message protocol is called SNMPv1 and described in STD 15, RFC 1157 [RFC1157]. A second version of the SNMP message protocol, which is not an Internet standards track protocol, is called SNMPv2c and described in RFC 1901 [RFC1901] and RFC 1906 [RFC1906]. The third version of the message protocol is called SNMPv3 and described in RFC 1906 [RFC1906], RFC 2572 [RFC2572] and RFC 2574 [RFC2574].
  
  
• Protocol operations for accessing management information. The first set of protocol operations and associated PDU formats is described in STD 15, RFC 1157 [RFC1157]. A second set of protocol operations and associated PDU formats is described in RFC 1905 [RFC1905].
  
  
• A set of fundamental applications described in RFC 2573 [RFC2573] and the view-based access control mechanism described in RFC 2575 [RFC2575].

A more detailed introduction to the current SNMP Management Framework can be found in RFC 2570 [RFC2570].

Managed objects are accessed via a virtual information store, termed the Management Information Base or MIB. Objects in the MIB are defined using the mechanisms defined in the SMI.

This memo specifies a MIB module that is compliant to the SMIv2. A MIB conforming to the SMIv1 can be produced through the appropriate translations. The resulting translated MIB must be semantically equivalent, except where objects or events are omitted because no translation is possible (use of Counter64). Some machine readable

information in SMIv2 will be converted into textual descriptions in SMIv1 during the translation process. However, this loss of machine readable information is not considered to change the semantics of the MIB.

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 [RFC1889]. 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 RTP MIB is structured around "Session," "Receiver" and "Sender" conceptual abstractions.

2.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 [RFC1889].

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 [RFC1889]. The sender is also a source of RTCP Sender Report packets as specified in section 6 of [RFC1889].

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 [RFC1889].

2.2 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 [RFC1889]. Use of the RTP MIB for RTP Translators and Mixers, as defined in section 7 of [RFC1889], is for further study.

2.2.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 lifetime of an RTP session as in a "help-desk" scenario.

2.2.2 RTP Monitors of multicast RTP sessions may be third-party or may be located in the RTP 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.

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. For example, an agent for an RTP host that is sending a stream would use data from its RTP system to maintain the rtpSenderTable, but it may want to maintain a rtpRcvrTable for endpoints that are receiving its stream. To do this the RTP agent will collect RTCP data from the receivers of its stream to build the rtpRcvrTable. A host monitor system MUST set the rtpSessionMonitor object to 'true(1)', but it does not have to accept management operations that create and destroy rows in its rtpSessionTable.

2.3 The Structure of the RTP MIB

There are six tables in the RTP MIB. The rtpSessionTable contains objects that describe active sessions at the host, or monitor. The rtpSenderTable contains information about senders to the RTP session. The rtpRcvrTable contains information about receivers of RTP session data. The rtpSessionInverseTable, rtpSenderInverseTable, and rtpRcvrInverseTable contain information to efficiently find indexes into the rtpSessionTable, rtpSenderTable, and rtpRcvrTable, respectively.

The reverse lookup tables (rtpSessionInverseTable, rtpSenderInverseTable, and rtpRcvrInverseTable) are optional tables to help management applications efficiently access conceptual rows in other tables. Implementors of this MIB SHOULD implement these tables for multicast RTP sessions when table indexes (rtpSessionIndex of rtpSessionTable, rtpSenderSSRC of rtpSenderTable, and the SSRC pair in the rtpRcvrTable) are not available from other MIBs. Otherwise, the management application may be forced to perform expensive tree walks through large numbers of sessions, senders, or receivers.

For any particular RTP session, the rtpSessionMonitor object indicates whether remote senders or receivers to the RTP session are to be monitored. If rtpSessionMonitor is true(1) then senders and receivers to the session MUST be monitored with entries in the rtpSenderTable and rtpRcvrTable. RTP sessions are monitored by the RTP 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.

3. Definitions

RTP

MIB DEFINITIONS ::= BEGIN
IMPORTS Counter32, Counter64, Gauge32, mib-2, Integer32, MODULE-IDENTITY,

OBJECT-TYPE, Unsigned32 RowStatus, TAddress, TDomain, TestAndIncr,	FROM SNMPv2-SMI
TimeStamp, TruthValue	FROM SNMPv2-TC
OBJECT-GROUP, MODULE-COMPLIANCE	FROM SNMPv2-CONF
Utf8String	FROM SYSAPPL-MIB
InterfaceIndex	FROM IF-MIB;

rtpMIB MODULE-IDENTITY

LAST-UPDATED "200010020000Z" -- 2 October 2000 ORGANIZATION

"IETF AVT Working Group

Email: rem-conf@es.net"
CONTACT-INFO

"Mark Baugher

Postal:

Intel Corporation
2111 NE 25th Avenue Hillsboro, OR 97124

United States

Tel: +1 503 466 8406
Email: mbaugher@passedge.com

Bill Strahm

Postal:

Intel Corporation
2111 NE 25th Avenue Hillsboro, OR 97124 United States

Tel: +1 503 264 4632
Email: bill.strahm@intel.com

Irina Suconick

Postal:

Ennovate Networks
60 Codman Hill Rd., Boxboro, Ma 01719

Tel: +1 781-505-2155
Email: irina@ennovatenetworks.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 sender.
3. Information about RTP streams received on an RTP session by a particular receiver from a particular sender.

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."

REVISION "200010020000Z" -- 2 October 2000 DESCRIPTION "Initial version of this MIB.

Published as RFC 2959."

::= { mib-2 87 }

--
-- OBJECTS

--
rtpMIBObjects OBJECT IDENTIFIER ::= { rtpMIB 1 }
rtpConformance OBJECT IDENTIFIER ::= { rtpMIB 2 }

--

-- SESSION NEW INDEX
--

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  SMIv2'.  For an RTP
       system that supports the creation of rows, 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 agent is not acting as a monitor, only the RTP agent may create conceptual

rows in the RTP session table."
::= { rtpMIBObjects 1 }

--
-- SESSION INVERSE TABLE
--

to retrieve the row(s) in the rtpSessionTable corresponding to a given session without having to walk the entire (potentially

RtpSessionInverseEntry

:= SEQUENCE { rtpSessionInverseStartTime TimeStamp

by the RTP Agent at the start of a session when one or more senders or receivers are observed. Rows created by an RTP agent MUST be deleted when the session is over and there are no rtpRcvrEntry and no rtpSenderEntry for this session. An RTP session SHOULD be monitored to create management information on all RTP streams being sent or received when the rtpSessionMonitor has the TruthValue of 'true(1)'. An RTP monitor SHOULD permit row creation with the side effect of causing the RTP System to join the multicast session for the purposes of gathering management information (additional conceptual rows are created in the rtpRcvrTable and rtpSenderTable). Thus, rtpSessionTable rows SHOULD be created for RTP session monitoring purposes. Rows created by a management application SHOULD be deleted via SNMP operations by

management applications. Rows created by management operations are deleted by management operations by setting

by all senders and receivers of RTP session data. In a unicast RTP session this is the unicast address of the remote RTP system. '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 snmpUDPDomain, this is an IP address and even-numbered UDP Port with the RTCP being sent on the next higher odd-numbered

rtpSessionRemAddr and rtpSessionLocAddr will have different unicast addresses. See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 3. The transport service is identified by rtpSessionDomain. For snmpUDPDomain, this is an IP address and even-numbered UDP Port with the RTCP being sent on

to or received from, or in the case of an RTP Monitor the interface that RTCP packets will be received on. Cannot be

(rtpSessionStartTime). A sender 'joins' an RTP session by sending to it. 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. Every time a new RTP sender is detected either using RTP or RTCP, this counter

session by sending RTCP Receiver Reports to the session. 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

"Boolean, Set to 'true(1)' if remote senders or receivers in

addition to the local RTP System are to be monitored using RTCP. RTP Monitors MUST initialize to 'true(1)' and RTP Hosts SHOULD initialize this 'false(2)'. Note that because 'host monitor' systems are receiving RTCP from their remote participants they

initialized before becoming 'active'. A conceptual row that is in the 'notReady' or 'notInService'

state MAY be removed after 5 ::= { rtpSessionEntry 11 }

minutes."

--
-- SENDER INVERSE TABLE
--

sorted by rtpSessionIndex. Given the rtpSessionDomain and rtpSenderAddr, a set of rtpSessionIndex and rtpSenderSSRC values can be returned from a tree walk. When rtpSessionIndex is specified in the SNMP Get-Next operations, one or more

INDEX { rtpSessionDomain, rtpSenderAddr, rtpSessionIndex,

            rtpSenderSSRC }
    ::= { rtpSenderInverseTable 1 }

RtpSenderInverseEntry

:= SEQUENCE { rtpSenderInverseStartTime TimeStamp

--
-- SENDERS TABLE
--

entry in this table for each sending stream being received by this host. RTP monitors MUST create an entry for each observed sender to a multicast RTP Session as a side-effect when a conceptual row in the rtpSessionTable is made 'active' by a

identified to the the SNMP entity by rtpSessionIndex. Rows are removed by the RTP agent when a BYE is received from the sender or when the sender times out (see RFC

1889, Sec. 6.2.1) or when the rtpSessionEntry is deleted."
INDEX { rtpSessionIndex, rtpSenderSSRC }
::= { rtpSenderTable 1 }

--
-- RECEIVER INVERSE TABLE
--

rather than by rtpSessionIndex. Given rtpSessionDomain and rtpRcvrAddr, a set of rtpSessionIndex, rtpRcvrSRCSSRC, and rtpRcvrSSRC values can be returned from a tree walk. When rtpSessionIndex is specified in SNMP Get-Next operations, one or

RtpRcvrInverseEntry

:= SEQUENCE {
rtpRcvrInverseStartTime TimeStamp

        }

rtpRcvrInverseStartTime OBJECT-TYPE
    SYNTAX          TimeStamp

MAX-ACCESS	read-only
STATUS DESCRIPTION	current
"The value of created."	SysUpTime at the time that this row was
::= { rtpRcvrInverseEntry 1 }

--
-- RECEIVERS TABLE
--

pair. RTP hosts that send RTP session packets MAY create an entry in this table for each receiver to their stream using RTCP feedback from the RTP group. RTP monitors create an entry for each observed RTP session receiver as a side effect when a conceptual row in the rtpSessionTable

'RTP: A Transport Protocol for Real-Time Applications' sec.6). The session is identified to the the RTP Agent entity by rtpSessionIndex. Rows are removed by the RTP agent when a BYE is received from the sender or when the sender times out (see RFC 1889, Sec. 6.2.1) or when the rtpSessionEntry is

"The unicast transport address on which the receiver is

Applications.' This algorithm can produce meaningful results when the RTP agent has the same clock as the stream sender (when the RTP monitor is also the sending host for the particular receiver). Otherwise, the entity should return

--
-- MODULE GROUPS

--
--
-- There are two types of RTP Systems, RTP hosts and RTP Monitors.
-- Thus there are three kinds of objects: 1) Objects common to both
-- kinds of systems, 2) Objects unique to RTP Hosts and 3) Objects

-- unique to RTP Monitors. There is a fourth group, 4) Objects that -- SHOULD be implemented by Multicast hosts and RTP Monitors

DESCRIPTION

--
-- Compliance

--
rtpCompliances OBJECT IDENTIFIER ::= { rtpConformance 2 }

rtpHostCompliance MODULE-COMPLIANCE
STATUS current

DESCRIPTION

"Host implementations MUST comply."
MODULE RTP-MIB
MANDATORY-GROUPS {
rtpSystemGroup,
rtpHostGroup
}
GROUP rtpMonitorGroup
DESCRIPTION
"Host systems my optionally support row creation and deletion.
This would allow an RTP Host system to act as an RTP Monitor."
GROUP rtpInverseGroup
DESCRIPTION
"Multicast RTP Systems SHOULD implement the optional
tables."
OBJECT rtpSessionNewIndex

MIN-ACCESS not-accessible DESCRIPTION
"RTP system implementations support of row creation and deletion is OPTIONAL so implementation of this object is OPTIONAL." OBJECT rtpSessionDomain
MIN-ACCESS read-only
DESCRIPTION
"RTP system implementation support of row creation and deletion is OPTIONAL. When it is not supported so write access is OPTIONAL."
OBJECT rtpSessionRemAddr
MIN-ACCESS read-only
DESCRIPTION
"Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionIfIndex
MIN-ACCESS read-only
DESCRIPTION
"Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionRowStatus
MIN-ACCESS not-accessible DESCRIPTION
"Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionInverseStartTime MIN-ACCESS not-accessible DESCRIPTION
"Multicast RTP Systems SHOULD implement the optional tables."

OBJECT rtpSenderInverseStartTime MIN-ACCESS not-accessible DESCRIPTION
"Multicast RTP Systems SHOULD implement the optional tables."
OBJECT rtpRcvrInverseStartTime MIN-ACCESS not-accessible DESCRIPTION
"Multicast RTP Systems SHOULD implement the optional

MIN-ACCESS not-accessible DESCRIPTION
"RTP monitor sourcing of RTP or RTCP data packets is OPTIONAL and implementation of this object is OPTIONAL."
OBJECT rtpRcvrPT
MIN-ACCESS not-accessible DESCRIPTION
"RTP monitor systems 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" OBJECT rtpSenderPT
MIN-ACCESS not-accessible DESCRIPTION
"RTP monitor systems 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." OBJECT rtpRcvrOctets
MIN-ACCESS not-accessible DESCRIPTION
"RTP monitor systems may receive only the RTCP messages and not the RTP messages that contain the octet count of the RTP message. Thus implementation of this object is OPTIONAL"
OBJECT rtpRcvrPackets
MIN-ACCESS not-accessible DESCRIPTION
"RTP monitor systems may receive only the RTCP messages and not the RTP messages that contain the octet count of the RTP message. Thus implementation of this object is OPTIONAL." OBJECT rtpSessionIfIndex
MIN-ACCESS read-only
DESCRIPTION
"Row creation and deletion is OPTIONAL so read-create access to this object is OPTIONAL." OBJECT rtpSessionInverseStartTime MIN-ACCESS not-accessible DESCRIPTION
"Multicast RTP Systems SHOULD implement the optional tables."
OBJECT rtpSenderInverseStartTime MIN-ACCESS not-accessible DESCRIPTION
"Multicast RTP Systems SHOULD implement the optional tables."
OBJECT rtpRcvrInverseStartTime MIN-ACCESS not-accessible DESCRIPTION
"Multicast RTP Systems SHOULD implement the optional

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. However, there are a number of management objects defined in this MIB that have a MAX-ACCESS clause of read-write and/or read-create. Such objects may be considered sensitive or vulnerable in some network environments. The support for SET operations in a non-secure environment without proper protection can have a negative effect on network operations.

None of the read-only objects in this MIB reports a password, though some SDES [RFC1889] items such as the CNAME [RFC1889], 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. 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, and 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 [RFC1889]. 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 [RFC1889]."

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

The authors wish to thank Bert Wijnen and the participants from the ITU SG-16 management effort for their helpful comments. Alan Batie and Bill Lewis from Intel also contributed greatly to the RTP MIB through their review of various drafts of the MIB and their work on the implementation of an SNMP RTP Monitor. Stan Naudus from 3Com and John Du from Intel contributed to the original RTP MIB design and co-authored the original RTP MIB draft documents; much of their work remains in the current RTP MIB. Bill Fenner provided solid feedback that improved the quality of the final document.

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 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

[RFC1889]

Shulzrinne, H., Casner, S., Frederick, R. and V. Jacobson, "RTP: A Transport Protocol for real-time applications," RFC 1889, January 1996.

[RFC2571]

Harrington, D., Presuhn, R. and B. Wijnen, "An Architecture for Describing SNMP Management Frameworks", RFC 2571, April 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, April 1999.

[RFC2579]

McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD 58, RFC 2579, April 1999.

[RFC2580]

McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose, M. and S. Waldbusser, "Conformance Statements for SMIv2", STD 58, RFC 2580, April 1999.

[RFC1157]

Case, J., Fedor, M., Schoffstall, M. and J. Davin, "Simple Network Management Protocol", STD 15, RFC 1157, May 1990.

[RFC1901]

Case, J., McCloghrie, K., Rose, M. and S. Waldbusser, "Introduction to Community-based SNMPv2", RFC 1901, January 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, January 1996.

[RFC2572]

Case, J., Harrington D., Presuhn R. and B. Wijnen, "Message Processing and Dispatching for the Simple Network Management Protocol (SNMP)", RFC 2572, April 1999.

[RFC2574]

Blumenthal, U. and B. Wijnen, "User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3)", RFC 2574, April 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, January 1996.

[RFC2573]

Levi, D., Meyer, P. and B. Stewart, "SNMPv3 Applications", RFC 2573, April 1999.

[RFC2575]

Wijnen, B., Presuhn, R. and K. McCloghrie, "View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP)", RFC 2575, April 1999.

[RFC2570]

Case, J., Mundy, R., Partain, D. and B. Stewart, "Introduction to Version 3 of the Internet-standard Network

Management Framework", RFC 2570, April 1999.

8. Authors' Addresses

Mark Baugher
Intel Corporation
2111 N.E.25th Avenue
Hillsboro, Oregon 97124
U.S.A.

EMail: mbaugher@passedge.com

Bill Strahm
Intel Corporation
2111 N.E.25th Avenue
Hillsboro, Oregon 97124
U.S.A.

EMail: Bill.Strahm@intel.com

Irina Suconick
Ennovate Networks
60 Codman Hill Rd.,
Boxboro, Ma 01719
U.S.A.

EMail: irina@ennovatenetworks.com

9. Full Copyright Statement

Copyright (C) The Internet Society (2000). All Rights Reserved.

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.

Acknowledgement

Funding for the RFC Editor function is currently provided by the Internet Society.

Baugher, et al. Standards Track [Page 31]