rfc1419.txt

RFC 的详细文档！

Network Working Group                                       G. Minshall
Request for Comments: 1419                                 Novell, Inc.
                                                              M. Ritter
                                                   Apple Computer, Inc.
                                                             March 1993


                          SNMP over AppleTalk

Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Introduction

   This memo describes the method by which the Simple Network Management
   Protocol (SNMP) as specified in [1] can be used over AppleTalk
   protocols [2] instead of the Internet UDP/IP protocol stack.  This
   specification is useful for network elements which have AppleTalk
   support but lack TCP/IP support.  It should be noted that if  a
   network element supports multiple protocol stacks, and UDP is
   available, it is the preferred network layer to use.

   SNMP has been successful in managing Internet capable network
   elements which support the protocol stack at least through UDP, the
   connectionless Internet transport layer protocol.  As originally
   designed, SNMP is capable of running over any reasonable transport
   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 a
   method of transmitting an SNMP message inside an AppleTalk protocol
   data unit.

   This RFC is the product of the SNMP over a Multi-protocol Internet
   Working Group of the Internet Engineering Task Force (IETF).

1. Background

   The AppleTalk equivalent of UDP (and IP) is DDP (Datagram Delivery
   Protocol).  The header field of a DDP datagram includes (at least
   conceptually) source and destination network numbers, source and



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 header
   field which may be used to further demultiplex packets.  The data
   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 form
   "object:type@zone", where "zone" is determined, loosely, by the
   network on which the named entity resides; "type" is the kind of
   entity being named; and "object" is any string which causes
   "object:type@zone" to be unique in the AppleTalk internet.
   Generally, "object" also helps an end-user determine which instance
   of a specific type of service is being accessed.  NBP names are not
   case sensitive.  Each field of the NBP name ("object", "type", and
   "zone") is  limited to 32 octets.  The octets usually consist of
   human-readable ascii characters.

2. Specification

   SNMP REQUESTS encapsulated according to this standard will be sent to
   DDP socket number 8; they will contain a DDP protocol type of 8.  The
   data octets of the DDP datagram will be a standard SNMP message as
   defined in [1].

   SNMP RESPONSES encapsulated according to this standard will be sent
   to the DDP socket number which originated the corresponding SNMP
   request; they will contain a DDP protocol type of 8.  The data octets
   of the DDP datagram will be a standard SNMP message as defined in
   [1].  (Note:  as stated in [1], section 4.1, the *source* address of
   a RESPONSE PDU will be the same as the *destination* address of the
   corresponding REQUEST PDU.)

   A network element which is capable of responding to SNMP REQUESTS
   over AppleTalk must advertise this capability via the AppleTalk Name
   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 SNMP
   TRAP must advertise this capability via the AppleTalk Name Binding
   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 to
   DDP socket number 9; they will contain a DDP protocol type of 8.  The
   data octets of the DDP datagram will be a standard SNMP message as
   defined in [1].  The agent-addr field of the Trap-PDU must be filled
   with a NetworkAddress of all zeros (the unknown IP address). Thus, to
   identify the trap sender, the name and value of the nbpObject and



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


   nbpZone corresponding to the nbpEntry with the nbpType equal to "SNMP
   Agent" should be included in the variable-bindings of any trap that
   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 typical
   TCP/IP end system changes.  It is suggested that the NBP name be
   stored in some form of stable storage (PRAM, local disk, etc.).

3. Discussion of AppleTalk Addressing

3.1 Introduction

   The AppleTalk protocol suite has certain features not manifest in the
   standard TCP/IP suite.  Its unique naming strategy and the dynamic
   nature of address assignment can cause problems for SNMP management
   stations that wish to manage AppleTalk networks.  TCP/IP end nodes,
   as of this writing, have an associated IP address which distinguishes
   each from the other.  AppleTalk end nodes, in general, have no such
   characteristic.  The network level address, while often relatively
   stable, can change at every reboot (or more frequently).

   Thus, a thrust of this proposal is that a "name" (as opposed to an
   "address") for an end system be used as the identifying attribute.
   This is the equivalent, when dealing with TCP/IP end nodes, of using
   the domain name.  While the mapping (DNS name, IP address) is more
   stable than the mapping (NBP name, DDP address), the mapping (DNS
   name, IP address) is not required to exist (e.g., hosts with no host
   name, only an IP address). In contrast, all AppleTalk nodes that
   implement this specification are required to respond to NBP lookups
   and confirms (e.g., implement the NBP protocol stub), which
   guarantees that the mapping (NBP name, DDP address) will exist.

   In determining the SNMP name to register for an agent, it is
   suggested that the SNMP name be a name which is associated with other
   network services offered by the machine.  On a Macintosh system, for
   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 the
   "object" field of the NBP name.  This name has AppleTalk
   significance, and is tightly bound to the network's concept of a
   given system's identity.

   NBP lookups, which are used to turn NBP names into DDP addresses, can
   cause large amounts of network traffic as well as consume CPU
   resources. It is also the case that the ability to perform an NBP
   lookup is sensitive to certain network disruptions (such as zone
   table inconsistencies, etc.) which would not prevent direct AppleTalk



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 with
   the primary purpose being to create a cache of name-to-address
   mappings. These cached mappings should then be used for any further
   SNMP requests. It is recommended that SNMP management stations
   maintain this cache between reboots.  This caching can help minimize
   network traffic, reduce CPU load on the network, and allow for (some
   amount of) network trouble shooting when the basic name-to-address
   translation mechanism is broken.

3.2 How To Acquire NBP names:

   A management station may have a pre-configured list of names of
   agents to manage. A management station may allow for an interaction
   with an operator in which a list of manageable agents is acquired
   (via NBP) and presented for the operator to choose which agents
   should be managed by that management station.  Finally, a management
   station may manage all manageable agents in a set of zones or
   networks.

   An agent must be configured with the name of a specific management
   station or group of management stations before sending SNMP traps.
   In the absence of any such configured information, an agent is NOT to