As per Relevance of the word services, we have this rfc below:
Network Working Group F. Kastenholz,
Request for Comments: 1270 Clearpoint Research
October 1991
SNMP Communications
Status of This
This memo provides information for the Internet community. It
not specify an Internet standard. Distribution of this memo
unlimited
Table of
1. Abstract .............................................. 1
2. Introduction .......................................... 1
3. Standardization ....................................... 3
4. Interoperability ...................................... 3
5. To Transport or Not To Transport ...................... 3
6. Connection Oriented vs. Connectionless ................ 6
7. Which Protocol ........................................ 8
8. Security Considerations ............................... 9
9. Appendix .............................................. 9
10. References ........................................... 10
11. Acknowledgements ..................................... 11
12. Author's Address ..................................... 11
1.
This memo is being distributed to members of the Internet community
an Informational RFC. The intent is to present a discussion on
issues relating to the communications services for SNMP. While
issues discussed may not be directly relevant to the research
of the Internet, they may be interesting to a number of
and implementors
2.
This document discusses various issues to be considered
determining the underlying communications services to be used by
SNMP implementation
As reported in RFC 1052, IAB Recommendations for the Development
Internet Network Management Standards [8], a two-prong strategy
network management of TCP/IP-based internets was undertaken. In
short-term, the Simple Network Management Protocol (SNMP), defined
RFC 1067, was to be used to manage nodes in the Internet community
SNMP Working Group [Page 1]
RFC 1270 SNMP Communications Services October 1991
In the long-term, the use of the OSI network management framework
to be examined. Two documents were produced to define the
information: RFC 1065, which defined the Structure of
Information (SMI), and RFC 1066, which defined the
Information Base (MIB). Both of these documents were designed so
to be compatible with both the SNMP and the OSI network
framework
This strategy was quite successful in the short-term: Internet-
network management technology was fielded, by both the research
commercial communities, within a few months. As a result of this
portions of the Internet community became network manageable in
timely fashion
In May of 1990, the core documents were elevated to "
Protocols" with "Recommended" status. As such, the Internet-
network management framework consists of: Structure and
of Management Information for TCP/IP-based internets, RFC 1155 [9],
which describes how managed objects contained in the MIB are defined
Management Information Base for Network Management of TCP/IP-
internets, which describes the managed objects contained in the MIB
RFC 1156 [10]; and, the Simple Network Management Protocol, RFC 1157
[1], which defines the protocol used to manage these objects
In parallel with this activity, documents specifying how to
SNMP messages over protocols other than UDP/IP have been developed
published: SNMP Over Ethernet [3], SNMP Over OSI [2], and SNMP
IPX [6] and it would be suprising if more were not developed.
memos have caused a degree of confusion in the community.
document is intended to disperse that confusion by discussing
issues of relevance to an implementor when choosing how to
SNMP packets
None of these documents have been made full Internet Standards.
Over ISO and SNMP Over Ethernet are both Experimental protocols.
Over IPX [6] is an Internet Draft. Only the SNMP Specification [1]
an Internet Standard
No single transport scheme can be considered the absolute
solution for all circumstances. This note will argue that, except
a very small set of special circumstances, operating SNMP over UDP/
is the optimal scheme
This document does not present a standard or a protocol for
Internet Community. For production use in the Internet the SNMP
its required communication services are specified in [1].
SNMP Working Group [Page 2]
RFC 1270 SNMP Communications Services October 1991
3.
Currently, the SNMP Specification [1] only specifies that the
protocol be used to exchange SNMP messages. While the IAB
standardize other protocols for use in exchanging SNMP messages in
future, only UDP is currently standardized for this purpose
In order to claim full compliance with the SNMP Specification,
implementation would have to use UDP for SNMP message exchange
4.
Interoperability is the degree to which the equipment produced by
vendor can can operate with equipment produced by another vendor
Related to Interoperability is compliance with a standard.
else being equal, a device that complies with some standard is
likely to be interoperable than a device that does not
For commercial product development, the pros and cons of developing
interoperable product must be weighed and a choice made.
engineering and marketing organizations participate in this process
The Internet is the single largest market for SNMP systems. A
portion of SNMP systems will be developed with the Internet as
target environment. Therefore, it may be expected that the Internet'
needs and requirements will be the driving force for SNMP. SNMP
UDP/IP is specified as the "Internet Standard" protocol. Therefore
in order to operate in the Internet and be managed in that
on a production basis, a device must support SNMP over UDP/IP.
situation will lead to SNMP over UDP/IP being the most common
of operating SNMP. Therefore, the widest degree of
and widest acceptance of a commercial product will be attained
operating SNMP over UDP/IP
The preponderance of UDP/IP based network management stations
strongly suggests that an agent should operate SNMP over UDP/IP
The results of the interoperability decision drive a number
technical decisions. If interoperability is desired, then SNMP must
operated over UDP/IP
5. To Transport or Not To
A major issue is whether SNMP should run on top of a transport-
protocol (such as UDP) or not. Typically, the choice is to run over
transport/network/data link protocol or just run over the datalink
In fact, several protocols have been published for operating SNMP
SNMP Working Group [Page 3]
RFC 1270 SNMP Communications Services October 1991
several different datalink and transport protocols
Operation of SNMP over a Transport and Network protocol
is preferred. These protocols provide at least five
that are of vital importance to the movement of SNMP
through a network
o
The network layer provides routing functions,
improves the overall utility of network management.
network has the ability to re-route packets around
areas. This allows network management to
operating during localized losses of service (It
be noted that these losses of service occur not
because of failures, but also for non-failure
such as preventive maintenance).
o Media
The network layer provides a high degree of
independence. By using this capability, many
types of network elements may be managed. Tying SNMP
a particular data link protocol limits the
scope of those SNMP entities to just those devices
use that datalink protocol
o End-to-End
The end-to-end checksum provided by transport
improves the reliability of the data transfer
o Multiplexing/
Transport protocols provide multiplexing
demultiplexing services. These services facilitate
many-to-many management relationships possible with SNMP
o Fragmentation and
This is related to media independence. IP allows
packets to transit media with differing MTU sizes.
capability is not available for datalink
transmission schemes
Fragmentation and Reassembly does reduce the
robustness of network management since, if any
fragment is lost along the way, the operation will fail
The worse the network operates, the higher
probability that a fragment will get lost or delayed
For monitoring and data gathering while the network
operating normally, Fragmentation and Reassembly is not
problem. When the network is operating poorly (and
SNMP Working Group [Page 4]
RFC 1270 SNMP Communications Services October 1991
network operators are typically trying to diagnose
repair a failure), small packets should to be used
preventing the packet from being fragmented
There are other services and functions that are provided by
connection oriented transport. These services and functions are
desired for SNMP. A later section will explore this issue in
detail
The main drawbacks that are cited with respect to using Transport
Network layers in the managed object are: a) Increased
time and b) Increased resource requirements. These arguments
less than compelling
There are several excellent public domain or freely
UDP/IP stacks that provide enough support for SNMP. The
required to port the essential components of one of these stacks
small compared to the overall effort of installing the SNMP software
The additional resources required in the managed object to
UDP/IP are minimal. CPU resources are required only when
transmitting or receiving a packet. The largest single
requirement of a UDP/IP is calculating the UDP checksum, which
very small compared to the cost of doing the ASN.1 encoding/decoding
Object Identifier lookup, and so on
The author has personal knowledge of a UDP/IP stack that
developed expressly for the purpose of supporting SNMP. This
requires less than 4Kb of code space. It is a
implementation of UDP/IP in that it is "just enough" so support SNMP
This stack supports UDP, IP, ARP, and handles ICMP redirect and
request messages. Furthermore, this stack was developed by a
person in approximately two months. Obviously, neither
development effort nor the memory requirements are large
The network overhead of using UDP/IP is relatively small. A UDP/
header requires 28 octets (assuming no IP options). Since the UDP
connectionless, it will generate no overhead traffic of its own (
as TCP SYNs, FINs, and ACKs).
The growing popularity of internetworking outside of The
mandates that SNMP operate over, at least, a network layer protocol
These internetworks consist of a number of networks all
together with routers. In order to traverse a router, a packet
be one of the network layer protocols that the router understands
Therefore, for SNMP management to be deployed in an internetwork,
SNMP entities in that internetwork must use a network layer protocol
SNMP over a datalink can not traverse a router
SNMP Working Group [Page 5]
RFC 1270 SNMP Communications Services October 1991
There are some circumstances where running SNMP over some datalink
appropriate
There are schemes are under development to provide Out-Of-Band (OOB
management access to network devices. This OOB access is
provided over point-to-point or dial-up connections. Since
connections are dedicated to OOB network management and go
from the network management station to the managed device,
Transport/Network protocol may not be necessary
Using a Transport/Network protocol on these links may be easier
a development point of view though. It is probably a
configuration operation to have the management station's IP use
serial port rather than the "normal" (e.g., Ethernet) port
traffic destined for a particular node
If the Out-Of-Band link is also used as a "primary" route to
nodes, then the functions of a network-layer are required.
functions are readily supplied by using UDP/IP
For a datalink interface and driver (e.g., a PC Ethernet
card) that must be manageable independent of the higher
protocol suite (which might NOT be manageable), operating
directly over the datalink is reasonable. It is not known, a priori
what higher-level protocol services may be available, so
services can not be used. If an arbitrary choice is made
example, to put in an elementary UDP/IP stack, then there may be
independent UDP/IPs in the system (which is undesireable as
would require two IP addresses per managed node), or a new
stack will be introduced into the environment
6. Connection Oriented vs.
While this section primarily addresses itself to transport
issues, its basic discussion of connection oriented vs
applies to any layer which provides communication services for SNMP
For SNMP, connectionless transport service (UDP) is specified in
Protocol Specification [1]. This choice was made after careful
and consideration by the original SNMP developers
The prime motivation of this choice is that SNMP must continue
operate (if at all possible) when the network is operating at
worst. For other applications, such as Telnet or FTP, the user
always "try again later" if the network is operating poorly. On
other hand, the major purpose of a network management protocol is
fix the network when it is operating poorly so the "try again later
strategy is useless
SNMP Working Group [Page 6]
RFC 1270 SNMP Communications Services October 1991
By using a connectionless transport protocol, SNMP takes on
responsibility of reliable data transmission (A SNMP application
time out outstanding requests and either retransmit them or
them as appropriate). However, the SNMP requires these
only of the sender of a Request PDU (get, getNext, or Set),
typically is a network management station. Since the Agent
generates responses, it need not perform any of these functions
This vastly reduces the resource and functional requirements on
Agent
If a connection oriented transport is used, then a fundamental
choice must be made with respect to connection maintenance
(1) Keep a connection open to each managed object on
network
(2) Establish and tear down connections on a per-
basis,
(3) Keep a fixed number of connections open and, when
connection is needed, use some algorithm (e.g., LRU)
select one for closing and opening to the new agent
All of these alternatives pose severe problems, and because of them
each is undesirable
The first option reduces the amount of resources required to
a single operation in that the connection establishment
termination cost is "amortized" over many operations. On the
hand, keeping a connection open implies that the management
needs to maintain a large number of connection records (in
hundreds or even thousands). Furthermore, if either side of
connection engages in "keep-alives" (even though such behavior
frowned upon), a large amount of traffic will be generated,
a large amount of network resources, all for no gain
The second option reduces the amount of idle resources such
connection records, but vastly increases the amount of
required to perform an operation. A connection must be established
the request Message sent and the response returned, and then
connection closed for each operation. For a TCP, this
typically require 10 separate packet transfers plus the TCP Time-
(see the Appendix for details).
In the face of pathological network problems, a connection
transport protocol may simply cease to operate because
probability of getting all of these packets through reduces to a
small number
SNMP Working Group [Page 7]
RFC 1270 SNMP Communications Services October 1991
The third option requires that the management station
connection usage information in order to implement the LRU algorithm
This excessively complicates the management station. Furthermore
this option tends to reduce to the second option when doing
check polling for a number of agents that is large compared to
number of supported connections
A connection oriented transport protocol may provide services
are undesirable or unneeded by SNMP
For example, one application of network management is to poll
to determine if they are up or not. When a node is up, it
little difference whether SNMP operates over TCP or UDP. However,
the node goes down then TCP will eventually close the connection
Every poll request must then be translated into a TCP Open
while the managed node is down. Once the node comes up, the
must then be done
For connection oriented transports, the transport ACK does
necessarily indicate delivery of data to the destination
process (for TCP, see section 2.6 of [4]). The SNMP would still
its own timeout/retry procedure to ensure that the SNMP
actually got the packet
A connection oriented transport such as TCP provides flow control
the data stream. Because of the lock-step nature of SNMP
exchanges, this is not a service that SNMP requires
Architectural purists may argue that an "Application" layer
(SNMP) must not perform operations that are properly the realm of
Transport layer (timeouts, retransmissions, and so on).
architecturally pure, this line of reasoning is not relevant.
network management applications and protocols are monitoring
"health" of the network and, as a result, have the best
and are in the best position to adapt their own behavior to the
of the network, and thereby, continuing operations in the face
network adversity
7. Which
The final point of discussion is the actual choice of a protocol
support SNMP
If a device is destined for use in the Internet then it must
SNMP over UDP/IP
If the device is operating in some other protocol environment,
SNMP ought to use the transport services that are native to
SNMP Working Group [Page 8]
RFC 1270 SNMP Communications Services October 1991
environment. It may make very little sense to introduce a
protocol stack into a network in order to provide just one service
For example, it could require that the network operations
understand and be able to administer and operate two protocol stacks
that hosts and routers understand both protocols, and so on. It
also be bureaucratically impossible to introduce UDP/IP into
environment (the "We are only a FOONET shop - if it doesn't
FOONET, we don't want it" argument).
References [2] and [6] are experimental standards for operating
over IPX and OSI respectively. In these environments,
standards ought to be adhered to
8. Security
Security issues are not discussed in this memo
9.
This appendix details the TCP packet transfers required to perform
single SNMP operation assuming that the connection is
only for that operation and that a single SNMP operation (e.g.,
request) is performed. We also assume that all operations
"normal" i.e., that there are no lost packets, no simultaneous opens
no half opens, and no simultaneous closes. We also ignore
possibility of TCP segmentation and IP fragmentation
The nomenclature used to illustrate the packet transactions is
same as that used in the TCP Specification [4].
SNMP Working Group [Page 9]
RFC 1270 SNMP Communications Services October 1991
Packet Management
Number Station
Connection Open...
1 >------------------------->
2 <---------------------<
3 >------------------------->
Connection now open
SNMP Request is sent
4 >--------------->
Response comes
5 <--Response, CTL=ACK>---<
6 >------------------------->
Operation is complete
Management station initiates
close
7 >--------------------->
8 <-------------------------<
9 <---------------------<
10 >------------------------->
Wait 2
Connection now closed
Some optimizations are possible IF the TCP has knowledge of the
of operation. However, a general purpose TCP would not be tuned
SNMP operations so those optimizations would not be done
10.
[1] Case, J., Fedor, M., Schoffstall, M., and J. Davin, "
Network Management Protocol", RFC 1157, SNMP Research
Performance Systems International, Performance
International, MIT Laboratory for Computer Science, May 1990.
[2] Rose, M., Editor, "SNMP over OSI", RFC 1161, Performance
International, Inc., June 1990.
[3] 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.
[4] Postel, J., "Transmission Control Protocol - DARPA
Program Protocol Specification", RFC 793, DARPA, September 1981.
[5] Postel, J., "User Datagram Protocol", RFC 768, USC/
Sciences Institute, August 1980.
[6] Wormley, R., "SNMP Over IPX", draft in process, August 1990.
SNMP Working Group [Page 10]
RFC 1270 SNMP Communications Services October 1991
[7] Postel, J., Editor, "IAB Official Protocol Standards", RFC 1250,
IAB, August 1991.
[8] Cerf, V., "IAB Recommendations for the Development of
Network Management Standards", RFC 1052, NRI, April 1988.
[9] Rose M., and K. McCloghrie, "Structure and Identification
Management Information for TCP/IP-based internets", RFC 1155,
Performance Systems International, Hughes LAN Systems, May 1990.
[10] McCloghrie K., and M. Rose, "Management Information Base
Network Management of TCP/IP-based internets", RFC 1156,
LAN Systems, Performance Systems International, May 1990.
11.
The author wishes to thank Jeff Case, Chuck Davin and
McCloghrie for their technical and editorial contributions to
document
12. Author's
Frank
Clearpoint Research
35 Parkwood
Hopkinton, Mass. 01748
Phone: (508) 435-2000
Email: kasten@europa.clearpoint.
SNMP Working Group [Page 11]
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
