Paradise 205486 REV F - Manual (Page 135)

Operations Manual, HPA2, Compact Outdoor SSPA 208495 REV C 135
introduced GetBulkRequest, an alternative to iterative GetNextRequests for retrieving large
amounts of management data in a single request. However, the new party-based security
system in SNMPv2, viewed by many as overly complex, was not widely accepted.
The format of the trap message was also changed in SNMPv2. To avoid these compatibility
issues, the trap mechanism was not implemented in the Paradise Datacom SSPA MIB.
SNMP V3
Although SNMPv3 makes no changes to the protocol aside from the addition of cryptographic
security, it looks much different due to new textual conventions, concepts, and terminology.
SNMPv3 primarily added security and remote configuration enhancements to SNMP.
Problems with implementing SNMP V2 and V3 in Teledyne Paradise Datacom SSPA product
family
Many embedded controllers and microprocessors that are used in electronic components
such as amplifier modules do not have support for SNMP V2 or V3. This is due to the exten-
sive memory resources required by the computation intensive cryptographic security of SNMP
V3.
For this reason V3 has not gained widespread support amongst embedded MCU platform
manufacturers. Existing port implementations are limited to very powerful ARM5 or above
cores, running under full-scale OS systems (Linux, Android, etc.). At large, these configura-
tions require external bulk RAM/FLASH to operate. This requirement ultimately affects the
minimum device startup time (tens of seconds, due to the large boot BIOS) and working tem-
perature range (mostly indoor).
As noted in Cisco’s release notes about SNMP V3:
SNMP notifications can be sent as traps or informs. Traps are unreliable be-
cause the receiver does not send acknowledg-ments when it receives
traps. The sender cannot determine if the traps were received. However, an
SNMP entity that receives an inform request acknowledges the message with
an SNMP response PDU. If the sender never receives the response, the inform
request can be sent again. Thus, informs are more likely to reach their intended
destination.
However, informs consume more resources in the agent and in the network. Un-
like a trap, which is discarded as soon as it is sent, an inform request must be
held in memory until a response is received or the request times out. Also, a
trap is sent only once, while an inform may be retried several times. The retries
increase traffic and contribute to a higher overhead on the network.
( http://www.cisco.com/en/US/docs/ios/12_0t/12_0t3/feature/guide/Snmp3.html )