home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1419 < prev    next >
Text File  |  1993-03-03  |  16KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                       G. Minshall
  8. Request for Comments: 1419                                 Novell, Inc.
  9.                                                               M. Ritter
  10.                                                    Apple Computer, Inc.
  11.                                                              March 1993
  12.  
  13.  
  14.                           SNMP over AppleTalk
  15.  
  16. Status of this Memo
  17.  
  18.    This RFC specifies an IAB standards track protocol for the Internet
  19.    community, and requests discussion and suggestions for improvements.
  20.    Please refer to the current edition of the "IAB Official Protocol
  21.    Standards" for the standardization state and status of this protocol.
  22.    Distribution of this memo is unlimited.
  23.  
  24. Introduction
  25.  
  26.    This memo describes the method by which the Simple Network Management
  27.    Protocol (SNMP) as specified in [1] can be used over AppleTalk
  28.    protocols [2] instead of the Internet UDP/IP protocol stack.  This
  29.    specification is useful for network elements which have AppleTalk
  30.    support but lack TCP/IP support.  It should be noted that if  a
  31.    network element supports multiple protocol stacks, and UDP is
  32.    available, it is the preferred network layer to use.
  33.  
  34.    SNMP has been successful in managing Internet capable network
  35.    elements which support the protocol stack at least through UDP, the
  36.    connectionless Internet transport layer protocol.  As originally
  37.    designed, SNMP is capable of running over any reasonable transport
  38.    mechanism (not necessarily a transport protocol) that supports bi-
  39.    directional flow and addressability.
  40.  
  41.    Many non-Internet capable network elements are present in networks.
  42.    Some of these elements are equipped with the AppleTalk protocols.
  43.    One method of using SNMP to manage these elements is to define a
  44.    method of transmitting an SNMP message inside an AppleTalk protocol
  45.    data unit.
  46.  
  47.    This RFC is the product of the SNMP over a Multi-protocol Internet
  48.    Working Group of the Internet Engineering Task Force (IETF).
  49.  
  50. 1. Background
  51.  
  52.    The AppleTalk equivalent of UDP (and IP) is DDP (Datagram Delivery
  53.    Protocol).  The header field of a DDP datagram includes (at least
  54.    conceptually) source and destination network numbers, source and
  55.  
  56.  
  57.  
  58. Minshall & Ritter                                               [Page 1]
  59.  
  60. RFC 1419                  SNMP over AppleTalk                 March 1993
  61.  
  62.  
  63.    destination node numbers, and source and destination socket numbers.
  64.    Additionally, DDP datagrams include a "protocol type" in the header
  65.    field which may be used to further demultiplex packets.  The data
  66.    portion of a DDP datagram may contain from zero to 586 octets.
  67.  
  68.    AppleTalk's Name Binding Protocol (NBP) is a distributed name-to-
  69.    address mapping protocol.  NBP names are logically of the form
  70.    "object:type@zone", where "zone" is determined, loosely, by the
  71.    network on which the named entity resides; "type" is the kind of
  72.    entity being named; and "object" is any string which causes
  73.    "object:type@zone" to be unique in the AppleTalk internet.
  74.    Generally, "object" also helps an end-user determine which instance
  75.    of a specific type of service is being accessed.  NBP names are not
  76.    case sensitive.  Each field of the NBP name ("object", "type", and
  77.    "zone") is  limited to 32 octets.  The octets usually consist of
  78.    human-readable ascii characters.
  79.  
  80. 2. Specification
  81.  
  82.    SNMP REQUESTS encapsulated according to this standard will be sent to
  83.    DDP socket number 8; they will contain a DDP protocol type of 8.  The
  84.    data octets of the DDP datagram will be a standard SNMP message as
  85.    defined in [1].
  86.  
  87.    SNMP RESPONSES encapsulated according to this standard will be sent
  88.    to the DDP socket number which originated the corresponding SNMP
  89.    request; they will contain a DDP protocol type of 8.  The data octets
  90.    of the DDP datagram will be a standard SNMP message as defined in
  91.    [1].  (Note:  as stated in [1], section 4.1, the *source* address of
  92.    a RESPONSE PDU will be the same as the *destination* address of the
  93.    corresponding REQUEST PDU.)
  94.  
  95.    A network element which is capable of responding to SNMP REQUESTS
  96.    over AppleTalk must advertise this capability via the AppleTalk Name
  97.    Binding Protocol using an NBP type of "SNMP Agent" (hex 53, 4E, 4D,
  98.    50, 20, 41,  67, 65, 6E, 74).
  99.  
  100.    A network management station which is capable of receiving an SNMP
  101.    TRAP must advertise this capability via the AppleTalk Name Binding
  102.    Protocol using an NBP type of "SNMP Trap Handler" (hex 53, 4E, 4D,
  103.    50, 20, 54, 72, 61, 70, 20, 48, 61, 6E, 64, 6C, 65, 72).
  104.  
  105.    SNMP TRAPS encapsulated according to this standard will be sent to
  106.    DDP socket number 9; they will contain a DDP protocol type of 8.  The
  107.    data octets of the DDP datagram will be a standard SNMP message as
  108.    defined in [1].  The agent-addr field of the Trap-PDU must be filled
  109.    with a NetworkAddress of all zeros (the unknown IP address). Thus, to
  110.    identify the trap sender, the name and value of the nbpObject and
  111.  
  112.  
  113.  
  114. Minshall & Ritter                                               [Page 2]
  115.  
  116. RFC 1419                  SNMP over AppleTalk                 March 1993
  117.  
  118.  
  119.    nbpZone corresponding to the nbpEntry with the nbpType equal to "SNMP
  120.    Agent" should be included in the variable-bindings of any trap that
  121.    is sent [3].
  122.  
  123.    The NBP name for both an agent and a trap handler should be stable -
  124.    it should not change any more often than the IP address of a typical
  125.    TCP/IP end system changes.  It is suggested that the NBP name be
  126.    stored in some form of stable storage (PRAM, local disk, etc.).
  127.  
  128. 3. Discussion of AppleTalk Addressing
  129.  
  130. 3.1 Introduction
  131.  
  132.    The AppleTalk protocol suite has certain features not manifest in the
  133.    standard TCP/IP suite.  Its unique naming strategy and the dynamic
  134.    nature of address assignment can cause problems for SNMP management
  135.    stations that wish to manage AppleTalk networks.  TCP/IP end nodes,
  136.    as of this writing, have an associated IP address which distinguishes
  137.    each from the other.  AppleTalk end nodes, in general, have no such
  138.    characteristic.  The network level address, while often relatively
  139.    stable, can change at every reboot (or more frequently).
  140.  
  141.    Thus, a thrust of this proposal is that a "name" (as opposed to an
  142.    "address") for an end system be used as the identifying attribute.
  143.    This is the equivalent, when dealing with TCP/IP end nodes, of using
  144.    the domain name.  While the mapping (DNS name, IP address) is more
  145.    stable than the mapping (NBP name, DDP address), the mapping (DNS
  146.    name, IP address) is not required to exist (e.g., hosts with no host
  147.    name, only an IP address). In contrast, all AppleTalk nodes that
  148.    implement this specification are required to respond to NBP lookups
  149.    and confirms (e.g., implement the NBP protocol stub), which
  150.    guarantees that the mapping (NBP name, DDP address) will exist.
  151.  
  152.    In determining the SNMP name to register for an agent, it is
  153.    suggested that the SNMP name be a name which is associated with other
  154.    network services offered by the machine.  On a Macintosh system, for
  155.    example, it is suggested that the system name (the "Macintosh Name"
  156.    for System 7.0 which is used to advertise file sharing, program-to-
  157.    program communication, and possibly other services) be used as the
  158.    "object" field of the NBP name.  This name has AppleTalk
  159.    significance, and is tightly bound to the network's concept of a
  160.    given system's identity.
  161.  
  162.    NBP lookups, which are used to turn NBP names into DDP addresses, can
  163.    cause large amounts of network traffic as well as consume CPU
  164.    resources. It is also the case that the ability to perform an NBP
  165.    lookup is sensitive to certain network disruptions (such as zone
  166.    table inconsistencies, etc.) which would not prevent direct AppleTalk
  167.  
  168.  
  169.  
  170. Minshall & Ritter                                               [Page 3]
  171.  
  172. RFC 1419                  SNMP over AppleTalk                 March 1993
  173.  
  174.  
  175.    communications between a management station and an agent.
  176.  
  177.    Thus, it is recommended that NBP lookups be used infrequently with
  178.    the primary purpose being to create a cache of name-to-address
  179.    mappings. These cached mappings should then be used for any further
  180.    SNMP requests. It is recommended that SNMP management stations
  181.    maintain this cache between reboots.  This caching can help minimize
  182.    network traffic, reduce CPU load on the network, and allow for (some
  183.    amount of) network trouble shooting when the basic name-to-address
  184.    translation mechanism is broken.
  185.  
  186. 3.2 How To Acquire NBP names:
  187.  
  188.    A management station may have a pre-configured list of names of
  189.    agents to manage. A management station may allow for an interaction
  190.    with an operator in which a list of manageable agents is acquired
  191.    (via NBP) and presented for the operator to choose which agents
  192.    should be managed by that management station.  Finally, a management
  193.    station may manage all manageable agents in a set of zones or
  194.    networks.
  195.  
  196.    An agent must be configured with the name of a specific management
  197.    station or group of management stations before sending SNMP traps.
  198.    In the absence of any such configured information, an agent is NOT to
  199.    generate any SNMP traps.  In particular, an agent is NEVER to
  200.    initiate a wildcard NBP lookup to find a management station to
  201.    receive a trap.  All NBP lookups generated by an agent must be fully
  202.    specified.  Note, however, that this does not apply to a
  203.    configuration utility that might be associated with such an agent.
  204.    Such a utility may well allow a user to navigate around the network
  205.    to select a management station or stations to receive SNMP traps from
  206.    the agent.
  207.  
  208. 3.3 When To Turn NBP Names Into Addresses:
  209.  
  210.    When SNMP agents or management stations use a cache entry to address
  211.    an SNMP packet, they should attempt to confirm the mapping if it
  212.    hasn't been confirmed in T1 seconds.  This cache entry lifetime, T1,
  213.    has a minimum, default value of 60 seconds.  This value should be
  214.    configurable.
  215.  
  216.    A management station may decide to prime its cache of names prior to
  217.    actually sending any SNMP requests to any given agent.  In general,
  218.    it is expected that a management station may want to keep certain
  219.    mappings "more current" than other mappings.  In particular, those
  220.    nodes which represent the network infrastructure (routers, etc.) may
  221.    be deemed "more important" by the management station.
  222.  
  223.  
  224.  
  225.  
  226. Minshall & Ritter                                               [Page 4]
  227.  
  228. RFC 1419                  SNMP over AppleTalk                 March 1993
  229.  
  230.  
  231.    Note, however, that a long-running management station starting up and
  232.    reading a configuration file containing a number of NBP names should
  233.    not attempt to prime its cache all at once.  It should, instead,
  234.    issue the resolutions over an extended period of time (perhaps in
  235.    some pre-determined or configured priority order).  Each resolution
  236.    might, in fact, be a wildcard lookup in a given zone.
  237.  
  238.    An agent should NEVER prime its cache.  It should do NBP lookups (or
  239.    confirms) only when it needs to send an SNMP trap to a given
  240.    management station.  An agent does not need to confirm a cache entry
  241.    to reply to a request.
  242.  
  243. 3.4 How To Turn NBP Names Into Addresses:
  244.  
  245.    If the only piece of information available is the NBP name, then an
  246.    NBP lookup should be performed to turn that name into a DDP address.
  247.  
  248.    However, if there is a piece of stale information, it can be used as
  249.    a hint to perform an NBP confirm (which sends a unicast to the
  250.    network address which is presumed to be the target of the name
  251.    lookup) to see if the stale information is, in fact, still valid.
  252.  
  253.    An NBP name to DDP address mapping can also be confirmed implicitly
  254.    using only SNMP transactions.  If a management station is sending a
  255.    get-request, it can add a request, in the same packet, for the
  256.    destination's nbpObject and nbpZone corresponding to the nbpEntry
  257.    with the nbpType equal to "SNMP Agent" [3].  The source DDP address
  258.    can be gleaned from the reply and used with the nbpObject and nbpZone
  259.    returned to confirm the cache entry.
  260.  
  261.    The above notwithstanding, for set-requests, there is a race
  262.    condition that can occur where an SNMP request may go to the wrong
  263.    agent (because the old node went down and a new node came up with the
  264.    same DDP address.)  This is problematic becase the wrong agent might
  265.    generate a response packet that the management station could not
  266.    distinguish from a reply from the intended agent.  In the future,
  267.    when SNMP security is implemented, each packet is authenticated at
  268.    the destination, and the reply should implicitly confirm the validity
  269.    of the cache entry used and prevent this race condition.
  270.  
  271. 3.5 What if NBP is broken:
  272.  
  273.    Under some circumstances, there may be connectivity between a
  274.    management station and an agent, but the NBP machinery required to
  275.    turn an NBP name into a DDP address may be broken.  Examples of
  276.    failures which would cause this include:  NBP FwdReq (forward NBP
  277.    lookup onto locally attached network) broken at a router on the
  278.    network containing the agent; NBP BrRq (NBP broadcast request)
  279.  
  280.  
  281.  
  282. Minshall & Ritter                                               [Page 5]
  283.  
  284. RFC 1419                  SNMP over AppleTalk                 March 1993
  285.  
  286.  
  287.    mechanism broken at a router on the network containing the managment
  288.    station (because of a zone table mis-configuration, for example); or
  289.    NBP broken in the target node.
  290.  
  291.    A management station which is dedicated to AppleTalk management might
  292.    choose to alleviate some of these failures by implementing the router
  293.    portion of NBP within the management station itself.  For example,
  294.    the management station might already know all the zones on the
  295.    AppleTalk internet and the networks on which each zone appears.
  296.    Given an NBP lookup which fails, the management station could send an
  297.    NBP FwdReq to the network in which the agent was last located.  If
  298.    that failed, the station could then send an NBP LkUp (an NBP lookup
  299.    packet) as a directed (DDP) multicast to each network number on that
  300.    network.  Of the above (single) failures, this combined approach will
  301.    solve the case where either the local router's BrRq to NBP FwdReq
  302.    mechanism is broken or the remote router's NBP FwdReq to NBP LkUp
  303.    mechanism is broken.
  304.  
  305. 4. Acknowledgements
  306.  
  307.    Some of the boilerplate in this memo is copied from [4], [5], and
  308.    [6].  The Apple-IP Working Group was instrumental in defining this
  309.    document.  Their support and work was greatly appreciated.
  310.  
  311. 5. References
  312.  
  313.    [1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "A Simple
  314.        Network Management Protocol (SNMP)", STD 15, RFC 1157, SNMP
  315.        Research, Performance Systems International, Performance Systems
  316.        International, MIT Laboratory for Computer Science, May 1990.
  317.  
  318.    [2] Sidhu, G., Andrews, R., and A. Oppenheimer, "Inside AppleTalk
  319.        (Second Edition)", Addison-Wesley, 1990.
  320.  
  321.    [3] Waldbusser, S., "AppleTalk Management Information Base", RFC
  322.        1243, Carnegie Mellon University, August 1991.
  323.  
  324.    [4] Schoffstall, M., Davin, C., Fedor, M., and J. Case, "SNMP over
  325.        Ethernet", RFC 1089, Rensselaer Polytechnic Institute, MIT
  326.        Laboratory for Computer Science, NYSERNet, Inc., University of
  327.        Tennessee at Knoxville, February 1989.
  328.  
  329.    [5] Bostock, S., "SNMP over IPX", RFC 1420, Novell, Inc., March 1993.
  330.  
  331.    [6] Piscitello, D., "Guidelines for the Specification of Protocol
  332.        Support of the SNMP", Work in Progress.
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Minshall & Ritter                                               [Page 6]
  339.  
  340. RFC 1419                  SNMP over AppleTalk                 March 1993
  341.  
  342.  
  343. 6. Security Considerations
  344.  
  345.    Security issues are discussed in section 3.4.
  346.  
  347. 7. Authors' Addresses
  348.  
  349.    Greg Minshall
  350.    Novell, Inc.
  351.    1340 Treat Blvd, ste. 500
  352.    Walnut Creek, CA  94596
  353.  
  354.    Phone: 510 947-0998
  355.    Fax:   510 947-1238
  356.    EMail:  minshall@wc.novell.com
  357.  
  358.  
  359.    Mike Ritter
  360.    Apple Computer, Inc.
  361.    10500 North De Anza Boulevard, MS: 35-K
  362.    Cupertino, California 95014
  363.  
  364.    Phone: 408 862-8088
  365.    Fax:   408 862-1159
  366.    EMail: MWRITTER@applelink.apple.com
  367.  
  368.  
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Minshall & Ritter                                               [Page 7]
  395.  
  396.