Network Working Group Keith McCloghrie
Internet Draft Michael Fine
Cisco Systems
22 October 1999
A Comparison of Policy Provisioning Protocols
draft-kzm-policy-protcomp-00.txt
Status of this Memo
This document is an Internet-Draft and is in full conformance with all
provisions of Section 10 of RFC2026 [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.
Distribution of this document is unlimited. Please send comments to
the RAP Working Group at rap@iphighway.com.
Copyright Notice
Copyright (C) The Internet Society (1999). All Rights Reserved.
Internet Draft Comparison of Policy Protocols Spetember 1999
1. Introduction
The IETF's RAP Working Group has almost completed its task of defining
COPS as a standards-track protocol for RSVP Admission Policy. The
WG's charter is now being extended to cover standardizing a policy
provisioning protocol, and the proposal put forward for consideration
by the WG is based on defining a new Client-type for COPS. This new
Client-type is intended to work in conjunction with the QoS Policy
objects and schema definitions being defined in two other IETF Working
Groups: Differentiated Services, and Policy. Before proceeding any
further, it has been requested that a comparison be undertaken as to
why COPS is better suited to this than a (modified if necessary)
version of SNMP. This memo attempts to document such a comparison.
2. Background Information on QoS Policy
Several years ago, the IETF took a step towards standardizing Quality
of Service (QoS) by defining Integrated Services [INTSERV]. A part of
that effort was to define RSVP [RSVP] as a standardized QoS signaling
protocol. When RSVP is used, each router participating in the
signaling can independently allocate local resources to an individual
RSVP session, or reject a request when local resources are exhausted.
However, local information is insufficient to make a decision to admit
or reject an RSVP request based on network-wide policy. Such policy
might be static, or alternatively, might depend on dynamic network-
wide state information. With RSVP signaling, the policy does not need
to be distributed to each and every router; rather, both the policy
and any network-wide state upon which the policy might depend, can be
kept at a (few) centralized Policy Server location(s); the receipt of
RSVP signaling messages provides the opportunity for a particular
router to ask its Policy Server for an admit/reject decision for that
RSVP session. It also provides the opportunity for the Policy Server
to respond with not only a decision, but also to specify other policy-
driven actions (e.g., modifying or augmenting the policy information
contained in the RSVP messages).
The use of COPS [COPS] as the protocol by which a router (the Policy
Enforcement Point, or PEP) queries a central Policy Server (the Policy
Decision Point, or PDP) on receipt of RSVP messages has been
successfully tested in Interoperability Tests involving multiple
vendors, and the specifications are currently under review by the IESG
for progression to Proposed Internet Standard status.
A subsequent IETF effort towards standardizing QoS was to define
Differentiated Services [DSARCH]. In its basic form, DiffServ
McCloghrie & Fine [Page 2]
Internet Draft Comparison of Policy Protocols Spetember 1999
specifies no signaling protocol. Rather, each packet gets marked with
a DiffServ Codepoint (DSCP) and it is the DSCP which then determines
the QoS treatment (the Per Hop Behaviour) which a packet receives. In
this situation, a router does not have the opportunity to ask the
centralized Policy Server when it receives the signaling message,
since the packets arrive without being preceded by a signaling
message. Therefore, the policy to be applied must be provisioned by
the Policy Server. Note that such provisioning is not necessarily
static, but may vary depending upon dynamic network-wide state
(similar to RSVP policy).
The latest direction of IETF WGs includes the identification of
scenarios and the definition of mechanisms whereby the two different
QoS schemes (Integrated Services and Differentiated Services) can be
used in tandem. One proposal involves how the path across the network
of a particular session can include one or more domains of Integrated
Services, as well as one or more domains of Differentiated Services
[DSRSVP]. A related proposal involves using RSVP signaling as the
means by which the specific DSCP value to be used in packets of that
session can be communicated back towards the source [DCLASS]. Another
proposes that both RSVP and DiffServ be used for the same sessions in
the same domain: RSVP in the control plane for the application of
admission control policy, and DiffServ in the data plane for
specifying how a router treat the individual packets [DSRSVP]. A
conclusion to be drawn from these proposals is that it is increasingly
likely that there will be domains having a need for both RSVP-based
policy as well as DiffServ-based policy, and that these two parallel
types of policies will need to be consistent and coordinated, i.e.,
administered by the same set of Policy Servers.
Thus, in addition to being RSVP's policy protocol, COPS is also being
proposed as the protocol for provisioning DiffServ policy [COPS-PROV],
since using it for both facilitates the required consistency and
coordination.
3. COPS
3.1. COPS Client-Types
COPS has a multiplexing mechanism whereby a single TCP connection can
be used for multiple independent client-types. A client-type is
defined for RSVP in [COPS-RSVP].
A different client-type is defined in [COPS-PROV] for provisioning.
This client-type defines the concept of a Policy Information Base
McCloghrie & Fine [Page 3]
Internet Draft Comparison of Policy Protocols Spetember 1999
(PIB) as the means by which to convey policy data. The first PIB
[QOSPIB] is for a subset of QoS Policy which roughly equates to
DiffServ.
3.2. The Structure of Policy Information and the PIB
Much like SNMP calls for a structure of management information and a
Management Information Base of concrete management objects, COPS for
provisioning calls for a structure of policy information (SoPI) and a
Policy Information Base of concrete policy objects. SoPI and PIBs are
intentionally like SMI and MIBs, in order to leverage knowledge of and
experience with MIBs, but with a few intentional differences.
- PIBs are aimed at the definition of "higher-level" policy, e.g.,
network-wide policy, rather than the device-specific
configuration and monitoring at which MIBs are aimed.
- PIBs are optimized for bulk configuration of multi-attribute
objects; this is a big win.
3.3. Exclusive Access by the PDP
[COPS-PROV] specifies that one and only one PDP (Policy Server)
controls a device (for a specific set of PIBs) at any one time.
Giving one PDP exclusive access avoids SNMP's need to provide
synchronization mechanisms to protect against multiple SNMP managers
trying to access the same MIB objects at the same time. For example,
this is the major reason why read-create tables in MIBs always have a
RowStatus object. In contrast, PIBs for use with COPS do not need
RowStatus to solve the multi-manager problem because only one PDP can
be accessing the PIB at any one time.
Giving one PDP exclusive access also means that, during the time when
COPS for Provisioning is enabled for a particular type of policy, SNMP
and/or CLI are disabled from modifying any related configuration in
the device. Of course, if configuration via SNMP/CLI becomes
necessary, then COPS for Provisioning can be disabled (via SNMP or the
CLI). Note that the PDP will recognize this because the COPS
connection will be torn down.
An application, which configures a device using SNMP, can never be
sure that the configuration it set several minutes/hours/days ago is
still in effect, because it's possible that some other management
application (or human) might have modified the configuration more
recently. So, a prudent management application will periodically re-
McCloghrie & Fine [Page 4]
Internet Draft Comparison of Policy Protocols Spetember 1999
check that the configuration is unchanged. This need for re-checking
is not specific to SNMP, but it is similarly required when
configuration is done via CLI. In contrast, exclusive access by a
single PDP avoids the uncertainity and consequent need for re-checking
that the device's configuration has not been tampered with.
As well as not needing RowStatus, PIBs do not need the spin-locks
(TestAndIncrement objects) which are included in some MIBs. This not
only makes a PIB simpler, but it also reduces the complexity of the
PDP's code as compared to a SNMP manager. For example, the following
procedure is specified in [USEC] by which a manager creates a new
(private and authenticated) user:
1) GET(usmUserSpinLock.0) and save in sValue.
2) SET(usmUserSpinLock.0=sValue,
usmUserCloneFrom=templateUser,
usmUserStatus=createAndWait)
You should use a template user to clone from
which has the proper auth/priv protocol defined.
3) generate the keyChange value based on the secret
privKey of the clone-from user and the secret key
to be used for the new user. Let us call this pkcValue.
4) GET(usmUserSpinLock.0) and save in sValue.
5) SET(usmUserSpinLock.0=sValue,
usmUserPrivKeyChange=pkcValue
usmUserPublic=randomValue1)
6) GET(usmUserPulic) and check it has randomValue1.
If not, repeat steps 4-6.
8) generate the keyChange value based on the secret
authKey of the clone-from user and the secret key
to be used for the new user. Let us call this akcValue.
9) GET(usmUserSpinLock.0) and save in sValue.
10) SET(usmUserSpinLock.0=sValue,
usmUserAuthKeyChange=akcValue
usmUserPublic=randomValue2)
11) GET(usmUserPulic) and check it has randomValue2.
If not, repeat steps 9-11.
13) SET(usmUserStatus=active)
Notice that without the need to use usmUserSpinLock, the procedure
would have 5 fewer steps, would have no loops, and three less values
to be set. In fact, COPS would recommend the whole procedure be done
in a single DEC message using a single OID and a single vector of
values.
McCloghrie & Fine [Page 5]
Internet Draft Comparison of Policy Protocols Spetember 1999
3.4. Different Design Philosophy compared to SNMP
Many of the SNMP protocol's design choices were based on the need for
its use in debugging network problems (see section 6 of [RFC1270]).
In contrast, the design choices for the COPS protocol have always
assumed that the network is up and working. Thus, SNMP runs over UDP,
whereas COPS runs over TCP. This choice of UDP versus TCP is one
example of the difference in design philosophies.
3.5. COPS Takes Advantage of TCP
The use of TCP allows COPS to enjoy the use of large, and therefore
more efficient messages (e.g., up to 64KB for each COPS object)
spanning many TCP segments, without it needing to be aware of Path
MTU. In contrast, SNMP-over-UDP requires an implementation to support
a minimum of 484 bytes as its largest message size. Many SNMP agents
support larger maximum message sizes than 484, but messages must still
fit into one IP packet, in order to avoid the degradation in
reliability of IP fragmentation. Thus, the use of SNMP messages
larger than 1500 bytes is rare.
Like SNMP, each COPS message is a "transaction", meaning that all
policies contained in one message must be successfully installed, or
none of them are. However, COPS's much larger messages allow much
more policy to be created, deleted and/or modified in one transaction,
than would be possible with SNMP. With SNMP's limited message size,
only small updates can be made atomically which could result in
windows of time where the installed policy is inconsistent with
itself.
Another consequence of SNMP's small message size is the potential that
a complete row of a MIB table might not fit into one message. For
example, a row containing six objects, each having a 255-byte long
value, will overflow a 1500 byte message; and it takes only two such
objects to overflow a 484 byte message. COPS's use of larger messages
ensures that a whole row will fit into a single message. This allows
COPS to create new rows/modify existing rows atomically by including
the whole row at once, and in fact COPS only allows access to whole
rows, not to the individual columnar objects within them. In
contrast, SNMP must allow the option of creating/modifying rows by
"dribbling" the individual values into the agent, one or more per
message.
This potential for dribbled creation of an SNMP read-create table can
result in many corner/error cases which have to be catered for in a
McCloghrie & Fine [Page 6]
Internet Draft Comparison of Policy Protocols Spetember 1999
MIB implementation. The number of such corner/error cases is
significantly reduced by the COPS requirement of atomic access to a
row. Thus, support for a PIB table takes less code, and is easier and
quicker to implement and test.
COPS also gains another advantage from requiring atomic access to
whole rows. Since a whole row must be included in a COPS message,
there is no need to include the name of each and every columnar object
instance being access; instead, only the name of the row needs to be
specified. 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.
3.6. SNMP over TCP
Proposals to run SNMP over TCP have been put forward several times in
the past, and each time have sparked debate. None of these past
proposals were accepted enough to be published as RFCs. However, the
result of one such debate is documented within [RFC1270].
The latest proposal is contained in [SNMPTCP]. It provides the
interesting combination of using SNMP over UDP and TCP at the same
time, with the sender of any initiating (i.e., not a Response) SNMP
message choosing which transport protocol to use. Either side is
allowed to tear down connections at any time if their resources are
scarce, and non-initiators may refuse TCP connections whenever they
wish. [As an aside: two statements in [SNMPTCP] would seem to be
questionable: a) it's not clear why UDP necessarily increases latency
due to small packet-sizes; and b) as RFC 1270 states, (some form of)
retransmissions at the application level are needed even over TCP.]
Note, however, this latest proposal can not take full advantage of the
use of TCP (e.g., the atomic access to rows described above), because
the MIBs must still be able to be used with SNMP-over-UDP. Nor can it
make use of only one OID for a whole row (and the resultant savings in
message sizes), since it uses the same SNMP message format over both
TCP and UDP.
McCloghrie & Fine [Page 7]
Internet Draft Comparison of Policy Protocols Spetember 1999
3.7. COPS over TCP (Revisited)
By way of contrast, the use of TCP is fundamental to the way COPS for
Provisioning works. COPS's Keep-alive operation code is used to
ensure that at least one message is exchanged between the PEP and PDP
within a timer value (specified by the PDP). (Note that these keep-
alives serve as COPS's form of retransmission at the application-
layer, see quote from RFC 1270 above.) 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. If that
connection attempt also fails (and while the PEP continues attempting
to connect to both the primary and secondary), all policy which was
provisioned during the previous COPS session is subject to an expiry
timeout (set as part of the policy). That is, when the expiry timeout
occurs before a COPS connection is re-established, the current
policies expire with it. Thus, the policy itself is volatile and
dependent upon the current state of the COPS TCP connection. For some
policies, it is useful to have an infinite expiration time (which
never expires); other policies may be ephemeral.
Note well that this expiry timer has no effect while the COPS
connection is established. Obviously, while the COPS connection is
established, the PDP can delete policies as and when they should
expire. It is only when the COPS connection is lost such that the PDP
cannot delete expiring policies, that use of the expiry timer is
needed.
Again, SNMP is different: SNMP itself does not specify whether the
creation or modification of values is volatile or non-volatile;
instead, it leaves such specification to be part of the definition of
MIB objects. One reason for this is that SNMP sets are used for both
the setting of parameter values (which might normally be non-
volatile), as well as a way of initiating actions (which of course are
volatile).
3.8. Modifying Message Formats
SNMP has a very stable message format, which is not easily changed.
Specifically, changes in this message format are not warranted for
small gains in functionality, particularly if such changes were to
alter the design parameters of the protocol. In fact, the last change
in SNMP message format was to replace the uniquely-formatted SNMPv1
trap message with the SNMPv2_trap message having a format identical to
all the other SNMP messages; this change was made specifically to make
all the message formats the same (i.e., the only difference in ASN.1
McCloghrie & Fine [Page 8]
Internet Draft Comparison of Policy Protocols Spetember 1999
format definitions is that the Response PDU uses two integers for
error status and index, whereas the GetBulk PDU uses the same two
integers for non-repeaters and max-repetitions).
In contrast, the COPS message format has only recently become stable,
and some aspects of the message format are specific to individual
client-types. Further, different COPS message have different sets of
objects in them, and all values in a COPS message (except those in the
message header) are formatted using a TLV format, such that new types
can be specified in the future. That is, it is only the COPS message
header which is common to all COPS messages.
Thus, COPS for Provisioning is at a point in time where changes in
message format can be made for small but useful gains. An example of
this is the inclusion in [COPS-PROV] messages of multiple error-codes,
potentially one per individual row. Indeed, the values of these
error-codes can be specific to the particular row's definition. That
is, they can be specified as part of the definitions in a PIB, with
new error-codes being defined for new PIB objects. In contrast, the
SNMP message format has a single error-code, whose values are
specified as part of the protocol-specification, and so can not be
specific to individual objects, and new ones can not be specified in
MIBs. (Note also that one of SNMP's design parameters, which is a
fundamental aspect of many agent implementations, is that the
varbindlist in an SNMP SetRequest is returned unchanged in the
Response to that SetRequest; this design choice was made so that
simple agents could modify a received message and send it as the
Response, all in the same buffer.)
Fundamentally, COPS is an extensible protocol, so it will always be
simpler to add functionality to COPS than SNMP. This will enable COPS
to integrate the outsourcing and proxied functionality which will be
required by AAA applications and bandwidth brokers.
3.9. Initiation by the PEP
For the purpose of obtaining policy, it is better for the device to
locate a PDP, rather than for a PDP to try and find devices that need
their policies. Initiation by the PEP works particularly well in the
event of PDP failure with the primary/secondary mechanism (see above).
It also works well in the event of a PEP reboot, in that the PEP can
initiate communication as soon as it is ready rather than having to
wait for the SNMP management station to poll it.
McCloghrie & Fine [Page 9]
Internet Draft Comparison of Policy Protocols Spetember 1999
In contrast, SNMP is designed such that multiple management stations
can monitor a device as and when they need to, and hence it is each
management station that must initiate SNMP communication. It is also
not clear how a "secondary" SNMP management station would constantly
monitor for a failure of communication between the primary and each
device. Thus, the (normal) SNMP model does not seem to lend itself to
initiation by the PEP.
It has been suggested an alternative way to get initiation by the PEP
using SNMP would be to have the device (e.g., a router) contain a
command generator [SNMPARCH]. While routers do not usually contain
command generators, it is possible that they could. However, the use
of SNMP's get-type requests would be a very awkward means of obtaining
only that subset of policies which are relevant to this router; such
requests might well need an SQL-like query capability (or the similar
searching capabilities of LDAP which some PDPs use to extract policies
out of a Directory.)
With COPS, initiation by the PEP is achieved without the PEP needing
to issue any search queries. Instead, on establishment of the TCP
connection, the PEP sends an indication of its capabilities and status
to the PDP. It then asks the PDP to send it the relevant policies.
3.10. Deleting Policy
COPS for Provisioning includes a mechanism in the protocol for
specifying whether the policies in a DEC message are being installed
or deleted. The deletion capability can remove a single row (called a
"policy rule instance" in COPS), or all rows of a table (all "policy
rule instances" of a "policy rule class").
SNMP can have a similar capability by having MIB objects which can be
set to cause various instances to be deleted: RowStatus is common for
deleting a particular row; objects to delete all rows in a table are
not so common.
4. PIBs
4.1. Syntactic Differences
PIBs are intentionally similar to MIBs, in order to leverage knowledge
of and experience with MIBs. The major syntactic differences are
designed to accommodate the differences in COPS versus SNMP.
McCloghrie & Fine [Page 10]
Internet Draft Comparison of Policy Protocols Spetember 1999
- a PIB module begins with keyword PIB-DEFINITIONS rather than the
keyword DEFINITIONS, to identify it as a PIB rather than a MIB.
This will avoid the confusion which was common when MIBs were
used with ATM's ILMI protocol [ILMI].
- a POLICY-ACCESS clause in a PIB replaces the MAX-ACCESS clause in
a MIB. This accommodates the different granularity of access
(row versus columnar object), and the different message types in
the two protocols. The POLICY-ACCESS clause is specified only on
a PIB class (an SNMP "table"), whereas SNMP's MAX-ACCESS is
specified on all MIB objects including columnar objects. The use
of "notify" in the POLICY-ACCESS clause signifies a capability or
status class whose vector of values must be passed in the initial
REQ and when synchronizing state; the use of "install" signifies
a class into which the PDP can download policies via a DEC
message.
- a PIB includes an additional clause allowing per-class install
errors to be specified.
- PIBs do not allow scalar objects (since atomic access to rows
would cause complications in accessing scalars). Of course, MIBs
for use in Policy Provisioning could be also be defined without
scalars, but then there would be two types of MIBs - those that
could be used with Policy Provisioning, and those that could not;
this would no doubt cause problems through customers trying to
use the ones that could not for Policy Provisioning.
- PIBs are a little simpler than MIBs, because they do not need to
include multi-manager synchronization objects or objects for
deleting one/more/all rows, such as RowStatus, spin-locks, etc.,
nor do they need to specify procedures for how these additional
objects are used.
Note that at this point in time, the specification of the SoPI is not
yet as complete as will be needed for it to be standardardized. Work
is ongoing to rectify this.
4.2. Semantic Differences
At the semantic level, PIBs are aimed at the definition of abstracted,
or "higher-level" policy, e.g., network-wide policy. Multiple types
of higher-level/network-wide abstractions are expected to be defined
in the future.
McCloghrie & Fine [Page 11]
Internet Draft Comparison of Policy Protocols Spetember 1999
The specific example of this defined in the first PIB [QOSPIB] is the
granularity at which policy configuration is specified for network
interfaces. Specifically, this first PIB uses the concept of "role"
applied to interfaces. This concept is explained in [POLICYTERMS] as
follows:
Roles can be used to identify specific objects (e.g., device
interfaces) that should be configured in a common manner using
one or more policies. These interfaces may be defined by the
purpose that they play in the network (e.g., "edge" vs.
"backbone"), the characteristics of the object (e.g., frame relay
interfaces require a different configuration than ATM
interfaces), or other factors.
Roles provide a powerful abstraction mechanism. They enable new
policies to be specified for a single role, and have them applied
to the devices that use that role. This is much more efficient
and less error prone than having to specify a new policy for each
and every individual network component. In addition, it enables
policies to be modified at the (single) role level, instead of
having to search for every occurrence of every policy and
individually modify the policy. But most importantly, it enables
the devices and their interfaces to be abstracted from the Policy
Server. In other words, the Policy Server no longer needs to have
intimate knowledge of each and every device (let alone each and
every device interface!) in the network.
All interface-related policies in the PIB are defined, not per
individual interface, but on a per-role basis. So, PIBs do not have
the interface-naming issues of the [IF-MIB], where the original
concept of physical interfaces has been expanded with logical
interfaces and dynamically-created/deleted interfaces, to the extent
that three different ways of naming interfaces are needed (ifIndex,
ifName and ifAlias).
In contrast, an SNMP MIB is naturally aimed at device-specific
configuration and monitoring. Whereas the same policies can be
applied to two similar (but not identical) interfaces having the same
role, the MIB must allow each interface to have different status,
different statistics and different low-level configuration.
Therefore, a MIB is needed which contains per-interface information
(normally indexed by ifIndex), irrespective of whether roles are used
to define policies.
McCloghrie & Fine [Page 12]
Internet Draft Comparison of Policy Protocols Spetember 1999
4.3. SNMP and MIBs are Still Needed
It is worth repeating for the sake of emphasis that the use of COPS
and PIBs does not obviate the need for SNMP, which is still needed for
- monitoring, which is not a function of the COPS protocol, and
- setting local configuration.
As an example of local configuration, see the COPS Client MIB, [COPS-
MIB] which has a read-create table for configuring the addresses of
primary/secondary/etc. PDPs.
5. What-if Questions
5.1. Could SNMP be Modified ?
One might ask: why couldn't SNMP be modified to have the same
functionalities as are described for COPS ? The answer is that with
sufficient changes, it could. However, it would no longer be the same
protocol, and this new different (and more complex) protocol would
need to be an addition (not a replacement) for the existing protocol
which currently (and successfully) provides the network monitoring
functions of the Internet.
As well as the differences, there would, of course, be similarities.
The code-sharing due to these similarities would seem to be the only
advantage of such major modifications to the SNMP protocol. However,
implementations of COPS for Provisioning would also result in code-
sharing, since some of the COPS design choices are specifically aimed
at this:
- the similarity of PIBs to MIBs,
- the use of OIDs for naming rows in PIBs,
- the use of the BER encoding for OID and data values in COPS
messages.
This together with the code sharing between the multiple COPS Client-
types could well produce a larger amount of code-sharing.
Further, there would be at least one disadvantage of having two
different protocols both being called SNMP, fulfilling different
McCloghrie & Fine [Page 13]
Internet Draft Comparison of Policy Protocols Spetember 1999
functions - it would result in significant confusion in the Internet
community. This is a huge issue; there is already so much fear,
uncertainty and doubt with respect to SNMP evolution that more
confusion would be a "real killer".
5.2. Could Roles be used in MIBs ?
One might ask: why couldn't roles be used in MIBs ? The answer is
that they could, but to do so would result in having two different
MIBs at different granularities. This is no better than having a MIB
and a PIB at different granularities. At least with a MIB and a PIB,
it is clear that one of them (and which one of them) is specifically
defined to be at a higher-level for use by a protocol optimized for
bulk configuration of multi-attribute objects.
Indeed, [QOSPIB] defines a mechanism for converting a PIB into a MIB.
The derived MIB is specified as read-only, with the primary intention
of use with existing MIB tools, and/or use by SNMP in monitoring the
policies downloaded by COPS. Note that information is lost in the
process of converting a PIB into a MIB, i.e., the conversion is not
invertable to creating a PIB from a MIB. Nevertheless, all the policy
configured in the PIB by COPS is accessible by SNMP via the derived
MIB.
McCloghrie & Fine [Page 14]
Internet Draft Comparison of Policy Protocols Spetember 1999
6. Security Considerations
Security mechanisms are defined for both SNMP (in [USEC] and [VACM]),
and for COPS (in [COPS]). SNMP's mechanisms were defined for
exclusive use by SNMP; this design decision was based (in part) on:
- SNMP must not rely on the mechanisms it is trying to fix; for
example, from [RFC1270]:
... SNMP must continue to operate (if at all possible) when
the network is operating at its worst. For other
applications, such as Telnet or FTP, the user can always "try
again later" if the network is operating poorly. On the other
hand, the major purpose of a network management protocol is to
fix the network when it is operating poorly so the "try again
later" strategy is useless.
- IP-only mechanisms were insufficient, because of existing usage
of SNMP over multiple network-layer protocols: not only IP, but
AppleTalk, IPX, etc. as well.
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 authentication, 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:
- 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.).
McCloghrie & Fine [Page 15]
Internet Draft Comparison of Policy Protocols Spetember 1999
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.
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. Acknowledgements
The authors thank the following individuals who provided comments on
this document: David Durham, Silvano Gai, and John Seligson.
8. Intellectual Property
The IETF takes no position regarding the validity or scope of any
intellectual property or other rights that might be claimed to pertain
to the implementation or use of the technology described in this
document or the extent to which any license under such rights might or
might not be available; neither does it represent that it has made any
effort to identify any such rights. Information on the IETF's
procedures with respect to rights in standards-track and standards-
related documentation can be found in BCP-11. Copies of claims of
rights made available for publication and any assurances of licenses
to be made available, or the result of an attempt made to obtain a
general license or permission for the use of such proprietary rights
by implementors or users of this specification can be obtained from
the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
McCloghrie & Fine [Page 16]
Internet Draft Comparison of Policy Protocols Spetember 1999
Director.
9. References
[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.
[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.
[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-MIB]
Smith, A., Partain, D., and J. Seligson, "Definitions of Managed
Objects for Common Open Policy Service (COPS) Protocol Clients",
draft-ietf-rap-cops-client-mib-00.txt, work-in-progress, June
1999.
[DCLASS]
Bernet, Y., "Usage and Format of the DCLASS Object With RSVP
Signaling", draft-ietf-issll-dclass-00.txt, work-in-progress,
June 1999.
[DSARCH]
Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W.
Weiss, "An Architecture for Differentiated Service", RFC 2475,
December 1998.
[DSRSVP]
Bernet, Y., Yavatkar, R., Ford, P., Baker, F., Zhang, L., Speer,
M., Braden, R., and B. Davie, "Integrated Services Operation Over
Diffserv Networks", draft-ietf-issll-diffserv-rsvp-02.txt, work-
in-progress, June 1999.
[IF-MIB]
McCloghrie, K., and F. Kastenholz, "The Interfaces Group MIB
McCloghrie & Fine [Page 17]
Internet Draft Comparison of Policy Protocols Spetember 1999
using SMIv2", RFC 2233, November 1997.
[ILMI]
ATM Forum Technical Committee, "Integrated Local Management
Interface (ILMI) Specification", Version 4.0, af-ilmi-0065.000,
September 1996.
[INTSERV].
Braden, R., Clark, D., and S. Shenker, "Integrated Services in
the Internet Architecture: an Overview", RFC 1633, June 1994.
[POLICYTERMS]
Strassner, J., and E. Ellesson, "Terminology for describing
network policy and service", draft-ietf-policy-terms-00.txt,
work-in-progress, June 1999.
[QOSPIB]
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.
[RFC1270]
Kastenholz, F., "SNMP Communications Services", RFC 1270, October
1991.
[RFC2026]
Bradner, S., "The Internet Standards Process -- Revision 3", RFC
2026, BCP 9, October 1996.
[RSVP]
Braden, R., Zhang, L., Berson, S., Herzog, S., and S. Jamin,
"Resource ReSerVation Protocol (RSVP) -- Version 1 Functional
Specification", RFC 2205, September 1997.
[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.
McCloghrie & Fine [Page 18]
Internet Draft Comparison of Policy Protocols Spetember 1999
[CONFv2]
McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., Rose,
M. and S. Waldbusser, "Conformance Statements for SMIv2", STD
58, RFC 2580, April 1999.
[SNMPARCH]
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.
[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.
10. Authors' Addresses
Keith McCloghrie
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: 408-526-5260
Email: kzm@cisco.com"
Michael Fine
Cisco Systems, Inc.
170 West Tasman Drive
San Jose, CA 95134-1706
Phone: 408-527-8218
Email: mfine@cisco.com"
McCloghrie & Fine [Page 19]
Internet Draft Comparison of Policy Protocols Spetember 1999
11. Full Copyright Statement
Copyright (C) The Internet Society (1999). 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."
McCloghrie & Fine [Page 20]
Internet Draft Comparison of Policy Protocols Spetember 1999
Table of Contents
1 Introduction .................................................. 2
2 Background Information on QoS Policy .......................... 2
3 COPS .......................................................... 3
3.1 COPS Client-Types ........................................... 3
3.2 The Structure of Policy Information and the PIB ............. 4
3.3 Exclusive Access by the PDP ................................. 4
3.4 Different Design Philosophy compared to SNMP ................ 6
3.5 COPS Takes Advantage of TCP ................................. 6
3.6 SNMP over TCP ............................................... 7
3.7 COPS over TCP (Revisited) ................................... 8
3.8 Modifying Message Formats ................................... 8
3.9 Initiation by the PEP ....................................... 9
3.10 Deleting Policy ............................................ 10
4 PIBs .......................................................... 10
4.1 Syntactic Differences ....................................... 10
4.2 Semantic Differences ........................................ 11
4.3 SNMP and MIBs are Still Needed .............................. 13
5 What-if Questions ............................................. 13
5.1 Could SNMP be Modified ? ................................... 13
5.2 Could Roles be used in MIBs ? .............................. 14
6 Security Considerations ....................................... 15
7 Acknowledgements .............................................. 16
8 Intellectual Property ......................................... 16
9 References .................................................... 17
10 Authors' Addresses ........................................... 19
11 Full Copyright Statement ..................................... 20
McCloghrie & Fine [Page 21]