Nbi feature description, Nbi feature description. . . . . . . . . . . . f-2 – Comtech EF Data VMS v3.12.x Vipersat User Manual
Page 500
NBI Feature Description
MN/22156, rev 12
F-2
VMS User Guide
NBI Feature Description
In order to reduce the management overhead for typical device monitor queries,
the new NBI feature of the VMS adds many advantages through caching tech-
niques. Each of the devices (modems and gateway routers) in the network, by
design, already report using an unsolicited message that contains the majority of
the key parameters required by monitor systems. These Status Update Messages
(SUM) are sent on 60 second intervals to the active VMS. These messages are
encoded using a highly efficient “over the air” format that can reduce the data
per variable to as little as 5 bits, as compared to a typical SNMP variable bind-
ing consuming hundreds of bits when considering the bi-directional nature of
SNMP. Disregarding per packet overhead, a typical alarm query will require
~300 bits by SNMP, where as the worst case for a SUM would be 9 bits, and for
no alarm states it’s 5 bits. That's a 30x to 60x saving overall, and that is only one
example.
Per packet overhead is also significant. A round trip SNMP message will use
around 128 bytes just for headers within the UDP payload, whereas the SUM
message has a per packet overhead of around 30 bytes. The content of these
SUM messages are parsed and processed to support the UI, system events, and
key internal processes. Some of these collected values are stored in volatile
memory while others are stored to non-volatile memory. In either case, an
active VMS can fulfill all standard queries directly while reducing overhead
significantly.
The nomenclature behind Northbound refers to an interface that conceptualizes
lower level details; e.g., modems and the VMS. It interfaces to higher level
layers (managers) which are normally drawn at the top of an architectural
network overview. With that said, the feature is an exposed single interface that
accepts SNMP messages—GET, GET NEXT, etc.—parses packet data, and
redistributes to internals and network agents. This interface acts as a Proxy to
incoming SNMP requests forwarding to the appropriate handlers, providing a
single point of entry for one or more managers.
The Proxy cache currently accepts MIB OIDs as read only for Series800, CDM-
570, CDD-56X, and SLM-5650/A, and processes a subset of variables using a
proprietary CEFD caching mechanism. All other requests that fall outside of the
scope of the local caching are directly forwarded to the end agent for standard
processing.
The following diagram (figure F-1) depicts a simplistic overview of the module
flow. Note that the Proxy function is integral to the core software libraries of the
VMS.