One document matched: draft-ietf-opsawg-survey-management-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1157 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1157.xml">
<!ENTITY rfc1901 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1901.xml">
<!ENTITY rfc2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY rfc2438 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2438.xml">
<!ENTITY rfc2613 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2613.xml">
<!ENTITY rfc2819 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2819.xml">
<!ENTITY rfc2863 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2863.xml">
<!ENTITY rfc2865 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2865.xml">
<!ENTITY rfc3084 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3084.xml">
<!ENTITY rfc3159 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3159.xml">
<!ENTITY rfc3165 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3165.xml">
<!ENTITY rfc3317 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3317.xml">
<!ENTITY rfc3410 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3410.xml">
<!ENTITY rfc3411 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3411.xml">
<!ENTITY rfc3413 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3413.xml">
<!ENTITY rfc3418 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3418.xml">
<!ENTITY rfc3444 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3444.xml">
<!ENTITY rfc3460 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3460.xml">
<!ENTITY rfc3535 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3535.xml">
<!ENTITY rfc3585 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3585.xml">
<!ENTITY rfc3588 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3588.xml">
<!ENTITY rfc3644 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3644.xml">
<!ENTITY rfc3670 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3670.xml">
<!ENTITY rfc3805 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3805.xml">
<!ENTITY rfc4011 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4011.xml">
<!ENTITY rfc4133 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4133.xml">
<!ENTITY rfc4502 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4502.xml">
<!ENTITY rfc4668 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4668.xml">
<!ENTITY rfc4669 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4669.xml">
<!ENTITY rfc4710 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4710.xml">
<!ENTITY rfc4741 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4741.xml">
<!ENTITY rfc4825 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml">
<!ENTITY rfc4930 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4930.xml">
<!ENTITY rfc5101 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5101.xml">
<!ENTITY I-D.ietf-syslog-protocol SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-syslog-protocol.xml">
<!ENTITY I-D.ietf-sipping-rtcp-summary SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-sipping-rtcp-summary.xml">
<!ENTITY I-D.ietf-opsawg-operations-and-management SYSTEM "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-opsawg-operations-and-management.xml">
]>
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<?rfc strict="yes"?>
<?rfc rfcedstyle="yes"?>
<rfc category="info" docName="draft-ietf-opsawg-survey-management-00"
ipr="pre5378Trust200902">
<!--
$Id: draft-ietf-opsawg-survey-management.xml,v 1.1 2008/03/20 17:19:45 H73653 Exp $
-->
<front>
<title abbrev="Survey of IETF Network Management">Survey of IETF Network
Management Standards </title>
<author fullname="David Harrington" initials="D" surname="Harrington">
<organization>HuaweiSymantec</organization>
<address>
<postal>
<street>1700 Alma Dr, Suite 100</street>
<city>Plano</city>
<region>TX</region>
<code>75075</code>
<country>USA</country>
</postal>
<phone>+1 603 436 8634</phone>
<facsimile></facsimile>
<email>dharrington@huawei.com</email>
<uri></uri>
</address>
</author>
<date year="2009" />
<area>IETF Operations and Management Area</area>
<keyword>management</keyword>
<keyword>operations</keyword>
<abstract>
<t>This document provides a survey of existing IETF standards-track network management
protocols and data models. The purpose of this document is to help protocol designers,
implementers, and users to select appropriate standard management
protocols and data models to address relevant management needs.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document provides a survey of existing IETF standards-track network management
protocols and data models. The purpose of this document is to help protocol designers,
implementers, and users to select appropriate standard management
protocols and data models to address relevant management needs.
</t>
<t><xref target="I-D.ietf-opsawg-operations-and-management">Guidelines for Considering Operations and Management of New Protocols and Extensions</xref> recommends working groups consider operations and management needs, and then select appropriate management
protocols and data models. This document is designed to ease this process by surveying the IETF standards-track network management protocols and management data models available at the time of this document's publication.</t>
<t>Section 2 discusses IETF standards-track management protocols and
their uses. Section 3 discusses Draft and Full Standard data models,
such as MIB modules, that have been designed to address specific sets of
issues.Section 4 describes Proposed Standard management data models that have been
designed to address specific sets of issues.</t>
<section title="Terminology">
<t>This document deliberately does not use the (capitalized) key words
described in <xref target="RFC2119">RFC 2119</xref>. RFC 2119 states
the keywords must only be used where it is actually required for
interoperation or to limit behavior which has potential for causing
harm (e.g., limiting retransmissions). For example, they must not be
used to try to impose a particular method on implementers where the
method is not required for interoperability. This document is a survey
of existing IETF network management technologies. This document does
not describe requirements, so the key words from RFC2119 have no place
here.</t>
<t><list>
<t>CLI: Command Line Interface</t>
<t>Data model: A mapping of the contents of an information model into a form
that is specific to a particular type of data store or repository.</t>
<t>Information model: An abstraction and representation of the entities in a managed
environment, their properties, attributes and operations, and
the way that they relate to each other. It is independent of
any specific repository, software usage, protocol, or platform.</t>
</list></t>
<t><list style="symbols">
<t>[DISCUSS] markers indicate a lack of consensus on what should
be written.</t>
<t>[TODO] markers indicate the editor has a reasonable
understanding of what needs to be (re-)written. Contributions of
text would be welcome.</t>
<t>Note to RFC Editor - All [DISCUSS] or [TODO] marks should be
resolved before RFC publication. If any still exist, including in
the Terminology section, then please return the document to the
editor for resolution.</t>
</list></t>
</section>
</section>
<section title="Protocols">
<t>This Section reviews which protocols the IETF has to offer for
management and discusses for which applications they were designed and/or already
successfully deployed. These are protocols that have reached Proposed
Standard status or higher within the IETF. [DISCUSS: Juergen: I like
to perhaps see even stronger guidelines]</t>
<t> The <xref target="RFC3535">Overview of the 2002 IAB Network Management Workshop
</xref> documented strengths and weaknesses of
some IETF management protocols. In choosing existing protocol solutions to meet the management
requirements, it is recommended that these strengths and weaknesses be
considered. Some of the recommendations from the 2002 IAB
workshop have become outdated, some have been standardized, and some are
being worked on in the IETF.</t>
<t> Some Area Directors have formed directorates composed of
experienced members of the IETF and the technical community. The details of the role for each group
differ from area to area, but the primary intent is that these groups assist the Area Director(s) with the review of specifications, and serve as technical advisors when needed. At the time of this writing, the OPS Area has directorates focused on Address Management, Operations, DNS, and MIB modules. Other areas have directorates that might apply as well. Protocol designers should consider asking for help from the IETF directorates knowledgeable in available existing solutions. </t>
<section title="SNMP">
<t>SNMP is widely used for monitoring fault and performance data. Some
operators use SNMP for configuration in various
environments/technologies while others find SNMP an inappropriate
choice for configuration in their environments. </t>
<t><xref target="RFC1157">SNMPv1</xref> is a Full
Standard that the IETF has declared Historic and it is NOT RECOMMENDED due to its lack of security features.
<xref target="RFC1901">SNMPv2c</xref> is an Experimental specification (not a standard of any kind) that the IETF has
declared Historic and it is NOT RECOMMENDED due to its lack of security features.
SNMPv3 is a Full Standard that is RECOMMENDED due to its security features, including support for
authentication, encryption, timeliness and integrity checking, and fine-grained data access controls. An overview
of the SNMPv3 document set is in <xref target="RFC3410"></xref>.</t>
<t>SNMP utilizes the Management Information Base, a virtual information store of
modules of managed objects. MIB module support is uneven across
vendors, and even within devices. The lack of standard MIB module
support for all functionality in a device forces operators to use
other protocols such as a command line interface (CLI) to do configuration of some aspects of
their managed devices. Many operators have found it easier to use one protocol for all
configuration than to split the task across multiple protocols.</t>
<t>SNMP is good at determining the operational state of specific
functionality, but not necessarily for the complete operational state
of a managed device.</t>
<t>SNMP is good for statistics gathering for specific functionality.
The wide-spread use of counters in standard MIB modules permits the
interoperable comparison of statistics across devices from different
vendors. Counters have been especially useful in monitoring bytes and
packets going in and out over various protocol interfaces.
SNMP is often used to poll a device for sysUpTime, which
serves to report the time since the last reinitialization of the device,
to check for operational liveness, and to detect discontinuities in
some counters.</t>
<t>SNMP traps and informs can alert an operator or an application when
some aspect of a protocol fails or encounters an error condition,
and the contents of a notification can be used to guide subsequent
SNMP polling to gather additional information about an event.</t>
<t>Standards exist to use SNMP over multiple network protocols,
including UDP, Ethernet, Appletalk, OSI, and others..</t>
</section>
<section title="SYSLOG">
<t>The SYSLOG protocol <xref target="I-D.ietf-syslog-protocol"></xref>
allows a machine to send system log messages across networks
to event message collectors. The protocol is simply designed to
transport these event messages. No acknowledgement of the receipt is
made. One of the fundamental tenets of the SYSLOG protocol and process
is its simplicity. No stringent coordination is required between the
transmitters and the receivers. Indeed, the transmission of SYSLOG
messages may be started on a device without a receiver being
configured, or even actually physically present. Conversely, many
devices will most likely be able to receive messages without explicit
configuration or definitions. This simplicity has greatly aided the
acceptance and deployment of SYSLOG.</t>
<t>Since each process, application and operating system was written
somewhat independently, there has been little uniformity to the
message format or content of SYSLOG messages.</t>
<t>The IETF has developed a new Proposed Standard version of the
protocol that allows the use of any number of transport protocols
including reliable transports and secure transports. The IETF has also standardized
the application of message security for SYSLOG messages using TLS, and has
defined a mechanism to digitally sign log data to ensure its integrity as
log data is moved across the network and/or copied to different data stores.</t>
<t>The IETF has standardized a new message header format, including timestamp,
hostname, application, and message ID, to improve filtering,
interoperability and correlation between compliant
implementations.</t>
<t>SYSLOG message content has traditionally been unstructured natural
language text. This content is human-friendly, but difficult for
applications to parse and correlate across vendors, or correlate with
other event reporting such as SNMP traps. The IETF syslog
protocol includes structured data elements to aid application-parsing.
The structured data element design allows vendors to define their own
structured data elements to supplement standardized elements.</t>
<t>The IETF has standardized MIB Textual-Conventions for facility and severity
labels and codes to encourage consistency between syslog and MIB representations
of these event properties.</t>
<t>IETF working groups are encouraged to standardize structured data elements,
extensible human-friendly text, and consistent facility/severity values for SYSLOG to
report events specific to their protocol.</t>
</section>
<section title="IPFIX">
<t>There are several applications such as usage-based accounting,
traffic profiling, traffic engineering, intrusion detection, and QoS
monitoring, that require flow-based traffic measurements.</t>
<t>IPFIX <xref target="RFC5101"></xref> is a Proposed
Standard approach for transmitting IP traffic flow information over
the network from an exporting process to an information collecting
process.</t>
<t>IPFIX defines a common representation of flow data and a standard
means of communicating the data over a number of transport
protocols.</t>
</section>
<section title="PSAMP">
<t>Several applications require sampling packets from specific data
flows, or across multiple data flows, and reporting information about
the packets. Measurement-based network management is a prime example.
The PSAMP standard includes support for packet sampling in IPv4, IPv6,
and MPLS-based networks.</t>
<t>PSAMP standardizes sampling, selection, metering, and reporting
strategies for different purposes.</t>
<t>To simplify the solution, the IPFIX protocol is used for exporting
the reports to collector applications.</t>
<t>[TODO: this is in IESG review to become a PS. update as needed]</t>
</section>
<section title="NETCONF">
<t>The NETCONF protocol <xref target="RFC4741"></xref> is a Proposed
Standard that provides mechanisms to install, manipulate, and delete the
configuration of network devices. It uses an Extensible Markup
Language (XML)-based data encoding for the configuration data as well
as the protocol messages. The NETCONF protocol operations are
realized on top of a simple Remote Procedure Call (RPC) layer.
</t>
<t>A key aspect of NETCONF is that it allows the functionality of the
management protocol to closely mirror the native command line
interface of the device. This reduces implementation costs and allows
timely access to new features. In addition, applications can access
both the syntactic and semantic content of the device's native user
interface.</t>
<t>The contents of both the request and the response can be fully
described in XML DTDs or XML schemas, or both, allowing both parties
to recognize the syntax constraints imposed on the exchange. As of
this writing, no standard has been developed for data content
specification.</t>
</section>
<section title="COPS-PR">
<t>COPS-PR and the Structure of Policy Provisioning Information (SPPI)
have been approved as Proposed Standards. COPS-PR <xref
target="RFC3084"></xref> uses the Common Open Policy Service (COPS)
protocol for support of policy provisioning. The COPS-PR specification
is independent of the type of policy being provisioned (QoS, Security,
etc.) but focuses on the mechanisms and conventions used to
communicate provisioned information between policy-decision-points
(PDPs) and policy enforcement points (PEPs). COPS-PR does not make any
assumptions about the policy data model being communicated, but
describes the message formats and objects that carry the modeled
policy data. Policy data is modeled using Policy Information Base
modules (PIB modules).</t>
<t>COPS-PR has not had wide deployment, and operators have stated that
its use of binary encoding (BER) for management data makes it
difficult to develop automated scripts for simple configuration
management tasks in most text-based scripting languages. In an IAB
Workshop on Network Management <xref target="RFC3535"></xref>, the
consensus of operators and protocol developers indicated a lack of
interest in PIB modules for use with COPS-PR.</t>
<t>As a result, the IESG has not approved any policy models (PIB
modules) as an IETF standard, and the use of COPS-PR is not
recommended.</t>
</section>
<section title="RADIUS">
<t>RADIUS <xref target="RFC2865"></xref>, the remote Authentication
Dial In User Service, is a Draft Standard that describes a protocol
for carrying authentication, authorization, and configuration
information between a Network Access Server which desires to
authenticate its links and a shared Authentication Server.</t>
<t>This protocol is widely implemented and used. RADIUS is widely used
in environments, such as enterprise networks, where a single
administrative authority manages the network, and protects the privacy
of user information.</t>
</section>
<section title="Diameter">
<t>DIAMETER <xref target="RFC3588"></xref> is a Proposed Standard that
provides an Authentication, Authorization and Accounting (AAA)
framework for applications such as network access or IP mobility.
DIAMETER is also intended to work in local Authentication,
Authorization, Accounting situations and in roaming situations.</t>
<t>Diameter is designed to resolve a number of known problems with
RADIUS. Diameter supports server failover, transmission-level
security, reliable transport over TCP, agents for proxy and redirect
and relay, server-initiated messages, auditability, capability
negotiation, peer discovery and configuration, and roaming support.
Diameter also provides a larger attribute space than RADIUS.</t>
<t>Diameter features make it especially appropriate for environments
where the providers of services are in different administrative
domains than the maintainer (protector) of confidential user
information.</t>
</section>
<section title="EPP">
<t>The Extensible Provision Protocol <xref target="RFC4930"></xref> is
a Draft Standard that describes an application layer client-server
protocol for the provisioning and management of objects stored in a
shared central repository. EPP permits multiple service providers to
perform object provisioning operations using a shared central object
repository, and addresses the requirements for a generic registry
registrar protocol.</t>
</section>
<section title="VCCV">
<t>VCCV is a Proposed Standard protocol that provides a control
channel associated with a Pseudowire. It is used for operations and
management functions such as connectivity verification over the
control channel. VCCV applies to all supported access circuit and
transport types currently defined for Pseudowires.</t>
</section>
<section title="ACAP">
<t> The Application Configuration Access Protocol (ACAP) is designed to
support remote storage and access of program option, configuration
and preference information. The data store model is designed to
allow a client relatively simple access to interesting data, to allow
new information to be easily added without server re-configuration,
and to promote the use of both standardized data and custom or
proprietary data. Key features include "inheritance" which can be
used to manage default values for configuration settings and access
control lists which allow interesting personal information to be
shared and group information to be restricted.</t>
<t>ACAP's primary purpose is to allow users access to their
configuration data from multiple network-connected computers. Users
can then sit down in front of any network-connected computer, run any
ACAP-enabled application and have access to their own configuration
data. Because it is hoped that many applications will become ACAP-
enabled, client simplicity was preferred to server or protocol
simplicity whenever reasonable.</t>
</section>
<section title="XCAP">
<t>XCAP <xref target="RFC4825"></xref> is a Proposed Standard protocol
that allows a client to read, write, and modify application
configuration data stored in XML format on a server.</t>
<t>XCAP is a protocol that can be used to
manipulate per-user data. XCAP is a set
of conventions for mapping XML documents and document components into
HTTP URIs, rules for how the modification of one resource affects
another, data validation constraints, and authorization policies
associated with access to those resources. Because of this
structure, normal HTTP primitives can be used to manipulate the data.
XCAP is
meant to support the configuration needs for a multiplicity of
applications, rather than just a single one.</t>
<t> XCAP was not designed as a general purpose XML search protocol, XML
database update protocol, nor a general purpose, XML-based
configuration protocol for network elements.</t>
</section>
<!--
<section title="Other Protocols">
<t>A command line interface (CLI) might be used to provide initial
configuration of the target functionality. Command line interfaces are
usually proprietary, but working groups could suggest specific
commands and command parameters that would be useful in configuring
the new protocol, so implementers could have similarities in their
proprietary CLI implementations.</t>
<t>[DISCUSS: Routing and control plane people may prefer NETCONF since
it is close to CLIs which seem to rule in this space. ]</t>
<t>[DISCUSS] Other PS-level NM protocols? SIP NM?</t>
</section>
-->
</section>
<section title="Draft and Standard Level Data Models">
<t>[DISCUSS: JS: The weakest part of the document is IMHO section 6. It
is not clear to me what David's intention were here; sometimes he gives
general advise while at other places he kind of surveys data models and
such things. I am also not sure all the stuff listed there is actually
useful to list; for example, has anybody ever deployed the technology
which came out of the snmpconf working group? So we need to be more
selective and probably also organize our pointers based on the protocol
layer people are working on (transmission specific MIB modules are kind
of widely used, people managing application servers usually do not use
much of SNMP; the IETF application management MIBs we have produced have
not gained large deployments as far as I can tell). ]</t>
<t>[DISCUSS: David: Some MIB modules may not be deployed because few
people know about them and have never tried them. Others may have been
tried and been found to be inadequate. We have very little feedback
concerning which ones are useful and which are widely deployed, which
have been found useful by operators, and which have been found to be
junk. ;-) I hesitate to make recommendations that people should avoid a
MIB module unless there is real evidence that it is unsuitable for its designed
task. Even then, I hesitate because maybe the MIB would be found useful
in a different environment that is just emerging. Maybe the IETF needs to
perform a de-crufting operation for data models, similar to that done
for protocols a few years ago. But I think that would require feedback
from LOTS of operators and application developers - and these tend to be
scarce in the IETF. ]</t>
<t>The purpose of this section is to inform protocol designers about
solutions for which information or data models have been standardized in the
IETF, so they can reuse existing solutions or apply the information model to new solutions.</t>
<t>This section discusses management data models that have reached at
least Draft Standard status in the IETF. IETF specifications must have
"multiple, independent, and interoperable implementations" before they
can be advanced to Draft Standard status. Management data
models have a slightly different interpretation for interoperability. This is
discussed in detail in <xref target="RFC2438">BCP 27: Advancement of MIB specifications on the IETF Standards Track</xref> discusses special considerations about the advancement process for management data models. Most IETF management data models never advance beyond Proposed Standard. T his section will focus on those
data models that have reached at least Draft status. This is supplemented by a chapter that lists
additional data models that are Proposed Standard status.</t>
<t>[TODO] discuss specific MIB modules, SDEs, XML schemas that are
designed to solve generic problems. This might cover things like Textual
Conventions, RFC3415 Target tables, SYSLOG SDEs defined in -protocol-,
SYSLOG -sign-, IPFIX IEs, etc.</t>
<section title="Fault Management">
<t></t>
<t>RFC 3418 <xref target="RFC3418"></xref>, part of STD 62 SNMP,
contains objects in the system group that are often polled to
determine if a device is still operating, and sysUpTime can be used to
detect if a system has rebooted, and counters have been
reinitialized.</t>
<t>RFC3413 <xref target="RFC3413"></xref>, part of STD 62 SNMP,
includes objects designed for managing notifications, including tables
for addressing, retry parameters, security, lists of targets for
notifications, and user customization filters.</t>
<t>An RMON monitor <xref target="RFC2819"></xref> can be configured to
recognize conditions, most notably error conditions, and continuously
to check for them. When one of these conditions occurs, the event may
be logged, and management stations may be notified in a number of
ways. See further discussion of RMON under Performance Management.</t>
</section>
<section title="Configuration Management">
<t>It is expected that standard XML-based data models will be
developed for use with NETCONF, and working groups might identify
specific NETCONF data models that would be applicable to the new
protocol. At the time of this writing, no such standard data models
exist.</t>
<t>For monitoring network configuration, such as physical and logical
network topologies, existing MIB modules already exist that provide
some of the desired capabilities. New MIB modules might be developed
for the target functionality to allow operators to monitor and modify
the operational parameters, such as timer granularity, event reporting
thresholds, target addresses, and so on.</t>
<t>RFC 3418 <xref target="RFC3418"></xref>, part of STD 62 SNMPv3,
contains objects in the system group that are often polled to
determine if a device is still operating, and sysUpTime can be used to
detect if a system has rebooted and caused potential discontinuity in
counters. Other objects in the system MIB are useful for identifying
the type of device, the location of the device, the person responsible
for the device, etc.</t>
<t>RFC3413 <xref target="RFC3413"></xref>, part of STD 62 SNMPv3,
includes objects designed for configuring notification destinations,
and for configuring proxy-forwarding SNMP agents, which can be used to
forward messages through firewalls and NAT devices.</t>
<t>RFC2863 <xref target="RFC2863"></xref>, the
Interfaces MIB is used for managing Network Interfaces. This includes
the 'interfaces' group of MIB-II and discusses the experience gained
from the definition of numerous media-specific MIB modules for use in
conjunction with the 'interfaces' group for managing various
sub-layers beneath the internetwork-layer.</t>
</section>
<section title="Accounting Management">
<t>TODO: RADIUS Accounting MIBs are PS; are there any DS data models
for accounting? ]</t>
</section>
<section title="Performance Management">
<t>MIB modules typically contain counters to determine the frequency
and rate of an occurrence.</t>
<t>RFC2819, STD 59 RMON, defines objects for managing remote network
monitoring devices. An organization may employ many remote management
probes, one per network segment, to manage its internet. These devices
may be used for a network management service provider to access a
client network, often geographically remote. Most of the objects in
the RMON MIB module are suitable for the management of any type of
network, and there are some which are specific to managing Ethernet
networks.</t>
<t>RMON allows a probe to be configured to perform diagnostics and to
collect statistics continuously, even when communication with the
management station may not be possible or efficient. The alarm group
periodically takes statistical samples from variables in the probe and
compares them to previously configured thresholds. If the monitored
variable crosses a threshold, an event is generated.</t>
<t>The RMON host group discovers hosts on the network by keeping a
list of source and destination MAC Addresses seen in good packets
promiscuously received from the network, and contains statistics
associated with each host. The hostTopN group is used to prepare
reports that describe the hosts that top a list ordered by one of
their statistics. The available statistics are samples of one of their
base statistics over an interval specified by the management station.
Thus, these statistics are rate based. The management station also
selects how many such hosts are reported.</t>
<t>The RMON matrix group stores statistics for conversations between
sets of two addresses. The filter group allows packets to be matched
by a filter equation. These matched packets form a data stream that
may be captured or may generate events. The Packet Capture group
allows packets to be captured after they flow through a channel. The
event group controls the generation and notification of events from
this device.</t>
<t>The RMON-2 MIB <xref target="RFC4502"></xref> extends RMON by
providing RMON analysis up to the application layer. The SMON MIB
<xref target="RFC2613"></xref> extends RMON by providing RMON analysis
for switched networks.</t>
</section>
<section title="Security Management">
<t>Working groups should consider existing data models that would be
relevant to monitoring and managing the security of the new
protocol.</t>
<t>The IETF has no standard data models for managing security
protocols such as TLS and SSH.</t>
</section>
</section>
<section title="Proposed Standard Data Models">
<!-- ******************************************************* -->
<section title="Fault Management">
<t>The IETF SYSLOG protocol <xref
target="I-D.ietf-syslog-protocol"></xref> is a Proposed Standard that
includes a mechanism for defining structured data elements (SDEs). The
SYSLOG protocol document defines an initial set of SDEs that relate to
content time quality, content origin, and meta-information about the
message, such as language. Proprietary SDEs can be used to supplement
the IETF-defined SDEs.</t>
<t>DISMAN-EVENT-MIB in RFC 2981 and DISMAN-EXPRESSION-MIB in RFC 2982
provide a superset of the capabilities of the RMON alarm and event
groups. These modules provide mechanisms for thresholding and reporting
anomalous events to management applications.</t>
<t>The ALARM MIB in RFC 3877 and the Alarm Reporting Control MIB in RFC
3878 specify mechanisms for expressing state transition models for
persistent problem states. There is also a mechanism specified to
correlate a notification with subsequent state transition notifications
about the same entity/object.</t>
<t>Other MIB modules that may be applied to Fault Management include:
<list>
<t>NOTIFICATION-LOG-MIB in RFC 3014</t>
<t>ENTITY-STATE-MIB in RFC 4268</t>
<t>ENTITY-SENSOR-MIB in RFC 4268</t>
</list></t>
</section>
<!-- ******************************************************* -->
<section title="Configuration Management">
<t>The Entity MIB <xref target="RFC4133"></xref> is used for managing multiple logical and physical entities managed
by a single SNMP agent. This module provides a useful mechanism for
identifying the entities comprising a system. There are also event
notifications defined for configuration changes that may be useful to
management applications.</t>
<t>RFC3159 <xref target="RFC3159"></xref> discusses the Structure of
Policy Provisioning Information, an extension to the SMI standard for
purposes of policy-based provisioning, for use with the COPS-PR protocol
defined in RFC3084 <xref target="RFC3084"></xref>. RFC3317 <xref
target="RFC3317"></xref> defines a DiffServ QoS PIB. At the time of this
writing, there are no standards-track PIBs. During the IAB Workshop on
Network Management, the workshop had rough consensus from the protocol
developers that the IETF should not spend resources on SPPI PIB
definitions, and the operators had rough consensus that they do not care
about SPPI PIBs.</t>
<t>The Policy Based Management MIB <xref target="RFC4011"></xref> defines
objects that enable policy-based monitoring and management of SNMP
infrastructures, a scripting language, and a script execution
environment.</t>
<t>RFC3165 <xref target="RFC3165"></xref> supports
the use of user-written scripts to delegate management
functionality.</t>
<t>Proposed Standard RFC4011 <xref target="RFC4011"></xref> defines
objects that enable policy-based monitoring using SNMP, using a
scripting language, and a script execution environment.</t>
<t>Few vendors have implemented MIB modules that support
scripting. Some vendors consider running user-developed scripts within
the managed device as a violation of support agreements.</t>
<t>[TODO] Informational RFC3317 defines a DiffServ QoS PIB,
and Informational RFC3571 defines policy classes for monitoring and
reporting policy usage feedback, as well as policy classes for
controlling reporting intervals, suspension, resumption and
solicitation. At the time of this writing, there are no standards-track
PIBs During the IAB Workshop on Network Management, the workshop had
rough consensus from the protocol developers that the IETF should not
spend resources on SPPI PIB definitions, and the operators had rough
consensus that they do not care about SPPI PIBs.</t>
</section>
<!-- ******************************************************* -->
<section title="Accounting Management">
<t>DIAMETER <xref target="RFC3588"></xref> accounting might be collected
for services, and working groups might document some of the
RADIUS/DIAMETER attributes that could be used. [TODO: what data
models?]</t>
<t>RADIUS Authentication Client MIB <xref target="RFC4668"></xref> and
RADIUS Authentication Server MIB <xref target="RFC4669"></xref> allow
the gathering of accounting data.</t>
<t>[TODO] The IPFIX protocol <xref target="RFC5101"></xref> can
collect information related to IP flows, and existing Information
Elements (IEs) may be appropriate to report flows of the new protocol.
New IPFIX Information Elements might be useful for collecting flow
information useful only in consideration of the new protocol. As of this
writing, no IEs have reached Proposed Standard status yet, but a base
set of IEs has been submitted to IESG for advancement. These include IEs
for Identifying the scope of reporting, Metering and Export Process
configuration, IP and Transport and Sub-IP header fields, Packet and
Flow properties, timestamps, and counters.</t>
</section>
<!-- ******************************************************* -->
<section title="Performance Management">
<t>RAQMON <xref target="RFC4710"></xref> describes Real-Time Application
Quality of Service Monitoring.</t>
<t>The IPPM WG has defined metrics for accurately measuring and
reporting the quality, performance, and reliability of Internet data
delivery services. The metrics include connectivity, one-way delay and
loss, round-trip delay and loss, delay variation, loss patterns, packet
reordering, bulk transport capacity, and link bandwidth capacity. [TODO:
detail the RFCs - 4737, 3393, 2681, 2680, 2679, 2678]</t>
<t>SIP Package for Voice Quality Reporting <xref
target="I-D.ietf-sipping-rtcp-summary"></xref> defines a SIP event
package that enables the collection and reporting of metrics that
measure the quality for Voice over Internet Protocol (VoIP)
sessions.</t>
</section>
<!-- ******************************************************* -->
<section title="Security Management">
</section>
</section>
<section title="IANA Considerations">
<t>This document does not introduce any new codepoints or name spaces
for registration with IANA. Note to RFC Editor: this section may be
removed on publication as an RFC.</t>
</section>
<section title="Security Considerations">
<t>This document introduces no new security concerns.</t>
</section>
<section title="Acknowledgements">
</section>
</middle>
<back>
<references title="Informative References">
&rfc1157;
&rfc1901;
&rfc2119;
&rfc2438;
&rfc2613;
&rfc2819;
&rfc2863;
&rfc2865;
&rfc3084;
&rfc3159;
&rfc3165;
&rfc3317;
&rfc3410;
&rfc3413;
&rfc3418;
&rfc3444;
&rfc3535;
&rfc3585;
&rfc3588;
&rfc3644;
&rfc3670;
&rfc3805;
&rfc4011;
&rfc4133;
&rfc4502;
&rfc4668;
&rfc4669;
&rfc4710;
&rfc4741;
&rfc4825;
&rfc4930;
&rfc5101;
&I-D.ietf-syslog-protocol;
&I-D.ietf-sipping-rtcp-summary;
&I-D.ietf-opsawg-operations-and-management;
</references>
<section title="Open Issues">
<t><list>
<t>[TODO: need to verify all citations have references (in xref
format)]</t>
<t>Organize data models by layer?</t>
</list></t>
</section>
<section title="Change Log">
<t>Changes from being part of opsawg-operations-and-management to being opsawg-survey-00
<list>
<t></t>
</list></t>
</section>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 03:55:47 |