[ntpwg] NTPv4 MIB Revised Version 1.3
Heiko Gerstung
heiko.gerstung at meinberg.de
Mon Feb 27 08:31:29 UTC 2006
Hi!
In preparation for Dallas I modified the MIB according to our
discussions, it now represents all floating point values as
DisplayString objects.
One thing I am unsure of is the location of the MIB in the MIB tree.
Enterprise-specific MIBs are located under
.iso.org.dod.internet.private.enterprises. (e.g. the Meinberg MIB
Objects are all located under
.iso.org.dod.internet.private.enterprises.5597), but
this one should be located under .iso.org.dod.internet.mgmt.mib-2 and I
guess we need to ask IANA for a number assignment.
I also tried to add the RFC stuff like header, introduction, copyright
statement, security considerations and so on. I kindly request all RFC
gurus to check the formalities and all of you to read the introduction
and technical description in order to give me some feedback and let me
know where something sounds too much like pidgin english..
Regards (and a nice start-of-the-week to everyone),
Heiko
--
------------------------------------------------------------------------
*MEINBERG Funkuhren*
Auf der Landwehr 22
D-31812 Bad Pyrmont, Germany
Tel.: ++49 (0)5281 9309-25
Fax: ++49 (0)5281 9309-30
eMail: heiko.gerstung at meinberg.de <mailto:heiko.gerstung at meinberg.de>
Internet: www.meinberg.de <http://www.meinberg.de/>
------------------------------------------------------------------------
Meinberg radio clocks: 25 years of accurate time worldwide
-------------- next part --------------
NTP Working Group Heiko Gerstung
Request for Comments: xxxx Meinberg Funkuhren
Category: Standards Track Gmbh & Co. KG
March 2006
Definitions of Managed Objects for
Network Time Protocol Version 4 (NTPv4)
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
The Network Time Protocol (NTP) is used in networks of all types and
sizes for time synchronization of servers, workstations and other
networked equipment. As time synchronization is more and more a
mission critical service, standardized means for monitoring and
management of this subsystem of a networked host are required to
allow operators of such a service to setup a monitoring
system that is platform- and vendor-independant.
This RFC draft provides a standardized collection
of data objects for monitoring the NTP service of such a network
participant and it is part of the NTP Version 4 standardization effort.
Table of Contents
1. The Internet-Standard Management Framework ......................2
2. Introduction ....................................................2
3. Technical Description ...........................................3
4. MIB Definition ..................................................4
5. IANA Considerations ............................................xx
6. Security Considerations ........................................xx
7. Normative References ...........................................xx
8. Informative References .........................................xx
Gerstung Standards Track [Page 1]
RFC xxxx NTPv4 MIB March 2006
1. The Internet-Standard Management Framework
For a detailed overview of the documents that describe the current
Internet-Standard Management Framework, please refer to section 7 of
RFC 3410 [RFC3410].
Managed objects are accessed via a virtual information store, termed
the Management Information Base or MIB. MIB objects are generally
accessed through the Simple Network Management Protocol (SNMP).
Objects in the MIB are defined using the mechanisms defined in the
Structure of Management Information (SMI). This memo specifies a MIB
module that is compliant to the SMIv2, which is described in STD 58,
RFC 2578 [RFC2578], STD 58, RFC 2579 [RFC2579] and STD 58, RFC 2580
[RFC2580].
2. Introduction
The NTPv4 MIB Module is designed to allow SNMP to be used to monitor
and manage local NTP service instances. It provides a collection of
data objects that can be queried using the SNMP protocol and represent
the current status of the NTP service instance. This includes general
information about the NTP service instance itself (vendor, product,
version) as well as connectivity to upstream NTP servers used as
sources of reference time and to hardware reference clocks like radio
clocks. The most important values are included in order to be able to
detect failures before they can have an impact on the overall time
synchronization status of the network.
Gerstung Standards Track [Page 2]
RFC xxxx NTPv4 MIB March 2006
3. Technical Description
The NTPv4 MIB Module is divided into sections for general server
information, current NTP service status, status information of all
mobilized associations (e.g. unicast upstream time servers, multicast
or broadcast time references and hardware clocks) as well as SNMP trap
definitions for core events.
The general server information section contains static information and
can be queried to identify which NTP service implementation is running
on a host. This includes the vendor and product name of the running NTP
software as well as version information, hardware/os platform identity
and the time resolution of the underlying OS.
Section 2 (current NTP status) includes data objects that represent the
current operational status of the NTP service instance.
The third section contains data objects that represent the set of time
references ("associations") the NTP instance is currently working with.
Certain important events can occur while the NTP instance is running.
The fourth section defines SNMP traps for a collection of the most
important ones ("core events") and additionally provides a heartbeat trap
as well as a test trap to allow management systems to test the reception
of NTP related traps as well as enable heartbeat-based monitoring systems
to assure that the NTP service is still up and running.
Gerstung Standards Track [Page 3]
RFC xxxx NTPv4 MIB March 2006
4. MIB Definition
-- **************************************************************************
--
-- $Id: ntpv4-snmp-mib-draft.mib 1.5 2006/02/27 08:28:16Z heiko TRASH $
-- $Name: $
--
-- The Network Time Protocol Version 4
-- Management Information Base (MIB)
--
-- Author: Heiko Gerstung (heiko.gerstung at meinberg.de)
-- for the Internet Engineering Task Force (IETF)
-- NTP Working Group (ntpwg)
--
--
-- **************************************************************************
--
-- $Log: ntpv4-snmp-mib-draft.mib $
-- Revision 1.5 2006/02/27 08:28:16Z heiko
-- - changed to RFC format and added header as well as
-- introduction and technical description
-- - added other necessary RFC components (copyright statement etc.)
-- Revision 1.4 2006/02/27 07:06:49Z heiko
-- - removed all objects with data type REAL
-- - everything that needs to be floating point is now defined as DisplayString
-- Revision 1.2 2006/01/23 08:58:11Z heiko
-- - changed the datatype of offset, jitter and delay objects from Integer32
-- to REAL
--
-- **************************************************************************
NTPv4-MIB DEFINITIONS ::= BEGIN
IMPORTS
MODULE-IDENTITY, OBJECT-TYPE , Integer32, NOTIFICATION-TYPE, enterprises
FROM SNMPv2-SMI
MODULE-COMPLIANCE, OBJECT-GROUP, NOTIFICATION-GROUP
FROM SNMPv2-CONF
DisplayString FROM SNMPv2-TC;
ntpSnmp MODULE-IDENTITY
LAST-UPDATED "200512190000Z"
ORGANIZATION "www.ietf.org"
CONTACT-INFO
" The IETF NTP Working Group (ntpwg)"
DESCRIPTION
" Management Information Base for NTP time servers"
REVISION "200511160000Z"
DESCRIPTION
"Initial draft"
REVISION "200512190000Z"
DESCRIPTION
"revised edition (added traps and stuff)"
::= { xxxTODOxxx }
--
-- Section 1: General Server information objects (static information)
--
ntpSrvInfo OBJECT IDENTIFIER ::= { ntpSnmp 0 }
ntpSrvSoftwareName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"product name of the installed NTP version"
-- the product name of the running ntp implementation, e.g. "ntpd"
::= { ntpSrvInfo 1 }
ntpSrvSoftwareVersion OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Software version of the installed NTP implementation"
-- full version string, e.g. "ntpd-4.2.0b at 1.1433 ..."
::= { ntpSrvInfo 1 }
ntpSrvSoftwareVersionVal OBJECT-TYPE
SYNTAX Integer32 (-2147483648..2147483647)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Software version of installed NTP as an Integer32 value"
-- e.g. if version string is "4.2.0b" this could be translated into 4202
-- could be useful to find out if version of server a is newer or older
-- than version of server b (without too much string parsing trouble)
::= { ntpSrvInfo 2 }
ntpSrvSoftwareVendor OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"the vendor/author of the installed NTP version"
::= { ntpSrvInfo 3 }
ntpSrvSystemType OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"general hardware/os platform information"
-- e.g. "Linux 2.6.12 / x86"
-- freely configurable, default is OS Version / Hardware platform
::= { ntpSrvInfo 4 }
ntpSrvTimeResolution OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"string describing the time resolution of the running NTP
implementation"
-- e.g. "100ns"
-- depends on the NTP implementation and the underlying OS. The current
-- resolution should be used, so if the OS only supports 10ms and ntpd is
-- capable of 1ns, the 10ms should be advertised
::= { ntpSrvInfo 5 }
ntpSrvTimeResolutionVal OBJECT-TYPE
SYNTAX Integer32
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"time resolution in integer format"
-- ntpSrvTimeResolution in Integer format
-- shows the resolution based on 1 second, e.g. "1ms" translates to 1000
::= { ntpSrvInfo 6 }
--
-- Section 2: Current NTP status (dynamic information)
--
ntpSrvStatus OBJECT IDENTIFIER ::= { ntpSnmp 1 }
ntpSrvStatusCurrentState OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"actual status of NTP as a string"
--- possible strings:
--- "not running" : NTP is not running
--- "not synchronized" : NTP is not synchronized to any time source
--- (stratum = 16)
--- "sync to local" : NTP is synchronized to own local clock
--- (degraded reliability)
--- "sync to refclock" : NTP is synchronized to a local hardware refclock
--- (e.g. GPS)
--- "sync to remote server" : NTP is synchronized to a remote NTP server
--- ("upstream" server)
::= { ntpSrvStatus 1 }
ntpSrvStatusCurrentStateVal OBJECT-TYPE
SYNTAX INTEGER {
notRunning(0),
notSynchronized(1),
syncToLocal(2),
syncToRefclock(3),
syncToRemoteServer(4),
unknown(99)
}
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"current state of the NTP as integer value"
-- see ntpSrvStatusCurrentState
DEFVAL { 99 }
::= { ntpSrvStatus 2 }
ntpSrvStatusStratum OBJECT-TYPE
SYNTAX INTEGER (1..16)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"own stratum value"
-- should be stratum of syspeer + 1 (or 16 if no syspeer)
DEFVAL { 99 }
::= { ntpSrvStatus 3 }
ntpSrvStatusActiveRefclockId OBJECT-TYPE
SYNTAX INTEGER ( 0..99999 )
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"the association ID of the current syspeer"
DEFVAL { 99 }
::= { ntpSrvStatus 4 }
ntpSrvStatusActiveRefclockName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"The hostname/descriptive name of the current refclock selected
as syspeer"
-- e.g. "ntp1.ptb.de" or "GPS" or "DCFi" ...
-- maybe something like "RefClk(8)" = "hardware clock using driver 8"
-- would be nice
::= { ntpSrvStatus 5 }
ntpSrvStatusActiveOffset OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Time offset to the current selected refclock as string"
-- including unit, e.g. "0.032 ms" or "1.232 s"
::= { ntpSrvStatus 6 }
ntpSrvStatusNumberOfRefclocks OBJECT-TYPE
SYNTAX INTEGER (0..99)
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Number of refclocks configured in the NTP "
DEFVAL { 0 }
::= { ntpSrvStatus 7 }
ntpSrvStatusAuthKeyId OBJECT-TYPE
SYNTAX INTEGER ( 0..1024 )
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Authentication Key ID of active refclock is active "
-- xxxTODOxxx Check docs :"How many keys are allowed?"
DEFVAL { 0 }
::= { ntpSrvStatus 8 }
ntpSrvStatusServiceUptime OBJECT-TYPE
SYNTAX TimeTicks
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Uptime of NTP service"
-- time since ntpd was (re-)started
DEFVAL { 0 }
::= { ntpSrvStatus 9 }
--
-- Section 3: Status of all currently mobilized associations
--
ntpSrvAssociations OBJECT IDENTIFIER ::= { ntpSnmp 3 }
ntpSrvAssocTable OBJECT-TYPE
SYNTAX SEQUENCE OF ntpAssociation
MAX-ACCESS read-only
DESCRIPTION
"Table of currently mobilized associations"
::= { ntpSrvAssociations 1 }
ntpSrvAssociation SEQUENCE {
ntpSrvAssocId Integer32,
ntpSrvAssocName DisplayString,
ntpSrvAssocAddress DisplayString,
ntpSrvAssocOffset DisplayString,
ntpSrvStatusAssocJitter DisplayString,
ntpSrvStatusAssocDelay DisplayString
}
ntpSrvAssocId OBJECT-TYPE
SYNTAX Integer32 ( 0..99999 )
MAX-ACCESS read-only
DESCRIPTION
"Association ID"
::= { ntpSrvAssociation 1 }
ntpSrvAssocName OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
DESCRIPTION
"Hostname or other descriptive name for association"
::= { ntpSrvAssociation 2 }
ntpSrvAssocAddress OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
DESCRIPTION
"IP address (IPv4 or IPv6) of association OR refclock driver ID"
-- contains IP address of uni/multi/broadcast associations or
-- a refclock driver ID like "127.127.1.0" for other associations
::= { ntpSrvAssociation 3 }
ntpSrvAssocOffset OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Time offset to the association as string"
-- including unit, e.g. "0.032 ms" or "1.232 s"
::= { ntpSrvAssociation 4 }
ntpSrvStatusAssocJitter OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Jitter in miliseconds as string"
::= { ntpSrvAssociation 5 }
ntpSrvStatusAssocDelay OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"Network delay in miliseconds as string"
::= { ntpSrvAssociation 8 }
--
-- Section 4: Server SNMP trap definitions
--
-- xxxTODOxxx : define Payload
ntpSrvTraps OBJECT IDENTIFIER ::= { ntpSnmp 4 }
ntpSrvTrapNotSync NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when NTP is not synchronised "
::= { ntpSrvTraps 1 }
ntpSrvTrapServiceStarted NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when NTP starts up "
::= { ntpSrvTraps 2 }
ntpSrvTrapServiceStopped NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when NTP stopps "
::= { ntpSrvTraps 3 }
ntpSrvTrapStratumChange NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when stratum level of NTP changes"
::= { ntpSrvTraps 4 }
ntpSrvTrapSyspeerChanged NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when a (new) syspeer has been selected"
::= { ntpSrvTraps 5 }
ntpSrvTrapAddAssociation NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when a new association is mobilized"
::= { ntpSrvTraps 6 }
ntpSrvTrapRemoveAssociation NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when an association is demobilized"
::= { ntpSrvTraps 7 }
ntpSrvTrapConfigChanged NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when NTP configuration has changed"
-- e.g. when the system connected to the internet and was assigned
-- a new IP address by the ISPs DHCP server
::= { ntpSrvTraps 8 }
ntpSrvTrapLeapSecondAnnounced NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when a leap second has been announced "
::= { ntpSrvTraps 9 }
ntpSrvTrapHeartbeat NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent periodically to indicate that the NTP server
is still alive "
::= { ntpSrvTraps 88 }
ntpSrvTrapTestNotification NOTIFICATION-TYPE
STATUS current
DESCRIPTION
"trap to be sent when a test notification has been requested "
::= { ntpSrvTraps 99 }
ntpSrvTrapMessage OBJECT-TYPE
SYNTAX DisplayString
MAX-ACCESS read-only
STATUS current
DESCRIPTION
"used as a payload object for all traps, holds a clear text event message"
DEFVAL { "no event" }
::= { ntpSrvTraps 100 }
--
-- Conformance/Compliance statements
--
ntpSrvConformance OBJECT IDENTIFIER ::= { ntpSnmp 90 }
ntpSrvCompliances OBJECT IDENTIFIER ::= { ntpSrvConformance 1 }
ntpSrvGroups OBJECT IDENTIFIER ::= { ntpSrvConformance 2 }
ntpSrvCompliance MODULE-COMPLIANCE
STATUS current
DESCRIPTION
"The compliance statement for SNMP entities which implement version 2
of the Server MIB"
MODULE -- this module
MANDATORY-GROUPS {
ntpSrvObjectsGroup,
ntpSrvTrapsGroup
}
::= { ntpSrvCompliances 1 }
ntpSrvObjectsGroup OBJECT-GROUP
OBJECTS {
-- xxxTODOxxx add all objects
}
STATUS current
DESCRIPTION
"The collection of objects for the Server MIB"
::= { ntpSrvGroups 1 }
ntpSrvTrapsGroup NOTIFICATION-GROUP
NOTIFICATIONS {
-- xxxTODOxxx add all traps
}
STATUS current
DESCRIPTION
"The collection of traps for the Server MIB"
::= { ntpSrvGroups 2 }
END
5. IANA Considerations
The IANA has made a unique MIB OID assignment under the transmission
branch for IFCP-MGMT-MIB.
6. Security Considerations
All data objects in this MIB are read-only and therefore security
is managed by the implementation of the SNMP agent providing the
data objects in this MIB. The general access management methods
used for SNMP agents apply.
7. Normative References
[RFC2021] Waldbusser, S., "Remote Network Monitoring Management
Information Base Version 2 using SMIv2", RFC 2021, January
1997.
[RFC2578] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Structure of Management Information Version 2 (SMIv2)",
STD 58, RFC 2578, April 1999.
[RFC2579] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Textual Conventions for SMIv2", STD 58, RFC 2579, April
1999.
[RFC2580] McCloghrie, K., Perkins, D., and J. Schoenwaelder,
"Conformance Statements for SMIv2", STD 58, RFC 2580,
April 1999.
[RFC3411] Harrington, D., Presuhn, R., and B. Wijnen, "An
Architecture for Describing Simple Network Management
Protocol (SNMP) Management Frameworks", STD 62, RFC 3411,
December 2002.
8. Informative References
[RFC3410] Case, J., Mundy, R., Partain, D., and B. Stewart,
"Introduction and Applicability Statements for Internet-
Standard Management Framework", RFC 3410, December 2002.
Authors' Addresses
Heiko Gerstung
Meinberg Funkuhren GmbH & Co. KG
Auf der Landwehr 22
31812 Bad Pyrmont
Germany
Mail: heiko.gerstung at meinberg.de
Phone: +49 5281 9309 25
Fax: +49 5281 9309 30
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr at ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).
More information about the ntpwg
mailing list