Protocol Action: SNMP over Various Protocols to Proposed Standard

[IESG Secretary <[e-mail]>]

Recommendation

  The IESG recommends to the IAB that the following Internet Drafts
  from the SNMP over a Multi-protocol Internet Working Group be
  published as Proposed Standards. The IESG contact persons is Dave
  Piscitello.

   "SNMP over OSI" <draft-ietf-mpsnmp-overosi-03.txt> 
   "SNMP over AppleTalk" <draft-ietf-mpsnmp-appletalk-02.txt>
   "SNMP over IPX" <draft-ietf-mpsnmp-overipx-01.txt>

Technical Summary

   These memos describe the method by which the Simple Network
   Management Protocol (SNMP) as specified in RFC 1157 can be used over
   protocols other than the Internet UDP/IP protocol stack. Also
   specified is information needed to operate secure SNMP (RFCs
   1351-1353) in alternate protocol contexts.

   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.

   These specifications are useful for network elements which have
   alternate protocol support but lack TCP/IP support. Many non-IP
   capable network elements are present in the internet.  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.

 o SNMP Over AppleTalk

   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
   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.

   The memo <draft-ietf-mpsnmp-appletalk-02.txt> specifies the use of
   these AppleTalk protocol mechanisms to transport SNMP messages.

 o SNMP Over IPX

   Mapping SNMP onto IPX is particularly straight-forward since IPX
   provides a datagram service very similar to that provided by
   IP/UDP.

   Although modifications have been made elsewhere in the NetWare
   protocol suite, IPX is identical to the Xerox Internet Datagram
   Protocol (IDP).  The socket address space authority is administered
   by Novell.

   The memo <draft-ietf-mpsnmp-overipx-00.txt> specifies the use of IPX
   protocol mechanisms to transport SNMP messages.

 o SNMP Over OSI

   The memo <draft-ietf-mpsnmp-overosi-03.txt> specifies the operation
   of the SNMP over the OSI connectionless-mode transport service.

   Mapping the SNMP onto the CLTS is straight-forward.  The elements of
   procedure are identical to that of using the UDP.  Note that the
   CLTS and the service offered by the UDP both transmit packets of
   information which contain full addressing information.  Thus, for
   purposes of mapping the SNMP onto the CLTS, a "transport address" in
   the context of RFC 1157, is simply a transport-selector and network
   address.

   It should be noted that the mapping of SNMP onto a
   connectionless-mode transport service is wholly consistent with
   SNMP's architectural principles, as described in RFCs 1157 and
   1270.  However, the CLTS itself can be realized using either a
   connectionless-mode or a connection-oriented network service.  The
   mapping described in this memo allows for either realization.  When
   both network services are available, the CLNS should be used as the
   basis of realization.

Greg Vaudreuil
IESG Secretary