| T.R | Title | User | Personal
Name | Date | Lines |
|---|
| 1987.1 | Best answer available | TOOK::MATTHEWS | | Tue Dec 24 1991 08:57 | 71 |
| The primary consideration is the protocol. If they are dealing with
existing agents that are not SNMP, OSI CMIP, or DEC CMIP (which
isn't likely) then they have to write a minimal AM just for
communications.
If they are actually developing the agent and have the choice of
the protocol, then SNMP is probably their best bet. It does have
some restrictions that they have to live with. The restrictions
are more in the SMI (structure of management information) than
in the protocol itself. If the process they want to model can
be modeled with the IETF SMI then SNMP is a good choice.
SNMP provides fairly primitive services (SHOW, SET, and TRAP) but
they provide generally acceptable levels of service. The SMI is
limited in that it is rather flat and is very limited in dealing
with complex structures.
The basic problems are not apparent until you want to develop
applications (ie. FMs). At the basic access level you can do anything
with SNMP that you need to. The problem is when you want to simplify
the obect at the UI, it takes a lot of code and effort because the
SMI is so primitive. If your application has a structure that is
intuitive to the object, it is likely not to fit the SMI. That means
you write a lot of glue software to get access via SNMP that could
be reduced with a custom AM.
That is why most of the SNMP management systems UIs are not intuitive.
The SNMP SMI forces operators to know about the SMI and forces
implementers to abandon intuitive models of applications and
processes because they do not fit the SMI.
If you really want to understand this area, pick an object that has
some complexity. Read the Simple Book by Marshall Rose. There are
only 50 or so pages of tutorial material. The majority of the book
is appendices. Now try to define the MIB for your object. When you
get through compare your conceptual model to the MIB and note all
the compromises you made. Now imagine building management applications
or a UI that provides the user with your conceptual model. You have
to provide all the glue software on your workstation to provide a
reasonable model.
If you had the ability to develop a new access method between
the manager and the agent, you could reduce the complexity of the
manager and the agent software POTENTIALLY. Now we are at the
root of the SIMPLE MODEL. It is simple for the access method but
at a cost. For many complex applications it makes the application
and the agent more complex than it has to be. So it is like the
bag or dough. You squeeze it at the access method level and force
all the dough into the application and/or agent.
You are a winner for simple objects and a majority of the things
we want to model are simple so that is why SNMP is such a powerful
tool and has unlocked a new area of growth. However, for complex
objects it creates as many problems as it solves.
I hope this provides you with an insight into the issue you raised.
If you are looking for a cookbook list of things to tell a customer,
forget it. They will not be convinced until they have gone through
the process of modelling a complex object with the IETF SMI. The
list will sound like a bunch of excuses until they do it once and
have to live with the results.
Save yourself a lot of grief. Recommend SNMP now. IF they come
back a year from now, it will be because they have learned and they
have a more complex problem. Then we can recommend CMIP rather than
a custom protocol. For most objects, they will be satisfied with
SNMP and learn to live with its ugly features. Who knows they may
actually believe Marshall Rose's bullshit and become devout SNMP
bigots.
wally
|
| 1987.2 | THANK YOU!!! | MUTTON::LAMB | Peter Lamb - GSG Santa Clara | Fri Dec 27 1991 16:20 | 12 |
| Nice work! And, thanks for the quick answer!
Have you ever seen anything like this written up into a white paper??
I'm thinking about taking your reply and rewording it a little (like taking
out the b word...) to make it suitable for giving to a customer. If anyone
has already seen something like this please let me know... Otherwise I'll
assume it doesn't exist and post my version here.
Thanks again!!
Peter
|
| 1987.3 | White Paper Offered | MUTTON::LAMB | Peter Lamb - GSG Santa Clara | Mon Jan 06 1992 17:46 | 26 |
| Hello,
I have taken the information offered by Wally Matthews (offered in .1 of this
note and put it into a "White Paper" which I will make available to anyone
that needs it.
Both the Postscript version and the DECwrite .DOC file can be found on
the default decnet directory on node MUTTON.
Dir MUTTON""::DECmcc*.* returns the following...
Directory MUTTON""::SYS$SPECIFIC:[FAL$SERVER]
DECMCC_CUSTOM_AM.DOC;1 DECMCC_CUSTOM_AM.PS;1
Total of 2 files.
Enjoy!!
Regards,
Peter Lamb
P.S. If anyone has any recommendations or suggestions for improvements
please let me know. I believe the paper is reasonably accurate but please
don't hesitate to let me know if I have some grave error in it.
|
| 1987.4 | Text Only version of White Paper | MUTTON::LAMB | Peter Lamb - GSG Santa Clara | Tue Jan 07 1992 11:52 | 307 |
| To whom it may concern...
Included below is an ascii version (pictures removed) version of the white
paper available on MUTTON"":: which discusses Custom Access Modules vs
SNMP MIB extensions.
DECmcc - Application Management
Developing Custom Access Modules
vs
SNMP Private MIB Extensions
for Application Management
A White Paper
Written By:
Peter Lamb & Glen Sitz
Digital Equipment Corporation
January 6, 1992
Network Management
Custom Access Modules vs SNMP Private MIB Extensions
Introduction
This paper will briefly discuss some of the considerations of
when to use a custom DECmcc Access Module and Management Agent
vs when it may make more sense to write an SNMP 1 MIB2 extension
to support the management of "higher level" computer
applications (such as "Mission Critical" Process Control
systems, Financial Applications, etc.) over an extended network.
Protocol
A primary consideration is which protocol is being run on the
remote system which will be the target of Application
Management. For example, if the remote system is only capable
of running DECnet or even an older version of TCP/IP that
doesn't support SNMP, it is probably unrealistic to consider
attempting to manage this system using SNMP and private MIB
extensions. To do this, one would have to first commit
significant resources simply to write the lower level
communications access routines.
Management Complexity
Providing the system to be managed:
� Supports TCP/IP.
� Supports SNMP and has an SNMP Agent..
� The application management requirements are fairly simple
and straight forward; i.e., they can be met with simple
set, show & trap directives.
Using a private MIB extension and SNMP may be the easiest way to
proceed. Many manageable candidates meet this criteria. This
is why SNMP is often used as a management protocol.
If on the other hand, the management requirements are more
complex or are in anyway hierarchical in nature, the rather flat
nature of the SMI3 will seriously limit the capabilities of the
MIB extension that is developed. These limitations of the SMI
will also make it much more difficult to develop the MIB
extension (again, providing the object to be managed is fairly
complex) and will also contribute to making the overall
management interface counter-intuitive and thus difficult to
use.
SNMP: Simple Network Management Protocol as defined by RFC 1156
MIB: Management Information Base as defined by RFC 1157 and 1158
SMI: Structure of Management Information as defined by RFC 1155
In the words of one of our software engineers who has done both
(written custom MIBs and DECmcc access modules), the basic
problems are not apparent until you attempt to develop the
applications (i.e., the things that will actually manage the
remote agents). At the basic access level, you can do anything
with SNMP that you need to. The problem is when you want to
simplify the object at the UI, it takes a lot of code and effort
because the SMI is so primitive. If your application has a
structure that is intuitive to the object, it is likely not to
fit the SMI. That means you write a lot of glue software to get
access via SNMP that could be reduced with a custom Access
Module."
Possible Scenarios
Non-custom Example
It is possible to determine whether or not a particular node is
"alive" without writing any custom code simply by querying or
"pinging" over the network with DECmcc. This can be accomplished
in at least three different ways. These are...
1. Using the DECnet IV access module to communicate with the
embedded NCP agent present on all DECnet phase IV nodes
(pictured below).
2. Using the SNMP access module to communicate with the TCP/IP
protocol stack present on any TCP/IP systems on the network
(regardless of whether they are running SNMP).
3. Using the Ethernet access module to communicate directly
with the remote system's Ethernet controller to determine
whether it is "alive" and communicating.
For an illustration of the DECnet Phase IV example, please see
figure 1 below.
Management System
DECmcc
Director
Remote System
Presentation Module
DECnet +
Functional Module
Management NCP Operating System
DECnet Phase IV Protocol
Access Module
Figure 1
Custom SNMP MIB Extension
Illustrated in the figure below is an example of the mechanism
required to manage an object using MIB extensions.
Management System Managed Entity
DECmcc TCP/IP Only!
Director SNMP agent
Presentation Module
Functional Module
Standard MIB
SNMP Access
Module Private MIB extensions
Managed Object
Figure 2
Minimally, the following steps are required...
1. Define the interface between the Managed Object and the MIB
extension.
2. Define a MIB extension using the SMI as a guide.
3. Modify the SNMP agent by registering the extension.
4. Add MIB extensions to the Management System using the MIB
compiler.
Integral to this design must be the communications mechanism
between the MIB extension and the Managed Object. It is very
important that a clearly defined mechanism be developed to enable
the SNMP agent to access the database (health and status, etc.)
of the Managed object.
Custom Access Module for DECmcc
Illustrated in the figure below is an example of the mechanism
required to manage an object using a DECmcc Custom Access
Module.
Management System
DECmcc
Director
Presentation Module
Functional Module Remote System
Custom Access
Module Managed
Any Agent
Protocol Object
Figure 3
The following steps are required to develop a "custom" Access
Module and Agent...
1. Define interface between the Agent and the Managed Object
2. Develop the custom Access Module using the DECmcc Toolkit
3. Develop the custom Agent
4. Register custom Access Module with DECmcc
The key advantages of this approach as opposed to the custom MIB
extension are...
� Protocol Independence
� Verbs and Management Interface not limited to simple Set,
Show & Trap Commands
Note: Much like the SNMP example, integral to this design must
be the communications mechanism between the Agent and the
Managed Object. It is very important that a clearly defined
mechanism be developed to enable the Agent to access the
database (health and status, etc.) of the Managed object.
Conclusion
It is very important when considering or prototyping a custom
access module vs. an SNMP custom MIB that one consider the
following...
� If possible, prototype/evaluate all of the management
requirements. If your intention is to develop a MIB
extension, it is important that you model the complex
object against the SMI. A good reference for helping with
this is the "Simple Book" by Marshall Rose. Failure to do
a complete modeling job risks making an invalid evaluation
based on the relative ease of developing a simple MIB
extension for a simple management application vs the task
of developing a MIB extension for a complex management
application.
� Evaluate not only the task of developing the MIB extension
but also the relative complexity of the user interface of
the two solutions (i.e., how difficult it is to query
and/or status the remote application through the network
management tool for the custom MIB extension vs the custom
Access Module).
|
| 1987.5 | ? | STAR::DANIELE | | Tue Jan 07 1992 13:54 | 48 |
|
> In the words of one of our software engineers who has done both
> (written custom MIBs and DECmcc access modules), the basic
> problems are not apparent until you attempt to develop the
> applications (i.e., the things that will actually manage the
> remote agents). At the basic access level, you can do anything
> with SNMP that you need to. The problem is when you want to
> simplify the object at the UI, it takes a lot of code and effort
> because the SMI is so primitive. If your application has a
> structure that is intuitive to the object, it is likely not to
> fit the SMI. That means you write a lot of glue software to get
> access via SNMP that could be reduced with a custom Access
> Module."
But if you are using DECmcc, and the SNMP AM, aren't these moot points?
The application structure is defined, it's DECmcc's implementation
of the entity model. The "glue software" is already written, it's in
the guts of the AM. (For instance, the code that transforms a
request like MCC> show snmp fred.nac.dec.com interface * all char
into a series of GetNext Requests, and handles the reponses, and
the errors, and the UDP retries, packages up an MCC response, etc.)
>
Figure 2
> Minimally, the following steps are required...
> 1. Define the interface between the Managed Object and the MIB
> extension.
> 2. Define a MIB extension using the SMI as a guide.
> 3. Modify the SNMP agent by registering the extension.
> 4. Add MIB extensions to the Management System using the MIB
> compiler.
> Integral to this design must be the communications mechanism
> between the MIB extension and the Managed Object. It is very
> important that a clearly defined mechanism be developed to enable
> the SNMP agent to access the database (health and status, etc.)
> of the Managed object.
Now assuming you use the common agent, aren't these all moot points?
An calling interface exists to register objects and transfer data
between the agent and the managed object module (the code you would
have to write).
My 2 cents,
Mike
|