Re: How is party proliferation problem solved in SMP?

["Steven L. Waldbusser" <[e-mail]>]

Excerpts from mail: 22-Sep-92 How is party proliferation .. Michael L.
Kornegay@math (255)

> How is party proliferation problem solved in SMP?

> One of the slides in the SMP BOF of July 15, 1992 indicated this problem
> with the SNMP Administrative Model was solved with SMP.

A management station is typically made up of many different functional
units (graphers, pollers, maps, browsers, ...).  Often several instances
of each may be running on a single management station.

The protection from message reordering provided by the SNMP
Administrative Model demands that all PDU's to and from a particular
party be issued with clock/nonce values in sequence, or else the packets
out of sequence get dropped as unauthentic.  With this constraint, two
pollers on management station A polling agent B have three available
strategies for cooperation:

1.  Each poller uses a separate party at the agent and a separate party
at the MS.
2.  The pollers share parties, but use some locking scheme to ensure
that between them, they build and send PDU's in sequence.
3.  The pollers use some protocol to speak to a central protocol engine
that will issue SNMP PDU's on their behalf - this central protocol
engine has no difficulty meeting the constraint of sending PDU's in
sequence.

Solutions 2 and 3 are difficult due to added complexity (and therefore
decreased reliability) due to their distributed nature.  They also have
significant performance limitations.  In addition, they lack a standard
mechanism for communication of locking info (solution 2) or PDU requests
(solution 3).  This is especially important when the level of
application integration is at the menu level.  In other words, two
application from different vendors called from the menu of a platform
from yet a third vendor are unlikely to agree on either (1) a database
protocol to retrieve and lock the next clock/nonce values, or (2) an API
to send requests to an SNMP protocol engine to generate SNMP PDU's.

This leaves us with solution #1.  This solution does not require the
definition and implementation of a standard protocol among applications.
 Unfortunately, if N parties are needed to perform management between MS
A and agent B, and there are M instances of applications running on MS
A, M*N parties must be configured per MS/Agent pair.  The grand total
for a network is M*N*(#MSs)*(#agents).  This can grow to unmanageable
levels on a campus network.  Because the number of applications on a
platform, M, can easily be more than ten, it is a major contributing
factor to the large number of parties needed.  

SMP drops the protection from message reordering (retaining protection
from replay and adding reordering protection for SETs on an as-needed
basis).  This allows all of the applications on a platform to share the
same set of parties without sending PDU's out of sequence and thus
reduces the number of parties needed by an order of magnitude.



Steve