As per Relevance of the word minshall, we have this rfc below:
Network Working Group G.
Request for Comments: 1419 Novell, Inc
M.
Apple Computer, Inc
March 1993
SNMP over
Status of this
This RFC specifies an IAB standards track protocol for the
community, and requests discussion and suggestions for improvements
Please refer to the current edition of the "IAB Official
Standards" for the standardization state and status of this protocol
Distribution of this memo is unlimited
This memo describes the method by which the Simple Network
Protocol (SNMP) as specified in [1] can be used over
protocols [2] instead of the Internet UDP/IP protocol stack.
specification is useful for network elements which have
support but lack TCP/IP support. It should be noted that if
network element supports multiple protocol stacks, and UDP
available, it is the preferred network layer to use
SNMP has been successful in managing Internet capable
elements which support the protocol stack at least through UDP,
connectionless Internet transport layer protocol. As
designed, SNMP is capable of running over any reasonable
mechanism (not necessarily a transport protocol) that supports bi
directional flow and addressability
Many non-Internet capable network elements are present in networks
Some of these elements are equipped with the AppleTalk protocols
One method of using SNMP to manage these elements is to define
method of transmitting an SNMP message inside an AppleTalk
data unit
This RFC is the product of the SNMP over a Multi-protocol
Working Group of the Internet Engineering Task Force (IETF).
1.
The AppleTalk equivalent of UDP (and IP) is DDP (Datagram
Protocol). The header field of a DDP datagram includes (at
conceptually) source and destination network numbers, source
Minshall & Ritter [Page 1]
RFC 1419 SNMP over AppleTalk March 1993
destination node numbers, and source and destination socket numbers
Additionally, DDP datagrams include a "protocol type" in the
field which may be used to further demultiplex packets. The
portion of a DDP datagram may contain from zero to 586 octets
AppleTalk's Name Binding Protocol (NBP) is a distributed name-to
address mapping protocol. NBP names are logically of the
"object:type@zone", where "zone" is determined, loosely, by
network on which the named entity resides; "type" is the kind
entity being named; and "object" is any string which
"object:type@zone" to be unique in the AppleTalk internet
Generally, "object" also helps an end-user determine which
of a specific type of service is being accessed. NBP names are
case sensitive. Each field of the NBP name ("object", "type",
"zone") is limited to 32 octets. The octets usually consist
human-readable ascii characters
2.
SNMP REQUESTS encapsulated according to this standard will be sent
DDP socket number 8; they will contain a DDP protocol type of 8.
data octets of the DDP datagram will be a standard SNMP message
defined in [1].
SNMP RESPONSES encapsulated according to this standard will be
to the DDP socket number which originated the corresponding
request; they will contain a DDP protocol type of 8. The data
of the DDP datagram will be a standard SNMP message as defined
[1]. (Note: as stated in [1], section 4.1, the *source* address
a RESPONSE PDU will be the same as the *destination* address of
corresponding REQUEST PDU.)
A network element which is capable of responding to SNMP
over AppleTalk must advertise this capability via the AppleTalk
Binding Protocol using an NBP type of "SNMP Agent" (hex 53, 4E, 4D
50, 20, 41, 67, 65, 6E, 74).
A network management station which is capable of receiving an
TRAP must advertise this capability via the AppleTalk Name
Protocol using an NBP type of "SNMP Trap Handler" (hex 53, 4E, 4D
50, 20, 54, 72, 61, 70, 20, 48, 61, 6E, 64, 6C, 65, 72).
SNMP TRAPS encapsulated according to this standard will be sent
DDP socket number 9; they will contain a DDP protocol type of 8.
data octets of the DDP datagram will be a standard SNMP message
defined in [1]. The agent-addr field of the Trap-PDU must be
with a NetworkAddress of all zeros (the unknown IP address). Thus,
identify the trap sender, the name and value of the nbpObject
Minshall & Ritter [Page 2]
RFC 1419 SNMP over AppleTalk March 1993
nbpZone corresponding to the nbpEntry with the nbpType equal to "
Agent" should be included in the variable-bindings of any trap
is sent [3].
The NBP name for both an agent and a trap handler should be stable -
it should not change any more often than the IP address of a
TCP/IP end system changes. It is suggested that the NBP name
stored in some form of stable storage (PRAM, local disk, etc.).
3. Discussion of AppleTalk
3.1
The AppleTalk protocol suite has certain features not manifest in
standard TCP/IP suite. Its unique naming strategy and the
nature of address assignment can cause problems for SNMP
stations that wish to manage AppleTalk networks. TCP/IP end nodes
as of this writing, have an associated IP address which
each from the other. AppleTalk end nodes, in general, have no
characteristic. The network level address, while often
stable, can change at every reboot (or more frequently).
Thus, a thrust of this proposal is that a "name" (as opposed to
"address") for an end system be used as the identifying attribute
This is the equivalent, when dealing with TCP/IP end nodes, of
the domain name. While the mapping (DNS name, IP address) is
stable than the mapping (NBP name, DDP address), the mapping (
name, IP address) is not required to exist (e.g., hosts with no
name, only an IP address). In contrast, all AppleTalk nodes
implement this specification are required to respond to NBP
and confirms (e.g., implement the NBP protocol stub),
guarantees that the mapping (NBP name, DDP address) will exist
In determining the SNMP name to register for an agent, it
suggested that the SNMP name be a name which is associated with
network services offered by the machine. On a Macintosh system,
example, it is suggested that the system name (the "Macintosh Name
for System 7.0 which is used to advertise file sharing, program-to
program communication, and possibly other services) be used as
"object" field of the NBP name. This name has
significance, and is tightly bound to the network's concept of
given system's identity
NBP lookups, which are used to turn NBP names into DDP addresses,
cause large amounts of network traffic as well as consume
resources. It is also the case that the ability to perform an
lookup is sensitive to certain network disruptions (such as
table inconsistencies, etc.) which would not prevent direct
Minshall & Ritter [Page 3]
RFC 1419 SNMP over AppleTalk March 1993
communications between a management station and an agent
Thus, it is recommended that NBP lookups be used infrequently
the primary purpose being to create a cache of name-to-
mappings. These cached mappings should then be used for any
SNMP requests. It is recommended that SNMP management
maintain this cache between reboots. This caching can help
network traffic, reduce CPU load on the network, and allow for (
amount of) network trouble shooting when the basic name-to-
translation mechanism is broken
3.2 How To Acquire NBP names
A management station may have a pre-configured list of names
agents to manage. A management station may allow for an
with an operator in which a list of manageable agents is
(via NBP) and presented for the operator to choose which
should be managed by that management station. Finally, a
station may manage all manageable agents in a set of zones
networks
An agent must be configured with the name of a specific
station or group of management stations before sending SNMP traps
In the absence of any such configured information, an agent is NOT
generate any SNMP traps. In particular, an agent is NEVER
initiate a wildcard NBP lookup to find a management station
receive a trap. All NBP lookups generated by an agent must be
specified. Note, however, that this does not apply to
configuration utility that might be associated with such an agent
Such a utility may well allow a user to navigate around the
to select a management station or stations to receive SNMP traps
the agent
3.3 When To Turn NBP Names Into Addresses
When SNMP agents or management stations use a cache entry to
an SNMP packet, they should attempt to confirm the mapping if
hasn't been confirmed in T1 seconds. This cache entry lifetime, T1,
has a minimum, default value of 60 seconds. This value should
configurable
A management station may decide to prime its cache of names prior
actually sending any SNMP requests to any given agent. In general
it is expected that a management station may want to keep
mappings "more current" than other mappings. In particular,
nodes which represent the network infrastructure (routers, etc.)
be deemed "more important" by the management station
Minshall & Ritter [Page 4]
RFC 1419 SNMP over AppleTalk March 1993
Note, however, that a long-running management station starting up
reading a configuration file containing a number of NBP names
not attempt to prime its cache all at once. It should, instead
issue the resolutions over an extended period of time (perhaps
some pre-determined or configured priority order). Each
might, in fact, be a wildcard lookup in a given zone
An agent should NEVER prime its cache. It should do NBP lookups (
confirms) only when it needs to send an SNMP trap to a
management station. An agent does not need to confirm a cache
to reply to a request
3.4 How To Turn NBP Names Into Addresses
If the only piece of information available is the NBP name, then
NBP lookup should be performed to turn that name into a DDP address
However, if there is a piece of stale information, it can be used
a hint to perform an NBP confirm (which sends a unicast to
network address which is presumed to be the target of the
lookup) to see if the stale information is, in fact, still valid
An NBP name to DDP address mapping can also be confirmed
using only SNMP transactions. If a management station is sending
get-request, it can add a request, in the same packet, for
destination's nbpObject and nbpZone corresponding to the
with the nbpType equal to "SNMP Agent" [3]. The source DDP
can be gleaned from the reply and used with the nbpObject and
returned to confirm the cache entry
The above notwithstanding, for set-requests, there is a
condition that can occur where an SNMP request may go to the
agent (because the old node went down and a new node came up with
same DDP address.) This is problematic becase the wrong agent
generate a response packet that the management station could
distinguish from a reply from the intended agent. In the future
when SNMP security is implemented, each packet is authenticated
the destination, and the reply should implicitly confirm the
of the cache entry used and prevent this race condition
3.5 What if NBP is broken
Under some circumstances, there may be connectivity between
management station and an agent, but the NBP machinery required
turn an NBP name into a DDP address may be broken. Examples
failures which would cause this include: NBP FwdReq (forward
lookup onto locally attached network) broken at a router on
network containing the agent; NBP BrRq (NBP broadcast request
Minshall & Ritter [Page 5]
RFC 1419 SNMP over AppleTalk March 1993
mechanism broken at a router on the network containing the
station (because of a zone table mis-configuration, for example);
NBP broken in the target node
A management station which is dedicated to AppleTalk management
choose to alleviate some of these failures by implementing the
portion of NBP within the management station itself. For example
the management station might already know all the zones on
AppleTalk internet and the networks on which each zone appears
Given an NBP lookup which fails, the management station could send
NBP FwdReq to the network in which the agent was last located.
that failed, the station could then send an NBP LkUp (an NBP
packet) as a directed (DDP) multicast to each network number on
network. Of the above (single) failures, this combined approach
solve the case where either the local router's BrRq to NBP
mechanism is broken or the remote router's NBP FwdReq to NBP
mechanism is broken
4.
Some of the boilerplate in this memo is copied from [4], [5],
[6]. The Apple-IP Working Group was instrumental in defining
document. Their support and work was greatly appreciated
5.
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A
Network Management Protocol (SNMP)", STD 15, RFC 1157,
Research, Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.
[2] Sidhu, G., Andrews, R., and A. Oppenheimer, "Inside
(Second Edition)", Addison-Wesley, 1990.
[3] Waldbusser, S., "AppleTalk Management Information Base",
1243, Carnegie Mellon University, August 1991.
[4] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP
Ethernet", RFC 1089, Rensselaer Polytechnic Institute,
Laboratory for Computer Science, NYSERNet, Inc., University
Tennessee at Knoxville, February 1989.
[5] Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
[6] Piscitello, D., "Guidelines for the Specification of
Support of the SNMP", Work in Progress
Minshall & Ritter [Page 6]
RFC 1419 SNMP over AppleTalk March 1993
6. Security
Security issues are discussed in section 3.4.
7. Authors'
Greg
Novell, Inc
1340 Treat Blvd, ste. 500
Walnut Creek, CA 94596
Phone: 510 947-0998
Fax: 510 947-1238
EMail: minshall@wc.novell.
Mike
Apple Computer, Inc
10500 North De Anza Boulevard, MS: 35-
Cupertino, California 95014
Phone: 408 862-8088
Fax: 408 862-1159
EMail: MWRITTER@applelink.apple.
Minshall & Ritter [Page 7]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
