home
***
CD-ROM
|
disk
|
FTP
|
other
***
search
/
Internet Info 1997 December
/
Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso
/
ietf
/
91nov
/
devdisc-minutes-91nov.txt
< prev
next >
Wrap
Text File
|
1993-02-17
|
12KB
|
255 lines
CURRENT_MEETING_REPORT_
Reported by Fred Baker/ACC
SNMP Device Discovery BOF Minutes
Prior to meeting at the IETF, there was an extended discussion on the
SNMP and finder@emerald.acc.com mailing lists. It is summarized as
follows, as it represents a significant context to the BOF held at the
IETF meeting.
Essentially, we have two problems and at least three solutions on the
table. The purpose of the BOF is exploratory - there exists a subset of
individuals who feel that there is no viable problem to solve, and if
there is it should not be solved; there are others who support various
viewpoints. We need to get all the laundry on the table and come up
with a problem statement before we can either proceed or decide to not
proceed.
The problems are:
o Within a single administrative domain, it should be possible for
Network Management Systems to locate all of the systems appropriate
for them to manage (e.g., with SNMP) without preconfiguration.
This is believed to be helpful to Network Managers in that they now
have positive assurance that they do in fact know all of the key
devices in their networks. This viewpoint has been presented by a
couple of vendors, and was in fact the start of the discussion.
o Within a single administrative domain, it is possible and probable
that devices are added to the network without the knowledge of the
network manager. Several Network Managers have indicated a desire
to know literally all of the devices on their networks, and their
network layer attributes.
The potential solutions may be classified as ``first person'',
``second person'', and ``third person'' solutions, and there are a
couple of variations on each of those:
First Person:
Examples of current deployment:
Wide area: RWHO... Immediate Neighbor: OSPF, ES-IS, IS-IS,
DECNET, RIP, DECNET, DEC MOP, DEC LAT...
Each SNMP-manageable device on the network periodically emits a
trap which announces its presence to interested parties. The trap
is sent to a multicast which is received by interested parties on
the extended LAN. Its contents include Object Identifiers of MIB
Groups supported by the device, system.sysObjectID, and the
Read-only community string/party to be used with this agent. If we
presume that the probability that a multicast will reach all of its
intended recipients > some value, then the probability that all of
the network managers know about all of the devices they should
manage within some amount of time is a function of the emission
rate and the time limit.
1
A second version of this might use IP Multicasting to propagate
information throughout the administrative domain.
Concerns:
First approach: Impact of SNMP Security Architecture not yet
analyzed. Does not propagate information beyond router.
Second approach: scaling, definition of administrative boundaries,
some details in SNMP. Impact of SNMP Security Architecture not yet
analyzed.
Doesn't solve second problem.
second person: Examples of current deployment: ARP, 802.5 RIF
Discovery, DEC RBMS
Each interested party does something to elicit a response from the
systems it is concerned about. This might include sweeping MIBs
and then pinging new folks discovered in ARP caches, etc. Someone
has suggested letter bombs - broadcast a GET system.sysDescr, and
collect the responses. In the latter class of solution, there
would need to be either some random ``host delay'' to avoid
flooding the network, or an ``exclusion group'' to advise
responders to NOT respond.
Concerns: scaling, traffic level, both burst and sustained,
definition of administrative boundaries.
Sweeps may solve second problem, or at least part of it, but this
is not assured. broadcast ``pings'' only solve it for the
architectures whose ``ping'' is used, and not all architectures
define a ``ping''.
third person: Examples of current deployment: RMON MIB
A subset of the systems in the network actively notify the
interested NMSs of new systems that they detect. ``Detection'' is
somewhat imprecise - one proposal defines detection to be a
protocol specific neighboring relationship; another defines it as
the use of a LAN source address. In the latter, the RMON MIB is
proposed as a solution.
Concerns:
With the RMON MIB, no network layer information is captured. If
the network manager is not on the local wire with the system found,
it has no information other than the MAC Address and the location
of the monitor with which to do anything further and no protocol
with which to get it.
With the RMON MIB, only LAN systems are detected, and then only on
LANs that have objects defined in RMON. As it stands today, RMON is
fairly obviously targeted at Ethernet. For use on Token Ring or
FDDI, there is additional work defined by the RMON WG. Multipoint
networks such as SMDS and Frame Relay are not addressed; this may
or may not be an issue - can we assume that contracts exist in the
presence of these technologies? Are private networks a concern?
With the protocol specific detection, a router or bridge could
advertise the MAC and network layer information to the NMS; the
fact that a TRAP is unreliable means that the NMS might nonetheless
fail to learn the information. Use of a SET has been suggested,
but some feel that specifying an application residing in the router
or bridge is distasteful. Each NMS could also poll the subset of
systems (monitors, routers, etc, a limited subset of the network)
for new information.
The BOF was started with a presentation by Anil Rijsinghani of
2
Digital, whose question on the SNMP Mailing List is what actually
started the whole debate. His fundamental concern, echoed by some
other vendors, was that there is today no single, reliable, way to
find all of the SNMP Manageable devices in an administrative
domain. Corollary to that, there is no way to determine what MIBs
any given station supports. Even a MIB walk may not return that
information if a MIB is primarily composed of tables and the
service is not currently configured or active. Mechanisms that are
available depend on assumptions that may not hold, such as the use
of the ``public'' community in SNMP or that SNMP capable systems
periodically send SNMP messages. Other drawbacks of existing
mechanisms may include: they are complex, generate excessive
traffic, and require every NMS to perform its own discovery.
Requirements of a solution to this problem include: it should be
reliable (discover every SNMP device), be simple, use small amount
of network bandwidth, require a small amount of agent effort,
should work regardless of powerup sequence, impose a low load on
others and convey useful standardized information.
The remainder of the BOF was given over to determining what problem
the assembled company wanted to solve; this is a non-trivial
problem in its own right. The discussion was as wide-ranging, and
a number of quite divergent opinions were presented. It was
generally felt that the problems of finding all SNMP capable
systems, finding all SNMP/UDP/IP capable systems, and finding all
systems that use the Internet were quite distinct and call for
different solutions, and that finding all equipment attached to the
Internet is not a solvable problem.
After much discussion, it was concluded that the fundamental
problem seeking solution borrowed components of each of these
problems. Network Managers do in fact need to know what equipment
is attached to their networks, and are helped by products which
will perform this function. Products that do this utilize the RMON
MIB, proprietary MIBs and algorithms, and scan such tables as the
ARP cache and Routing cache. However, the problem of device
discovery does not include a number of other functions (such as
drawing a picture or matrix of Internet connectivity). These are
``next step'' processes which follow the discovery of the systems
in the network.
Given this much problem definition, the conclusion was reached that
the RMON MIB could be extended to solve much of the discovery
process. The reasons that it is inadequate now are:
it is limited to finding systems attached to LANs, and
it does not capture the protocol type or network layer protocol
addresses that a device is using.
As a result, the information captured about a system found by RMON,
as it stands, cannot be used to perform the next step, that of
pinging the device, especially if the device is separated from the
NMS by a router. Therefore, the ultimate solution reached was to
recommend that the RMON MIB be extended with a table containing, at
minimum, the following information:
deviceTable deviceEntry [deviceMacAddress, deviceProtocol]
deviceMacAddress OCTET STRING deviceProtocol OCTET STRING or OBJECT
IDENTIFIER deviceProtocolAddress OCTET STRING
There may not be a protocol address for all protocols layered onto
3
the Data Link Layer, so the NMS must expect that
deviceProtocolAddress may have a length of zero octets.
A prototype MIB will be forwarded to Mike Ehrlinger of MTI for
consideration by the RMON WG.
Attendees
Miriam Amos Nihart miriam@decwet.zso.dec.com
Robert Austein sra@asylum.sf.ca.us
Fred Baker fbaker@emerald.acc.com
Steve Bostock steveb@novell.com
David Bridgham dab@asylum.sf.ca.us
Theodore Brunner tob@thumper.bellcore.com
Jeffrey Buffum buffum@vos.stratus.com
Lida Carrier lida@apple.com
Jeffrey Case case@cs.utk.edu
Richard Cherry rcherry@wc.novell.com
James Codespote jpcodes@tycho.ncsc.mil
Dave Cullerot cullerot@ctron.com
James Davin jrd@ptt.lcs.mit.edu
Jeff Erwin
Bill Fardy fardy@ctron.com
Shawn Gallagher gallagher@quiver.enet.dec.com
William Jackson jackson@manta.nosc.mil
Ron Jacoby rj@sgi.com
Satish Joshi sjoshi@synoptics.com
Scott Kaplan
Frank Kastenholz kasten@europa.clearpoint.com
David Kaufman
Manu Kaycee kaycee@ctron.com
Mark Kepke mak@cnd.hp.com
Yoav Kluger ykluger@fibhaifa.com
Stev Knowles stev@ftp.com
Deidre Kostick dck2@sabre.bellcore.com
Ron Lau
Keith McCloghrie kzm@hls.com
Evan McGinnis bem@3com.com
David Minnich dwm@fibercom.com
Michael Newell mnewell@nhqvax.hg.nasa.gov
David Perkins dperkins@synoptics.com
Radia Perlman perlman@radia.enet.dec.com
Robert Purvy bpurvy@us.oracle.com
Anil Rijsinghani anil@levers.enet.dec.com
Michael Ritter mwritter@applelink.apple.com
Jonathan Saperia saperia@tcpjon.enet.dec.com
Mark Schaefer schaefer@davidsys.com
John Seligson johns@ultra.com
Timon Sloane peernet!timon@uunet.uu.net
Ravi Srinivasan ravi@eng.vitalink.com
Bob Stewart rlstewart@eng.xyplex.com
Bruce Taber taber@interlan.com
Iris Tal 437-3580@mcimail.com
Mark Therieau markt@python.eng.microcom.com
Dean Throop throop@dg-rtp.dg.com
John Veizades veizades@apple.com
Sudhanshu Verma verma@hpspdla.hp.com
4
Lee Wade wade@nsipo.arc.nasa.gov
Steven Waldbusser waldbusser@andrew.cmu.edu
Jeremy Wilson
Junekang Yang natadm!yang@uunet.uu.net
John Ziegler ziegler@artel.com
5