Internet Draft Luis Sanchez, BBN
draft-ops-mumble-conf-management-00.txt Keith McCloghrie, Cisco
Expires in Six Months Jon Saperia, Consultant
October 22, 1999
Evaluation of COPS/PIB and SNMP/MIB approaches for configuration
management of IP-based networks.
Status of this Memo
This document is an Internet-Draft and is in full conformance
with all provisions of Section 10 of RFC2026.
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.
Abstract
This document is the output of a design team chartered with the
identification of a global set of configuration management
requirements for IP-based networks. The document includes
evaluations of the COPS/PIB and SNMP/MIB based approaches with
respect to these requirements. In addition, the document discusses
possible enhancements to both of these approaches and includes
evaluations of the costs associated with their development and
deployment.
L. Sanchez, K. McCloghrie, J. Saperia [page 1]
Internet Draft October 22, 1999
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1 Motivation, Scope and Goals of this document . . . . . . . 2
1.2 Requirements Terminology . . . . . . . . . . . . . . . . . 3
1.3 Audience . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.4 Definition of Technical Terms. . . . . . . . . . . . . . . 3
2. Statement of the Problem . . . . . . . . . . . . . . . . . . . 4
3. Requirements for an IP-based Configuration Management System . 7
4. Evaluation of COPS-PR/SoPI . . . . . . . . . . . . . . . . . . 8
4.1 The COPS+SNMP solution: Introduction . . . . . . . . . . . 8
4.2 Does COPS-PR meet the requirements? . . . . . . . . . . .10
4.3 Status of COPS-PR . . . . . . . . . . . . . . . . . . . . 17
4.4 Summary for COPS-PR. . . . . . . . . . . . . . . . . . . 17
5. Evaluation of SNMP/SMI. . . . . . . . . . . . . . . . . . . . 17
5.1 Does SNMP/SMI meet the requirements?. . . . . . . . . . . 17
5.2 Areas of Improvement for SNMP/SMI . . . . . . . . . . . . 24
5.3 Cost of Implementation for SNMP/SMI . . . . . . . . . . . 25
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 26
References. . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
L. Sanchez, K. McCloghrie, J. Saperia [page 2]
Internet Draft October 22, 1999
1. Introduction
1.1 Motivation, Scope and Goals of this document
Over the past months, a number of IETF working groups have
introduced new technologies which offer integrated and
differentiated services. To support these new technologies,
working group members found that they had new requirements for
configuration of these technologies. One of these new requirements
was for the provisioning (configuration) of behavior at the
network level.
An example of this type of configuration would be instructing all
routers in a network to provide 'gold' service to a particular set
of customers. Depending on the specific network equipment and
definition of 'gold' service, this configuration request might
translate to different configuration parameters on different
vendors equipment and many individual configuration commands at
the router. This higher level of configuration management has come
to commonly be known as policy based management.
Working groups associated with these new technologies believed
that the existing SNMP based management framework, while adequate
for fault, configuration management at the individual instance
(e.g., interface) level, performance and other management
functions commonly associated with it, was not able to meet these
new needs. As a result they began working on new solutions and
approaches.
COPS [COPS] for RSVP [RSVP] provides routers with the opportunity
to ask their Policy Server for an admit/reject decision for a
particular RSVP session. This model allows routers to outsource
their resource allocation decisions to some other entity. However,
this model does not work with DiffServ [DSARCH] where there is no
signalling protocol. Therefore, the policies that affect resource
allocation decisions must be provisioned to the routers. It became
evident that there was a need for coordinating both RSVP-based and
DiffServ-based policies to provide end2end QoS. Working groups
began to extend and leverage approaches such as COPS for RSVP to
support Diffserv policies. This gave birth to COPS-PR [COPS-PR].
These extensions caused concern that the IETF was about to develop
a set of fragmented solutions which were locally optimized for
specific technologies and not well integrated in the existing
Internet Management Framework. The concern prompted some of the
Area Directors associated with Operations and Management, the
Transport and General areas, and some IAB members to organize a
two day meeting in mid September 1999. The primary purpose of the
meeting was to examine the requirements for configuration
management and evaluate the COPS/PIB and SNMP/MIB approaches in
light of these requirements.
L. Sanchez, K. McCloghrie, J. Saperia [page 3]
Internet Draft October 22, 1999
By the end of the two day meeting there was no consensus on
several issues and as a result a number of 'design teams' were
created. This document is the output of the design team chartered
with the identification of a global set of configuration
management requirements and the further evaluation of the COPS/PIB
and SNMP/MIB based approaches with respect to these requirements.
In addition, the design team was chartered with investigation of
enhancements to both of these approaches and evaluation of the
costs associated with their development and deployment.
1.2 Requirements Terminology
Keywords "MUST", "MUST NOT", "REQUIRED", "SHOULD", "SHOULD NOT"
and "MAY" that appear in this document are to be interpreted as
described in RFC 2119 [Bra97].
1.3 Audience
The target audience for this document includes system designers,
implementers of network configuration and management technology
and others interested in gaining a general background
understanding of the issues related to configuration management in
general, and in the Internet in particular along with associated
requirements. In addition, the audience are those people who wish
to gain additional information about how COPS-PR and SNMP have
been measured against those requirements. This document assumes
that the reader is familiar with the Internet Protocol, related
networking technology, and general network management terms and
concepts.
1.4 Definition of Terms
Device-Local Configuration
Configuration data that is specific to a particular network
device. This is the finest level of granularity for configuring
network devices.
Network-Wide Configuration
Configuration data that is not specific to any particular network
device and from which multiple device-local configurations can
be derived. Network-wide configuration provides a level of
abstraction above device-local configurations.
Configuration Data Translator
A function that transforms Configuration Management Data
(high-level policies) or Network-wide configuration data
(middle-level policies) into device local configurations
(low-level policies) based on the generic capabilities of network
devices. This function can be performed either by devices
themselves or by some intermediate entity.
L. Sanchez, K. McCloghrie, J. Saperia [page 4]
Internet Draft October 22, 1999
2. Statement of the Problem
Configuring large networks is becoming an increasingly difficult
task. The problem intensifies as networks increase their size, not
only in terms of number of devices, but also with a greater
variety of devices, with each device having increasing
functionality and complexity. That is, networks are getting more
complex in multiple dimensions simultaneously (number of devices,
time scales for configuration, etc.) making the task of
configuring these more complex.
In the past, configuring a network device has been a three step
process. The network operator, engineer or entity responsible for
the network created a model of the network and its expected
behavior. Next, this (model + expected behavior) was formalized
and recorded in the form of high-level policies. Finally, these
policies were then translated into device-local configurations and
provisioned into each network device for enforcement. Any
high-level policy changes ( changes in the network topology and/or
its expected behavior) needed to be translated and provisioned to
all network devices affected by the change. Figure 1 depicts this
model and shows how high-level policies for a network could be
translated into four device-local configurations. In this model,
network operators or engineers functioned as configuration data
translators. Network operators or engineers translated the
high-level policies to device-local configuration data.
A configuration data translator could take the topology
independent behavior description such as high-level policies
(first input source) combine it with topology information (second
input source) as well as status/performance/monitoring information
(third input source) to derive device-local configurations. Note
that there could be several configuration data translators
operating in tandem on a set of devices. However, there could be
only one configuration data translator operating at a particular
device at any given instance.
L. Sanchez, K. McCloghrie, J. Saperia [page 5]
Internet Draft October 22, 1999
Configuration Management
Data (High-level Policies)
|
|
|
|
Network V Network
Topology -----> Configuration <---- Status/performance
Information Data Translator(s) Information
|
|
|
|
-------------------------------------------------
| | | |
Device Device Device Device
Local Local Local Local
Conf(1) Conf(2) Conf(3) Conf(4)
Figure 1. Current model for configuring network devices.
Historically, network operators and engineers used protocols and
mechanisms such as SNMP and CLI applications to provision or
configure network devices. In their current versions, these
mechanisms have proven to be difficult to use because of their
low-level of granularity and their device-specific nature. This
problem is worse when provisioning multiple network devices
requiring large amounts of configuration data.
It is evident that network administrators and existing
configuration management software can not keep up with the growth
in complexity of networks and that an efficient, integrated
configuration management solution is needed. Several IETF Working
Groups working on this problem converged into adding a layer of
abstraction to the traditional configuration management process
described in figure 1. Figure 2 depicts this process after the
layer of abstraction is added. As in the previous figure, first
the network operator, engineer or entity responsible for the
network creates a model of the network and its expected
behavior. This is formalized and recorded in the form of
high-level policies.
L. Sanchez, K. McCloghrie, J. Saperia [page 6]
Internet Draft October 22, 1999
Configuration Management
Data (High-level Policies)
|
|
|
|
Network V Network
Topology -----> Network-Wide <---- Status/performance
Information Configuration Information
Data
|
|
|
|
V
Configuration
Data Translator(s)
|
|
|
|
-------------------------------------------------
| | | |
Device Device Device Device
Local Local Local Local
Conf(1) Conf(2) Conf(3) Conf(4)
Figure 2. Propose model for configuring network devices.
These policies are combined with topology information as well as
status/performance information to generate network-wide
configuration data. These middle level-policies are simpler to
manage and represent behaviors shared by multiple network devices.
Device local configurations are generated by automated
configuration data translators and are supplied to each network
device for enforcement. Note how this model only describes the
function of the configuration data translators and it does not
dictate its functional location. This is to say that translators
may reside outside of the devices (as it was the case in figure 1
since they were humans) or may be collocated with each device if
possible.
As in the previous model, any high-level policy changes (changes
in the network topology and/or its expected behavior) needs to be
propagated to all network devices affected by the change. However,
in the configuration model depicted in figure 2 network operators
and engineers can specify the behavior of the network in a
simplified manner reducing the amount of device specific knowledge
needed.
L. Sanchez, K. McCloghrie, J. Saperia [page 7]
Internet Draft October 22, 1999
One should keep in mind that in some cases per instance device
local configuration is needed in network devices. An integrated
solution MUST allow room for this. Also, the introduction of
automated configuration data translators assumes that all
information needed to make an error free conversion of
network-wide configuration data into device-local configuration
data is available. In the event that such data is not available
the solution MUST detect this and act accordingly.
3. Requirements for an IP-based Configuration Management System
The following requirements for configuration management will be
used in evaluating the cost effectiveness of the extension to SNMP
and/or the use of COPS-PR with modifications for configuration
management. An integrated configuration management solution MUST:
1) provide means by which the behavior of the network can be
specified at a level of abstraction (network-wide
configuration) higher than a set of configuration information
specific to individual devices,
2) be capable of translating network-wide configurations into
device-local configuration. The identification of the relevant
subset of the network-wide policies to be down-loaded is
according to the capabilities of each device,
3) be able to interpret device-local configuration, status and
monitoring information within the context of network-wide
configurations,
4) be capable of provisioning (e.g., adding, modifying, deleting,
dumping, restoring) complete or partial configuration data to
network devices,
5) provide efficient means compare to today's mechanisms (CLI,
SNMP) to provision large amounts of configuration data,
6) provide secure means to provision configuration data. The
system must provide provide support for access control,
authentication, integrity-checking, replay- protection and/or
privacy security services. The minimum level of granularity for
access control and authentication is host based. The system
SHOULD support user/role based access control and
authentication,
7) provide expiration time capabilities to configuration data. It
is required that some configuration data items be set to
expire, and other items be set to never expire,
8) provide error detection (including data-specific errors) and
failure recovery mechanisms for the provisioning of
configuration data,
L. Sanchez, K. McCloghrie, J. Saperia [page 8]
Internet Draft October 22, 1999
9) eliminate the potential for mis-configuration occurring through
shared write access to the device's configuration data,
10) provide facilities (with host and user-based authentication
granularity) to help in tracing back configuration changes,
11) allow for the configuration of redundant components (both as
network elements and configuration application platforms). In
addition, the system should support the concept of individuals
(humans) in different roles with different access privileges,
12) be flexible and extensible to accommodate for future
needs. Configuration management data models are not fixed for
all time and are subject to evolution like any other
management data model. It is therefore necessary to anticipate
that changes will be needed, but it is not possible to
anticipate what those changes might be. Such changes could be
to the configuration data model, supporting message types,
data types, etc., and to provide mechanisms that can deal with
these changes effectively without causing inter-operability
problems or having to replace/update large amounts of fielded
networking devices,
13) leverage knowledge of the existing SNMP management
infrastructure. The system MUST leverage knowledge of and
experience with MIBs and SMI.
4. Evaluation of COPS-PR/SoPI
This section describes how COPS-PR meets the requirements listed
in section 3. It also provides an introduction to COPS and the WG
status. Keith McCloghrie provided the text for this section and
his views are not necessarily shared by the co-authors of this
document.
4.1 The COPS+SNMP solution: Introduction
For the past decade, the use of SNMP and the Internet Management
Framework has been used very successfully both to monitor devices
and to set device-local configuration data in devices. The
low-level access which SNMP provides has proved to be the
appropriate level for these tasks. There are some improvements to
SNMP which would be beneficial in performing these tasks, but the
already-achieved success speaks to the fact that wholesale changes
are not required.
L. Sanchez, K. McCloghrie, J. Saperia [page 9]
Internet Draft October 22, 1999
Indeed, any significant set of changes to SNMP would be
detrimental to its stability. SNMP's most pressing need at this
time is to get significant deployment of the recently approved
SNMPv3 specifications, and stability will be a major factor in
SNMPv3 being successfully deployed. Therefore, this COPS+SNMP
solution uses SNMP as defined today (with whatever improvements
can be made without causing instability) for the tasks of
monitoring devices and setting small amounts of device-local
configuration. These are the tasks for which SNMP was designed
and to which it is well suited.
However, the advent of policy-based configuration (as described in
the preceding sections of this document) has introduced new
requirements, many of which are listed in section 3 above.
Today's SNMP has difficulty with many of these requirements, and
thus, this COPS+SNMP solution uses COPS-for-Provisioning to meet
the new policy-based requirements. COPS-for-PR is also aligned
with the use of COPS for outsourcing; this is another requirement
for policy-based management (but outside the scope of
configuration management).
The COPS framework defines the notion of Policy Servers, called
Policy Decision Points (PDPs), and devices, called Policy
Enforcement Points (PEPs). A PDP and a PEP communicate via the
COPS protocol. The COPS protocol defines the notion of Client
Types. The first Client-Type was defined for use in
RSVP-outsourcing, i.e., with Integrated Services (IntServ), a
router/PEP on receiving a RSVP message sends a request message to
the PDP to ask for a policy decision concerning that RSVP message,
and the PDP responds with a decision. With Differentiated
Services (DiffServ), a router typically does not receive a
signalling message telling it about the forthcoming packet stream;
instead, it must be pre-loaded/provisioned with the policy
decision ready for use when the packets arrive. For this
provisioning of policy decisions/data, COPS-for-PR has been
defined as a new COPS Client-Type.
With COPS-for-PR, the network-wide policy/configuration data that
a PDP downloads to a PEP is defined in Policy Information Bases
(PIBs). New PIBs can be defined as and when necessary to extend
the usage of COPS-for-PR to new data items without changing the
protocol. This is the same strategy as MIBs provide for SNMP. In
fact, the design of COPS-for-PR has purposely been defined to
leverage as many SNMP strategies/mechanisms as are appropriate in
meeting the new requirements. Further examples of this leverage
are:
- PIBs are defined using a variant of SNMP's SMI used to
define MIBs; i.e., PIBs are easily recognizable to those
engineers and operators who are already familiar with MIBs.
The differences in the rules for defining a PIB are solely
those needed for use with the COPS-for-PR protocol and
network-wide policies/configuration.
L. Sanchez, K. McCloghrie, J. Saperia [page 10]
Internet Draft October 22, 1999
- PIBs define a "policy rule class", which is equivalent to a
row definition in a MIB table, and a "policy rule instance"
which is equivalent to a particular row in a MIB table.
- PIBs name policy rule classes via OIDs (i.e., the same
naming mechanism use in MIBs).
The COPS model specifies that a single PDP has exclusive access to
a PEP at any one time for a particular set of PIBs. The TCP
connection used for the COPS protocol is initiated by the PEP to
the IP-address of the PDP contained in the PEP's device-local
configuration. This avoids the complications that SNMP has
through allowing multiple Network Management Stations to have
concurrent write-access to its MIBs. (See below for more details
of how this works.)
This section can obviously not go into full details of the
protocols and PIB. The reader is encouraged to consult [COPS],
[COPS-RSVP], [COPS-PR] and [PIB] for more details.
4.2 Does COPS-PR meet the requirements?
The COPS+SNMP solution meets the requirements listed in section 3 as
follows:
1. PIBs are defined to contain (higher-level) network-wide
policies/configuration data, while MIBs continue to be used to
define (lower-level) device-local data, both for configuration and
monitoring, i.e., the same usage of MIBs as exists today. This
separation of function between PIBs and MIBs provides clarity, and
fosters understanding of, and focus on using the right tool for
each task.
2. A significant difficulty with current Management Stations is
the scalability problem (mentioned in an earlier section) of being
able to keep up with the ever expanding set of devices-types, each
of which has multiple versions supporting a different variety of
low-level features, each with their own type of device-local
configuration. With the COPS+SNMP solution, it is the
network-wide configurations which are downloaded from the PDP into
the devices, and the devices which perform the "Configuration Data
Translator" function of translating the received network-wide
configurations into the specific device-local configuration needed
by the individual device. This eases the scalability problems of
the PDP/Policy Server, since it can now concentrate on
understanding the abstractions of the network-wide configurations
and delegate the understanding of each device's low-level
device-local configurations to that device itself.
L. Sanchez, K. McCloghrie, J. Saperia [page 11]
Internet Draft October 22, 1999
COPS-for-PR also defines a mechanism to upload from the PEP to the
PDP the capabilities (and "roles", see [PIB] for more details) of
the PEP. The particular items of capability data are defined in
the PIBs (via the use of "notify" in a PIB's POLICY-ACCESS clause,
see [PIB] for more details). The PDP uses the information
provided by these capabilities to determine what subset of the
(complete set of) network-wide policies that need to be downloaded
into a particular device. That is, the PDP does not need to have
a priori knowledge of what subset of policies are needed by
particular device-types, which again helps to ease the scalability
problem.
3. A particular device's capabilities (and "roles") are not only
contained in a PIB, but also in a device's MIB. However, in the
MIB, they are defined at a lower-level of granularity. For
example, a PIB contains just the set of "roles" a device has; it
is only in the MIB that "roles" are associated (configured) to
individual interfaces. (This means that the PIB, and therefore,
the PDP also, does not have to know all the details and names of
the individual interfaces on a device.) It is these linkage
mechanisms between the PIBs and the MIBs which enable a monitoring
application to interpret the device-local configuration, status
and monitoring information (contained in MIBs) within the context
of network-wide configurations (contained in PIBs). For example,
a monitoring application can determine how successful a particular
policy associated with a "role", by summarizing the activity on
all interfaces that have that "role".
4. COPS-for-PR provides for the installing of new policies or the
modification of existing policies. It also provides for the
deletion of previously downloaded policies, either an individual
policy rule instance, or all policies within a particular OID
subtree (which could potentially be all policies contained in the
device).
In addition, the PIB defines a "Policy Incarnation Table", this
has a POLICY-ACCESS clause of "install-notify" which means that it
is not only uploaded along with the device's capabilities, but the
PDP is also able to store information into it. One of the items
in this table is an Incarnation-id. This incarnation-id allows
the PDP to set the value according to the current set of policies
loaded into the PEP; it also allows a new PDP (e.g., a secondary
PDP taking over from a failed primary) to know what is currently
loaded into the PEP without needing to dump the whole or partial
configuration. If a secondary PDP determined that it needed to
restore a whole or partial set of configuration, it could delete
those policies which are not wanted, and download the set of
policies which are to be used instead.
L. Sanchez, K. McCloghrie, J. Saperia [page 12]
Internet Draft October 22, 1999
COPS-for-PR has also specified the potential of algorithmically
converting a PIB into a read-only MIB. This read-only MIB would
be available for reading via SNMP by a Management Station other
the current PDP to query the device for its current configuration
(i.e., the ability to dump the whole or a partial set of the
policies contained in the device). Note that such a
algorithmically-defined MIB would NOT be redundant with the
existing device-local configuration MIB, as depicted in the Figure
3.
| Defined | Algorithmically- |
| by Human | converted |
-----------------------------|----------|-------------------|
Network-wide Configuration | PIB ---|--> read-only MIB |
-----------------------------|----------|-------------------|
Device-local Configuration | MIB | |
-------------------------------------------------------------
Figure 3: Distinction between PIBs and MIBs
5. One of the advantages of COPS-for-PR over SNMP is its
higher-level of access. This provides a much more efficient means
than today's mechanisms (CLI, SNMP). This gain in efficiency is
not only with respect to bandwidth, but also a reduced number of
exchanged messages, and most significantly, a reduction in
complexity. This is important for the ever increasingly large
amounts of configuration data that today's devices need. While
SNMP will still be used for device-local configuration, the amount
of device-local configuration will be significantly reduced, since
an increasing amount of it will be replaced by the downloading of
network-wide configuration data via COPS-for-PR.
One gain in efficiency over today's SNMP/CLI is the ability to
load network-wide policies into a device and have those policies
apply to multiple components of the device. For example, rather
than having to load device-local configuration data for each
individual interface, those interfaces which have the same
function (same "role") can share the same network-wide
configuration data, so that if twenty interfaces on a Wiring
Closet switch all need the same configuration, then that
configuration can be downloaded once, rather than twenty times.
Other gains in efficiency over SNMP result from differences in the
protocols:
- COPS-for-PR uses TCP.
- COPS-for-PR uses large messages, e.g., messages of up to
64kBytes (or longer) in length (without needing to suffer
the disadvantages of IP fragmentation).
L. Sanchez, K. McCloghrie, J. Saperia [page 13]
Internet Draft October 22, 1999
- Large messages are efficient in multiple ways, including the
ability of a PDP to download much more data as a single
"transaction", which avoids the complications of downloading
individual pieces one at a time and having to worry about
the inconsistency of each incremental set of pieces.
- COPS-for-PR access to policy data is at the granularity of a
policy rule instance, (equivalent to a whole row in SNMP).
COPS-for-PR does not provide access to individual leaf
instances like SNMP does.
- Atomic access to whole policy rule instances allows
COPS-for-PR to name whole rows, not individual leaf
instances. So, COPS messages include an OID naming the row,
plus a vector of values, one for each value in the row. In
contrast, SNMP messages contain a varbindlist, consisting of
the name and value of each referenced columnar object in the
row. This results in a significant difference in message
size, since OIDs are notoriously long. For example,
consider a row consisting of 10 integers, with OIDs of
length 15 bytes, and integer values of length 2 bytes: this
would use up 210 bytes of an SNMP message, but only 57 bytes
in a COPS message.
- Atomic access to whole policy rule instances also allows
devices to process whole rows at a time, which is more
efficient in processing, and produces less error/corner
cases than when a row is received a few data values at a
time. This results in less code, which is easier to
implement and easier to test.
Like COPS-for-PR, CLI access to a device also uses TCP and
provides access only on a "per-row" basis, but it does so via
human-understandable words, which is intrinsically less efficient
than the transfer of binary information.
6. With the use of COPS being exclusively over TCP, COPS provides
the following security choices:
- a (mandatory to implement) COPS-specific message integrity
object, providing authentication and replay protection, but
not encryption.
- IPSEC, providing per-host authentication and access-control,
message integrity, replay protection and/or encryption;
presumably sharing the same key distribution mechanism as
other uses of IPSEC.
- session level security mechanisms (SSL/TLS), which provide
increased security (and increased overhead!!).
Some of SNMP security's complications derive from the granularity
of its authentication and authorization mechanisms:
L. Sanchez, K. McCloghrie, J. Saperia [page 14]
Internet Draft October 22, 1999
- for authentication, SNMP provides per-user granularity.
- for access control, SNMP provides granularity to the
object-level or instance-level, and to the types of allowed
operations (read, write, etc.).
These low levels of granularity are necessary when multiple
network managers are using multiple network management stations to
access multiple MIBs. Their design accommodates, for example,
access from an on-call network manager in the middle of the night
to fix network problems, as well as out-of-band management. In
contrast, these low- levels are not needed in the COPS model where
the PDP has exclusive access to the PEP. So, COPS is only
required to provide per-IP-host authentication, and per-session
access control.
In the COPS model, the provision of different levels of
access-control for various users having different operational
responsibilities is performed by the PDP. All such users get
access to devices via the PDP. The PDP itself has full access to
all PIBs associated with its particular Client-Type. The PDP
authenticates individual users and restricts their access
according to their individual privileges.
As a result, COPS security (including its configuration) is always
simpler than SNMP's, and the reduced burden of configuring COPS
security can sometimes be further reduced through its commonality
with the security of other applications.
Furthermore, the deployment of SNMP security faces the difficulty
of overcoming the inertia of the installed base of SNMP systems
which lack security. The deployment of COPS security will be a
simpler task since security is included in its initial
(standardized) specification.
7. COPS provides for downloaded policies to have an expiration
time. This expiration time comes into play when a PEP looses its
communication with its PDP, both its primary and any secondaries
which might be defined for it. On loss of communication, the
expiration timer is started and continues to run until
communication with a PDP is re-established. If the expiration
timer reaches the value of a policy's expiration time, then that
policy expires. For example, security policies might need to have
infinite expiration timers, so that they never time out. On the
other hand, particular bandwidth reservations might have
relatively small expiration times.
8. For failure recovery, COPS uses a Keep-alive mechanism to
ensure that at least one message is exchanged over the TCP
connection between the PEP and PDP within a timer value. If no
message is received within the timer value, the connection is
assumed to have failed and the PEP initiates a TCP connection to a
Secondary PDP.
L. Sanchez, K. McCloghrie, J. Saperia [page 15]
Internet Draft October 22, 1999
For errors that occur in the downloaded policies, COPS provides
not only a generic error code applicable to all types of policy
rule classes, but allows individual policy rule classes to be
defined (in the PIB) with their own individual error codes. These
error codes are returned in a COPS Report message to the PDP.
This ability to have errors specific to policy rule classes
greatly simplifies the task of a PDP in diagnosing why a
particular problem occurred. For example, if an
"inconsistentValue" error needs to be returned, COPS-for-PR makes
it possible for the PEP to specify what it is inconsistent with.
9. When multiple Management Stations have write access to a
device's configuration, there is no mechanism to prevent one of
them from undoing the configuration which was set by another, nor
to prevent the configuration from any of them from being modified
via the CLI. COPS grants a single PDP exclusive access to an
associated set of PIBs. This is not only exclusive of other PDPs,
but also exclusive of SNMP and the CLI. Of course, SNMP and/or
the CLI is able to disable the use of COPS (via device-local
configuration) if and when local control of the device is required
(e.g., for emergency network debugging), but the PDP is informed
of this through the closure of the COPS TCP connection. When COPS
is enabled again, the TCP connection is re-established, and the
PDP can restore the configuration to what the higher-level
policies require it to be. This eliminates the potential for
mis-configuration occurring through shared write access to the
device's network-wide configuration.
10. Since all changes to the network-wide policies downloaded into
a device are made by a single PDP, this PDP can keep a full audit
log of all changes to the configuration. Assuming that the PDP
makes these changes based on input from particular users, then the
audit log can include the particular user who made each change.
11. As mentioned above, a PEP can be configured with a Primary PDP
and a Secondary PDP, with the PEP connecting to the Secondary
whenever it cannot reach the Primary. When two devices are used
such that one is a backup for the other, they will likely both
share the same network-wide configuration data to be downloaded
either by the same PDP for both, or by their respective PDPs
(which might share policies via the Directory).
In the COPS model, the provision of different levels of
access-control for various users having different operational
responsibilities is performed by the PDP. All such users get
access to devices via the PDP. The PDP itself has full access to
all PIBs associated with its particular Client-Type. The PDP
authenticates individual users and restricts their access
according to their individual privileges.
L. Sanchez, K. McCloghrie, J. Saperia [page 16]
Internet Draft October 22, 1999
12. PIBs allow the definition of new policy rule classes, and the
extension of existing policy rule classes. Procedures by which a
PDP can interoperate with a PEP when they support different
versions of a PIB are currently being added to the COPS-for-PR
specification. Briefly, these will allow policy rule classes to
be extended with additional columns; a PDP will know in advance
the policy rule classes and their columns that the PEP supports
through the uploading of the policyPrcSupportTable as part of the
device capabilities, and can either take special actions or use
the following default procedures: a PEP supporting more columns
than a PDP will supply its own default values for any additional
columns it receives; a PEP supporting fewer columns than a PDP
will ignore any additional columns it receives; for obsolete
columns, a PDP can supply a null value.
The COPS protocol is inherently extensible in that it does not
have fixed message formats except for its common message header
(containing version, flags, op-code and Client-Type). The
remainder of each message contains "objects" defined using a TLV
format, such that new objects can be added to a particular message
type, as and when that might be necessary. PIB objects are
contained in Client-Specific objects defined for COPS-for-PR
Client-Types.
New message types can be added, and new data types can be added
over time. Error codes are being defined such that if and when a
PDP/PEP receives a message-type or data-type that it doesn't
understand, it will report the occurrence as an error.
13. The design of COPS-for-PR has purposely been defined to
leverage as many SNMP strategies/mechanisms as are appropriate in
meeting the new requirements. Examples of this leverage are:
- PIBs are defined using a variant of SNMP's SMI used to define
MIBs; i.e., PIBs are easily recognizable to those engineers
and operators who are already familiar with MIBs. The
differences in the rules for defining a PIB are solely those
needed for use with the COPS-for-PR protocol.
- PIBs define a "policy rule class", which is equivalent to a
row definition in a MIB table, and a "policy rule instance"
which is equivalent to a particular row in a MIB table.
- PIBs name policy rule classes via OIDs (i.e., the same naming
mechanisms used in MIBs)
- COPS-for-PR uses the same BER-encodings of OIDs and data
values as SNMP uses.
L. Sanchez, K. McCloghrie, J. Saperia [page 17]
Internet Draft October 22, 1999
4.3 Status of COPS-PR
The COPS protocol and the COPS-for-RSVP specifications have passed
their Working Group Last Calls, and are awaiting approval by the
IESG. The COPS-for-PR spec and an initial PIB are newer and have
only recently become a topic of Working Group discussions. While
its specification is complete enough such that several initial
implementations have been completed, further details need to be
defined and existing details will no doubt be refined as the
specification progresses through the Working Group process.
4.4 Summary for COPS-PR
The COPS+SNMP solution leverages SNMP for monitoring devices and
for setting small amounts of device-local configuration data in
devices. These are tasks for which its low-level of access has
been very successful over the past decade. In addition, the
COPS+SNMP solution adds the capability to download network-wide
configuration data into devices through the use of COPS-for-PR, as
a new "tool" in the Configuration Management toolkit. This tool
provides for a higher-level of Configuration Management, which
results in much-needed simplifications and efficiencies to the
overall implementation and usage. This solution avoids the "swiss
army knife" approach of having a single tool to perform all
functions; instead, it defines a set of tools each tailored to
perform their specific tasks well.
5. Evaluation of SNMP/SMI
This section describes how SNMP meets the requirements listed in
section 3. It also provides a list of possible areas where SNMP
could be improved and the cost associated with implementing these
improvements. Jon Saperia provided the text for this section
and his views are not necessarily shared by the co-authors of this
document.
5.1 Does SNMP/SMI meet the requirements?
The SNMP solution meets the requirements listed in section 3 as
follows:
1. For the purposes of this document SNMP is meant broadly in that
it refers to the Internet Standard Management Framework which
includes many components. See RFC 2570, Introduction to Version 3
of the Internet-standard Network Management Framework and RFC
2571, Architecture for SNMP Frameworks, for additional
details. The current Structure of Management Information (SMI) in
L. Sanchez, K. McCloghrie, J. Saperia [page 18]
Internet Draft October 22, 1999
use by the Internet Standard Management Framework allows full
expression of the required higher level (network-wide)
configuration parameters. In addition, the Simple Network
Management Protocol (SNMP), can carry this information without
modification. Network-wide behaviors such as: for traffic of a
particular type cause a particular action or behavior can easily
be specified. An example is: for all inbound traffic marked with
a Differentiated Services Code Point of a specific value, when
forwarded over all interfaces in the router (or a specific
sub-set), treat the traffic as high priority. High priority could
be specified in the policy by a set of Weighted Fair Queue or
other reasonable parameter combinations.
Using this SNMP-based approach, policies (network-wide behaviors)
would exist in MIB Groups/Tables. These behaviors would exist as
entries which would have standard indices and sub-indices. The
nature of the indices and sub-indices would be as required by the
nature of the data elements (MIB Objects) used to specify the
various network wide behaviors in the table(s). In addition, it is
possible to have control tables activate one or many more than one
of these behaviors at a time. All these capabilities are a
function of MIB design. For those that use this approach, they
can create and control policies with a minimum of data exchange
between the configuration application and the managed device.
Further, the use of control tables can be used to eliminate the
need for the use of the row status textual convention for those
that wish to avoid it's use. A control table could be a very
simple table with the behavior index and an on/off control which
would turn the entire policy on or off. A richer set of other
attributes could also be implemented in the control table if
desired such as policy refresh/time out values etc.
2. A consistent name space is essential to efficiently achieve
this goal. Through the use of a common data definition language,
the SMI, as a means of defining these network wide configuration
parameters (policies) the 'translation' to the device local
configuration becomes much easier. In effect what happens with
this approach is that as one moves from the abstract to the
specific, names get increasingly refined. In the most refined
level they are instance specific object identifiers. Use of the
standard SMI provides this ability to move from the very abstract
to the specific efficiently for the computer systems since
translation is not necessary given this integrated model. This
consistency also aids the understanding of the people who will
have to develop, debug, and deploy the technology.
L. Sanchez, K. McCloghrie, J. Saperia [page 19]
Internet Draft October 22, 1999
The requirement also states that the network wide configuration
information sent to a device should be 'according to the
capabilities' of the device. Many capabilities are already
expressed in terms of the SMI, using this standard would
facilitate the collection from the devices of their capabilities
and reduce cost of implementation where the code for the
capabilities already exists. An important feature of the SMI is
its ability to represent scalar information which can be helpful
when representing a devices capability set such as the queuing
methods available, maximum sustained packet rate, etc. This
capability will clearly be of benefit as the specification of
network wide behavior increases.
3. To the extent that network wide configuration information uses
a name space which is consistent with device local naming, and to
the extent that the naming and retrieval mechanisms are compatible
with the tools for retrieving and processing status such as fault
or performance data, then the task of the management of network
wide behavior is simplified.
All the components of the SNMP Framework use this consistent name
space which makes the achievement of this requirement much easier
than with other approaches. It would be extremely difficult
without writing large amounts of new code for both the end systems
and the management application area to achieve these results.
Below are some examples of network wide behavior which is only
fully realizable when configuration data is integrated with
capabilities of the device and performance and status information
- an area that SNMP has been doing with increasing success for
many years.
- Reserve up to 50% of the networks capacity for
'preferential' treatment of traffic from one department to
another.
- In the event of a network/component failure, only allow a
maximum of X packets or octets of data per unit of time to
move through the network which are of low priority or 'best
effort' service.
- Give gold service (e.g., expedited forwarding) to certain
kinds of traffic from a particular customer. This may be
further refined with upper limits on the amount of traffic
per unit time to pass through the network.
The requirement and the examples above show the importance of the
integration of all types of management data (e.g., fault,
configuration, performance, security, etc.). In fact, the
requirement is not achievable without this integration. The
configuration management system must be capable of both expressing
the desired network wide behavior and monitoring ongoing
performance and status to verify operation within the specified
behavior patterns. IP networks have achieved this level of
integration in the past only through the use of labor intensive
L. Sanchez, K. McCloghrie, J. Saperia [page 20]
Internet Draft October 22, 1999
and expensive approaches, that is through the use of many very
highly skilled individuals. The requirements in this document
along with others will drive network operations to seek more
automated and timely software based approaches. There are
examples in other fields such as the telco industry and earlier
proprietary network technologies where this type of integration
has been realized. These examples all have had integrated
solutions.
SNMP is already widely deployed and used to collect information
about utilization and is the method most often used to make an
initial detection of a failure. There is a wide body of code in
place to count packets, make interface status available,
etc. through SNMP. Without a great deal of work any other
approach would have to re-invent much of this capability. This
capability [collection of fault and performance data] is just the
start of being able to write software which will help simplify the
task of management as networks become larger and more
complex. Reinventing this capability will delay the ultimate goal
of an integrated system suggested by the requirement.
4. It is inefficient to reconfigure an entire system based on a
single change. The requirement above suggests that portions of a
device can be (re)configured on an as needed basis. Once a device
has been provisioned to be IP communicative (e.g., initial IP
address), SNMP provides the capability to monitor or provision
(add, modify, or delete) all or a portion of a system's
configuration at a time. Further it has mechanisms when properly
applied to help ensure that when partial configuration changes are
made, inconsistent results to not occur.
It is far more efficient to download a portion of a configuration
when that is useful than all of it. The cost in not only in the
network transfer but in the delay caused by the managed element
while it 'parses' the new configuration information. In the case
of downloading a network wide behavior to a device there is
relatively little data since it is not 'instance specific'. There
can be significant cost in converting the network wide behavior to
the necessary instance specific values. There is no magic here,
this conversion to instance specific information will have to take
place regardless of the method used to send the network wide
behavior to the managed system. If each time a change were needed,
the entire configuration or a significant portion must be down
loaded, there will be significant cost. The incremental approach
used by SNMP helps avoid these costly major configuration
events. The only way to reduce these large operations is to have
more and more specialized separate 'policy servers' in the
COPS/PIB approach - a management problem itself.
L. Sanchez, K. McCloghrie, J. Saperia [page 21]
Internet Draft October 22, 1999
This capability (partial download or modify/delete) is
particularly important when there are failures in one or more of
the network components, including the configuration application
platforms. Since SNMP does not require a large resynchronization
when a managed element looses contact with its manager(s) and vice
versa, there is not the potential for oscillation in times of
network stress that could occur when entire or large portions of
(re)configurations are needed as with persistent connection based
approaches. The other capability that the SNMP based approach
allows is for 'emergency' type reconfigurations, even if they were
to be done by a CLI. It will continue to be the case that network
'events' will happen and experts will need to tweak configurations
a bit here and there to make the system regain normal operation.
An SNMP based environment is well suited to this since it does not
assume a single owner for each major type of configuration element
(type of policy). There are SNMP based systems which exist today
with the capability to have changes made from the CLI or other
methods and which prevent the manager station multiple write
condition feared in requirement 9.
5. SNMP is not used too widely today for configuration management.
The most widely deployed configuration tool is the Command Line
Interface. One of the problems with this approach is that it does
not have a level of abstraction above the box (or standards to
support it). As a result it is inefficient in many dimensions.
It is inefficient because of the large number of configuration
operations that are necessary to configure a system and it is
inefficient because each implementation is different which
prevents the development of standards. If we were to use SNMP and
MIBs for policies as described under requirement 1, we could
develop a wider range of standards while still allowing individual
vendor distinctions.
The term efficiency is not only a measure of the number round
trips between a manager and a managed element required to
configure it, it is a measure of how much work it will take to
convert the high level network wide information into a form that
is usable by the device. As noted previously, a common name space
such as that offered by the SNMP aids in this efficiency. Control
over one or more 'policies' with control tables as provided in the
extant Management Framework also gives far more efficient control
over the installation deletion and modification of policies on a
managed device.
With regard to efficiency of implementation, SNMP also offers
significant benefits. These include the large knowledge base of
people familiar with MIBs, their specification and implementation.
In addition, the simple suggestion in requirement 1 which allows
for a single simple communication between a manager and a managed
device which may have potentially many instances created on the
device not improves efficiency over the wire as previously
described, it can improve efficiency of implementation for those
who wish to write simple policies and not use the row status
conventions.
L. Sanchez, K. McCloghrie, J. Saperia [page 22]
Internet Draft October 22, 1999
6. The administrative framework for SNMP has been specifically
designed to meet all of the requirements in item 6. More
importantly from a security perspective, some people feel that
having the authentication and access control at the device
granting the access is an inherently more secure method than when
that authority is delegated across a network to other systems.
The SNMP administrative features include the ability to control
access at the user/role level. This is extremely important since
some users would be allowed to modify some policies and others
only to read them. Others might have access to a variety of sub
sets. It is for this reason that managed systems should have
local access control capabilities by users/roles rather than
delegating this to a remote system to implement. This approach is
not only more flexible, and in some views more secure, it is also
more resilient in times of network stress when individuals might
want to gain control of systems in a secure way from different
locations.
7. This is an issue for the data an not a protocol. As such SNMP
provides an excellent mechanism for this requirement. At whatever
level of granularity is appropriate, expiration times can be set to
any configuration element, even those that are network wide in scope
very much like how the TTL in the SOA record works. The level of
granularity and control is an issue of the MIB design. A MIB based
approach to this requirement also allows for on-the-fly updates to the
expiry value for a network wide or instance specific item which is not
provided in other approaches. In certain circumstances the effective
duration a policy might need to be extended. An example is the case of
types of transit traffic to permit over certain links in failure
conditions such as when an important peer has been lost. It is far
more efficient to update a single value (perhaps from an authorized
source which is NOT the main configuration application platform) than
to reload the entire configuration or significant sub sets from a
configuration application server.
8. Recent improvements to the SNMP protocol address the first part
of this requirement, protocol error reporting. The second part of
the requirement, the data specific part, can be met by design of
the tables. A table which is indexed by set serial number and
other index information could be constructed which makes it
possible to include why the set failed - the data specific
part. So the return could include not only that there was an
'inconsistent value' by why there was an inconsistent value. Also
note that such a table would be retrievable even in times of
network stress whereas having return information in a response PDU
might be lost or lost in the event of a broken connection in a
connection oriented approach. If the information were lost in
transit, it could be retrieved via the MIB on the managed element.
L. Sanchez, K. McCloghrie, J. Saperia [page 23]
Internet Draft October 22, 1999
9. The current SNMP framework provides a number of mechanisms
which address this requirement without imposing the significant
restrictions of having only one manager in control at one time and
the associated costs or manager change in the COPS/PIB
approach. This [SNMP] approach also provides for user/role based
authentication at the managed device which is far more flexible
that IP address or host based authentication. Some of the
mechanisms which address this requirement include the row status
textual convention, context locking and the advisory locks which
can be placed on tables which give clear indication of who is in
control while allowing the flexibility to have another manager
take over some or all of a system in a secure fashion when need
arises.
10. The extant SNMP administrative framework provides for these
capabilities. Systems have been built which track all levels of
configuration change based on users and the machines from which
they accessed the managed device. In effect an SNMPv3 based
system can produce an 'audit' trail of who made changes, from
where and when. SNMPv3 based systems also exist which can provide
this information even when changes have been made with a CLI.
Correctly implemented these two tools can coexist and compliment
each other. For additional details on how the security mechanisms
work please see the reference section.
11. As described in requirement 10, the existing SNMP provides for
monitoring and control based on individuals and roles, not at a
remote system but at the managed element itself. Additionally it
has several features which further support this requirement. They
include:
- Use of informs sent to multiple sites based on
configuration. This allows management staff to more rapidly
know about failures of either the managed elements or the
management systems. It also allows for rapid fall back in
the case of management system failure.
- Multiple destination addresses further reduce the likelihood
of management system isolation as would be the case of only
a single back up system.
- The ability to perform 'trap directed polling' in the same
name space as the configuration name space can improve time
to fault isolation or determine the source of a
configuration failure (see requirement 8).
All of this is accomplished without the unnecessary instability
created in a system where it is necessary to have extensive resync
operations or reload significant portions of a devices
configuration in the event of a communication loss with a single
manager.
L. Sanchez, K. McCloghrie, J. Saperia [page 24]
Internet Draft October 22, 1999
12. This has been a feature of SNMP since its earliest stages.
The OID assignment process allows for evolution without knowing
what the changes would be. New software has been deployed without
replacement/upgrade of large amounts of fielded network devices.
Managers exist today which speak to devices with SNMPv1 which have
never been upgraded (and are not likely to be) as well as the
newest SNMPv3 devices.
13. The existing SNMP management infrastructure consists of
several components which include:
1. The language for the definition of MIBs, the Structure of
Management Information.
2. The extant standards-based MIBs.
3. The extant vendor specific MIBs.
4. The SNMP itself.
5. The public and private domain support for MIB writing and
verification tools.
6. The public and private domain support for agent writing
tools and utilities.
7. The public and private domain support for management
applications.
8. Software Engineering expertise in all of the above areas
9. Network engineering and Network Operations Center Staff
experience and training with the applications, tools, MIBs
(data objects), etc.
Clearly and SNMP based approach would leverage all these
investments. Further the enhancements suggested are small and
inexpensive in terms of computing, network and human resources.
5.2 Areas of Improvement for SNMP/SMI
Clearly the evaluation above leads to the conclusion that; for
configuration management, SNMP can be a very effective tool. This
effectiveness extends to the domain of the configuration of
network wide data (policy). As with all tools, as additional
requirements arise, enhancements can be beneficial. SNMP as
currently defined in the RFCs can meet all of the requirements
listed in this document. Even the enhancement pointed to in
requirement 1 can be accomplished without any change to the
existing standards. Essentially it is a MIB design question.
L. Sanchez, K. McCloghrie, J. Saperia [page 25]
Internet Draft October 22, 1999
This is not to say that SNMP should remain static or that
improvements would not be beneficial. Here are recommendations
for the improvement to the Internet Standard Management Framework
which would benefit not only the area of configuration management,
but all areas served by the SNMP.
1. A new data type, any, which would allow any valid value to
be returned and its value would be conveyed by it's type
and value.
2. It would be nice to have people be members of multiple
groups at a time. Now a group has to be created which is
the union of all the security/access features desired for
a set of people. This is a minor change.
3. The 'set history' table as described in requirement 8.
This does not really require changes, just the
specification of a standard way to do this function.
4. Standardization of transactions at a higher level than
currently supported. There have been several studies on
how this could be achieved. A review of these should be
made and a single solution selected and standardized.
5. A more powerful way to specify 'aggregate' objects.
6. OID compression/Performance improvement. People have
noted for some time that the OID can represent a
significant amount of the total amount of data in an SNMP
communication. There have been several methods proposed
for improvement in this area as well. A study should be
made in this area as well and the best choice selected.
5.3 Cost of Implementation for SNMP/SMI
The costs for the suggested approach are to have been evaluated
with respect to cost and time of implementation, impact on
deployed systems and management staffs. Note that without change,
the SNMP framework currently meets all the requirements so there is
not incremental cost. Below is an investigation of costs for the
suggested improvements to the SNMP.
Taken in turn. The cost and time to implement these changes will
be small since the potential solutions have already been discussed
in some areas and prototypes of some are available. Their
incremental computational cost is small, indeed some will reduce
the computational and network cost of using SNMP. The biggest win
is in using the method proposed in recommendation 1 (see section
5.2). This eliminates the need for instance level sets to
configure much of a device and uses the framework we have today.
As a result of this approach, impact on deployed systems and
management staffs will be small.
L. Sanchez, K. McCloghrie, J. Saperia [page 26]
Internet Draft October 22, 1999
Acknowledgments
The authors thank Juergen Schoenwaelder for his contributions to
this document. The authors also thank Walter Weiss and Andrew
Smith for providing feedback to early versions of this
document. Finally, the authors thank the IESG for motivating and
supporting this work.
References
[Bra97] Bradner, S., "Key Words for use in RFCs to indicate
Requirement Levels", RFC2119, March 1997.
[COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan, R.,
and A. Sastry, "The COPS (Common Open Policy Service) Protocol",
draft-ietf-rap-cops-07.txt, work-in-progress, August 1999.
[RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol
(RSVP) Version 1 - Functional Specification", RFC 2205, September
1997.
[COPS-RSVP] Boyle, J., Cohen, R., Durham, D., Herzog, S., Rajan,
R., and A. Sastry, "COPS usage for RSVP",
draft-ietf-rap-cops-rsvp-05.txt, work-in-progress, June 1999.
[COPS-PROV] Reichmeyer, F., Herzog, S., Chan, K., Durham, D.,
Yavatkar, R., Gai, S., McCloghrie, K., and A. Smith, "COPS Usage
for Policy Provisioning", draft-ietf-rap-pr-00.txt,
work-in-progress, June 1999.
[PIB] Fine, M., McCloghrie, K., Seligson, J., Chan, K., Hahn, S.,
and A. Smith, "Quality of Service Policy Information Base",
draft- mfine-cops-pib-01.txt, work-in-progress, June 1999.
[SMIv2] 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.
[TCv2] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J.,
Rose, M. and S. Waldbusser, "Textual Conventions for SMIv2", STD
58, RFC 2579, April 1999.
[SNMP] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing SNMP Management Frameworks", RFC
2571, April 1999.
[SNMPTCP] Schoenwaelder, J., "SNMP-over-TCP Transport Mapping",
draft-irtf- nmrg-snmp-tcp-01.txt, work-in-progress, June 1999.
[SNMPCOMP] Schoenwaelder, J., "SNMP Compression",
draft-irtf-nmrg-snmp-compression-00.txt, work-in-progress, June
1999.
L. Sanchez, K. McCloghrie, J. Saperia [page 27]
Internet Draft October 22, 1999
[USEC] Blumenthal, U., and B. Wijnen, "User-based Security Model
(USM) for version 3 of the Simple Network Management Protocol
(SNMPv3)", RFC 2574, January 1998.
[VACM] Wijnen, B., Presuhn, R., and K. McCloghrie, "View-based
Access Control Model (VACM) for the Simple Network Management
Protocol (SNMP)", RFC 2575, January 1998.
Disclaimer
The views and specification here are those of the authors and are
not necessarily those of their employers. The authors and their
employers specifically disclaim responsibility for any problems
arising from correct or incorrect implementation or use of this
specification.
Copyright (C) The Internet Society (November 1997). 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.
L. Sanchez, K. McCloghrie, J. Saperia [page 28]
Internet Draft October 22, 1999
Author Information
Keith McCloghrie Jon Saperia
Cisco Systems, Inc. Independent Consultant
170 West Tasman Drive 174 Chapman Street
San Jose, CA 95134-1706 Watertown, MA 02472
USA USA
Email: kzm@cisco.com" Email: saperia@mediaone.net
Phone: 408-526-5260 Telephone: +1 (617) 744-1079
Luis A. Sanchez
BBN Technologies
10 Moulton Street
Cambridge, MA 02138
USA
Email: lsanchez@bbn.com
Telephone: +1 (617) 873-3351
L. Sanchez, K. McCloghrie, J. Saperia [page 29]