SNMP ARCHITECTURE
What Is SNMP?
SNMP stands for Simple Network Management Protocol. It is a standard management protocol used to retrieve management information from network devices and equipment, receive notifications of status changes, and modify settings when required.
The IETF SNMP framework divides an SNMP engine into subsystems such as message processing, security, and access control. It then defines applications that issue requests, respond to requests, generate notifications, and receive notifications. SNMP is therefore more than a simple protocol for reading values; it is a framework for handling management information securely and continuously.
Managing Side
Sends requests, receives responses and notifications, and aggregates equipment status.
Managed Side
Exposes internal device status through a MIB and responds to requests.
Meaning of Information
Identifies values such as voltage, temperature, and operating status and defines what they mean.
Status Change Notification
Reports faults and events to the monitoring side so that the initial response can begin sooner.
The SNMP architecture is defined in RFC 3411, application types in RFC 3413, and the principal protocol operations in RFC 3416.
OUR PROTOCOL STACK
Implementing SNMP In-House to Integrate Different Equipment into One Monitoring Framework
We do more than register SNMP-enabled devices with a commercial monitoring service. We have developed our own SNMP protocol stack and MIB and have continuously operated monitoring, management, and remote control for actual customer equipment for more than 20 years.
Commercial SNMP devices and standard MIBs alone could not adequately represent the power, communications, control, fault, and other information required for our operations. This created the need for proprietary MIBs and protocol implementations tailored to the monitored equipment and its operating requirements.
Information obtained from serial devices connected through RS-485, RS-232C, and similar interfaces is also defined as SNMP management objects. This allows Ethernet devices, power equipment, sensors, and control equipment to be handled consistently through the same monitoring platform.
A defining feature of our SNMP technology is the ability to normalize different communication methods and equipment information through MIBs, seamlessly connecting identification, monitoring, control, and historical records.
Understand the Protocol
- Understand request, response, and notification processing in-house
- Design timeouts, retries, and communication loss as operating conditions
- Integrate different devices and generations into the same monitoring framework
- Define required management information as MIB objects and OIDs
Understand the Field Environment
- Distinguish communication loss from device shutdown
- Correlate power abnormalities with network abnormalities
- Distinguish temporary fluctuations from persistent failures
- Connect notifications to maintenance, escalation, and recovery procedures
Technical differences are difficult to see during normal operation.
The value of a monitoring platform becomes clear under abnormal conditions: no response, implausible values, duplicate notifications, or simultaneous instability in communications and power. Without understanding both the protocol and the field equipment, an anomaly shown on a screen cannot be connected to its cause.
MIB / OBJECT IDENTIFIER
Collecting Values Alone Is Not Monitoring
Values retrieved through SNMP are given meaning by MIBs and OIDs. Even when two values are represented by the same integer type, voltage, temperature, operating status, and alarm codes have different units and normal ranges. A monitoring platform must define not only the name of each value, but also its type, unit, update interval, threshold, state transitions, and treatment of missing data.
| Information | Monitoring Significance | Conditions Required for Judgment |
|---|---|---|
| Voltage, Current, and Power | Power status, load variation, and available capacity | Ratings, input source, operating mode, and duration |
| Temperature | Environmental abnormality, insufficient cooling, and component degradation | Installation location, season, load, and sensor position |
| Communication Response | Reachability, device operation, and path status | Circuit, router, power supply, and timeout conditions |
| Alarm and Status Codes | Failure, protective action, and operating-mode change | Device specifications, preceding values, and correlation with other sensors |
A MIB is not merely a list of items. It is a common language that allows equipment status to be interpreted consistently from a remote location.
POLLING + NOTIFICATION
Combining Periodic Checks with Event Notifications
Monitoring is incomplete when it relies only on polling at fixed intervals or only on notifications such as traps sent by devices. Combining both methods and correlating them with communication-path and power-status information reduces missed abnormalities and false judgments.
POLLING
Check Periodically
Continuously track value trends, response times, missing data, and status changes. This covers abnormalities that do not generate notifications and gradual deterioration.
TRAP / INFORM
Report Changes Immediately
Notify the monitoring side of events detected by the device and begin the initial response without waiting for the next polling cycle.
CORRELATION
Correlate Multiple Sources
Compare responses, voltage, communication paths, and other devices at the same site to distinguish a single-device failure from a site-wide outage.
RFC 3413 separately defines applications that issue and respond to requests and applications that generate and receive notifications.
NETWORK + POWER
Communication Failure or Power Failure?
One of the most difficult problems in SNMP monitoring is that a single result, no response, can have many possible causes. Device failure, circuit disconnection, router shutdown, authentication settings, congestion, utility power loss, and UPS shutdown may all appear as the same non-response condition on a monitoring screen.
When Monitoring the Network Alone
- Judge failures only by the presence or absence of Ping and SNMP responses
- Cannot distinguish communication loss from device power loss
- Cannot track restart behavior or instability after power restoration
- May fail to record temporary stoppages caused by momentary interruptions or voltage dips
When Monitoring Communications and Power Together
- Correlate communication responses with input-power and stored-energy status
- Distinguish a site-wide outage from a single-device failure
- Review state transitions before and after a power outage in chronological order
- Verify voltage, load, and communication stability after recovery
Why We Expanded Our Technology into Power Systems
Continuous network monitoring reveals that communication continuity is governed by power quality. We have developed SNMP, remote monitoring, smart meters, UPS systems, and distributed power as one operational framework for keeping equipment running, rather than as separate products.
OPERATIONAL DOMAINS
snmp.jp and ethernet.jp as an Operational Foundation for Long-Term Monitoring
We have continuously managed and operated the SNMP- and Ethernet-related domains snmp.jp and ethernet.jp for more than 20 years.
These domains are used as part of systems that monitor and manage actual customer equipment. They continuously connect monitored devices, management servers, and communication paths and are operational assets that support status verification, alarm notification, and remote management.
Maintaining dedicated domains over the long term preserves the identity of the monitoring system and the continuity of its connection endpoints, allowing the same operating framework to continue after equipment replacement.
snmp.jp
It represents our core technology in SNMP monitoring and management and is also a practical domain asset maintained in long-term operation.
ethernet.jp
It is a domain asset representing our technical origins in Ethernet and our operational network infrastructure.
For security reasons, we do not disclose the architecture, connection endpoints, authentication methods, user information, or operating procedures of the monitoring systems. This page explains only the technical and historical significance of using these domains in actual operations.
SECURITY AND ACCESS CONTROL
Separating What Can Be Observed from What Can Be Controlled
In remote monitoring, permission to retrieve information must not be treated in the same way as permission to change settings. Targets, users, operations, connection sources, time, and records must be separated, and the system must operate with the minimum privileges required.
| Function | Purpose | Primary Controls |
|---|---|---|
| Read | Review status values, settings, and history | Scope, viewers, and retrieval frequency |
| Write / Control | Configuration changes, state switching, and remote operation | Separation of privileges, condition checks, and operation records |
| Notify | Notification of faults and events | Destinations, filtering, and duplicate suppression |
The SNMPv3 framework defines the User-based Security Model, or USM, for user-based authentication and privacy protection, and the View-based Access Control Model, or VACM, for controlling read, write, and notification access to management information. The SNMP version, cryptographic methods, network segmentation, and connection methods must nevertheless be designed according to the constraints and risks of the target equipment.
USM is specified in RFC 3414 and VACM in RFC 3415. This page does not disclose the specific security architecture of our monitoring environment.
AUTONOMY / ECONOMIC SECURITY
Understanding and Maintaining the Monitoring Platform In-House
Economic security is not determined only by whether equipment is manufactured domestically or overseas. What matters is who identifies the devices, who reads the management information, who evaluates abnormalities, and whether operations can continue when an external service becomes unavailable.
Identification
Meaning
Observation and Control
Continuity
We combine our own OUI, in-house SNMP protocol stack, proprietary MIB, monitoring platform, power technology, and domestic maintenance capability. The value lies in being able to understand equipment status and make recovery decisions during abnormal conditions without depending solely on a specific vendor or cloud interface.
SNMP by itself is not economic security.
The operational capability to understand and sustain identification, monitoring, control, power, and maintenance in-house contributes to the autonomy, stable operation, and explainability of critical infrastructure.
20+ YEARS OF OPERATION
Long-Term Operation Accumulates More Than Data
Over more than 20 years of operation, equipment upgrades, circuit changes, site relocations, changes in communication methods, component obsolescence, power outages, lightning, and natural disasters create conditions that cannot all be anticipated in the initial design. A monitoring platform must be designed to absorb these changes while continuing to operate.
Bridge Generations
Connect old and new equipment and different communication methods to the same operating framework.
Accommodate Site Differences
Reflect differences in circuits, power, environment, and maintenance conditions at each site in the monitoring criteria.
Preserve Operational Judgment
Accumulate logs, responses, and recovery outcomes from abnormal events and use them in future decisions.
The result of long-term monitoring is not measured by how many years of graphs are stored, but by the ability to keep changing equipment in operation.
CONCLUSION
From Visibility to Operational Judgment
The purpose of remote monitoring is not merely to display equipment values on a screen. It is to create a state in which operators can determine which device is where, what condition it is in, what caused the problem, and who should respond, when, and how.
For more than 20 years of actual operation, we have connected our own OUI, in-house SNMP protocol stack, proprietary MIB, customer monitoring platform, and power technology. SNMP is not a legacy network technology; it is a current foundation for the autonomous operation of AI, communications, power, medical, municipal, disaster-prevention, and industrial equipment.
References
- RFC 3411: SNMP Management Frameworks Architecture
- RFC 3413: SNMP Applications
- RFC 3414: SNMPv3 User-based Security Model
- RFC 3415: View-based Access Control Model
- RFC 3416: SNMP Protocol Operations
- RFC 3418: Management Information Base for SNMP
- Cabinet Office of Japan: System for Ensuring the Stable Provision of Critical Infrastructure Services
- IPA Japan: Requirements Development Guide for Systems Handling Important Information
This page contains technical information independently prepared and published by Kei Communication Technology Inc. It is not an official page operated or endorsed by IEEE or the IEEE Standards Association. Explanations of IEEE 802, OUI, EUI-48, EUI-64, and related identifiers are based on publicly available information from IEEE and the IEEE Registration Authority.
