SNMP stands for Simple Network Management Protocol ie: a mechanism for interaction with networked devices. That is any networked device can be managed and monitored if the receiver and sender can communication by some means. Commonly assumed to mean a connection by LAN but that is not an essential requirement, RS232 FM subcarrier even smoke signals (very low bauds) could be used.
Consult the relevent RFC's for detailed information. There are three elements involved, a Managed Device an which there runs an Agent and a Network Managment Station. The Agent is reponsable for two functions, i) responding to GET and SET request (there are 7 possible NMS originated events) from the NMS and ii) collecting status information on the Managed Device and sending that information to the NMS, thus operation is both synchronous GET, SET request under the control of the NMS and asynchronous sending of status infromation, TRAPS.
Each NMS originated request is defined by a number called an OID (Object IDentifier). Each OID is unique in the universe (the OID number range is so big, it is really mind boggling big) and one of those numbers is unique to the manufacturer of the equipment. These numbers are sent in UDP frames on port 161 with the replies on the same. On the other hand the TRAPS (these also have an OID) that originate from the agent are sent unsolicitated as UPD frames on port 162. Thus the NMS listens on port 162 for traps from all the equipments being monitored.
Although the name OID implies a single object eg: the current drain of a transistor, there is no reason why an object cannot be all the parameters of a FM power amplifier (currents, voltages, powers) in one petition. The problem comes in interpreting the reply. Simple NMS based upon a MIB (Management Information Base) based browser have difficulty with more than one parameter per OID. A manufacture specific NMS can handle this easily. For example a FM transmitter station (up the mountain) can be monitored using SNMP with a Lan connected NMS. A single OID is sent on the RDS channel to the transmitter complex, the transmitters then reply over a SCA channel, information of which is replaced on the LAN to the NMS. This method may be obsolete now adays since many sites now recive th program via AES/EBU on digital links, so the SNMP could easily be embedded in the spare bits of the digital stream. Though to avoid the cost of a return microwave link either a SCA channel or the new RDSv2 would be required as the return channel.
The OID (Object IDentifier) associates a unique number with an object of information or parameter. Either to request (GET) that information or configure (SET) that parameter. The format of the OID is determined in 'arcs', for example (iso.org.dod.internet.private.enterprise) is often known as a wild arc where enterprise is a number that refers to an organisation/manufacture/service. Everything in the tree below the enterprise number is unique to that enterprise. For example 220.127.116.11.4.26637 refers to a company called OMB. Refer to an OID repository for such node numbers (oid-info.com). To be assigned a new number talk to IANA (pen.iana.org) for a Private Enterprise Number (pen). It is then up to the manufacture to define the OID tree under the enterprise specific number.
One thing about the OID does not have to be incorporated in a MIB. An organisation can define a family of OID's for an equipment that are not expressed in the public MIB supplied to customers, a sort of a private/secret set of values (with Wiresharc there are no secrets). For example: 18.104.22.168.4.26622.214.171.124.34 may refer to a transistor drain current, whereas 126.96.36.199.4.266188.8.131.52.34 could refer to an internal OID only to be used for machine-machine communications and as such does not appear in any MIB definition.
The MIB (Management Information Base) is a database that defines the association between an OID and the information required to GET or SET. See the RFS's for details but in brief from the manufacture identifier downwards in tree fashion the OID are developed to link an OID to a piece of information. This is a very structural, (a tree), uses a subset of an encoding called Abstract Syntax Notation One (ASN.1). Supposedlythe MIB has a rigidly defined structure but in reality there are many MIB that contain erros and only work with a specific(manufacture supplied, of cause) browser. However there is no excuse to not apply a self conformance rule. There is a convalidation website (simpleweb.org) that allows MIB to be checked at different levels of rigor. I recomend that the most strict level 6 be used to give the technical support people a rest.
The agent resides in the equipment, normally between the Lan connection and the equipment data interface. The agent can be embedded, that is an integral part of the equipment sysop or an add on that uses an interface to the equipment. If the equipment has a serial port, then that can be used to interrogate the equipment for information and send commands. If the equipment uses relay contacts and analogue measurements that the agent would interface to these.
The agent acts under the control of the NMS most of the time (GET, SET etc...). It is common to have the agent with the abilty to generate TRAPS for example a Heartbeat TRAP is sent by the agent every interval of time (eg: 5min) to inform that everthing is well and shipshape. The NMS expects these heartbeat TRAPS and act accordingly to raise an alarm, trigger remedial action etc, in the event of a Heartbeat going missing. TRAPS take many forms, events such as alarms (overrange of ROE), change of program status, etc....
The NMS centralises the gathering and presentation of the information from a number of agents. Most of the time will be spent listening for TRAPS, though it is common to periodically do a sweep of the equipment status. The NMS can also be used to automate transmittor usage, eg: enter a reduced power night time mode, change frequency to maximise transmitter usage. Here we will look at a typical manufacture specific NMS