rfc1419.txt

RFC 的详细文档！

   generate any SNMP traps.  In particular, an agent is NEVER to
   initiate a wildcard NBP lookup to find a management station to
   receive a trap.  All NBP lookups generated by an agent must be fully
   specified.  Note, however, that this does not apply to a
   configuration utility that might be associated with such an agent.
   Such a utility may well allow a user to navigate around the network
   to select a management station or stations to receive SNMP traps from
   the agent.

3.3 When To Turn NBP Names Into Addresses:

   When SNMP agents or management stations use a cache entry to address
   an SNMP packet, they should attempt to confirm the mapping if it
   hasn't been confirmed in T1 seconds.  This cache entry lifetime, T1,
   has a minimum, default value of 60 seconds.  This value should be
   configurable.

   A management station may decide to prime its cache of names prior to
   actually sending any SNMP requests to any given agent.  In general,
   it is expected that a management station may want to keep certain
   mappings "more current" than other mappings.  In particular, those
   nodes which represent the network infrastructure (routers, etc.) may
   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 and
   reading a configuration file containing a number of NBP names should
   not attempt to prime its cache all at once.  It should, instead,
   issue the resolutions over an extended period of time (perhaps in
   some pre-determined or configured priority order).  Each resolution
   might, in fact, be a wildcard lookup in a given zone.

   An agent should NEVER prime its cache.  It should do NBP lookups (or
   confirms) only when it needs to send an SNMP trap to a given
   management station.  An agent does not need to confirm a cache entry
   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 an
   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 as
   a hint to perform an NBP confirm (which sends a unicast to the
   network address which is presumed to be the target of the name
   lookup) to see if the stale information is, in fact, still valid.

   An NBP name to DDP address mapping can also be confirmed implicitly
   using only SNMP transactions.  If a management station is sending a
   get-request, it can add a request, in the same packet, for the
   destination's nbpObject and nbpZone corresponding to the nbpEntry
   with the nbpType equal to "SNMP Agent" [3].  The source DDP address
   can be gleaned from the reply and used with the nbpObject and nbpZone
   returned to confirm the cache entry.

   The above notwithstanding, for set-requests, there is a race
   condition that can occur where an SNMP request may go to the wrong
   agent (because the old node went down and a new node came up with the
   same DDP address.)  This is problematic becase the wrong agent might
   generate a response packet that the management station could not
   distinguish from a reply from the intended agent.  In the future,
   when SNMP security is implemented, each packet is authenticated at
   the destination, and the reply should implicitly confirm the validity
   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 a
   management station and an agent, but the NBP machinery required to
   turn an NBP name into a DDP address may be broken.  Examples of
   failures which would cause this include:  NBP FwdReq (forward NBP
   lookup onto locally attached network) broken at a router on the
   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 managment
   station (because of a zone table mis-configuration, for example); or
   NBP broken in the target node.

   A management station which is dedicated to AppleTalk management might
   choose to alleviate some of these failures by implementing the router
   portion of NBP within the management station itself.  For example,
   the management station might already know all the zones on the
   AppleTalk internet and the networks on which each zone appears.
   Given an NBP lookup which fails, the management station could send an
   NBP FwdReq to the network in which the agent was last located.  If
   that failed, the station could then send an NBP LkUp (an NBP lookup
   packet) as a directed (DDP) multicast to each network number on that
   network.  Of the above (single) failures, this combined approach will
   solve the case where either the local router's BrRq to NBP FwdReq
   mechanism is broken or the remote router's NBP FwdReq to NBP LkUp
   mechanism is broken.

4. Acknowledgements

   Some of the boilerplate in this memo is copied from [4], [5], and
   [6].  The Apple-IP Working Group was instrumental in defining this
   document.  Their support and work was greatly appreciated.

5. References

   [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
       Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP
       Research, Performance Systems International, Performance Systems
       International, MIT Laboratory for Computer Science, May 1990.

   [2] Sidhu, G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk
       (Second Edition)", Addison-Wesley, 1990.

   [3] Waldbusser, S., "AppleTalk Management Information Base", RFC
       1243, Carnegie Mellon University, August 1991.

   [4] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over
       Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT
       Laboratory for Computer Science, NYSERNet, Inc., University of
       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 Protocol
       Support of the SNMP", Work in Progress.





Minshall & Ritter                                               [Page 6]

RFC 1419                  SNMP over AppleTalk                 March 1993


6. Security Considerations

   Security issues are discussed in section 3.4.

7. Authors' Addresses

   Greg Minshall
   Novell, Inc.
   1340 Treat Blvd, ste. 500
   Walnut Creek, CA  94596

   Phone: [phone]
   Fax:   [phone]
   EMail:  [e-mail]


   Mike Ritter
   Apple Computer, Inc.
   10500 North De Anza Boulevard, MS: 35-K
   Cupertino, California 95014

   Phone: [phone]
   Fax:   [phone]
   EMail: [e-mail]



























Minshall & Ritter                                               [Page 7]