NN Time and Date Management Strategy

Document number: TBD Document status: Draft 1.0.5

NORTEL NETWORKS CONFIDENTIAL The information contained in this document is the property of Nortel Networks. Except as specifically authorized in writing by Nortel Networks, the holder of this document shall keep the information contained herein confidential and shall protect same in whole or in part from disclosure and dissemination to third parties and use same for evaluation, operation and maintenance purposes only. The content of this document is provided for information purposes only and is subject to modification. It does not constitute any representation or warranty from Nortel Networks as to the content or accuracy of the information contained herein, including but not limited to the suitability and performances of the product or its intended application. The following are trademarks of Nortel Networks: *NORTEL NETWORKS, the NORTEL NETWORKS corporate logo, the NORTEL Globe mark, UNIFIED NETWORKS. The information in this document is subject to change without notice. Nortel Networks assumes no responsibility for errors that might appear in this document. Copyright2003 Nortel Networks, All Rights Reserved Printed in UK

1 DOCUMENT CONTROL
1.1 DOCUMENT
Title Master copy Disk file Author Time and Date Management TBD TBD H.Correa

1.2 REVISION HISTORY

Version 1.00/EN 1.01/EN 1.02/EN 1.03/EN 1.04/EN 1.05/EN Author H. Correa H. Correa H. Correa H. Correa H. Correa H. Correa Date 24/06/04 04/08/04 16/12/04 18/05/05 05/10/05 22/08/06 Comments Base Document First Release Second Release Third Release Fourth Release Fifth Release

1.3 PUBLICATION HISTORY

Version Comments 1.01/EN - Section 13.2.3 Syslog mechanism added 1.02/EN - Sections 8 and 11.1 updated - Sections 7.1 and 12.1 updated. CRs included 1.03/EN - Section 5.1 Error related to the Windows NT/2000 ntp support.

Clarifications done at the end of the section

1.04/EN - Section 12.1 updated related to the CR fix 1.05/EN - PWI rebranded to WNMS - Sections 5.3 and 13.2.3 updated related to Alarms are not sent by GGSN in the case of a synchronization loss to WNMS - Sections 5.3 and 5.4 updated. A restriction exists on GGSN 4.1.1 release. Deployment in O2 with CMC3 processors is not able to support multicast function with the NTP feature - Section 13.2.4 SNTP Event Log Table updated

1.4 CONTRIBUTORS

Name Jean Francois Richard Richard Anthony & R&D Team in Richardson William Bradee Moizuddin Syed Jean Leclerc Paul Suominen / Ethan Sun Shangli Lu David Mlinac

Department WNE Core OAM Servers Packet Domain SIG Packet Domain SCS Circuit Domain MSC Circuit Domain SDM Access Domain. RNC related RAS. CES1010 Packet Domain: SGSN DST configuration (Section 13.1.2.4)

Comments Without his continuous assessment this document could not be possible

This assessment is clever to have the DST configured properly

Luis Prez

Windows NT/2000 ntp support clarification Procedure to promote event logs to SNMP traps (alarms) using an snmp notification profile CSR 06052450668 Case ID: 060620-79013

Alan Carriere

2 RELATED DOCUMENTS
2.1 REFERENCES
The best source of basic information on NTP is the NTP website, at http://www.ntp.org. Included online are the NTP manual pages and the NTP FAQ, at http://www.eecis.udel.edu/~ntp/ntpfaq/NTP-a-faq.htm. [1] Preside for Wireless Internet Planning Guide for GPRS 5.0/UMTS 3.0, NTP 450-3101-638, WNE OAM [2] NTP Performance Analysis, David L. Mills, University of Delaware http://www.eecis.udel.edu/~mills/database/brief/new/new_files/v3_document.htm 4

[3] Office of telecommunications Standards For Telecommunications Metering Systems and Billing Systems 0TR003, OFTEL, 9 January 2002 [4] Wireless Network Engineering, OAM Solutions. Ports used by UMTS v3 OAM Solution. Engineering Guide [5] OAM SOFTWARE INSTALLATION PROCEDURE UMT/OAM/APP/0003. [6] UMTS V3.0b OAM Access Network Release Notes. Week19 update. Document number: UMT/DCL/APP/5958. Document issue: V1.07/EN. Document status: Preliminary. Date: April 28th , 2003 [7] 241-5701-600. Passport 7400, 15000, 20000. Configuration Guide [8] Nortel Networks Shasta 5000. Broadband Service Node. Administrative Command Line Interface Guide. Part No. 01451-01. March 2001. 4401 Great America Parkway. Santa Clara, CA 95054 [9] 411-5221-927. UMTS / GPRS Shasta GGSN. Procedures Reference Manual [10] Part No. 01451-01. Nortel Networks Shasta 5000. Broadband Service Node Administrative Command Line Interface Guide [11] Time Synchronization of OAM&P Elements in the GSM Network. Feature Number: 60011364. Release: GEM15. [12] A59032166. NORTEL Public Carrier Networks Technology. SNTP client support on Core NORTEL. [13] SDM Installation Manual for GEM16. Installation Method 24-9019 [13.1] SDM18 configuration procedure for SDM. NN 10103511 [14] Part No.: 816-1475-10. Revision 01, 07/09/01. Edition: July 2001. Using NTP to Control and Synchronize System Clocks - Part I: Introduction to NTP. By David Deeths - Enterprise Engineering and Glenn Brunette - Sun Professional Services. Sun BluePrints OnLine [15] Part No.: 816-0092-10. Revision 01, 08/23/01. Edition: August 2001. Using NTP to Control and Synchronize System Clocks - Part II: Basic NTP Administration and Architecture. By David Deeths - Enterprise Engineering and Glenn Brunette SunPS. Sun BluePrints OnLine [16] Part No.: 816-2353-10. Revision 1.1, 09/19/01. Edition: September 2001. Using NTP to Control and Synchronize System Clocks - Part III: NTP Monitoring and Troubleshooting. By David Deeths - Enterprise Engineering and Glenn Brunette SunPS. Sun BluePrints OnLine [17] NN10169-611 SN06 (DMS) Standard 04.02 September 2003

[18] Hardware Operations. About the TMLTool. UMT/DCL/DD/0019 03.06a Standard February 2004. 4118111519 [19] Reference for the Contivity VPN Switch. Version 3.6. Part No. 311643-C Rev 00. April 2001 [20] 411-3001-451. Wireless Networks Base/Telecom. Customer Data Schema Reference Manual Volume 2 of 4. Data Schema DCMEINV-MWDATA. CSP14 and up Standard 11.01 January 2001 [21] 411-5221-926. GPRS/UMTS Shasta GGSN User Guide [22] 411-5221-927. UMTS / GPRS Shasta GGSN. Procedures Reference Manual

TABLE OF CONTENTS
1 DOCUMENT CONTROL........................................................................................... 3 1.1 1.2 1.3 1.4 2 3 2.1 3.1 3.2 4 DOCUMENT ......................................................................................................... 3 REVISION HISTORY.............................................................................................. 3 PUBLICATION HISTORY ........................................................................................ 3 CONTRIBUTORS .................................................................................................. 3 REFERENCES ...................................................................................................... 4 PURPOSE.......................................................................................................... 10 NN TIME AND DATE MANAGEMENT SOLUTION .................................................... 10

RELATED DOCUMENTS ......................................................................................... 4 INTRODUCTION..................................................................................................... 10

BASICS................................................................................................................... 11 4.1 OVERVIEW ........................................................................................................ 11 4.2 NETWORK TIME PROTOCOL ............................................................................... 12 4.3 NETWORKING .................................................................................................... 13 4.4 RESOURCE REQUIREMENTS .............................................................................. 14 4.5 TYPES OF NTP SERVERS AND CLIENTS ............................................................. 14 4.6 NTP SERVER HIERARCHY (STRATUM)................................................................ 16 4.7 PRIMARY CLOCK SOURCES ............................................................................... 17 4.8 NTP COMPONENTS ........................................................................................... 17 4.9 NTP ACCURACY AND RESOLUTION .................................................................... 20 4.10 NTP ALGORITHMS............................................................................................. 21 4.11 NTP SECURITY ................................................................................................. 22 4.12 NETWORK TIME SYNCHRONIZATION RECOMMENDATIONS ................................... 22 4.12.1 Limiting SPOFs and Maximizing Independence...................................... 22 4.12.2 Controlling Network Impact ..................................................................... 23 4.12.3 Enabling Access Control ......................................................................... 24 4.12.4 Selecting Appropriate Reference Clocks................................................. 26 4.13 SNTP............................................................................................................... 28

NTP DESIGN CONSIDERATIONS IN WIRELESS NETWORKS .......................... 28 5.1 NTP COMPATIBILITY IN GPRS AND UMTS NETWORKS ....................................... 28 5.2 RECOMMENDED NTP ARCHITECTURE ................................................................ 30 5.3 DATE AND TIME ALIGNMENT:.............................................................................. 31 5.4 NETWORK TIME SYNCHRONIZATION ENGINEERING CONSIDERATIONS ................. 34 5.5 BASICS ON NTP CONFIGURATION ...................................................................... 36 5.5.1 Basic Client Configuration ....................................................................... 36 5.5.2 Basic Server Configuration...................................................................... 38 5.6 TIME ZONE CONSIDERATIONS ............................................................................ 42

NTP AND TIME ZONE DEFINITIONS FOR OAM AND SCS SERVERS............... 43 6.1 6.2 RUNNING THE TIMEZONE COMPILER: ............................................................... 43 TIMEZONE CONFIGURATION: ........................................................................... 44 7

6.3 7 8 9 10 10.1 10.2 10.3 10.4 11 11.1 11.2 11.3 11.4 12 12.1 12.2 12.3 12.4 12.5 12.6 12.7 12.8 13 7.1 8.1 9.1

VERIFYING THE PARAMETERS: ........................................................................... 45 EDITING THE NTP.CONF FILE .............................................................................. 45 EDITING THE NTP.CONF FILE .............................................................................. 47 EDITING THE NTP.CONF FILE .............................................................................. 48 NTP AND TIME ZONE DEFINITIONS IN SDM SERVER................................... 49 TOD CLOCK SYNCHRONIZATION ........................................................................ 50 NTP CONFIGURATION ....................................................................................... 50 CHECKING THAT THE XNTPD DAEMON ON THE SDM IS RUNNING .......................... 54 TIMEZONE CONFIGURATION: ........................................................................... 54 NTP AND TIME ZONE DEFINITIONS IN SIG .................................................... 56 EDITING THE NTP.CONF FILE .............................................................................. 56 TIMEZONE CONFIGURATION: ........................................................................... 58 RUNNING THE XNTPD PROCESS.......................................................................... 58 VERIFYING THE PARAMETERS: ........................................................................... 59 NTP AND TIME ZONE DEFINITIONS IN ACCESS DOMAIN ............................ 60 CONFIGURATION OF THE NTP SERVER IP ADDRESSES ON BOTH OMU: ............... 60 ACTIVATE NTP SERVER ON THE IRNC CNODE: .................................................. 65 NTP UPDATE .................................................................................................... 65 TIMEZONE CONFIGURATION: ........................................................................... 69 DATE CONFIGURATION ON EACH OMU............................................................... 70 ACTIVATE THE TIME ZONE AND DATE ON EACH OMU .......................................... 71 NTP SERVER CONFIGURATION & ACTIVATION ON IRNC-IN.................................. 71 DATE VERIFICATION ON NODE B ........................................................................ 71 NTP AND TIME ZONE DEFINITIONS IN PACKET DOMAIN ............................ 72

NTP DEFINITION IN MAIN SERVER ..................................................................... 45 NTP AND TIME ZONE DEFINITIONS IN PERFORMANCE SERVER .................. 47 NTP AND TIME ZONE DEFINITIONS IN SCS SERVER ....................................... 48

13.1.1 Network and Node Time.......................................................................... 72 13.1.2 Node time and date configuration:........................................................... 73 13.1.2.1 Synchronizing automatically with a network time server. ................ 73 13.1.2.2 Synchronizing manually with a network time server. ....................... 74 13.1.2.3 Configuring the time after a power off:............................................. 76 13.1.2.4 DST setting on SGSN from V3.0.1 .................................................. 76 13.1.3 Verifying the time configuration on the node: .......................................... 79 13.2 GGSN.............................................................................................................. 79 13.2.1 NTP definition .......................................................................................... 79 13.2.2 Configure or verify the time, date and time zone..................................... 80 13.2.3 Events log................................................................................................ 81 13.2.4 SNTP event logs...................................................................................... 83 14 14.1 14.2 14.3 NTP AND TIME ZONE DEFINITIONS IN CIRCUIT DOMAIN ............................ 84 CURRENT IMPLEMENTATION, LIMITATIONS AND RESTRICTIONS............................. 84 HOW TO SYNCHRONISE THE CORE TOD CLOCK TO NTP TIME?........................... 85 BASICS ............................................................................................................. 86 8

14.3.1 14.3.2 14.3.3 14.3.4 14.3.5 14.3.6 15 15.1 15.2 15.3 16

Time Of Day ............................................................................................ 86 Command to start SNTP client ................................................................ 86 Command to set TOD to ntp time............................................................ 87 Automated TOD Setting .......................................................................... 88 Command to query ntp time: ................................................................... 89 Interactions .............................................................................................. 89

NTP AND TIME ZONE DEFINITIONS FOR CES ............................................... 90 DATE AND TIME ................................................................................................. 90 VERIFYING THE TIME ZONE SETTING .................................................................. 91 CONFIGURE NETWORK TIME PROTOCOL (NTP).................................................. 93 ANNEX A. ........................................................................................................... 96 16.1.1 16.1.2 Broadcast and Multicast NTP Clients Configuration................................ 96 Broadcast and Multicast NTP Server Configuration ................................ 97

17 17.1 17.2 17.3 17.4 18

ANNEX B. ........................................................................................................... 98 ABOUT DAYLIGHT SAVING TIME ......................................................................... 98 IS DST ALWAYS 1 HOUR AHEAD OF NORMAL TIME? ............................................. 98 HOW DOES THE TRANSITION TO DST START? ..................................................... 99 HOW DOES THE TRANSITION TO DST END? ........................................................ 99 ANNEX C. ......................................................................................................... 100

18.1 TIME ZONE ABBREVIATIONS ............................................................................. 100 18.2 LIST OF ABBREVIATIONS .................................................................................. 100 18.2.1 Standard ................................................................................................ 100 18.2.2 Other abbreviations ............................................................................... 100 18.2.2.1 European ....................................................................................... 100 18.2.2.2 US and Canada ............................................................................. 101 18.2.2.3 Australia......................................................................................... 101 18.3 TIME ZONE LETTER ABBREVIATIONS ................................................................. 102 18.4 TIME ZONE DESCRIPTIONS IN SOLARIS .......................................................... 103 18.5 TIME ZONES IN AIX ......................................................................................... 111 18.6 TIME ZONES IN CIRCUIT DOMAIN...................................................................... 112 18.6.1 On SDM using sdmconfig...................................................................... 112 18.7 TIME ZONES IN GGSN .................................................................................... 114 18.8 TIME ZONES IN HP-UX .................................................................................... 119 19 ANNEX D. NTP PATH, FILES AND COMMANDS RELATIONSHIP IN SOLARIS/AIX/HP-UX ................................................................................................... 128 20 ANNEX E. SPECIFIC SECTIONS TO BE PREPARED FOR THE DTM SOLUTION PER CUSTOMER...................................................................................... 132 20.1 20.2 20.3 20.4 20.5 NTP GENERAL DESIGN FOR CUSTOMER NETWORK (S)..................................... 132 NTP DESIGN FOR CUSTOMER NETWORKS AS PER CUSTOMER STRATEGY ........ 132 NES/SERVERS INCLUDED INTO THE CUSTOMER NETWORK A ............................ 132 NES/SERVERS INCLUDED INTO THE CUSTOMER NETWORK B (IF APPLICABLE) ... 132 NES/SERVERS INCLUDED INTO THE CUSTOMER NETWORK C (IF APPLICABLE) ... 132

3 INTRODUCTION
3.1 PURPOSE
The purpose of this document is to present the overall solution for the Time and Date Management for Wireless networks. Time and Date Management (DTM) strategy covers the NTP topology definition and implementation, Time Zone settings and Time and Date configuration. It is important that the time stamped information be both accurate and consistent across the NEs and Servers. Time synchronization is essential for Accounting, Fault Management, Troubleshooting & Support, Security (i.e. Firewall logs), Network Monitoring, Performance Counter Correlation, and Logging. If Customer has its own topology for the DTM implementation; then, an agreement between NN and Customer needs to be done to show the final DTM Design and will be documented in a separate document.

3.2 NN TIME AND DATE MANAGEMENT SOLUTION

This section aims to present Customer with the Nortel Networks recommendation to define the NTP Network and associated parameters for the Wireless UMTS network. It is important that the time stamped information be both accurate and consistent across the NEs and servers. Time synchronization is essential for Accounting, Fault Management, Troubleshooting & Support, Security (i.e. Firewall logs), Network Monitoring, Performance Counter Correlation, and Logging. Time synchronization is achieved by means of the Network Time Protocol (NTP v3, RFC 1305) and, in some nodes (i.e. GGSN), a simplified version of NTP (SNPT, RFC 2030) Basics about NTP come from the OAM Feature UNIFIED TIME REFERENCE ACROSS OAM BOXES USING NTP (21961). From a Network Management perspective, time synchronization is required for Accounting, Fault Management, Performance counter correlation, logs (including security audit logs), etc. The word time in this description refers to the NTP timestamps = number of seconds since 00:00:00 on 1 January 1900 UTC (=> NTP is time zone agnostic). The synchronization is done every few minutes and at boot time. For OAM effectiveness, all the NE boxes are at the same time, i.e. the network elements NEs and the OAM servers. The Main server is used as the NTP time reference and the primary Main server is used as the overall time reference for the NEs and Servers that it manages (during the installation phase of the Primary Main Server, the NTP reference source is required). The time of the day (TOD) is provided with the following hierarchy: 10

Primary Main server provides time synchronization to: - Secondary Main servers, Performance servers, SCS servers - And to the NEs which it manages: RNC CN, RNC IN, RNC AN, Wireless Gateway, Shasta GGSN, MSC, HLR, etc

Secondary Main servers provide time of the day to the NEs they manage: RNC A/I, Wireless Gateway, Shasta GGSN, MSC, HLR, SGSN, etc

Unique source of time is the key for Network Management perspective. This feature is providing it which ensures accurate fault and performance metrics in particular. There is no more clock drift as NTP is an adaptive algorithm which addresses clocks skew/drift (frequency difference/variation) and network propagation delays. At the installation of the Primary Main server, the time host provided by an external NTP server is required. The user is able to choose the appropriate NTP server from different sources. Note that NodeBs are synchronized using the SE/PE protocol using the Main server time reference. Passport based NE do not provide DeltaUTC information. Therefore it is highly recommended that all OAM boxes (servers and clients) and all NEs managed by this OAM system be configured with the same time-zone (e.g. OAM time-zone, GMT timezone, etc). This recommendation provides an homogenous NE time configuration (i.e. NEs, OAM servers and clients will share the same timezone, e.g. GMT+2), the OAM user with a consistent time display (i.e. synchronous events are presented with the same time in OAM time reference). Seasonal time changes impacts have to be manually modified in NE Passport based (in case the time-zone is not GMT), except for SGSN in UMTS environments.

4 BASICS
4.1 OVERVIEW
The need for synchronized time is critical for todays network environments. As organizations grow and the network services they provide continue to increase, the challenges involved with providing accurate time to their systems and applications also increase. Every aspect of managing, securing, planning, and debugging a network involves determining when events happen. Time is the critical element that allows an event on one network node to be mapped to a corresponding event on another. In many cases, these challenges can be overcome by the enterprise deployment of the NTP service. Clearly, having any sort of meaningful time synchronization is almost impossible if clocks are allowed to run on their own. In some environments, this lack of synchronization isnt a big issue. However, in most modern networked computing environments, time synchronization is important. To reduce confusion in shared file systems, it is crucial for the modification times to be consistent, regardless of what machine the file systems are on. Billing services and similar applications must know the time accurately. Some 11

financial services even require highly accurate timekeeping by law. Sorting email and other network communications can also be difficult if time stamps are incorrect. In addition, tracking security breaches, network usage, or problems affecting a large number of components can be nearly impossible if time stamps in logs are inaccurate. Time is often the critical factor in separating cause from effect. As with any complex problem that is important in a wide variety of circumstances, a number of potential solutions to the time synchronization problem exist. There are several UNIX commands for setting and synchronizing time. In addition, there are several other time synchronization protocols, including Digital Time Service (alternately known as DTS or DTSS). Many other synchronization protocols and their relative merits are discussed in detail in RFC1305, which defines the NTP version 3 specification. Other time protocols have influenced the evolution of NTP, including rdate and DTS. The procedure for determining offsets evolved from a model used by telephone companies to synchronize time. NTP builds on the legacy and research efforts of these other protocols, which makes it a very robust and mature technology. NTP is a good choice for time synchronization in a variety of circumstances. Other schemes, such as DTS, are designed primarily for local area networks, while NTP is designed specifically for Internet environments. Although a number of UNIX commands provide setting or synchronizing time, they dont have the accuracy and robust feature set present in NTP. Flexibility of the client/server relationship and security methods allow NTP to work well in almost any environment. NTP not only automatically adjust for time drift on the client. This allows for less network traffic and keeps client clocks more stable, even if the network is unavailable. In addition, the NTP daemon can automatically adjust the time at periodic increments. NTP can also operate through firewalls and has a number of security features. In addition, NTP operates on a wide variety of platforms. Simple Network Time Protocol (SNTP) is a lightweight variation of NTP which is compatible with NTP and popular on Intel machines. Since many platforms and networking devices support one or both of these protocols, NTP can be easily standardized throughout an enterprise.

4.2 NETWORK TIME PROTOCOL

Contrary to popular belief, NTP is not based on the principles of synchronizing machines with each other. NTP is based on the principles of having all machines get as close as possible to the correct time. The effects may be similar, but this is a subtle but important distinction. The NTP algorithms and the structure of an NTP architecture clearly reflect this distinction. In addition, some of the behaviors of NTP applications can only be understood by keeping this distinction in mind. For instance, if two NTP servers are synchronized to each other as peers, what actually happens is the clocks decide among themselves which is the better source of time, and both clocks attempt to synchronize to that. The result is that the peer that is actually serving the time could change among the clocks as their accuracy changes.

12

At the top of any NTP hierarchy are one or more reference clocks. These are electronic clocks synchronized to a common time reference and each other using some methods outside the scope of NTP, for instance GPS signals, radio signals, or extremely accurate frequency control. Reference clocks are assumed to be accurate. The accuracy of other clocks is judged according to how close a clock is to a reference clock (the stratum of the clock, as described below), the network latency to the clock, and the claimed accuracy of the clock. The public NTP servers available on the Internet use Coordinated Universal Time (abbreviated as UTC, which does not stand for anything) as the ultimate source of time. UTC evolved from Greenwich Mean Time (GMT), and still uses the Greenwich time zone as the zero offset. GMT is based on the earths rotation, which is not constant enough to be used for detailed time measurements. UTC is based on a standard second length determined by the quantum phenomena. Time zones and Daylight Savings Time dont exist as far as NTP is concerned. Time is synchronized according to time zone neutral time (as in GMT), and then the time is projected to the time zone using the time zone environment variable (TZ), which can be set in /etc/default/init. The possible names for the time zones are the same as the paths to files contained under /usr/share/lib/zoneinfo. For instance, setting the time zone for a machine to East Newfoundland time can be accomplished by looking under /usr/share/lib/zoneinfo for the appropriate timezone, and then setting the TZ variable to that value in /etc/default/init as follows: TZ=Canada/East-Newfoundland Time zones for individual users can be changed by setting the TZ variable in their profiles. In environments that need more accurate time than an Internet link will allow (due to latency or other concerns), or environments that cannot rely on Internet time sources due to security implications, a radio time clock or GPS system (or cesium clock, if you happen to have one lying around), can be used to keep the primary NTP servers aligned with UTC. Synchronizing a few machines to an arbitrary time source, such as the internal clock on a given server, may be acceptable in a few rare cases, but in any sort of large installation it is critical to keep the clocks synchronized with some maintained time standard. Regardless of the configuration, an NTP server needs to be set up in order for clients to use it for synchronization.

4.3 NETWORKING
NTP functions as part of the UDP protocol suite, which in turn is part of the TCP/IP protocol suite. Therefore, a computer using NTP must have the TCP/IP protocol suite loaded. NTP uses the UDP protocol on port 123 to communicate between clients and servers. Attempts are tried at designated intervals until the server responds. The interval depends on a number of factors, and ranges from about once a minute to once every 17 minutes. Using UDP prevents retries from using up network bandwidth if a time server with a large number of clients goes down. 13

NTP is used to synchronize the time on the network elements and servers from external accurate time sources. Time synchronization consists of NTP servers and NTP clients which communicate over an IP Network. NTP servers are the time source, and NTP clients synchronize their clocks to the NTP servers. NTP server functionality can be implemented on a Network Time Server (NTS). Time servers based on NTP are a particular implementation of NTS, which would be recommended when time accuracies in the sub-second range are acceptable. Other implementations of NTS (non NTP based) could allow more accurate time exchanges. Higher levels of accuracy are usually required in the access segment of the wireless network (not as high in the core network). At the same time, all devices/servers in the data core network, all our current management applications are based on Sun hardware platforms, and most applications & services will also support NTP.

4.4 RESOURCE REQUIREMENTS

NTP requires little resource overhead. This allows NTP to be easily deployed on servers hosting other services, even if the servers are heavily loaded. Even a single processor NTP server can serve hundreds or even thousands of clients using only a few percent of its CPU capacity. If the server is a broadcast or multicast server, even fewer resources are required. The bandwidth requirements for NTP are also minimal. Unencrypted NTP Ethernet packets are 90 bytes long (76 bytes long at the IP layer). A broadcast server sends out a packet about every 64 seconds. A non-broadcast client/server requires 2 packets per transaction. When first started, transactions occur about once per minute, increasing gradually to once per 17 minutes under normal conditions. Poorly synchronized clients will tend to poll more often than well synchronized clients. In NTP version 4 implementations, the minimum and maximum intervals can be extended beyond these limits, if necessary.

4.5 TYPES OF NTP SERVERS AND CLIENTS

NTP Server NTP server sends updated timestamp to NTP clients. When NTP clients send a request to the server, the server sends back a time stamped response, along with information such as its accuracy and stratum. NTP servers can also send the time in Broadcast mode to NTP clients. NTP Client NTP client receives time responses from an NTP server or servers, and uses the information to calibrate its clock. The NTP client determines how far its clock is off and adjusts its time to match the NTP server. Adjustments are based on many time exchanges, and involve filtering and weighting as per defined (somewhat) in the protocol. NTP Modes NTP can work in Broadcast, Multicast or Unicast mode.

14

Broadcast/multicast server An NTP server when configured in a broadcast or multicast mode work similarly; broadcast servers send periodic time updates to a broadcast address, while multicast servers send periodic updates to a multicast address. Using broadcast packets can greatly reduce the NTP traffic on a network, especially for a network with many NTP clients. An NTP broadcast or multicast client listens for NTP packets on a broadcast or multicast address. When the first packet is received, it attempts to quantify the delay to the server in order to better quantify the correct time from later broadcasts. This is accomplished by a series of brief interchanges where the client and server act as a regular (nonbroadcast) NTP client and server. Once these interchanges occur, the client has an idea of the network delay and thereafter can estimate the time based only on broadcast packets. If this interchange is not desirable, it can be disabled using NTPs access control features. The -r option can be used when xntpd is started to hardwire a delay if the interchange fails because of access control issues or other problems. In the Unicast mode, the Client initiates a request to the NTP server which sends back the time. Unicast mode is more accurate since the client knows the round trip time associated with the exchange allowing for more accurate time offset estimates and local clock adjustments. For the purpose of this document, only Unicast NTP exchanges will be considered given that this mode allows the highest level of accuracy. In Unicast mode, the NTP client is the initiator of the exchange. The NTP client sends a request with its local time in the packet. When the NTP server receives the packet, it will add the servers time into the packet and send it back to the NTP client. The NTP client estimates traveling time and remote processing time once it receives the packet from the NTP server; to apply a correction on the timestamp received from the server to account for latency. The one-way traveling between the NTP client and server is estimated to be half of the total round trip delay, minus the remote processing time (appendix B shows how this is the main source of error with the NTP protocol). On the client side, corrections are made based on the traveling time. As the travel time to and from the server increases, the probability of loss of accuracy increases.

Peer An NTP peer is a member of a group of NTP servers that are tightly coupled (network wise) in normally the same stratum (refer to Stratum definition) and in communication with each other via NTP. In a group of two peers, at any given time, the most accurate peer could be acting as a server to the other peers if these estimate that the first peer would provide more accuracy than their own servers. Peers even exchange information about their own reference peers/servers and it could be possible for a NTP client to decide to get the time off a server/peer that was not in its originally configured list of servers/peers. This dynamic reconfiguration capability of NTP is seen as one of NTPs great capabilities; but as noted latter in this document, it also opens the door to security risks. Time Convergence It may take several minutes, or even hours to adjust a systems time to the ultimate degree of accuracy.

15

4.6 NTP SERVER HIERARCHY (STRATUM)

NTP works on a hierarchical model introducing the concept of a stratum, in which a small number of servers give time to a large number of clients. The clients on each level, or stratum, are in turn, potential servers to an even larger number of clients of a higher numbered stratum. Stratum numbers increase from the primary (stratum 1) servers to the low numbered strata at the leaves of the tree. Clients can use time information from multiple servers to automatically determine the best source of time and prevent bad time sources from corrupting their own time. Figure below illustrates the hierarchical strata model of servers used in NTP:

A stratum-1 server has an attached accurate time piece such as a radio clock or an atomic clock. A stratum-2 server gets time from a stratum-1 server, and so on, lower stratum NTP server (based on NTP). Stratum is equivalent to level. In the context of NTP, the stratum is the number of NTP server levels relative to a reference clock that is considered as the most accurate time for a given network. See below: Stratum-1: - It is the source of the network time in the hierarchy - It provides the absolute time source to other stratum servers - Usually a stratum-1 NTP server synchronizes itself to national time standards (i.e. Universal Coordinated Time, UTD) via radio, satellite (GPS), modems,... and the ultimate source of time is actually stratum-0. Stratum-2 - It is a NTP client to stratum-1 NTP server - It synchronizes the time from stratum-1 NTP server Stratum-3 - It is a NTP client to stratum-2 NTP server - It synchronizes the time from stratum-2 NTP server Stratum-n: 16

- It is a NTP client to stratum-(n-1) NTP server - It synchronizes the time from stratum-(n-1) NTP server The stratum server closer to the stratum-1 server implies that it is closer to the accurate source of time. The maximum number of the stratum levels is 15 in the hierarchy. Stratums are implemented for the main reason of reducing loading on the time servers. At the higher level (low stratum number) loads are normally maintained lower than what the server CPU/network bandwidth is actually capable of handling in order to optimize accuracy. However, at the lower levels and when firewalls are present, it is simpler to have a few servers communicating through the firewall and then having them distribute the time on the other side of the firewall.

4.7 PRIMARY CLOCK SOURCES

The network time source (higher level stratum) can be obtained from one of the following primary clocks. These are considered as the top stratum level for a network: A timeserver is synchronized by the signals of Global Positioning System (GPS) from the satellites. The satellite time system is based on a cesium clock that is periodically corrected to provide maximum accuracy Public primary (usually stratum 1, 2 or 3) NTP server from the Internet. The public NTP server can synchronize from national standard time sources. A preference should be for a source which is recognized by National standard bodies. Note also that reliable Internet NTP servers do not allow access without previous negotiations with site administration (there could be fees if desired level of accuracy and security (authentication is required). This can take a few days so set-up (refer to security recommendations before using NTP from the Internet) Server/Workstation internal clock. The time is not synchronized from the national standard time source. The initial accuracy is most likely to be that of the watch of the person doing the configuration and then drift at the rate of the server will degrade accuracy (server internal clock drift can be high). As per the recommendation section, server/workstation can be used as a NTP server (intermediary stratum) but needs to synchronize itself with a more accurate source

4.8 NTP COMPONENTS

Several components make up the NTP distribution. The NTP daemon, xntpd, is the usual method for using NTP. The ntpdate program can be used for fast initial synchronization before using xntpd, or instead of xntpd. The use of ntpdate instead of xntpd is discouraged, for reasons discussed below.

17

In addition, this ntpq, xntpdc, and ntptrace commands can be used to monitor and control NTP clients and servers. xntpd The xntpd process is the NTP daemon. The same daemon is used both for client and server. The file /etc/inet/ntp.conf configures the NTP servers and clients. The advanced options enable access control, authentication, monitoring, remote management, and better time approximation. In systems running default installations of Solaris OE versions 2.6 and later, the daemon is started automatically on startup by the /etc/init.d/xntpd file (which is linked to from /etc/rc2.d/S74xntpd) if the ntp.conf file exists. In default installations, the ntp.conf file does not exist, so the daemon never starts. A configuration can be created from scratch or copied from the ntp.servers or ntp.clients files in the same directory. If the configuration is changed, the daemon will need to be stopped and restarted in order to update the configuration without rebooting. The xntpd process can be started or restarted at any time, and is located at /usr/lib/inet/xntpd. Alternatively, the /etc/init.d/xntpd file can be run with the start or stop options. Keep in mind that changes made to the startup files could be removed by later upgrades or patches. While most of the configuration is taken care of by the ntp.conf file, there are a few command flags (described in the xntpd man page). While the command flags allow easy configuration from the command line, using them is discouraged, because the same can be accomplished using the configuration file. The advantage of using the configuration file is that all the configuration information is easily determined if troubleshooting is necessary. The following are the configuration files for Solaris implementation: /etc/inet/ntp.conf -----> NTP configuration file. The NTP configuration file contains the most important configuration data for the NTP daemon. This file is read whenever the daemon is started. A preset multicast client file that can be copied over the ntp.conf. An NTP client can have a number of servers, and broadcast and non-broadcast servers can be used by the same client. NTP clients synchronize their time to match NTP servers, while NTP servers never synchronize their time to match NTP clients. However, recall that NTP clients can also be NTP servers to clients of their own. A template server file that can be copied over to ntp.conf and modified xntpd drift file. The drift file contains information on the rate of drift of a client clock xntpd authentication keys file. The key file contains the cryptographic keys. directory for NTP statistics files (if used) 18

/etc/inet/ntp.client

----->

/etc/inet/ntp.server /etc/inet/ntp.drift /etc/inet/ntp.keys /var/ntp/ntpstats

-----> -----> -----> ----->

The xntpd process can communicate both time and configuration information. If enabled, this allows the configuration for xntpd to be queried or changed remotely. There are two different types of configuration messages which can be sent: mode 6 messages and mode 7 messages. Mode 6 messages are sent by the ntpq program and most mode 6 messages are informational. The others deal with setting variables. Mode 7 messages are sent by the xntpdc program. Mode 7 messages can be informational or can allow remote changing of the NTP configuration. ntpdate The ntpdate program allows a client to set its date from an NTP server without permanently running the NTP daemon. Multiple servers can also be specified to allow a better selection for the best time source. Essentially, this allows a one-shot NTP transaction. Because this interaction only occurs once, the clock will eventually stray again. Repeated usage of ntpdate can overcome this, but is far from an ideal solution. Some system administrators run an ntpdate command on an hourly, daily, or weekly basis as a cron job, which is capable of keeping servers in sync within a few seconds. This light-weight solution is useful in some environments because it requires one less daemon, gives the administrator more control over NTP traffic, and is easy to configure. However, in nearly all cases, the problems are likely to outweigh the benefits. The processor load of the NTP daemon is small, so little is gained by disabling it. In addition, many clients run cron jobs simultaneously, which causes blasts of network traffic for every cron job in the span of a few seconds. This is likely to overwhelm the network, and possibly even the server (if the server is small and has a large number of clients). The client-side xntpd process randomizes the delay before a time request is made, so that this overwhelming does not occur. Since both the ntpdate cron job and the NTP daemon are simple to configure, there is no clear management advantage to either. A final advantage of xntpd over ntpdate is that it produces a much better time sync. This is due to several facts. Unlike ntpdate, xntpd can limit the wander of the clock based on historical dataeven when a time server is unavailable. The process does time adjustment continuously, so the changes to the time can be small, so it rarely needs to use the time jumps that are likely to occur when is run. ntpq. The /usr/sbin/ntpq program allows querying the state of the NTP daemon on a local or remote machine. Using ntpq, an administrator can check the configuration of a remote host. If such queries are allowed on a host, this can be a useful way of choosing hosts to synchronize with, because information such as their peers and reference clock types can be determined. Since ntpq uses UDP packets, hosts may be falsely unreachable on congested networks. xntpdc. The /usr/sbin/xntpdc program also allows querying the state of a local or remote NTP daemon, however, xntpdc can also make runtime configuration requests to a remote machine. This allows changing the configuration on the fly. In order to make runtime configuration changes, an authentication key is needed. This requires the creation of an NTP keys file, which is described in the xntpd man page. Like ntpq, xntpdc uses UDP packets. 19

ntptrace. The /usr/sbin/ntptrace is an informational command that traces the source of a given clients time. The information found by ntptrace can be determined by successive runs of ntpq on each clients preferred server. However, ntptrace allows an easy and convenient way of learning this information. This can be a useful tool for debugging. The ntptrace output lists the client name, its stratum, its time offset from the local host, the synchronization distance, and the ID of the reference clock attached to a server, if one exists. The synchronization distance is a measure of clock accuracy, assuming that it has a correct time source. For the exact derivation, refer to the NTP specification.

4.9 NTP ACCURACY AND RESOLUTION

NTP may take several minutes or even hours to adjust a systems time to the ultimate degree of accuracy. There are several reasons for this. NTP averages the results of several time exchanges in order to reduce the effects of variable latency, so it may take several minutes for NTP to even reach consensus on what the average latency is. Generally this happens in about 5 minutes. In addition, It often takes several adjustments for NTP to reach synchronization. The result is that users shouldnt expect NTP to immediately synchronize two clocks. The ntpdate command can be used if instant synchronization is needed. The peers command can be used in ntpq to determine if synchronization has been achieved. When a client has synchronized, the synchronization server is listed with an asterisk in front of it. To allow clocks to quickly achieve high accuracy, yet avoid overshooting the time with large time adjustments, NTP uses a system where large adjustments occur quickly and small adjustments occur over time. For small time differences (less than 128 ms), NTP uses a gradual adjustment. This is called slewing. For larger time differences, the adjustment is immediate. This is called stepping. If the accuracy of a clock becomes too insufficient (off by more than about 17 minutes), NTP aborts the NTP daemon, with the assumption that something has gone wrong with either the client or server. In order to synchronize well with a server, the client needs to avoid step adjustments. The following line needs to be added to the ntp.conf file: disable pll. This forces the system to use NTPs clock setting discipline directly, rather than having NTP interact with the kernels clock setting discipline. The degree of synchronization to a server is dependent primarily on network latency. The accuracy of NTP thus depends on the network environment. Because NTP uses UDP packets, traffic congestion could temporarily prevent synchronization, but the client can still self-adjust, based on its historic drift. Under good conditions on a LAN without too many routers or other sources of network delay, synchronization to within a few milliseconds is normal. Anything that adds latency, such as hubs, switches, routers, or network traffic, will reduce this accuracy. The synchronization accuracy on a WAN is typically within the range of 10-100 ms. For the Internet, synchronization accuracy is unpredictable, so special attention is needed when configuring a client to use public NTP servers. 20

If synchronization accuracies better than the above estimates are required, there are several options for obtaining even higher synchronization accuracy: Connecting directly to a reference clock If a server is attached directly to a reference clock, the accuracy is limited only by the accuracy of the reference clock and the hardware and software latencies involved in the connections to it Pulse Per Second (PPS) Clocks can use PPS radio receivers, which receive on-thesecond radio pulses from a national standards organization. If the time is within a fraction of a second, the PPS pulses can be used to precisely synchronize to the tick of the second. This method achieves accuracies in the tens of microsecond range Precision time kernel The Solaris OE has a precision time kernel that allows the kernel clock to be updated to microsecond resolution (though not necessarily microsecond accuracy). By default, the precision time kernel is used by the versions of NTP which are included with the Solaris OE. Precision time kernels are defined in RFC 1589

The maximum resolution of an NTP time stamp is about 200 picoseconds (about the time it takes an electrical pulse to travel through 2 cm of copper wire), so the ultimate accuracy of NTP is likely to be limited by hardware and latency concerns, rather than by the NTP protocol. The important thing to remember is that NTP accuracy is always limited by the time source. A client synced to an inaccurate server, will be inaccurate. This dependency is true all the way up the chain to the reference clock. If the reference clock is miscalibrated, all the clients will be affected.

4.10 NTP ALGORITHMS

NTP is designed to allow a clock to synchronize as closely as possible to a universal time standard, even in the presence of incorrect time sources, or when accurate time sources are temporarily unavailable. Keeping time synchronized requires several different procedures. First, the current time needs to be ascertained. This involves statistical methods of choosing the best source from among several possible sources. Once a time source has been determined, the client needs to synchronize with it. In addition, to make synchronization less necessary and to allow the client to keep fairly accurate time in the absence of time servers, the client clock needs to be disciplined to adjust incorrect client clock frequency. Several steps are involved in determining the correct time. Although some of these steps are not necessary when a client is only synchronizing to a single server, it is essential to understand them for more complex setups. The following is a list of the basic steps involved in determining the time as closely as possible. The steps are performed in order: 21

1. 2. 3. 4.

Sanity checks ensure that packets are valid Filtering uses a history of samples for a given clock to reduce jitter Intersection algorithms remove clocks that appear to be set to the wrong time Candidate checks of the clustering algorithm remove the worst clocks until only 10 remain (to limit processing) 5. Synchronization of source selection of the clustering algorithm selects a best source out of those remaining 6. Clock combination revises the time from the best source based on time and error estimates from the other clocks Detailed explanation about the steps mentioned above can be found on [R16].

4.11 NTP SECURITY

The most significant risks to NTP services are tampering and jamming. Tampering occurs when the NTP server is affected by either accidental or malicious data modification. Jamming occurs when a time server is either destroyed or prevented from providing NTP service. As with any other application, administrators must remember that NTP is not guaranteed to be secure; poor coding and other flaws in the program could allow unintended access to NTP internals or the underlying operating system. The NTP service is capable of protecting itself against some of these threats using architectural choices such as redundancy, and configuration options such as access control and authentication. Access control is achieved by restricting what NTP functions can be accessed from specific hosts or networks. Authentication is currently provided using symmetric keys that are installed on the NTP servers and clients.

4.12 NETWORK TIME SYNCHRONIZATION RECOMMENDATIONS

4.12.1 LIMITING SPOFS AND MAXIMIZING INDEPENDENCE

Single points of failure can be reduced by assuring that client servers are as independent as possible. Using a number of independent servers reduces the effectiveness of an incorrectly configured server spoofing the time, and thus increases security. Verifying NTP server independence can be difficult if the server configuration is incoherent. To effectively map the dependencies on an NTP subnet, each of the peers and servers must be mapped. This quickly becomes unwieldy in a large configuration. A more workable solution is to use ntptrace to determine the hierarchy of time sources used by a client. It can then be easily identified if two machines share common time servers. This is less ideal, because it only shows the currently used time source, as opposed to all configured peers. Regardless, a client should always receive time from at least 4 servers. This will reduce the chances of it losing synchronization when a server fails. If fewer than four servers are used, the agreement algorithm cannot reliably detect a clique

22

including a majority of trusted sources. An easy solution is to use three servers from a lower stratum number and one unrelated peer from the same stratum.

4.12.2

CONTROLLING NETWORK IMPACT

It is important for NTP architects to understand how NTP and the network relate. The goals of an NTP architect are two-fold: to limit NTPs network activity and increase the accuracy of the clocks. To achieve high clock accuracy, the network latency needs to be low. NTP can achieve a high level of accuracy and remain a good network citizen if local NTP servers are used and NTP servers use the appropriate modes. The easiest way to increase accuracy in an NTP configuration is to reduce the latency between the connections by putting NTP servers on the same LAN as their clients. If a LAN is very large, it is a good idea to have multiple servers in different geographic or network segments. Reducing the latency of a single NTP connection does not necessarily reduce the overall network latency. This is because the latency from the root time source could be increased by putting an additional server in the way, even though the latency to that server is reduced. However, if several independent servers are used, the NTP clock selection algorithms will probably help mitigate the effects of any increased latency. Another advantage to using local servers is that they tend to reduce the load on the WAN, though NTP is unlikely to be a big source of network load. Another way of reducing NTP traffic, while keeping clock accuracy, is to use appropriate server modes. Central servers (generally stratum 1 and 2 servers) should use nonbroadcast server/client mode or peer mode, which allows more accurate time distribution. These servers are generally geographically distributed; therefore, the accuracy of the time distribution is critical. Broadcasting over high latency links can lead to very inaccurate time, both because of the latency and because it is likely the latency will be variable and unpredictable. Using broadcasting or multicasting over relatively local connections is acceptable. In fact, for a local server with a large number of clients and a fairly constant network latency broadcasting or multicasting is likely to be nearly as accurate as using a nonbroadcast server. Multicasting is preferable to broadcasting because it makes identifying NTP traffic easier and does not affect non-NTP clients on the network. Broadcasting or multicasting is a good fit in some environments; however, it is not appropriate for all environments. In particular, architectural or security concerns may preclude the use of broadcasting or multicasting. Broadcasting and multicasting are less acceptable than non-broadcast NTP transactions in many organizations due to the impact of these choices on their security architecture. Many companies are not willing to permit broadcast traffic through their firewalls. The use of broadcast or multicast NTP transactions also opens the network to possible denial of service attacks. Architectural or managerial constraints could also prevent the use of broadcasting and multicasting. 23

4.12.3

ENABLING ACCESS CONTROL

For security conscious environments, monitoring should be turned off because it could allow an attacker to obtain sensitive information about hosts or networks. In most other environments, disabling monitoring is an unnecessary restriction and only makes it more difficult to solve NTP problems. Requiring authorization keys for queries is another option. Limiting access to NTP queries prevents intruders from probing for information using the ntpq command. While the information obtained from ntpq may seem trivial, an intruder could discover sensitive information, including network delays (which could lead to determining network architecture), hostnames, IP addresses, and OS versions. In addition to authenticated transactions, NTP also provides the capability to restrict access to its services. This function is provided using the restrict keyword. This keyword is defined in the ntp.conf file and has the following syntax: restrict address [ mask numeric_mask ] [ flag ] [ ... ] The address and mask are both dotted octet representations of the IP address and network subnet mask to be restricted. The flags indicate what function is to be controlled. For example, if all communication from IP address 192.168.1.2 is to be ignored, the following access restriction can be used. restrict 192.168.1.2 ignore The restrict command is often used with the default keyword, which limits the specified access from all IP addresses: restrict default ignore After this default policy of denial, additional restrict statements can be used to increase the access. Any restrict statements which do not contain a keyword will enable (rather than restrict) access. For example, to only accept requests from the 192.168.1.0/24 network (the 24 indicates 24 bits of netmask), the following commands could be used: restrict default ignore restrict 192.168.1.0 mask 255.255.255.0 The following syntax can be used to further refine this configuration if, for example, no system on the 192.168.1.0/24 network is permitted to modify the run-time configuration of this server: restrict default ignore restrict 192.168.1.0 mask 255.255.255.0 nomodify Additional keywords such as noquery are also useful. The keyword, noquery, restricts who can query the run time configuration of the time server. While having the ability to query the server would appear to be relatively harmless, the query function can be useful in mapping network time architectures and exercising potential security 24

weaknesses. For example, with the ntpsweep command (supplied from the open-source NTP software distribution), it is possible to determine the operating system and processor type of NTP peers in a recursive manner. This function can be restricted using the noquery option, otherwise queries are allowed. The version information seen by outsiders could be modified to mask the OS version, but few administrators take the time to obscure this information. This allows hackers to easily obtain information about the operating system platforms and versions. A sample access control mechanism for a server could be something like as follows: # cat /etc/inet/ntp.conf # Prohibit general access to this service restrict default ignore # Permit systems on this network to synchronize with this # time service. Do not permit those systems to modify the # configuration of this service. Also, do not use those # systems as peers for synchronization restrict 192.168.1.0 mask 255.255.255.0 notrust nomodify notrap # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. restrict 192.168.1.254 noquery nomodify notrap # Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1 Conversely, a client could use the following controls: # cat /etc/inet/ntp.conf # Prohibit general access to this service. restrict default ignore # Permit time synchronization with our time source, but do not # permit the source to query or modify the service on this system. restrict 192.168.1.1 noquery nomodify notrap # Permit all access over the loopback interface. This could # be tightened as well, but to do so would effect some of # the administrative functions. restrict 127.0.0.1 It should be noted that as with any service founded on the UDP protocol, it is highly susceptible to IP spoofing. Using access control directives may not always provide sufficient protection for an organizations time services. Combining access control with authentication significantly improves the security of the NTP implementation. As with any service, however, security is only as strong as the weakest link. For NTP, this means not only its access control and authentication but also the platform security of its servers and clients. If a platform cannot be sufficiently protected, it is possible that the NTP configuration and authentication key files can be stolen or compromised.

25

4.12.4

SELECTING APPROPRIATE REFERENCE CLOCKS

A reference clock is needed to synchronize an NTP network to a useful standard. Clients cannot sync to a potential NTP server unless a reference clock exists in the servers synchronization path. There are three different ways to set up an NTP server for a large number of clients: Set up a reference clock on a secured network that uses accurate public NTP servers. Synchronizing the server to an accurate public NTP server is the most common route for most small installations. Assuring server accuracy is beyond the scope of this article, although ntptrace can give a general idea of the servers quality. It is important to find a server that is peered with several other servers to provide robustness. The NTP protocol is designed as a hierarchy to prevent large numbers of clients from accessing the same primary time sources. This hierarchy should be adhered to, and a large number of clients should not be configured to hit a busy stratum 1 time server. Networks should be designed to minimize the number of servers that interact with public NTP servers. In addition, because public stratum 1 servers are often overloaded, stratum 2 servers should be used except for large (over 100 clients) NTP configurations where highly accurate time is critical. A list of public NTP servers (along with a list of things to consider when using them) is available at http://www.eecis.udel.edu/~mills/ntp/servers.htm. The administrators of these servers should always be contacted first before using them as NTP servers. For secure environments where synchronized time is critical, it may not be appropriate to use a public reference clock. However, it is still important to use an external time source; otherwise, if the primary clock in the data center wanders, it causes all of the NTP clients connected to it to wander with it. While the primary clock could be adjusted to the true time occasionally, this would cause all of the clients to jump when the server adjusts. In addition, this time setting would have to be done manually; otherwise, it would compromise the security gained by not using a public NTP server. If a clock is ever adjusted to shift more than 17 minutes, all of the NTP daemons on its clients abort due to the sudden time shift. Set up a reference clock directly on a secured network. Another option is to place the main NTP sources for the enterprise on secure management networks and have them receive time from external servers. However, as with any externally provided service, it is also an entry point for attackers. Therefore it is important to keep the servers independent and well secured. A layered security approach should be used that encompasses isolated network segments and systems, in addition to platform and NTP security measures. For example, the NTP servers could be deployed on independent platforms running only the NTP service. These systems should be hardened based on the recommendations in the Sun BluePrints OnLine article, Solaris Operating Environment Security (the original version of this article covered Solaris OE 2.5.1, 2.6, and 7, but an updated version covers Solaris OE 8). 26

In addition, the servers should use the access control and authentication facilities in NTP to further restrict access to the service. If possible, only authenticated NTP packets should be accepted. The server should also only accept packets from known, approved sources. For additional security, the NTP packets could be tunneled between the NTP sources and their external servers over encrypted connections such as those provided by IPSEC in the Solaris OE. A proper approach for using reference clocks is to setup reference clocks on appropriately secured management networks. Choosing the best reference clock for a particular network is beyond the scope of this article, although details can be found at http://www.ntp.org. The NTP site provides suggestions for choosing reference clocks, and also points to lists of reference clock hardware and vendors such as the ones available at http://www.eecis.udel.edu/~ntp/hardware.html and http://www.boulder.nist.gov/timefreq/general/receiverlist.htm. A true reference clock can be expensive to obtain and maintain, but a variety of devices that sync to the correct time using long wave radio signals, CDMA technology, or GPS transmissions are also available. These devices are available for about US$600 and up. These are generally much cheaper and still provide time within a few milliseconds. In most datacenter environments, these are the most appropriate solution. GPS receivers need to be mounted on the roof or in a window, and even radio receivers may have problems operating in a shielded room. Additionally, to prevent a clock failure or an incorrect clock from affecting the clients time, it is best to have at least 3 independent time sources. If no public NTP servers are used, this means at least 3 reference clocks. Because of these restrictions, it may be difficult to have reference clocks available behind the firewall unless a site is willing to invest a great deal in infrastructure and design. Another option for obtaining secure externally synchronized time is using NTPs dial-up functionality to set a primary clock to a standard. Of course, the system should use a dial-out only modem and be protected with appropriate firewalls and other security methods. Use a servers local clock as a reference clock (generally not a good idea). Using the servers local clock as a reference clock is almost always a bad idea, especially if the server is in broadcast mode, because its time will wander and could eventually differ significantly from UTC.

Undisciplined Solaris Server Time Drift Sun specification: an undisciplined Solaris server can drift by 1 minute 59 second per month (undisciplined = not running NTP). This corresponds to 4 seconds per day. Disciplined Sun Server time Drift after loss of connectivity to primary sources. Once a Solaris NTP client has been synchronized with a server (disciplined), a time correction factor is applied to the hardware clock. This time correction continues to be applied even 27

if contact is lost with NTP source. In a case of loss of contact with the time sources, it was measured that a server will hold time about ten times more precisely than if it had never been synchronized via NTP. This would imply that after being synchronized, if there is a loss of contact with the NTP source, a server could drift at a rate of 400 msec per day. This is a worst case value of course, typically, it is much better.

4.13 SNTP
Simple Network Time Protocol (SNTP) V4 (Shasta and MSC/HLR) is a light weight version of NTP: the network facing interfaces are like those of NTP V3 for compatibility but dont use all the complex filtering algorithms. An SNTP client will normally adjust its clock at every single exchange, and this will be purely based on the results of that single exchange (contrary to NTP which takes into account multiple exchanges to minimize time jitter caused by the network). Similar to NTP, SNTP does perform some corrections on the round trip time. Moreover, since SNTP is not as accurate as NTP, its not recommended to use servers based on SNTP to distribute time to other NTP clients. SNTP was really designed for clients at the leafs of the NTP time tree.

5 NTP DESIGN CONSIDERATIONS IN WIRELESS NETWORKS

5.1 NTP COMPATIBILITY IN GPRS AND UMTS NETWORKS
Standardization of NTP usage, within the GPRS/UMTS network, requires little effort, since support for NTP already exists on most NEs and servers. Note that all the NEs, WNMS and OAM servers (in the wireless portfolio) which support NTP (see following list) support NTP version 3, with the exception of the Shasta device (GGSN) and MSC/HLR which support a simplified SNTP. Not all of them support all the NTP features such as the optional authentication feature, peering, between others. Table 1 covers the OAM components, please note that all Solaris based Sun servers can both be servers and clients at the same time. Table.2 and Table 3 are the Network Time Protocol client compatibility information summary of the network elements in the GPRS and UMTS networks respectively.

28

29

Windows NT/2000 has tools that permit to configure an equipment as NTP Client and/or Server. Please, see the following links for more information: http://www.microsoft.com/technet/prodtechnol/Windows2000Pro/maintain/w2kmngd/16_2kwts.ms px#ECAA http://www.microsoft.com/technet/archive/winntas/tips/techrep/ntp-nt.mspx

5.2 RECOMMENDED NTP ARCHITECTURE

It is recommended to use the WNMS Main Server as the central point for distributing the time throughout the network. The main advantage of using the Main server is that it must have connectivity to all the NEs or EMSs managed by a ROC which require time synchronization. To ensure accurate distribution, the Main Server should get the time from all the time sources available in the overall wireless network (up to 3 or 4 if possible). This would 30

limit the OAM traffic between NOCs, since only the WNMS Main Server would get the time off other servers outside of the NOC. For redundancy reasons, each client (NEs, other OAM servers, ...) should also be configured to get the time off an alternate source such as the secondary Main Server (if available) or even the Stratum 1 time source if it can be reached from the client or from the Performance Server. In terms of reference OAM architecture, the NTP stratum-1 sources would normally sit on the Server LAN (OAM-OAM network according to WNMS OAM documentation). Should the OAM network be segmented and isolated from other networks, the minimum security recommendations for NTP would be to disable peering functionality and remote monitoring/configuration capabilities.

5.3 DATE AND TIME ALIGNMENT:

All PRESIDE UNIX workstations are date and time synchronized using UNIX standard NTP (Network Time Protocol). This synchronization is configured editing the file /etc/ntp.conf. The task xntpd (Network Time Protocol Deamon) must be running on all workstations to be synchronized. This can be check using the command ps -e | grep xntpd. If xntpd is not running it can be started typing xntpd <CR>. The date and time on NEs are synchronized from PRESIDE also using NTP, except for GGSN and MSC/HLR. For GGSN and MSC/HLR the following apply: o One for GGSN where only one Unicast NTP source can be configured and o MSC/HLR only can take the NTP from the SDM/FT. The MSC/HLR will query time on the SDM via SNTP. The SCS server --being Solaris based-- can act simultaneously as NTP client and server. Thus it can act as NTP client to the main time sources and as NTP server for any GGSNs that are co-located with it." If SCS server is not co-located with the GGSNs, it is important to select a server with a short round trip time in order to have time synchronization accuracy for SNTP comparable to that which can be achieved with NTP (Round trip delay between the source and GGSN < 100 msec.). As long as the Shasta GGSN uses SNTP the important issue here is to ensure that a NTP server (stratum not so important) is collocated ideally on the same LAN/Switch. This will avoid having transit time affect time accuracy. If no time source is collocated, it is usually standard to recommend having the log server collocated. As the log server for Shasta (or SCS if avail.) is Solaris based, it could be configured act as both a client to other servers and a NTP source for the Shasta. Such a server could also be peered in with the WNMS main servers if they are used as a Stratum-2 time servers. Consensus was reached on the fact that for the GGSN the nearest and most accurate time server should be used, and that would be inclusive of using SCS if it is collocated with GGSN and there is no other box which has NTP capabilities. Current implementation of Date and Time Management on SCS is not documented in the SCS documents and IMs and it must be done manually (a 31

request has been made to have this supported in a future release). The idea here is that it is preferable for the GGSN to get its time from a closer intermediary NTP server than to use its native SNTP to get the time over a large network distance (so if the SCS is not collocated but there is another box running NTP that will do) For the GGSN, Unicast NTP is the preferred solution because of security. However, due to the fact that the GGSN doesn't support multiple NTP sources, the Multicast NTP solution is being deployed. Restriction about the NTP Alarms not sent to WNMS does not exist anymore. A restriction exists on GGSN 4.1.1 release. Deployment in O2 with CMC3 processors is not able to support multicast function with the NTP feature. The Design has been change to utilize the unicast function with the limitation that only one IP Address can be configured on the GGSN therefore in the event of a server/comms failure the GGSN will loose sync. Please, see Case ID: 06062079013 for details Command ntpdate -d <NTP server> can be issued from the NTP client to check the NTP server replies. Before starting ntp manually for the first time, you might need to shut down the applications, unless you know that there is only a small difference in time (less than 1 second, rare if systems have not been previously synchronized. You can find out how much your system is offset by typing ntpdate with the d option. This will let you know what it would do without actually doing it. In the example below, you can see that should ntpdate be run with the specified server, ntpdate would only correct time by 2.5 msecs. Since it is small, you could go ahead and change time without shutting down and restarting the applications. # ntpdate -d 47.129.29.101
16 Nov 06:44:59 ntpdate[28982]: ntpdate version=3.4y (beta multicast); Fri Aug 2 3 19:55:32 PDT 1996 (2) transmit(47.129.29.101) receive(47.129.29.101) transmit(47.129.29.101) receive(47.129.29.101) transmit(47.129.29.101) receive(47.129.29.101) transmit(47.129.29.101) receive(47.129.29.101) transmit(47.129.29.101) server 47.129.29.101, port 123 stratum 2, precision -18, leap 00, trust 000 refid [142.3.100.2], delay 0.03125, dispersion 0.00005 transmitted 4, in filter 4 reference time: Sat Oct 10 00:15:51 1936 originate timestamp: Sat Oct 10 00:16:43 1936 transmit timestamp: Sat Oct 10 00:16:43 1936 filter delay: 0.03140 0.03125 0.03136 0.03130 0.00000 0.00000 0.00000 0.00000 filter offset: 0.002539 0.002553 0.002641 0.002493 0.000000 0.000000 0.000000 0.000000 delay 0.03125, dispersion 0.00005 offset 0.002553 16 Nov 06:44:59 ntpdate[28982]: adjust time server 47.129.29.101 offset 0.002553 sec (note: actual change not performed)

# 32

In this case, we could decide that the time offset (2 msec) is small and we can adjust time without shutting down applications which is done in the following example. Note that the second time we performed this, the actual offset that was set on our server was less than 1 msec (normal, because of network delays, estimate of offset can differ by a few msec each time). # ntpdate 47.129.29.101
16 Nov 06:47:14 ntpdate[29558]: adjust time server 47.129.29.101 offset -0.000155 sec (note: time adjustment actually performed)

NTP will work only if the initial time difference between the client and the server is small. Also if the time is manually changed in the time server, do not expect the clients to update immediately to the new time. The process is gradual and takes some time. You can use ntpdate b <server> with xntpd daemon shutdown to achieve the initial synchronization. The program xntpdc is used to re-configure xntpd deamon at run time. Also it provides commands that can be used to monitor the NTP function. Some of them are: peers: provides a list of NTP servers connected to the client with their status. showpeer <ip addr>: provide detailed information about one server. sysinfo: shows local host information. NTP configuration file: /etc/ntp.conf Command ntptrace determines where a given Network Time Protocol (NTP) server gets its time from by following the chain of NTP servers back to their master time source. After changes are done in /etc/ntp.conf file, it is required to kill and restart the xntpd daemon, and wait about 10 minutes before the NTP start to work OK. If the higher hierarchy NTP servers in the system will not be synchronized from the Source, it will be required to include the lines server and fudge in the /etc/ntp.conf file to synch the server itself. Starting NTP server/client Processes: On Solaris 8, execute the following command: /etc/rc2.d/S74xntpd start.

Note on changing the time on a server with running applications: Some applications might not accept that time jumps (especially backwards) on the server on which they are running (which is the case of the Sun based servers). NTP configuration file for OMU is not the default one, but /OMU/local/usr/data/btime_ntp.conf built from /OMU/local/usr/data/btime_srv.conf and /OMU/local/usr/sbin/btime_ntp_start. Checking xntpd is running on AIX is done: $ lssrc -s xntpd Subsystem xntpd Group tcpip PID 7444 Status active 33

If service is not started, then Status is "inoperative" and PID is empty.

5.4 NETWORK TIME CONSIDERATIONS

SYNCHRONIZATION

ENGINEERING

NTP version 3 should be deployed as part of the UMTS and GPRS OAM solution. NTP V3 is the most popular one currently (and the default for most devices). NTP V3 is also compatible with SNTP V4 used in the GGSN Shasta and MSC/HLR. Each NTP client should have access to two NTP server sources for redundancy reasons to avoid single points of failure. If there is any doubt about the possible accuracy (or loss of accuracy) of these servers, this number should be increased to 3 (or 4) to allow the NTP clock selection algorithms to select the optimum source. Using a number of independent servers reduces the effectiveness of an incorrectly configured server spoofing the time, and thus increases security. One restriction exists with the GGSN, where only one Unicast NTP source can be configured. Redundancy and Resiliency. Redundancy is essential in the NTP configurations. As mentioned above, the NTP clients (this includes intermediary servers) should connects to at least 2 lower level NTP servers (i.e. such as GPS timeservers), and this number can be increased to 3 or 4. With such recommendations short outages of connectivity to these servers is unlikely but supported. This would ideally require adequate system monitoring (monitoring RFF is currently not supplied by the WNMS OAM server). The recommendation of having one (1) GPS type NTP server co-located in each ROC (with a minimum total of two (2) available to the WNMS main server) should be considered, specifically when there is local legislation on the accuracy of the timestamps used for billing.

To limit NTPs network activity and increase the accuracy of the clocks, it is recommended to have: o symmetrical transport times in between the server and client, and o avoid sustained congestion Only Unicast NTP exchanges will be considered given that this mode allows the highest level of accuracy, since the client knows the round trip time associated with the exchange allowing for more accurate time offset estimates and local clock adjustments. Exception is being done with GGSN, where currently Multicast NTP deployments are being done. A restriction exists on GGSN 4.1.1 release. Deployment in O2 with CMC3 processors is not able to support multicast function with the NTP feature. The Design has been change to utilize the unicast function with the limitation that only one IP Address can be configured on the GGSN therefore in the event of a server/comms failure the GGSN will loose sync. Please, see Case ID: 060620-79013 for details. However, the accuracy of multicast NTP 34

deployments can be greatly improved if the servers and clients are all collocated on the same LAN. Standard Accuracy Requirements. A key driver for synchronization accuracy requirement is billing. An example of such specifications is given in [3] where it is stated that in the UK, should a time stamp be used as part of the billing/rating strategy, it must be within 1 second of National Standards (this would refer the Tariff-Time-Change functionality on the NEs themselves) Related to the Access Control, the following are the most important recommendations o Disable peering capabilities. Peering allows for NTP clients dynamically reconfigure which source they use should another source appear more accurate. These other sources do not need to be programmed in the NTP server list configuration file. It is easy to attack NTP via this functionality and get the NTP client to change its time. Peering is not supported by the NEs but it is supported by the Solaris OAM (or other Unix based servers). An alternative could be to use the peer functionality with Authentication but this might not completely eliminate the risk of an attack. It is simpler to have a static NTP time distribution tree with static NTP links (use the server configuration statement instead of peer). o Disable remote configuration capabilities. NTP protocol has built in remote monitoring and configuration capabilities which can be accessed by the NTPQ utility. Remote configuration capabilities should not be allowed. This can be configured with the access control capabilities of NTP. As the NTPQ utility can be useful for troubleshooting, NTP should be configured to only allow monitoring requests which originate from the same server running the NTP process o As proper time stamps are an essential part to a sound security strategy, redundancy and resiliency is an important part of NTP security. When using 3 external time references, NTP will be able to eliminate a false clock which doesnt line up with others and also reduce the overall possibility that all 3 sources are down at the same time. Firewall should block the UDP port 123 for any connection outside the OAM network when not required. Time Source Selections. It is not in the scope of this document to propose recommended vendors or types of Stratum 1/2 servers. We would note however that considering the accuracy requirements discussed here that GPS type time servers meet the requirements and appear simple to operate/maintain at acceptable cost levels. Considering the Wireless Networks as secure environments where synchronized time is critical, then, for Internet Sources of NTP security restrictions apply. There is no engineering requirement to have Internet connectivity from the OAM network and this is something that would normally be avoided. Should an Internet Public source be used as a time reference (this is often requested for backup reasons) we would recommend building an intermediary stratum server somewhere off the OAM network and security investigations should go beyond the guidelines of this document. As a minimum, this intermediary server should have peering and remote configuration/monitoring disabled. Standard NTP 35

access control (ntp.conf file) should restrict all NTP communications to the servers involved in the configuration (i.e. the NTP servers on the Internet side and the WNMS OAM main server if this server is the main time distribution point). The optional encryption features of NTP should be considered to authenticate the source. NTP time sources available on the Internet normally charge a monthly fee for such services but would offer a guarantied level of accuracy. If guarantied accuracy servers are not used, it would be recommended to use 3 or 4 sources off the internet so that this intermediary time server can take advantage of the rich NTP algorithms to determine if some servers are inaccurate or incorrect. Firewalls should also be used and if these also allow flow control it should be assumed that the maximum rate is 1 packet per minute. This could offer some protection from denial of service attacks. NTP uses the UDP port 123 for the bi-directional communication between the NTP server and the NTP client. That is, the packet is sent and received on port 123. It is therefore easy to block or allow this communication on standard firewalls. Bandwidth considerations. For version 3 Unicast mode without the authentication option, the NTP packet size is 90 bytes for both the NTP client request packet and the NTP server reply packet. For each transaction, a packet is sent from the NTP client followed by the packet replying from the NTP server. When the time synchronization starts, there is one transaction per minute and increasing gradually to one transaction every 17 minutes under normal conditions, theoretically. The bandwidth requirement between the NTP client and the NTP server is at most 90 bytes per direction every 60 seconds (worst case) per NTP client. That is, 1 packet from the NTP client, and 1 packet from the NTP server. Some WNMS servers are actually configured to poll less often as the level of accuracies required are less than what is offered by the protocol. In the worst-case scenario (assuming a total of 1000 clients NEs/servers/devices) all requesting the same server, the total bandwidth requirement would be 100 Kbps. This is based on the start up rate of 1 request/minute and acceptable round trip times. Considering the flow of fault and performance information on the OAM network, NTP communications is negligible. Server resource usage (capacity). Performance analysis indicates that the CPU usage of the NTP server is insignificant [2]. The stratum-1 NTP server providing the time synchronization to 734 clients requires 1.54% CPU time only of a legacy Sun IPC workstation.

5.5 BASICS ON NTP CONFIGURATION

5.5.1 BASIC CLIENT CONFIGURATION

Setting up a computer as an NTP client requires simply adding several lines like the following to the ntp.conf file and restarting xntpd. 36

In this case address1, address2, and hostname3 are the addresses (or host names) of three NTP servers, which the client can use as potential synchronization partners. It is always best to synchronize with multiple servers to help protect the client from an incorrect or inoperational server. This is important, since in many environments, it is unlikely that an NTP server failure will be noticed promptly. server address1 server address2 server hostname3 The dependency chain of an NTP server can be determined by running the ntptrace command with each server as the argument. If possible, servers should not share common NTP parents. A server can be set to be preferred by use of the prefer keyword after the server name or address. A preferred server will be used as a synchronization source if it meets a minimum accuracy level, even if there are other more accurate servers. However, if a preferred server is far outside of the accuracy bounds determined by consulting other servers, it will be discarded. In general, a server will not fall outside these accuracy bounds unless it or the majority of other servers is misconfigured. Using preferred servers allows setting up clients to prefer a clock that is known to be very accurate. In the following example, the client is setup to prefer the host stonehenge. server stonehenge prefer server machupicchu server kukulcan The time exchange between the client and server can also be protected with an authentication key Note that if an alternate server is configured and is lower in stratum than that of the Main Server, the NTP clock selection algorithm will usually disregard the prefer statement and use the lower stratum clock. The prefer statement only really has an influence when comparing servers of same stratum. The configuration for a client is as follows: > cat /etc/ntp.conf #Each NTP client should have access at least to two NTP server #sources for redundancy reasons to avoid single points of failure # server "ntp external source 1 IP@" minpoll 9 maxpoll 14 prefer server "ntp external source 2 IP@" minpoll 9 maxpoll 14 # #Following lines allow a server to synchronize #with its own real-time clock # 37

server 127.127.1.0 minpoll 9 maxpoll 14 fudge 127.127.1.0 stratum 9 # #Next line it is used for maintenance purposes. #This file is used by the ntp daemon to write to. #This log file gives the correction factor to be applied to have #a more accurate clock. No symbolic links are allowed # driftfile /etc/inet/ntp.drift # #The following line permits to have a smooth #and slow change when differences in time are #detected, to avoid operational problems (only for WNMS Main Server) # slewalways yes # # Next line if not set, the local clock free-runs at # its intrinsic time and frequency offset # disable pll # # Next line restrict the access from all IP addresses not permitting # them to be used as peers for synchronization # restrict default nopeer # # Next line restrict the access from all IP addresses not permitting # them to query or modify the run time configuration of the time server # on this system # restrict default noquery restrict default nomodify # # Next line permits local users (logged #into the server to use ntpq restrict 127.0.0.1 #

5.5.2

BASIC SERVER CONFIGURATION

Local clock support: # xntpd supports a special pseudo-time server used for backup or when no other clock source is available (for example, if Internet access is not available). This feature can be used to run an isolated NTP synchronization network, where standard time source is not available, or is only intermittently available. This server is set as follows in the /etc/ntp.conf file: server 127.127.1.unit # Synchronization with local RTC fudge 127.127.1.unit stratum level 38

These lines allow a server to synchronize with its own real-time clock. The address of the local clock driver is 127.127.1.unit where the unit number can be 0, 1, 2, or 3. unit is usually set to 1. The stratum of the driver is 3 by default but this is usually changed using the fudge configuration command (or, alternatively, xntpdc): fudge 127.127.1.unit [time1 s] [time2 f] [stratum level] [refid ID] [flag1 0|1] [flag2 0|1] time1 specifies the time offset calibration factor in seconds. The default value is 0.0. time2 specifies the frequency offset calibration factor in parts per million. The default value is 0.0. stratum specifies the driver stratum level. The default value is 3. The suggested value is 10. refid specifies the driver reference identifier as an ASCII string from one to four characters. The default value is ``LCL''. flag1 specifies whether a leap seconds is to be inserted at the end of the current UTC day. The default value is 0 (no). flag2 specifies whether a leap seconds is to be removed at the end of the current UTC day. The default value is 0 (no). The local clock is usually configured at a high level stratum such as 10. This will minimize problems if it is being used as a backup, or if Internet connectivity is reacquired. Since the local clock is not connected to a reliable time source such as the Global Positioning System (GPS) or a radio signal. Configuring it at an elevated stratum allows it to be overlooked if more accurate servers are available. Note that the server, when synchronized to this pseudo-time server, will advertise a stratum one greater than that of the pseudo-time server. This allows peers and clients to recognize that the reliability of the service has changed. The following lines from /etc/ntp.conf illustrate how a server can be configured to use its own clock if necessary: server 127.127.1.1 # allow synchronization with local clock fudge 127.127.1.1 stratum 10 # but fudge the stratum to a low level

# Drift file. It is used for maintenance purposes. This file is used by the ntp daemon to write to. This log file gives the correction factor to be applied to have a more accurate clock. No symbolic links are allowed # slewalways yes. It permits to have a smooth and slow change when differences in time are detected, to avoid operational problems. Special patch has been included at the Installation time to permit the slewalways usage in Main Server. # pll enable. It enables the server to adjust its local clock. If not set, the local clock freeruns at its intrinsic time and frequency offset. This flag is useful in case the local 39

clock is controlled by some other device or protocol and NTP is used only to provide synchronization to other clients. No special configuration is required for a machine with a running NTP daemon to be used by other network nodes as a standard server (as opposed to a broadcast server or peer). However, access control is needed to prevent a machine from acting as an NTP server to clients. Setting up a peer can be accomplished by adding the peer command to the ntp.conf file. The configuration of a peer is basically the same as setting up a client: an address or host name needs to be specified, along with a key and possibly the prefer keyword. Peers also have an associated polling interval which can be set in the ntp.conf file. While a set of peers can use different polling intervals, true peers use the same polling interval. The defaults should be acceptable except when peers are connected by very slow links. Setting the polling range is described in the xntpd man page. Generally, peer connections are used to improve the time accuracy at the base of the NTP tree (low numbered strata), or provide additional redundancy at the leaves of the NTP tree (high numbered strata). Using peer connections allows both of these without resorting to creating a new level of hierarchy. The following shows the configuration of a set of peers: peer notredame peer charters # Peering is one of the features of NTP which is considered to be "great". However, it was developed before security became such an issue. Peering functionality is not recommended by WNE-OAM and should be disabled. NTPQ can be launched over to network and the diagnostic, monitoring and configurations can be done from anywhere else just like if you were on one of the Main Servers. Typing the "peers" command permits to any user to have the info as to what is the higher level stratum IP. Giving out topological information (giving out IP's of the time network) to anybody is to be considered a security flaw. Allowing anybody to change the configuration of a NTP server without even being logged into the server is obviously even more of a security issue. This can affect the overall distribution of time. This will not just have serious effects on the timestamps on the logs and also on billing. # restrict option places restrictions on one or more systems. This is implemented as a sorted address-and-mask list, with each entry including a set of flags which define what a host matching the entry *can't* do. noquery - host can have time, but can not make queries nomodify - allow the host to make queries except those which are actually run-time configuration commands. To avoid possible attacks via remote config functionality, it should ensure that ntpq can only be used by those who are logged into the server and also ensure that it can't be 40

used remotely. This can be achieved in Solaris 8 by adding the following configuration lines: restrict default nopeer restrict default noquery restrict default nomodify restrict 127.0.0.1 (Note that it is this last line that actually permits local users to use NTPQ) It is strongly recommended that only the user "root" have read and execute permission for both NTPQ (in /usr/lib directory) and to the NTP daemon process itself (/usr/lib/inet/xntpdc) and the ntp.conf configuration file. This will avoid letting other users have the rights to modify the configuration of NTP which could eventually affect the time stamps in the entire network. At install/upgrade time, ensure that the file permissions are set to read/execute for root only. The configuration for a server is as follows: > cat /etc/ntp.conf # Each NTP client should have access at least to two NTP server # sources for redundancy reasons to avoid single points of failure # server "ntp external source 1 IP@" minpoll 9 maxpoll 14 prefer server "ntp external source 2 IP@" minpoll 9 maxpoll 14 # #Following lines allow a server to synchronize #with its own real-time clock # server 127.127.1.0 minpoll 9 maxpoll 14 fudge 127.127.1.0 stratum 9 # #Next line it is used for maintenance purposes. #This file is used by the ntp daemon to write to. #This log file gives the correction factor to be applied to have #a more accurate clock. No symbolic links are allowed # driftfile /etc/inet/ntp.drift # #The following line permits to have a smooth #and slow change when differences in time are #detected, to avoid operational problems (only for WNMS Main Server) # slewalways yes # # Next line if not set, the local clock free-runs at # its intrinsic time and frequency offset # 41

disable pll # #Next line restrict the access from all IP addresses not permitting them to be used as peers for synchronization # restrict default nopeer # # Next line restrict the access from all IP addresses not permitting # them to query or modify the run time configuration of the time server # on this system # restrict default noquery restrict default nomodify # # Next line permits local users (logged #into the server to use ntpq restrict 127.0.0.1 #

5.6 TIME ZONE CONSIDERATIONS

Internally, Solaris uses Universal Time and is unaffected by time zone and daylight saving. However, the TZ line in /etc/default/init is adjusted to match with the location, so that programs can read and display time stamps appropriately for the location. For example, it should be used the line (as user root): TZ=Europe/Lisbon for Portugal Continental TZ=Europe/Madrid for Spain Continental TZ=Europe/London for Great Britain After the TZ line is changed in /etc/TIMEZONE linked to /etc/default/init, a reboot to propagate the change to all processes is required. An alternative temporary method to avoid the reboot can be reached using: # TZ=Europe/Lisbon # export TZ # TZ=Europe/Madrid # export TZ # TZ=Europe/London # export TZ A TZ setting like Europe/London operates by referring to a file /usr/share/lib/zoneinfo/Europe/London that contains compiled data about the history of time zone and daylight saving changes at that location. It is possible to run the time zone compiler yourself with a command like the following: 42

# In Solaris 8 and later: cd /usr/share/lib/zoneinfo/src cd /usr/share/lib/zoneinfo/usr/sbin/zic africa asia australasia europe northamerica southamerica This command generates compiled time zone files for all the locations mentioned in the text files 'africa', 'asia', etc. This is a much larger set than the set of compiled time zone files shipped by default in Solaris. If you're in an unusual location, you'll need to run zic to get the proper time zone file; e.g. you must run zic to get TZ=Antarctica/South_Pole to work. Changing the TZ= environment variable in the shell does not appear to affect the way that the date command works, so in order to know about the effect of the change, it is needed to do a reboot. Initial values of timezone settings do not consider the daylight savings time values. In 1993 the tz database went through the hassle of a great renaming, when old names like "GB" and "US/Eastern" were replaced by more specific names like "Europe/London" and "America/New_York". Previous values for timezone are still maintained to permit the old executables don't get confused by zone information that's in a new format since the new-format information is put in a place that the old executables don't look. The disadvantage of this approach is that old executables don't get *any* information about what the user wants. Time zones and daylight saving rules change every now and then, so the files in /usr/share/lib/zoneinfo are periodically updated by Sun, and you may need to install a time zone patch (e.g. patch 103834 for Solaris 2.5.1) to bring things up to date for your location. Or you can install the most recent version of the time zone text files from the public domain time zone database <ftp://elsie.nci.nih.gov/pub/>, and compile the files yourself with zic. You can also use a POSIX TZ setting like TZ=CET-1CEST,M3.5.0/2,M10.5.0/3 as described in the environ(5) man page, but this is more confusing and is easy to get wrong, and it mishandles time stamps preceding the most recent time zone or daylight saving rule change.

6 NTP AND TIME ZONE DEFINITIONS FOR OAM AND SCS SERVERS
The following sections are common to Main Server, Performance Server and SCS Server. In general they are applicable to Sun Servers.

6.1

RUNNING THE TIMEZONE COMPILER:

43

A TZ setting like Europe/London operates by referring to a file /usr/share/lib/zoneinfo/src/europe that contains compiled data about the history of time zone and daylight saving changes at that location. If you do not have this folder europe, it is possible to run the time zone compiler with the following command: # In Solaris 8 and later: #zic /usr/share/lib/zoneinfo/src/europe This command generates compiled time zone files for all the locations mentioned in the text files europe. This is a much larger set than the set of compiled time zone files shipped by default in Solaris. Time zones and daylight saving rules change every now and then, so the files in /usr/share/lib/zoneinfo are periodically updated by Sun, and it may be needed to install a time zone patch to bring things up to date for your location. Or it is possible to install the most recent version of the time zone text files from the public domain time zone database <ftp://elsie.nci.nih.gov/pub/>, and compile the files with zic. Please, see Annex A for details about the Time Zone descriptions.

6.2

TIMEZONE CONFIGURATION: The time zone that should be configured in workstations for UK is: For Europe/London for Great Britain In the European Union, Daylight Saving Time (DST) begins and ends at 1 am Universal Time Coordinated (UTC) or Greenwich Mean Time (GMT). British Summer Time advances the time by one hour from UTC. It starts the last Sunday in March, and ends the last Sunday in October. During the rest of the year, the time zone will be set to UTC.

The file /etc/TIMEZONE must exist, and it must contain the following lines (no more): # cat /etc/TIMEZONE # @(#)init.dfl 1.5 99/05/26 # # This file is /etc/default/init. /etc/TIMEZONE is a symlink to this file. # This file looks like a shell script, but it is not. To maintain # compatibility with old versions of /etc/TIMEZONE, some shell constructs # (i.e., export commands) are allowed in this file, but are ignored. # # Lines of this file should be of the form VAR=value, where VAR is one of # TZ, LANG, CMASK, or any of the LC_* environment variables. # TZ=Europe/London Export TZ 44

CMASK=022 # The file /etc/TIMEZONE must report this line: TZ= Europe/London File /etc/default/init must exist and contain the entry for Time Zone VERIFYING THE PARAMETERS:

6.3

# date # date -u The difference between these two commands is that the second one says the time difference related to the Greenwich meridian.

7 NTP DEFINITION IN MAIN SERVER

Nortel Networks recommendation to define the NTP Network and associated parameters for the Wireless UMTS network is presented below.

7.1

EDITING THE NTP.CONF FILE

As of UMTS V3/GPRS 5.0, WNMS OAM servers install scripts will support NTP configurations (install script asks for NTP servers (see CIQ) and this is used to configure the ntp.conf file. No manual configuration of the ntp.conf file is normally required. Following the NN NTP strategy the following applies: > cat /etc/ntp.conf #Each NTP client should have access at least to two NTP server #sources for redundancy reasons to avoid single points of failure # server ntp external source minpoll 9 maxpoll 14 prefer . . . . . . . server ntp external source minpoll 9 maxpoll 14 # # Following lines allow a server to synchronize # with its own real-time clock # server 127.127.1.0 minpoll 9 maxpoll 14 45

fudge 127.127.1.0 stratum 9 # #Next line it is used for maintenance purposes. #This file is used by the ntp daemon to write to. #This log file gives the correction factor to be applied to have #a more accurate clock. No symbolic links are allowed # driftfile /etc/inet/ntp.drift # #The following line permits to have a smooth #and slow change when differences in time are #detected, to avoid operational problems # slewalways yes # # Next line if not set, the local clock free-runs at # its intrinsic time and frequency offset # disable pll # # Next line restrict the access from all IP addresses not permitting # them to be used as peers for synchronization # restrict default nopeer # # Next line restrict the access from all IP addresses not permitting # them to query or modify the run time configuration of the time server # on this system # restrict default noquery restrict default nomodify # # Next line permits local users logged into the server to use ntpq restrict 127.0.0.1 # Remarks: Up to 3 external NTP servers are supported by the IM scripts. If more, then, ntp file must be edited. Case 040930-08080 was opened to permit the configuration of additional sources. Formal answer is that only three ntp servers are supported # If the Main server loses connectivity to all NTP servers, it will itself become a source of time and identify itself as stratum 9. # The Performance Server and Unix Client will all by default have a line added to them which will state that the preferred time source is the Main Server. If this line is not used, then, it is recommended to comment it.

46

8 NTP AND TIME ZONE PERFORMANCE SERVER

8.1
EDITING THE NTP.CONF FILE

DEFINITIONS

IN

As of UMTS V3/GPRS 5.0, WNMS OAM servers install scripts will support NTP configurations (install script asks for NTP servers (see CIQ) and this is used to configure the ntp.conf file. No manual configuration of the ntp.conf file is normally required. Example: > cat /etc/ntp.conf #Each NTP client should have access at least to two NTP server #sources for redundancy reasons to avoid single points of failure # server ntp external source minpoll 9 maxpoll 14 prefer . . . . . . . server ntp external source minpoll 9 maxpoll 14 # server ntp Main Server minpoll 9 maxpoll 14 # # The following will be used in CUSTOMER project as Secondary Source for NEs # #Following lines allow a server to synchronize #with its own real-time clock. # server 127.127.1.0 minpoll 9 maxpoll 14 fudge 127.127.1.0 stratum 10 # #Next line it is used for maintenance purposes. #This file is used by the ntp daemon to write to. #This log file gives the correction factor to be applied to have #a more accurate clock. No symbolic links are allowed # driftfile /etc/inet/ntp.drift # #The following line permits to have a smooth #and slow change when differences in time are #detected, to avoid operational problems # slewalways yes 47

# # Next line if not set, the local clock free-runs at # its intrinsic time and frequency offset # disable pll # # Next line restrict the access from all IP addresses not permitting # them to be used as peers for synchronization # restrict default nopeer # # Next line restrict the access from all IP addresses not permitting # them to query or modify the run time configuration of the time server # on this system # restrict default noquery restrict default nomodify # # Next line permits local users (logged #into the server to use ntpq restrict 127.0.0.1 # Same remarks than Main Server apply.

9 NTP AND TIME ZONE DEFINITIONS IN SCS SERVER

NTP configuration as of UMTS V3/GPRS 5.0, it is not supported on install script, and then manual configuration of the ntp.conf file is required. Even the default place to create this file is under /etc, /etc/inet is also a valid option. Due to the fact that Installation scripts only understand English language, for Time Zone settings, language must be English. If any other language is set up, the scripts will not work.

9.1

EDITING THE NTP.CONF FILE

Following the NN NTP strategy the following applies: > cat /etc/ntp.conf #Each NTP client should have access at least to two NTP server #sources for redundancy reasons to avoid single points of failure # server MAIN SERVER IP@ minpoll 9 maxpoll 14 prefer server PERFORMANCE SERVER IP@ minpoll 9 maxpoll 14 # 48

# Following lines allow a server to synchronize # with its own real-time clock. These are not being used at this time # # server 127.127.1.0 minpoll 9 maxpoll 14 # fudge 127.127.1.0 stratum 9 # #Next line it is used for maintenance purposes. #This file is used by the ntp daemon to write to. #This log file gives the correction factor to be applied to have #a more accurate clock. No symbolic links are allowed # driftfile /etc/inet/ntp.drift # #The following line permits to have a smooth #and slow change when differences in time are #detected, to avoid operational problems # slewalways yes # # Next line if not set, the local clock free-runs at # its intrinsic time and frequency offset # disable pll # # Next line restrict the access from all IP addresses not permitting # them to be used as peers for synchronization # restrict default nopeer # # Next line restrict the access from all IP addresses not permitting # them to query or modify the run time configuration of the time server # on this system # restrict default noquery restrict default nomodify # # Next line permits local users (logged #into the server to use ntpq restrict 127.0.0.1 #

10 NTP AND TIME ZONE DEFINITIONS IN SDM SERVER

sdmconfig application is the SDM configuration level organized like a wizard that walks the user through all steps required to get the SDM running. sdmconfig configuration environment is less error prone than editing files. 49

10.1 TOD CLOCK SYNCHRONIZATION

Before starting the NTP server on the SDM, its TOD clock must be synchronised with the NTP master server selected in the ntp.conf file using the ntpdate command: >ntpdate ntp external source xntpd has overwhelming advantages compared to ntpdate as a technique to synchronize a machine on an ongoing basis. Running ntpdate once before starting xntpd is however a good combination, because: 1. If the time on the machine is more than 1000 seconds offset compared to UTC, then NTP will simply not correct the clock 2. The NTP synchronization will occur more rapidly and without jerks if the machine is < 128 milliseconds offset from UTC when xntpd is started. This kind of precision is only achievable by ntpdate. A monitor process automatically starts xntpd as soon as servers are configured.

10.2 NTP CONFIGURATION

When NTP is running the DTS (Distributed Time Service) feature of DCE has to be disabled to prevent conflicts; however the other services of DCE (security, name service, remote procedure calls) are still available. If DCEs Distributed Time Service (DTS) is commissioned, you will be prompted to remove it once you have commissioned NTP. For this, you will need a DCE administrator password. At the local VT100 console or via a remote terminal session: 1. Log into the SDM as a root user 2. Access the SDM configuration level by typing # sdmconfig and pressing the Enter key 3. Access the NTP commissioning step level by typing > step <#> NTP step 16 and pressing the Enter key, where <#> is the number next to the Network Time Protocol commissioning step. Note: Use Up (12) or Down (13) to scroll through the list until you see the Network Time Protocol commissioning step.

50

4. Add an NTP server or peer by typing > add and pressing the Enter key. When prompted, select the type of host you want to add by typing > 1 (to add a server) or 2 (to add a peer) and pressing the Enter key. Note: A peer can act as a server When prompted, enter a description for that server or peer. When prompted, enter the host name for that server or peer. When prompted, enter the IP address for that server or peer.

Note 1: Only one server is required for synchronization. You can add a maximum of 20 server or peers to increase reliability. If the SDM cannot contact one server to synchronize, it may be able to contact another. It is recommended to add at least 3 servers. Note 2: For Security reasons, the usage of the peers is restricted, adding a line into the ntp.conf file > restrict default nopeer. For more details, please, read section Network Time Synchronization Engineering Considerations First NTP source: MAIN SERVER IP@ Second NTP source: PERFORMANCE SERVER IP@ 5. When prompted, confirm the add command by typing >y and pressing the Enter key Response: Synchronization in progress, may take up to 30 mins. Verifying if DTS (Distributed Time Service) feature of DCE is configured:

51

6. When prompted, enter your DCE administrator password and remove DTS 7. Use the following table to determine your next step

Verify that the servers configured show up in the list inside the sdmconfig NTP screen: > sdmconfig > step 16 Network Time Protocol Commissioned # Hostname Str. State When Poll Delay Offset Disp 1 ntpsource1 3 * 54 64 0 0 10 2 3 Check to see that the servers all display a non alarmed state. For checking, go to the NTP level of the sdmmtc command; servers are not alarmed if the state field is either + or *. 8. Reboot the SDM in order that the changes take effect.

9. Verify the date and time: > sdmconfig > step 4 Date and Time 10. Verify that the ntp.conf file contains the Access Control settings: # Settings can be modified via the edition of the ntp.conf file in stead to use the #sdmconfig application. This is not a recommended practice. During the upgrades #sdmconfig will in some cases overwrite changes made directly to /etc/ntp.conf #sdmconfig writes ntp servers in the /etc/ntp.conf file. This file is then read by #xntpd when it runs # 52

> more /etc/ntp.conf # Each NTP client should have access at least to two NTP server # sources for redundancy reasons to avoid single points of failure # the translation from hostname to NTP IP@ is done in the /etc/hosts file. # Warning! If administrators/users manually add more than 20 # servers/peers, the functionality of the NTP feature will be indeterminate! # server ntp_server_1 server ntp_server_2 # # Following lines allow a server to synchronize # with its own real-time clock. These are not being used in Customer project # # server 127.127.1.0 minpoll 9 maxpoll 14 # fudge 127.127.1.0 stratum 8 # # Next line it is used for maintenance purposes. # This file is used by the ntp daemon to write to. # This log file gives the correction factor to be applied to have # a more accurate clock. No symbolic links are allowed # tracefile /etc/ntp.trace driftfile /etc/ntp.drift # # Next line if not set, the local clock free-runs at # its intrinsic time and frequency offset # disable pll # #Next line restrict the access from all IP addresses not permitting #them to be used as peers for synchronization # restrict default nopeer # # Next line restrict the access from all IP addresses not permitting # them to modify the run time configuration of the time server # on this system # restrict default nomodify # # Next line permits local users (logged #into the server to use ntpq restrict 127.0.0.1 # The following is the Default NTP configuration file. # # Broadcast client, no authentication. # 53

# *Warning! If administrators/users manually add more than 20 # servers/peers, the functionality of the NTP feature will be indeterminate! driftfile /etc/ntp.drift tracefile /etc/ntp.trace restrict default nomodify restrict 127.0.0.1

10.3

CHECKING THAT THE XNTPD DAEMON ON THE SDM IS RUNNING

Note: sdmmtc and sdmconfig are linked each other. Documentation tends to refer to sdmconfig when talking about the initial system configuration, and sdmmtc for day-today maintenance. To check that xntp is running, verify that NTP level shows good values for the server parameters inside the sdmconfig NTP screen: > sdmconfig > step 16 Network Time Protocol Commissioned # Hostname Str. State When Poll Delay Offset Disp 1 ntpsource1 3 * 54 64 0 0 10 2 3

10.4 TIMEZONE CONFIGURATION:

If the Time Zone configuration settings are done at the same time that an upgrade, then, SDM must be either in split mode or out of service (non-split mode). If the Time Zone configuration settings are done independently of an upgrade, it is recommended to use the split-mode process as opposed to the non-split mode process, which would take the SDM out of service for approximately 20 min. To use the split mode process, first follow the steps [17] under Splitting the system and then follow the steps under Changing the system time zone and daylight savings time parameters in this procedure. To use the non-split mode process, first follow the steps [17] under Busying the SDM and then follow the steps under Changing the system time zone and daylight savings time parameters in this procedure. The time zone that should be configured is: GMT0BST. At the local VT100 console: 1. Log into the SDM as a root user 2. Enter the Time Zone level by typing # sdmconfig # step 3

54

and pressing the Enter key. 3. Change the time zone by typing > Change 3 and pressing the Enter key. Example response:

4. Refer to the following table to determine your next step:

Note: Use Up (12) or Down (13) to scroll through the list until you see the Network Time Protocol commissioning step. 5. Select a Time Zone by typing: >n Key 13 is the one for United Kingdom (GMT0BST) (CUT) and pressing the Enter key. 6. When prompted, confirm, reject, or edit the values 7. Verify the content of the file /etc/environment contains the TZ setting. There is a lot more information not related to timezone in the environment file, which is not worth mentioning. TZ= GMT0BST

55

11 NTP AND TIME ZONE DEFINITIONS IN SIG

11.1 EDITING THE NTP.CONF FILE
NTP configuration as of UMTS V3/GPRS 5.0, it is not formally supported by Nortel Networks. It means that the settings are not included into the install script, then manual configuration of the ntp.conf file is required and if there is any issue with this manual configuration, it is not guaranteed that it can be supported by Nortel Networks. In PC03 it is not allowed NTP to be used even in an "unsupported" scenario. It will be formally supported from PC04. The following are the steps followed for the creation of the ntp file: 1. Under /etc, to create the ntp.conf file: > cat /etc/ntp.conf #Each NTP client should have access at least to two NTP server #sources for redundancy reasons to avoid single points of failure # server MAIN SERVER IP@ version 3 prefer server PERFORMANCE SERVER IP@ version 3 # #Following lines allow a server to synchronize #with its own real-time clock. These are not being used at this time. # # server 127.127.1.0 minpoll 9 maxpoll 14 # fudge 127.127.1.0 stratum 9 # #Next line it is used for maintenance purposes. #This file is used by the ntp daemon to write to. #This log file gives the correction factor to be applied to have #a more accurate clock. No symbolic links are allowed # driftfile /etc/inet/ntp.drift # # Next line if not set, the local clock free-runs at # its intrinsic time and frequency offset # disable pll # #Next line restrict the access from all IP addresses not permitting #them to be used as peers for synchronization # restrict default nopeer # #Next line restrict the access from all IP addresses not permitting # them to query or modify the run time configuration of the time server #on this system 56

# restrict default noquery nomodify notrust # # Next line permits local users (logged #into the server to use ntpq restrict 127.0.0.1 # 2. Verify that the ntp line: ntp 123/udp # Network Time Protocol

it is uncommented in /etc/services 3. Under /etc, to create the ntp.drift file. 4. Slewing: The NTP daemon has three regimes in which it operates: offset below 128 milliseconds. This is the normal operating regime for NTP, and a properly configured NTP hierarchy (with reasonable networking) can operate for years without ever approaching the 128 msec upper limit. All time adjustments are small and smooth (known as SLEWING), and nobody even notices the SLEW adjustments unless they have a cesium clock or a GPS clock and expensive instrumentation to make sophisticated measurements (HP Santa Clara Division makes the instruments) offset above 128 milliseconds. This regime is often encountered at power-on, because those battery-backed real-time clocks they put in computers are not too great. Because NTP is quite capable of keeping the offset below one millisecond all the time it is running, many users want to get into the normal regime quickly when an offset above 128 msec is encountered at startup. So in this situation NTP will (fairly quickly) make a single STEP change, and is usually successful in getting the offset well below 128 msec so there will be no more of the disruptive STEP changes offset above 1000 seconds. This is so far out of the normal operating range that NTP decides something is terribly wrong and human intervention is required. The daemon shuts down.

The catch is that the dispersion on a WAN is frequently much greater than 128 msec, so you may see (a lot of) the STEP changes, perhaps as large as 1000 msec (depends on your network). But there are customer applications that are quite allergic to the STEP changes, particularly backward steps (which will happen about half the time). Databases and financial transaction systems are examples. NTP can be compiled in such a way that it never makes a STEP, but instead SLEWS the clock to drive the offset to zero. This effectively removes the middle operating regime. You won't get millisecond (or microsecond) precision with this method, but you probably can't get that over a WAN anyway. Just install PHNE_19711 to get the SLEW behavior in "/usr/sbib/xntpd.slew" (HPUX 11.X), or you can use "ntpdate -B". 57

11.2 TIMEZONE CONFIGURATION:

Under more /usr/lib/tztab, it is possible to see for all the settings to be used to configure the Time Zone in SIG equipments. The time zone that should be configured in workstations for UK is: GMT0BST The file /etc/TIMEZONE must exist, and it must contain the following lines (no more): TZ= GMT0BST Export TZ The file /etc/TIMEZONE must report this line: TZ= GMT0BST

11.3 RUNNING THE XNTPD PROCESS

The task xntpd (Network Time Protocol Deamon) must be running on all workstations to be synchronized. The section of the file where the XNTPD variable can be found is the following: ###################################### # xntp configuration. See xntpd(1m) # ###################################### # # Time synchronization daemon # # NTPDATE_SERVER: name of trusted timeserver to synchronize with at boot # (default is rootserver for diskless clients) # XNTPD: Set to 1 to start xntpd (0 to not run xntpd) # XNTPD_ARGS: command line arguments for xntpd # # Also, see the /etc/ntp.conf and /etc/ntp.keys file for additional # configuration. export NTPDATE_SERVER= XNTPD=1 export XNTPD_ARGS= # ###################################### The NTPDATE_SERVER is used to initially set the time at bootup. Usually this is the preferred NTP server. Setting the variable called NTPDATE_SERVER to be some working NTP server that is reachable. This will run the "/usr/sbin/ntpdate" command just before the NTP daemon is starting, and bring your system clock very close to the other server to start. This enormously improves stability at startup.

58

Then set the XNTPD variable to "1". This will cause the daemon to be started automatically when your system makes the transition from run level 1 to 2. Previous to run the xntpd daemon, run the ntpdate -B <server_name> command: The ntpdate -B option will adjust the internal HP-UX clock divisor slightly to about 50 ms per second, and once the time is within 128 ms of the time server, ntpdate will readjust the divisor back to normal. The rate is 50ms/sec--20 secs to move one second, 1200 secs (20 mins) to move one minute. When the time is accurate, ntpdate adjusts the HPUX clock divisor back to normal. If you see an error saying there is no server suitable for sync, use the ntpq -p <server> test to see if it is reachable. Once the server is accurate, you can start/stop xntpd using the standard start/stop script: > sh /sbin/init.d/xntpd start > sh /sbin/init.d/xntpd stop You can look for messages in the syslog file using > grep ntp /var/adm/syslog/syslog.log or into the /etc/rc.config.d/netdaemons file, see the specific path for the syslog. Also SAM tool can be used instead to setup the XNTPD variable to 1.

11.4 VERIFYING THE PARAMETERS:

Since the ntp deamon is not running on the SIG it has to be started for testing the changes: 1. Login to the Standby Server as root, verify that the SIG package is running on the other Server: cmviewcl 2. Reboot the standby server 3. Re-login to the Standby Server as root. 4. Verify that the "xntpd" is running: ps -aef | grep -i xntpd

5. Verify that the clock is synchronized with the external ntp server: ntpdate -q <ntp external source ip address>

6. > date 7. > date u The difference between commands in 6 and 7 is that the second one says the time difference with the Greenwich meridian. 59

8. Enable the switching Flags on the Standby server: cmmodpkg -e -n <Standby node> <SIG Package Name> e.g. cmmodpkg -e -n brc2h00c SIG 9. Enable the package switching Flag: cmmodpkg -e <SIG Package Name> e.g. cmmodpkg -e SIG 10. Use the ss7MgrStart GUI to switch the Stack to the Standby Server 11. Check that the package is running on the new Active Server: cmviewcl 12. Perform steps 1-8 on the new Standby Server

12 NTP AND TIME ZONE DEFINITIONS IN ACCESS DOMAIN

All iRNC cards will be Time synchronized with the OAM. The iRNC will be synchronized with the OAM server as primary source. The OAM main server is also synchronized on NTP server: Refer to the procedure [R5]. The following are the steps of configure and activate NTP server on the iRNC:

12.1

CONFIGURATION OF THE NTP SERVER IP ADDRESSES ON BOTH OMU:

The following is the procedure of xntpd startup for both OMUs. The standard unix configuration files like /etc/ntp.conf, and /etc/environment are never upgraded by the basic upgrade mechanism of the Control Node. The reason is that there are two versions of the software that is shipped on the disk of the OMU on two different subtrees and the upgrade is done on the unused subtree while the active one is running, then the software switch to the upgraded tree. AIX, its executables and its configuration files are not duplicated and cannot be so easily upgraded: a mechanism exists however when it is necessary (in fact the system is reboot and at start-up - before the application starts - the files are upgraded). /OMU is a symbolic link either on the active subtree /OMU_STORAGE/TREE1 or /OMU_STORAGE/TREE2. The software is delivered as a set of "packages" that are

60

archive files. The tree is not specified when building the package; the files will be installed either on tree1 or tree2. Contained into the set of packages are 2 configuration files installed under "/OMU/local/usr/data/": "btime_ntp.keys" for authentication "btime_srv.conf" for NTP server address These 2 files are allowed to be modified by user to customize the local NTP setup. They will be used to generate "btime_ntp.conf", which will be located at the same directory. btime_ntp.conf file includes the following additional information in addition to the provided by the "btime_ntp.keys" and the "btime_srv.conf" files: Authentication settings from the btime_ntp.keys ntp servers from the btime_srv.conf file.

When the System starts-up, bosinitd executes the btime_ntp_start script. The btime_ntp_start will execute build_xntp_conf() to generate "btime_ntp.conf" from "btime_ntp.keys" and "btime_srv.conf". The auto-generated btime_ntp.conf will contain the following lines: #-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=# Name : NTP server configuration file # File : /OMU/local/usr/data/btime_ntp.conf # Description : Configuration data for NTP server # # Gen. Date : Thu Sep 9 19:58:11 GDT 2004 # Server file : /OMU/local/usr/data/btime_srv.conf #-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=# # THIS FILE IS GENERATED AUTOMATICALLY # ---- DO NOT EDIT ---# #-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=# # Server options # enable auth monitor # # Path for the driftfile which contains information on the rate of drift of a client clock # driftfile /OMU/local/log/btime_ntp.drift # # Path for the NTP statistics files # statsdir /OMU/local/log/ 61

#filegen peerstats file peerstats type day enable #filegen loopstats file loopstats type day enable #filegen clockstats file clockstats type day enable # # Line to control the amount of output written to syslog or the logfile # #logconfig =syncall +clockall logconfig =syncstatus +sysevents # # Authentication Options from the btime_ntp.keys file: # keys /OMU/local/usr/data/btime_ntp.keys trustedkey 42 requestkey 42 controlkey 42 # # Lines allowing the OMU to synchronize with its own real-time clock # server 127.127.1.0 minpoll 4 maxpoll 6 prefer fudge 127.127.1.0 stratum 12 (please, see note below at the end of the section !!) # # ntp servers from the btime_srv.conf file # server 10.250.12.20 minpoll 12 maxpoll 14 prefer # # To send periodic broadcast messages to TMUs and other boards on the shelf # broadcast 172.253.255.255 The only key defined in btime_ntp.keys is key #42. This is used by /OMU/local/usr/sbin/btime_ntp_start and /OMU/local/usr/sbin/btime_ntp_set_server. Both scripts rely on xntpdc and xntpdcrequires these authentication keys to be defined. The active OMU will use "xntpdc" to configure the NTP on passive OMU. "btime_ntp.keys" contains keys and key identifiers used by ntpd, ntpq and ntpdc when operating with symmetric key cryptography. This is the same operation as the -k command line option. "btime_srv.conf" contains NTP server IP@. Users may modify this file to add or change the NTP server IP@. It must be avoided the edition of this file. Instead, users should use /OMU/local/usr/sbin/btime_config or TML to configure NTP server addresses on OMU. These 2 files can be used only to check the value and they must not be used for changes. btime_config w or TML should be used to configure NTP server addresses on OMU. Anyone who modifies them should be aware of the consequences.

After "btime_ntp.conf" is generated, btime_ntp_start.ksh will start xntpd with "-c" option to overwrite the standard configuration file "/etc/ntp.conf" with "btime_ntp.conf". 62

"/etc/ntp.conf" is not used in this system and "btime_ntp.conf" will be processed by xntpd. /OMU_STORAGE/TREEn/local/usr/data is the directory holding the btime (one of software components in BaseOS controlling NTP on C-Node) configuration files. Ensure that the following files exist on both OMUs: /OMU_STORAGE/TREEn/local/usr/data/btime_ntp.keys /OMU_STORAGE/TREEn/local/usr/data/btime_srv.conf If not, then software is not installed. Without these 2 files, "xntpd" will not be configured properly. So these 2 files have to be created before starting "xntpd". In order to avoid configuration loss when Creating/configuring files at software installation time, the following procedure needs to be done: Create, if it does not exist, the "btime_srv.conf" file on each OMU on the 2 following directories: /OMU_STORAGE/TREE1/local/usr/data /OMU_STORAGE/TREE2/local/usr/data

There are 2 copies of btime_srv.conf on every OMU. One copy for each subtree. To change NTP server addresses on OMU, both copies have to be modified to have the same NTP server addresses. There are 2 approaches can be used to change NTP server address on OMU: A> Going to each tree and modify the btime_srv.conf manually. (NOT RECOMMENDED). This approach is complicated and can be error prone. User will have to jump to 2 different directories, modify 2 files and make sure they are same. Using "btime_config -w" (RECOMMENDED). This command will hide all the complicities from users. User will invoke the command once on each OMU, type in the address once. Both copies of the btime_srv.conf will be modified and kept in sync.

B>

The format of "btime_srv.conf" file has to be as following: #-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=# Name : NTP server declaration file # File : btime_srv.conf # Description : Declaration of NTP servers # # Author : Christian Monfort # Date : Tue Apr 30 17:35:20 2002 # Reader : # Evolutions : # 30/04/2002 : C.Monfort CR Q00209310 63

# * First release #-=-=-=-=-=-=-=-=-=-=-=--=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=# # Primary NTP server (only the first one is mandatory) # Primary= # # Secondary NTP servers (optional) Secondary= Secondary= # At least the primary address must be filled. Secondary Addresses are optional. If the file already exits check that the NTP server IP addresses are correct and are the same on both directories and on both OMU private disk. Since "btime_ntp.conf" will be auto-generated and overwritten every time system starts, the access control can not be changed by simply modifing the "btime_ntp.conf". Note: Fudge value in OMU has been changed to 12. Then, no manual intervention is required Background. Because the current fudge settings in WNMS and OMUs differ being greater the one in WNMS (WNMS fudge = 9 and OMU fudge = 5), the OMU never will synch from the WNMS. Case Q00962995 has been opened to fix this situation and to change the fudge value in OMU to 12. In meantime that fudge setting is set up to 12, RNC value needs to be modified accordingly. To do that it is necessary to change the script /OMU/local/usr/sbin/btime_ntp_start: 1. CHANGE stratum="stratum ${5:-5}" # Default = 5 TO stratum="stratum ${5:-12}" # Default = 12 2. Stop and restart NTP server using btime_ntp_start 3. And restart ntp server whith the command : sbin 4. run_root btime_ntp_start 5. run_root btime_ntp_set_server 6. run_root ntpq -p The fudge value to 9 in WNMS server allows other Time sources, which might not be considered normally because they are of lower stratum than the usual WNMS stratum to be reconsidered as potential time sources when WNMS can no longer contact it's own source. When WNMS is no longer synchronized to a real and official time source, it falls back to its own clock which being Solaris based can NEVER be as good as even a bad source of high stratum value which is really synchronized via many hops to a real stratum 1 server. 64

By telling WNMS to consider itself as stratum 4 source, it means that it is better to use it's own internal clock than to use a real stratum 4 (or 5) source (and a backup time source taken off the net could easily be of stratum 4 or 5).

12.2

ACTIVATE NTP SERVER ON THE IRNC CNODE:

Two options are possible to activate the NTP server on the iRNC: 1. Execute the following command on each OMU with root login: /OMU/local/usr/sbin/btime_ntp_start

To start xntpd on OMU or the correct configuration file will not be used; remember that active OMU needs to listen to external NTP servers, and to synchronize passive OMU and broadcast NTP data to internal network. 2. Execute the following command on active OMU only: /OMU/local/usr/sbin/btime_ntp_set_server (This is automatically done when OMU becomes active). btime_config has a option "-s" to restart xntpd with new btime_srv.conf. "btime_config -s" combines "btime_ntp_start" and "btime_ntp_set_sever". And it's restricted to run only on active OMU.

3. New configuration can also be taken into account by restarting both OMUs without running the previous commands. If this method is chosen make sure that the Time Zone and date dont need to be modified. xntpd on both OMU are active by default after restart. To check that xntpd is running on AIX: > lssrc -s xntpd Subsystem Group xntpd tcpip PID 7444 Status active

If service is not started, then Status is "inoperative" and PID is empty.

12.3

NTP UPDATE

Configuration of the NTP servers can be done via btime_config or using the TML tool. Using btime_config the NTP Server /OMU/local/usr/data/btime_srv.conf file. configuration will be updated on

65

Syntax: btime_config -w [-s] addP addS1 addS2 addS3... | -r -w : Write the IP addresses in btime_srv.conf on both trees define one or more addresses to save -r : Read the IP addresses from btime_srv.conf on the current and alternate tree -s : Start the NTP server with the new configuration THE OMU MUST BE ACTIVE TO RESTART THE NTP SERVER

Using the TML tool it is possible to update the NTP servers. The following figure illustrates an example of the NTP server configuration dialog box. Select Configuration/Networking Protocol from the Univity RNC C-Node TML main window. The NTP server configuration dialog box appears:

66

Click Set to confirm, then, the NTP server configuration Warning window appears:

After confirmation, the NTP server configuration Summary window appears:

67

After exiting the NTP server configuration Summary window, the NTP server configuration reset Warning window appears.

Refer to the following table to continue:

68

12.4

TIMEZONE CONFIGURATION:

When any user logs in, the system sets environment variables from the "/etc/environment" file before reading the login profile, .profile. By default, the ".profile" for "root" and "omu" will not set TZ. For timezone changing utilities to work properly, TZ setting must not appear in ".profile". That includes chtz, bclock_config and smit. Anyone who adds TZ to ".profile" should be aware of the consequences.

69

A line in "/etc/environment" like "TZ=CST6CDT5,J129,J131/19:30" or "TZ=CST6CDT5,M5.1.0,M5.2.0" will set the timezone for all the users unless TZ is overwritten by user specific .profile. "chtz" command will take one parameter and use it as a string to change the "TZ=" line in "/etc/environment" file. This change will take effect after user logout and log back in. "bclock_config -s" will take one parameter and use it as an index to retrieve an item from a predefined list of timezone info. It will invoke "chtz" command to modify the "/etc/environment" file. In addition, it will invoke putenv() to change current value of TZ environment variable. "chtz" command is able to set daylight saving settings, which is not provided by "bclock_config -s". But it will allow any arbitrary string to be put in "/etc/environment" file. e.g. TZ=abc. "bclock_config -s" will validate the parameter. ("bclock_config -d" will display timezone info list with index). But it's lack of daylight saving facilities. And any changes to the available timezone info list will require coding changes. Then, in order to change the timezone settings, execute the following command on each OMU with root login: chtz TimeZoneName. For example: GMT0BST. For details about the correct way to configure the TZ settings, please, see appendix 15. Note: The environment file is only being used to check the value and it must not be used for changes. The file /etc/environment must exist, and it must contain the following lines: PATH=/usr/bin:etc/usr/sbin:/usr/ucb:/usr/bin/X11:/sbin TZ= GMT0BST LANG=en_US LOCPATH=/usr/lib/nls/loc NLSPATH=/usr/lib/nls/msg/%L/%N:/usr/lib/nls/msg/%L/%N.cat LC_FASTMSG=true ODMDIR=/etc/objrepos For UK, the time zone that should be configured is: Time Zone Name GMT0BST UTC Delta (Hour) 0 Time Zone Description United Kingdom 0

12.5 DATE CONFIGURATION ON EACH OMU

Execute the following command on each on each OMU if the date/time is not up to date with root login: 70

(root)# date MMDDHHMMYYYY For example: date 102815332002

12.6

ACTIVATE THE TIME ZONE AND DATE ON EACH OMU

To take into account the Time Zone modification & new date, both OMU must be restarted. Note: "bos_suicide -b" will reset the whole system. This command will cause the service loss. So it must not be used if the shelf is in service. In order to avoid a loss of service, the best option is to manually restart the passive OMU first and when it recovers, then perform a manual reset to the active OMU. 1> Type in "bos_suicide" without any parameters on passive OMU 2> Wait the OMU to come up. It will take a few minutes. There is not an easy to tell the OMU has finished the reboot. "sm_launcher.exe ps" and "omu_diag 3 cnbos" can be used. Just to be safe, just wait for 20 minutes. 3> After the passive OMU comes up completely, type in "bos_suicide" without any parameters on active OMU. This will cause a "OMU swact", i.e. the passive OMU will become active and previous active OMU will come up as passive. For changing timezone on OMU, it is possible for the user to choose from 2 different sequences: o o Configure the passive OMU, reset it, wait for the passive OMU to bootup, configure active OMU, reset it. Configure the passive OMU, configure the active OMU, reset the passive OMU, wait for the passive OMU to bootup, reset the active OMU.

There is no enforcement for system reboot after timezone change, neither any checking for different timezones on 2 OMUs in duplex system.

12.7 12.8

NTP SERVER CONFIGURATION & ACTIVATION ON IRNC-IN

Please, see below section 17.1 for PP based nodes. DATE VERIFICATION ON NODE B

CCM-RTC_TOOLS/UTIME>g -------------------------------------------------------------------CCM Card Time: Time in seconds from 01/01/1970 : 1057775656 Time in milliseconds : 80 Current RTIcount : 20337099 71

RTICountRef : 19611495 DeltaRTICheck : 725604 DeltaSecCheck : 14512 timePropagRef.msec :0 timePropagRef.second1970 : 1057761144 MilliSecCheck : 80 MilliSecondsCheck : 80 SecondsCheck : 1057775656 Date & Time : 9/7/2003 : 18H 34min 16sec 0msec -------------------------------------------------------------------CCM-RTC_TOOLS/UTIME>2003-07-09 19:34:59 WAR: 0x01365a62, CCM_SEPEPROXY_CORE> Get UTC to GPSAM Time at : 20030709193459+0200 2003-07-09 19:34:59 WAR: 0x01365a64, CCM_SEPEPROXY_CORE> Get UTC to GPSAM Tim e at : 20030709193459+0200

13 NTP AND TIME ZONE DEFINITIONS IN PACKET DOMAIN

13.1.1 NETWORK AND NODE TIME

There are three types of time to consider when configuring the time on a Passport node: reference time network time module time The reference time is the date and time that is the official reference around the world. The universally accepted reference time is Coordinated Universal Time (UTC) which, in general, is equivalent to Greenwich Mean Time (GMT). The network time is the date and time that is common across the whole network. This is the date and time to which all nodes in the network synchronize internally. Nortel Networks recommends that you use UTC for the network time. The network time is controlled by one or more time servers. The module time is the time on a particular Passport node. In most cases, you synchronize the module time on a node to the network time on a time server. You then adjust for time zone differences using a time zone offset. Passport uses the module time for time stamps in alarms, accounting records, and other time-stamped data. There are three main approaches to configuring time in a Passport network: Operating the whole network using reference time: This approach is recommended by Nortel Networks. It guarantees there is no confusion with the date and time presented in alarms, accounting records, and other time-stamped data. All such data generated by the network has the same, consistent time stamp based on UTC. With this approach, a time offset of zero is configured on each node in the Passport network. As well, the whole network is synchronized to a common time reference. See Synchronizing 72

automatically with a network time server and Synchronizing manually with a network time server. In this manner, the reference time is used as network time as well as module time. Operating the whole network in a single time zone: This approach can be used by networks where all nodes are within the same time zone. This approach can also be used by networks that are operated as if all nodes are in the same time zone. All alarm, accounting records, and other time-stamped data has the same, consistent time stamp based on a single time zone.. With this approach, a non-zero time offset representing a specific time zone is selected to be used for the whole network. The selected time offset is configured on each node in the Passport network. As well, the whole network is synchronized to a common time reference. See Synchronizing automatically with a network time server and Synchronizing manually with a network time server. In this manner, the time in the chosen time zone is used as network time as well as module time. Although the reference time (UTC) is used to synchronize all Passports in the network, each node displays time using the selected, common time offset. In this manner, the date and time reported by all nodes in the network is the same.

Operating each node in its own time zone: This approach can be used by networks that require that each node in the network display the time based on the time zone where the node resides. All alarm, accounting record, and other time-stamped data has a time stamp that corresponds to the time on the node it is coming from. With this approach, a different time offset is configured on each node in the Passport network. However, the whole network is still synchronized to a common time reference. See Synchronizing automatically with a network time server and Synchronizing manually with a network time server. Although the reference time (UTC) is used to synchronize all Passports in the network, each node displays time using its own time offset, based on the time zone where the node resides. In this manner, the date and time reported by all nodes in the network can be different. 13.1.2 NODE TIME AND DATE CONFIGURATION:

The Time and Server components provide access to management devices (MD) acting as network time servers. Passport XNTP is the software feature on Passport switches that controls network time synchronization. The XNTP protocol relays time server data between Passport nodes andMDtime servers using the user datagram protocol (UDP) over IP. These MDs can reside in the LAN or WAN environments, or both. Note: If there is a difference of more than 1000 seconds between the network time server MD and your Passport node, synchronization does not occur. In this situation, you have to set the node time manually so that it is within 1000 seconds of the MD time. 13.1.2.1 Synchronizing automatically with a network time server. You can synchronize your Passport node with up to 10 MDs that are acting as network time servers. An MD can be any workstation running either: stand-alone WNMS Main Server 73

 WNMS Main Server with public network time protocol (NTP) some other management system running public NTP.. See RFC 1305, Network Time Protocol (Version 3) for more information on public NTP. In case a network time server is not specified, Passport automatically attempts to synchronize with a WNMS workstation it can reach using its IP interface over frame relay (IPIFR) or its IP interface over virtual circuit (IPIVC). If time servers are deleted when Passport is up and running, Passport does not synchronize with a WNMS workstation. For example, automatic synchronization works at startup if no time servers are specified. Note: As soon as you configure a Server component, the Passport software disables the automatic synchronization capability. Perform the following procedure in provisioning mode: 1. Add a Server component for each network time server: add Time Server/<n> where: <n> is the instance of the Servercomponent. You can provision up to 10 Server components (decimal 1-10) on a Passport node. 2 Specify the IP address of the network time server: set Time Server/<n> ipAddress <address> where: <n> is the instance of the Server component. <address> is the IP address of the MD that you wish to set as a time server to your node. 3 Select the IP routing stack for time server connectivity: set Time Server/<n> ipStack <type> where: <n> is the instance of the Server component. <type> is either ipiFrIpiVc (for frame relay/X.25 connectivity to a time server MD) or VrIp (for IP connectivity to a time server MD).

13.1.2.2 Synchronizing manually with a network time server. You have the option to manually synchronize your Passport node with any MD that is running public NTP software. That MD can be any workstation running management software that includes NTP (such as WNMS server or third party). Passport XNTP software allows you to choose exactly which and how many (up to 10) MDs with which to synchronize your node. This flexibility means that you can choose MDs in both the WAN 74

and LAN. Connectivity to MDs running public NTP can be using IPIFR/IPIVC, or IP, over link layer protocols such as frame relay, X.25, asynchronous transfer mode (ATM), ethernet, and point-to-point protocol (PPP). If you cannot or do not want to synchronize the time on your node with the network time, you can manually set the module time. You cannot manually set the time if your node is already synchronized with a network time server. Perform the following procedure in provisioning mode: 1 Check the synchronization status of your node: display Time syncStatus 2 If the syncStatus attribute is unsynchronized, set the moduleTime attribute to the current date and time: set Time moduleTime <yyyy>-<mm>-<dd> <hh>:<mm>:<ss> where: <yyyy> is the year. <mm> is the month. <dd> is the day. <hh> is the hour. <mm> is the minute. <ss> is the second. 3. Configuring the time zone offset When your node synchronizes with an MD acting as a network time server, Passport XNTP sets the node time to the network time (reference time), which is UTC. This happens whether synchronization is done automatically or manually. You can account for different time zones by setting the difference from UTC using the offset attribute. The offset attribute is a writable operational attribute under the Time component. The time zone offset value ranges from -720 to 720 minutes, which represents a range of 24 hours (-12 hours to +12 hours). A time offset between 0 and 720 minutes (+12 hours) represents a time ahead of UTC (or east of the prime meridian). A time offset value between 0 and -720 minutes (-12 hours) represents a time behind UTC (or west of the prime meridian). Use the following examples as guidelines to set the time zone offset value: If you operate the whole network using reference time, set the time zone offset to 0 (the default value). If you operate the whole network in a time zone east of the prime meridian, add 60 minutes to the minimum time zone offset (0) for each hour you are ahead of UTC. For example, if your time zone is two hours ahead of UTC, set the time zone offset to 120. If you operate the whole network in a time zone west of the prime meridian (for example, Eastern Standard Time), subtract 60 from the minimum time zone offset (0) for 75

each hour you are behind UTC. For example, if your time zone is four hours behind UTC, set the time zone offset to -240. Perform this command in provisioning mode: 1 Set the offset attribute of the Time component to the number of minutes that the node local time is before or after the network time: set Time offset <offset> where: <offset > is the number of minutes from the network time. You can enter a value between -720 and 720. By example for UK the following apply: Winter Time offset = 0 Summer Time offset= 60 13.1.2.3 Configuring the time after a power off: If you are resetting the module time after a power off, you must always set the module time before you set the time zone offset. If the node has already synchronized with the network time server, the system automatically disallows the resetting of module time on the node. However, you can still set the offset time if required. If the node is powered off for more than 24 hours, perform the following procedure in provisioning mode. 1 Set the module time: set Time moduleTime <yyyy>-<mm>-<dd> <hh>:<mm>:<ss> where: <yyyy> is the year. <mm> is the month. <dd> is the day. <hh> is the hour. <mm> is the minute. <ss> is the second. 2 Set the time offset: set Time offset <offset value> where: <offset value> is a number between -720 and 720 (minutes).

13.1.2.4

DST setting on SGSN from V3.0.1

3G and 2G SGSNs automatically adjust the clock for Daylight Savings Time changes from V3.0.1. 76

For the other PP nodes based, the operator needs to make this adjustment manually. The following parameters need to be set to control the dates and times at which Daylight Savings Time changes are to take place in order that SGSNs be able to automatically adjust the clock for Daylight Savings Time: Spare name at CAS level Previously used startup file Default Value Variable name ----------------------------------------------------------------------------------------------------------spare1prov dstSpringFwdDateTime_g 10100 spare2prov dstFallBackDateTime_g 10100 In PROV mode for 3G SGSN: > add usgsn customspare/8 > set usgsn customspare/8 spare1prov MMDDHH > set usgsn customspare/8 spare2prov MMDDHH Similar configuration needs to be done for the 2G SGSN: > add sgsn customspare/8 > set sgsn customspare/8 spare1prov MMDDHH > set sgsn customspare/8 spare2prov MMDDHH

When the "Spring Forward" time is reached, the time will be moved forward one hour (+60). If the SpringForward time is not set, or is set to the default (10100), then the SGSN will not perform the automatic spring forward adjustment. When the "Fall Back" time is reached, the time will be moved back one hour (-60). If the FallBack time is not set, or is set to the default (10100), then the SGSN will not perform the automatic fall back adjustment. The MMDDHH format is used to encode the date and time in decimal format. MM = Month (01-12) DD = Day (01-31) HH = Hour (00-23) Examples: January 14, 12:00 AM (midnight) April 6, 12:00 PM (noon) October 10, 2:00 AM 11400 40612 101002

Values for European Union until 2008 are shown below:

77

European Union

Year 2000 2001 2002 2003 2004 2005 2006 2007 2008

Summertime Summertime period begins period ends at 1 a.m. UT at 1 a.m. UT March 26 March 25 March 31 March 30 March 28 March 27 March 26 March 25 March 30 October 29 October 28 October 27 October 26 October 31 October 30 October 29 October 28 October 26

If the SpringForward time is not set to a value within the valid ranges, then the SGSN will not perform the automatic spring forward adjustment. If the FallBack time is not set to a value within the valid ranges, then the SGSN will not perform the automatic fall back adjustment. At the time at which the SGSN changes its time offset, the following message alarm is generated. This is normal. Time; 2003-07-03 12:29:29.65 MSG warning operator operationalCondition 70150001 ADMIN: unlocked OPER: enabled USAGE: active AVAIL: PROC: CNTRL: ALARM: STBY: notSet UNKNW: false Id: 2C Rel: Com: Time offset changed by local operator for 3600 seconds. Time was 2003-07-03 11:29:29 Int: 0/1/2/28972; ntsCasInterface.cc; 1351; PCR4.2.50 From the Provisioning point of view the offset will be 0 and from the Operational point of view the offset will be 60 in Summer Time and 0 in Winter Time if the provisioning is done between the specified dates. Also, if the I&A of a node is performed after the date indicated into the spare1prov, then, it is a MUST to set the offset to 60. In a similar way if the I&A of a node is performed after the date indicated into the spare2prov has passed, then, the offset will be 0.

78

By example, for UK the following applies for 2005: Winter Time: offset = 0 spare2prov 103001 Summer Time: offset= 0 spare1prov 032701 13.1.3 VERIFYING THE TIME CONFIGURATION ON THE NODE:

To ensure that you have correctly configured module and network time on your node, perform the following procedure in operational mode. 1 Display the operational attributes of the Time component: display Time A number of attributes display, including the current module time, timezone offsets, synchronization status, and time server sources. 2 Display the current time on the node: display Time moduleTime The current time on the node displays in the form yyyy-mm-dd hh:mm:ss. 3 Display the operational attributes of the configured time servers: display Time Server/* 4 Display the provisionable attributes of the configured time servers: display -p Time Server/*

5 Display the operational attributes of a particular time server: display Time Server/<n> where: <n> is the instance value of the Server component.

13.2
13.2.1

GGSN NTP DEFINITION

1. Log into the SCS with a Device Owner profile. 2. Under the Device tab, configure the General Device Information section, and set the Administrative Status to Up 79

3. If the GGSN is to get its network time information from a Simple Network Time Protocol (SNTP) server, then address the SNTP Client Configuration portion of the window check the Enable SNTP check box select the appropriate client mode (Unicast, Multicast, or Broadcast) enter the server IP address. GGSN only permits the definition of one NTP source for Unicast mode Note the appropriate port number is 123 and this value (the default) cannot be changed 13.2.2 CONFIGURE OR VERIFY THE TIME, DATE AND TIME ZONE

Performance metrics generated by the GGSN include date and time information. In order for time stamp information to be valid, the date and time must be set correctly, and the time zone in which the GGSN resides must be properly defined. If they are not, the *.csv log files that are generated for device and group statistics will contain incorrect timing information. 1. Check current date, time and time zone information: Log into the CMC card. type the following commands: show time show timezone show tzdb (lists all possible time zones) If the time, date or time zone is incorrect, correct time as described in Correct time, date and time zone information Some useful commands are: enable ntp client {multicast,broadcast,unicast}. Example: enable ntp client ver=2 Enable ntp client parameters: multicast Listen for NTP time announcements on the IP multicast group for NTP. broadcast Listen for NTP time announcements sent to the IP broadcast address. unicast Accept only NTP time announcements from a specified NTP server. set ntp server [server=]<name>|<ipaddr>. Example: server=206.81.19.1 Show ntp. Example: ntp client is turned on multicast mode. Show uptime set ntp server

2. Correct time, date and time zone information: On the SCS client, click on the Devices tool icon, click on the region to which the GGSN in question belongs, and right-click on the icon representing the GGSN. From the pop-up menus that result, select Configure, then select Device... 80

The Configuration - Device window for that GGSN opens: Enter the correct time, date and time zone information in the Time and Timezone area of the window.

Even these parameters can be modified on GGSN- CMC, it is mandatory to do the modifications on the SCS client. Most problems with reading the time on the CSV logs arise from the fact that the time zones are incorrect. If the time zone is not set properly, or is misspelled, enter it correctly. Some useful commands are: 13.2.3 Show time Show timezone EVENTS LOG

The event manager on the Shasta 5000 BSN is used to report and log events for the Shasta GGSN, including: GGSN event logs Shasta base event logs

The event logs notification system is illustrated below. Shasta GGSN functional modules on the SSG generate events. Each event has an event number, log type, trap flag and event text attributes. The log type is either INFORMATION, WARNING or CRITICAL. The event manager uses the log type to determine where the log is sent. The event logs destination is configured with the SCS GUI on a per device basis. There are three possible destinations: Log files on the GGSN local disk GGSN device console UNIX systems (via UNIX SYSLOG messages)

The event manager uses the trap flag attribute to determine whether the event is also forwarded to the SNMP Agent to generate an alarm. Due to the significant impacts to CPU utilization when writing all event logs to the local disk, it is recommended that only event logs with CRITICAL log type be sent to the log files on the local disk. The SYSLOG utility is recommended to use for capturing event logs on a remote server. These event logs may be informational only, or they may be indicative of an abnormal system condition requiring administrative action. For those event logs requiring administrative action, it is recommended that the event logs be sent to a SYSLOG Server. 81

Restriction related to the SNTP alarms were not forwarded to the WNMS platform has been removed. Even the SYSLOG mechanism can still being used to send the SNTP event logs to a SYSLOG server can still be used, there is a procedure to promote event logs to SNMP traps (alarms) using an snmp notification profile.

set snmp notification profile Adds to the category and severity list for SNMP notification, building on the list already specified by the add snmp notification profile command. This allows the specified ISP to see additional traps. Syntax
set snmp notification profile [name=]<notification_profile> [isp=]<ispname> [[category=]{AAA, Atm_Line_Card, BGP, Card, Chassis_Alarms, CLI, COC3_Line_Card, Configuration, CT3_Line_Card, DCC, Debug, Disk_Capacity, Ethernet_Line_Card, Fabric, Frame_Relay, GTP, GTP_Accounting, IGMP, ILMI, Interface, IPHC, ISAKMP/IKE, ISP, Label_Fabric, L2TP, LI, MIP_FA, MIP_Home_Agent_Authentication, MPLS, MPLS_VRF, OAM, PPP, PPPOE, RED, RPC, SCP, SCS_Log, Services, SNTPC_Server, SPS, SSM, Subscriber, Sysmon, System, Task, User, VPN, WRAP] [[severity=]{none, critical, critical_major, critical_minor, critical_info, critical_major_minor, critical_major_info, critical_minor_info, major, major_minor, major_info, major_minor_info, minor, minor_info, info, all}]

This task can be setup via both SCS and CLI and that it will result in traps being sent. Details are covered under NTP 411-5221-922 GPRS6/UMTS4 Nortel GGSN Command Line Interface (CLI) Guide. Traps sent to WNMS after the previous configuration are registered under 411-5221-926 GPRS/UMTS Nortel GGSN User Guide and detailed in section 13.2.4. Processing within the SYSLOG Server to produce the SNMP traps to OSS Fault Management platforms is beyond the scope of this document and will be done by the customer. GGSN logs will be sent to a SYSLOG server, where any OSS agent will look for the traps text to find the one related to the SNTP Event logs. See section 13.2.4. When a SNTP Event log is founded, then, the OSS Agent will send a trap to a specific umbrella application, as per customer implementation. Processing within the SYSLOG Server is beyond the scope of this document and will be done by the customer. Some of the events requiring administrative action correspond to SNMP traps, in which case, sending to a SYSLOG server is redundant. Other event logs generated necessitate no particular administrative action, but may be indicative of configuration errors, or may be useful for troubleshooting if captured on a device console or SYSLOG Server.

82

If SYSLOG monitoring is to be performed, it is important to note that the event numbers reported to SYSLOG are not unique. Event content as well as event number must both be used in order to categorize events. The Subscriber Service Logs in the SCS GUI Logs Manager is not supported by the Shasta GGSN. Displaying the service logs would impact the system performance greatly.

13.2.4

SNTP EVENT LOGS

Table below lists the event logs generated to report SNTP Client events. Occurrences of these events may indicate networking problems or problems with the SNTP Servers themselves.

83

14 NTP AND TIME ZONE DEFINITIONS IN CIRCUIT DOMAIN

When NTP is running the DTS (Distributed Time Service) feature of DCE has to be disabled to prevent conflicts; however the other services of DCE (security, name service, remote procedure calls) are still available.

14.1 CURRENT IMPLEMENTATION, LIMITATIONS AND RESTRICTIONS

Here is the functionality the current implementation of the SNTP feature support: It synchronises DMS time of day clock to external NTP source using SDM only. The TOD clock is synchronized via SNTP protocol to the NTP server/client on the DMS-SDM DMS-SDM NTP server/client acts as secondary reference source to the DMSCore. DMS-SDM NTP server/client synchs to external reference source. A process polls the SDM (eg. every 5 mins) for the delta between TOD and NTP source. A critical log is generated when delta exceeds 500 ms. Two new CI commands, Queryntptime, to query the delta and Settontptime to set the TOD to NTP source exists Implementation supports time zone and day light saving time capabilities. The implementation also supports Leapseconds

Some of the limitations of the SNTP feature are: If SNTP client on core looses synchronization manual intervention is needed to restart the synchronization 84

A STOPNTP command is needed in the NTPCI as currently there is no way to stop NTP unless we kill the NTP process if there is any NTP problems. In the map level of NTPCI, the TOD alarm is not positioned properly. It can get partly overwritten or completely overwritten. We need to write a new map level for NTP. When the tuple SNTP_CLIENT is disabled, the TOD alarm should be cleared since the feature is disabled. If the feature is ON but NTP has not been started we need to generate a alarm to indicate that NTP is not running and clock is not synced Currently, NTPCI increment could be enter multiple times. Changes are required to check if the user already in NTPCI. TOD alarm should be erased on INACTIVE side as SNTPCLNT process only runs on ACTIVE side to communicate between the SDM. Tuple SNTP_CLIENT needed to accept the nil change. In case of any data corruption, a nil change could verify if the data is corrupted. The feature requires SDM to synchronize with NTP source. If source is anything else we would have to re-write the algorithm. Generate logs when start and stop NTP commands are used maybe even have them password protected for security reason NTP time server and DTS can co-reside in SDM with the restriction that SDM must be configured as NTP local server (using its local clock as its reference clock). This means that this feature uses the SDM as the only source for ntp reference time

14.2 HOW TO SYNCHRONISE THE CORE TOD CLOCK TO NTP TIME?

The procedure to synchronise the Core TOD clock with the NTP time is as below: 1. Ensure that the office parameter SNTP_CLIENT in the table OFCENG is set to Y. 2. Execute the DATE command to verify that the date displayed is that of the present day date or else set the present date properly by SETDATE command. CI> DATE CI>SETDATE <DD> <MM> <YYYY> 3. Go to the NTPCI level and execute the command STARTNTP with proper timezone value in minutes. NTPCI> STARTNTP <TIMEZONE> 4. Execute theQUERYNTPTIME command at the NTPCI level to query the present Core TOD clock offset with the ntp time. NTPCI> QUERYNTPTIME 5. Execute the SETTIMETONTP command at the NTPCI level to set the Core TOD clock with ntp time.

85

NTPCI> SETTIMETONTP This command will further ask for your confirmation to set the Core TOD clock with NTP time.

14.3
14.3.1

BASICS TIME OF DAY

The TOD (Time Of Day) clock is essentially used to stamp billing records and visible to a large number of end users, who have the date/time display on their CLASS phone. It is normally set by the crafts person using the CI command SETTIME. The SDM will get reference source from a NTP server and gets synchronized. SDM NTP server is in symmetric operation i.e. can operate as server and client. The SNTP client with highest stratum value runs at the core and gets synchronized to the ntp server of SDM. The SNTP client daemon has to run at the core and gets the SDM- NTP server reference time periodically. The periodicity can be 5 minutes. The client daemon can operate in unicast mode with SDM as the fixed peer for sync. The daemon will be recreated during every restart and the resources get initialised at IPL. The TOD of the core at any time can be queried, and requested to get set to NTP, by manual CI commands. These commands send ntp time request to the SNTP client daemon and set the system time to ntp or displays the query results. The accuracy of the TOD will be maintained within +/-500ms as against NTP reference source clock. Suitable logs with alarm indication will be generated, when the TOD exceeds the limits, like critical alarm when offset >500ms or major alarm when 400<offset<300ms. Suitable software error messages would be generated at the error conditions like SDM unreachable, time-out condition for NTP response from SDM. Daylight saving and time zone will be considered while calculating time conversion from local time to NTP time and vice versa. The DMS-MSC/HLR uses SNTP to synchronize its TOD clock to its associated SDM. The SNTP client process is manually configured. Once it is configured, SNTP client process periodically (every five minutes) sends a NTP time request message to the NTP server on the SDM. The NTP reply messages are validated against the round trip delay. Many samples are buffered and the best sample with smallest round trip delay is used for servicing the NTPCI command (SETTIMETONTP).

14.3.2 CI> NTPCI

COMMAND TO START SNTP CLIENT

86

This command gives warning message as command not supported, when this feature is disabled. The feature gets disabled when the office parameter SNTP_CLIENT in the table OFCENG is set to N. NTPCI> STARTNTP <TIMEZONE> <TIMEZONE> Range from -720 to 780. By example for UK the following apply: Winter Time = 0 and Summer Time = 60 This command is used to start SNTP client to start collecting samples from its NTP source for given time zone value. This command has one mandatory parameter TIME ZONE. The craft person has to enter value in minutes, which is the exact time difference of the local time compared with GMT time on that day. This would include the offset caused by day light saving time when applicable, e.g. Central European Time (CET) has an offset of 2 hours during the summer daylight saving period. A false <TIMEZONE> value can be corrected by reexecuting the STARTNTP command.

Note: It is advisable that before starting the SNTP CLIENT on the Core, the date on the switch should be verified to the present date of the day by executing the DATE command on the CI. If the date displayed is different than the present date of the day, it must be set correctly by executing the SETDATE command. 14.3.3 COMMAND TO SET TOD TO NTP TIME

NTPCI> SETTIMETONTP This command is used to set the Core TOD clock to NTP reference clock time. This command asks for confirmation message on successful execution. The successful execution means the Core TOD clock is set with ntp time obtained from the reference ntp source. Along with the confirmation message, the value of the following gets displayed: TOD offset, Round trip delay, Time zone, Best sample age, the NTP time and Valid sample percentage. TOD offset: The number of milliseconds the TOD is differing from NTP time. The value can be positive or negative. Round trip delay: The time in milliseconds, the message has taken to reach SDM from CM core and return back The smaller the value of round trip delay, better would be the offset accuracy. Time zone: The difference in time in minutes between the local clock of the time domain as against GMT. Best sample age: The age of the sample in minutes as against the present time, which is used to adjust the NTP time. The best sample is one with smallest round trip delay. NTP time: The equivalent NTP time determined on the Core at the time of setting the Core offset. 87

Valid Sample Percentage: This gives an indication of the percentage of valid samples present in the circular buffer. The number of elements in the buffer is determined as (One Hour / sampling Interval)*12 hrs. The system impact of the command is same as that of the command SETTIME, except that the TOD is set with the NTP time. 14.3.4 AUTOMATED TOD SETTING

Table DSTTABLE automates the time change required for the change from standard time to daylight saving time and the reverse operation. To perform this action, this table stores the associated time change requests. The datafill in this table controls the following: when time changes to and from daylight savings occur how time changes to and from daylight savings occur The system activates Automated Time-of-day Change feature when you enter one or more tuples in table DSTTABLE. You do not have to enter data in other tables before you enter data in table DSTTABLE. The table contains a maximum of ten entries. Each entry represents one automated change to daylight savings time or from daylight savings time. The datafill for table DSTTABLE appears in the following table.

88

Sample datafill for table DSTTABLE appears in the following example.

CSP06. Table DSTTABLE was introduced in CSP06. 14.3.5 COMMAND TO QUERY NTP TIME:

CI> NTPCI NTPCI> QUERYNTPTIME This command takes no parameter. On successful execution of the command the values of the following gets displayed: TOD offset, Round trip delay, Time zone, Best sample age, the NTP time and Valid sample percentage. The definition of these terms is same as mentioned in the SETTIMETONTP command. 14.3.6 INTERACTIONS

The interaction of this feature with the existing commands like SETTIME, SETDATE and the Daylight saving time functionality are as follows: The SETTIME command should not be used while the SNTP CLIENT on the core is running and the Core TOD clock is synchronised to the NTP reference source.

89

 Similarly, the SETDATE command should not be used while the SNTP CLIENT on the Core is running and the Core TOD clock is synchronised to the NTP reference source. Daylight saving time functionality works in the same manner as before this feature. The DST table still needs to be datafilled appropriately for the switch to run at local time. The SNTP CLIENT on Core will automatically interpret the Day light saving time changes and there will not be any alarms wrt the NTP reference source monitoring.

15 NTP AND TIME ZONE DEFINITIONS FOR CES

15.1 DATE AND TIME
This screen shows the current Date, Time, and Day of the week for the switch. You can change the time based on your time zone, or make daylight savings time adjustments, as necessary. To change either the Date or Time values, select the fields and enter the new values.

Date: Shows the current month, day, and year (mm/dd/yyyy). Time: Shows the current hour, minute, and seconds (hh:mm:ss) as displayed by a 24hour clock (00:00:00 to 23:59:59). Day: Shows the current day of the week. The day is based on the month, date, and year, and it cannot be changed manually.

90

The following command manually sets the system clock: Syntax: clock set <hh:mm:ss day month year> clock set <hh:mm:ss month day year> Parameters hh:mm:ss Current time in hours, minutes, and seconds. day Current day (date) of the month. month Current month (by name). year Current year; type four digits, for example, 2004 Default: None Command mode: Privileged EXEC Next command mode: Privileged EXEC Required privileges: System Management - Manage User Management - None Related commands: clock timezone show clock Example: CES# clock set 11:25:30 5 February 2004 CES# clock set 11:25:30 February 5 2004

15.2

VERIFYING THE TIME ZONE SETTING

Contivity Server current release does not have configuration fields for enabling & setting daylight saving time. It supports DST by default. DST is internally programmed. It will change DST twice a year, on April and October. So that, to make daytime saving work, there are two choices:

1. Add NTP servers, thus, Contivitys time will synchronize to NTP server. On CES, time zone must be set by manual 2. Without using NTP server, you have to manually setup Day and Time. There is no need to change CES time setting in April and Oct, since CES will take care of DST automatically. On the Contivity VPN Switch: 1. Go to the System Date & Time screen and verify that your switchs date, time, and time zone are set correctly 2. Change the date, time, and time zone, as appropriate 3. Time Zone: Click the drop-down list box to select the appropriate time zone. Time zones can be a critical factor in the usage of digital certificates.

91

The following command manually sets the clock timezone: Syntax clock timezone <zone> Parameters: zone is the name of the time zone to be displayed when standard time is in effect. Enter one of the following values: Default: GMT Bet (GMT -11:00) Bering Hst (GMT -10:00) Hawaii Standard Time Yst (GMT -9:00) Yukon Standard Time Pst (GMT -8:00) Pacific Standard Time Mst (GMT -7:00) Mountain Standard Time Cst (GMT -6:00) Central Standard Time Est (GMT -5:00) Eastern Standard Time Ast (GMT -4:00) Atlantic Standard Time Glte (GMT -3:00) Greenland Time Ost (GMT -2:00) Oscar Time At (GMT -1:00) Azores Time Gmt (GMT) Greenwich Mean Time Cet (GMT +1:00) Central Europe Time Nt (GMT +2:00) Nile Time Ukt (GMT +3:00) Ukraine Time Cat (GMT +4:00) Caspian Sea Time Pte (GMT +5:00) Pakistan Time Kt (GMT +6:00) Kazakh Time Wast (GMT +7:00) Java Time (West Australian Standard) Cct (GMT +8:00) China Coast Time Jt (GMT +9:00) Japan Time Mit (GMT +10:00) Mariana Islands Time Cit (GMT +11:00) Caroline Islands Time Nzst (GMT +12:00) New Zealand Standard Time Command mode: Privileged EXEC Next command mode: Privileged EXEC Required privileges: System Management - Manage User Management - None Related commands: clock set show clock Example: CES# clock timezone pst

92

15.3

CONFIGURE NETWORK TIME PROTOCOL (NTP)

NTP synchronizes the clocks of various devices across networks. It also automatically adjusts the time of network devices so that they are synchronized within milliseconds. The switch receives NTP updates from an NTP time server and continuously synchronizes its clock to universal standard time. The switch supports up to eight NTP (unicast) servers and broadcast, multicast servers. The switch provides support for the Network Time Protocol. The System Date and Time Network Time Protocol screen allows you to set up NTP on the switch. NTP synchronizes the clocks of various devices across networks. It also automatically adjusts the time of network devices so that they are synchronized within milliseconds. The switch receives NTP updates from an NTP time server and continuously synchronizes its clock to universal standard time. The switch supports up to eight NTP (unicast) servers and broadcast, multicast servers. To configure NTP: 1. Click on the Enable check box 2. If you want the switch to listen for and respond to broadcast messages, check the Synchronize time with NTP Broadcast Server box. If you want the switch to listen for and respond to multicast messages, check the Synchronize time with NTP Multicast Server box. The IP multicast address is 224.0.1.1 for NTP. NTP listens for both broadcast and multicast messages at the group address of the global network. To avoid disruption in multicast mode, both the client and servers should use authentication and the same trusted key and key identifier 3. Under Servers, click on the Add button to add a server: a. IP address of the NTP (unicast) server b. Under Interface, for security, you can specify either a private or public interface. The private interface is the management IP address. When adding a public interface, you can choose from a list of public interfaces. If you are using the Contivity Firewall, you need to configure an interface filter to add NTP c. Enter the Key ID. This specifies the Key ID for Message Digest (MD5) authentication. In authentication mode, each packet transmitted has a 32bit Key ID and a 64/128-bit cryptographic checksum using MD5 algorithms. With MD5, the receiving peer recomputes the checksum and compares it with the one in the packet. They must share at least one MD5 key (trusted key) and must associate the shared key with the same Key ID d. Enable Bursting to send a burst of eight packets at each poll interval e. Select the NTP version number (1, 2, 3, or 4) used on the NTP server. The default is 3 f. Click OK 4. Under Trusted Keys, click on the Add button to add an area key ID. The switch displays the Add/Edit Trusted Key screen. Enter the key ID, the password and the password confirmation 5. Click on the Return to the Date and Time page link to return to the previous page

93

The System Date and Time Network Time Protocol screen allows you to set up the Network Time Protocol (NTP) on the switch. NTP synchronizes the clocks of various devices across networks. It also automatically adjusts the time of network devices so that they are synchronized within milliseconds. The switch receives NTP updates from an NTP time server and continuously synchronizes its clock to universal standard time. The switch supports up to eight NTP (unicast) servers and broadcast, multicast servers.

Check the Enable NTP check box to enable NTP on the switch. If you want the switch to listen for and respond to broadcast messages, check the Synchronize time with NTP Broadcast Server box. If you want the switch to listen for and respond to multicast messages, check the Synchronize time with NTP Multicast Server box. The IP multicast address is 224.0.1.1 for NTP. NTP listens for both broadcast and multicast messages at the group address of the global network. To avoid disruption in multicast mode, both the client and servers should use authentication and the same trusted key and key identifier. Below the meaning of the different settings: Servers: The switch lists any existing NTP servers. Server IP Address: IP address of the NTP (unicast) server. Interface: For security, you can specify either a Private or Public interface. The private interface is the management IP address. When adding a public interface, you can choose from a list of public interfaces. If you are using the Contivity Firewall, you need to configure an interface filter to add NTP. 94

Key ID: Specifies the Key ID for Message Digest (MD5) authentication. In authentication mode, each packet transmitted has a 32-bit Key ID and a 64/128-bit cryptographic checksum using MD5 algorithms. With MD5, the receiving peer recomputes the checksum and compares it with the one in the packet. They must share at least one MD5 key (trusted key) and must associate the shared key with the same Key ID. Bursting: Specifies to send a burst of eight packets at each poll interval. Version: NTP version number (1, 2, 3, or 4) used on the NTP server. The default is 3. Actions: Edit: To edit an existing NTP server, click on the edit button in the Action column. Delete: Click on the Delete button to delete an NTP server. Add: You can add an NTP server by clicking on the Add button. The switch displays the Add/Edit Server screen. If you are adding an NTP server, enter the appropriate information as described above.

Trusted Keys: Key ID: Specifies the Key ID for MD5 authentication. Actions: Edit: To edit an existing key ID, click on the edit button in the Action column. Delete: Click on the Delete button to delete the trusted key. Add: You can edit an existing area key ID by clicking on the Edit button. The switch displays the Add/Edit Trusted Key screen. Enter the key Id, the password and the password confirmation. Click on the Return to the Date and Time page link to return to the previous page.

95

The following command disables or enables the Network Time Protocol (NTP) for the switch. Syntax: ntp no ntp

Parameters: None Default: Disable Command mode: Global Configuration Next command mode: Global Configuration Required privileges: ntp server User Management - None Related commands: clock set show clock Example: CES(config)# ntp CES(config)# no ntp

16 ANNEX A.
16.1.1 BROADCAST AND MULTICAST NTP CLIENTS CONFIGURATION

Clients can also be configured to respond to broadcast or multicast packets sent by a broadcast or multicast NTP server. Note that no additional steps are needed to allow a node running xntpd to be a non-broadcast NTP server (assuming access and authentication are set appropriately). However, an NTP node needs to be explicitly configured in order to send out broadcast or multicast packets for clients. Note that, since the clients are listening for broadcast packets, no server is specified after the keyword. Broadcast and multicast are generally used as the primary server on a LAN or subnet. Using broadcast or multicast allows synchronizing a large number of clients without creating large amounts of NTP traffic. In addition, servers can be changed 96

easily, since clients do not listen for a specific server when they are in broadcast mode. Because the links are mostly local, this allows accurate synchronization for the clients. The important NTP servers within an enterprise (generally low stratum numbers) and any servers separated by large distances or low latency links should use non-broadcast mode in order to maintain close synchronization. A computer can be configured to be a broadcast client by adding a line with broadcastclient to the ntp.conf file. A client synchronizes with any server which sends out broadcast NTP messages, so it is important to use authentication when configuring broadcast clients. Configuring a multicast client is accomplished the same way, but the line in ntp.conf begins with the entry, multicastclient instead. The reserved multicast address for NTP is 224.0.1.1, and this is the default multicast address. Other addresses can be specified after the multicastclient keyword, which is suggested for large configurations. Note that the server and client must be configured to use the same multicast address. If the clients are not configured to synchronize with a specific group of servers, a rogue system can influence the synchronization process by broadcasting invalid time information. To defend against this threat, authentication and access control should be used to help limit potential synchronization sources.

16.1.2

BROADCAST AND MULTICAST NTP SERVER CONFIGURATION

Configuring a broadcast or multicast server is slightly different. Both broadcast and multicast servers are defined using the broadcast command in the ntp.conf file. The broadcast address is specified after the broadcast command. Broadcast addresses are generally the subnet address with the host field set to maximum value (all binary ones). The official multicast address for NTP is 224.0.1.1, though other multicast addresses can be used. Authentication keys can (and should) be used. For broadcast servers, a timeto-live (TTL) value (the maximum number of hops) for the NTP packets should also be specified. This value defaults to 127, but should be changed to something appropriate to the network. It is important that the packets survive long enough to reach all the clients, but if long-lived packets are necessary, it may make more sense to add an additional stratum of servers in the appropriate subnets. The following shows the configuration for a broadcast server on subnet 192.72.23.0: The following shows the configuration for a multicast server. Note that the configuration still uses the broadcast keyword, but the address has changed to a multicast address. Any multicast address could be used. broadcast 192.72.23.255 ttl 6 broadcast 224.0.1.1 ttl 6

97

As a rule, authentication should always be used with broadcast or multicast clients. This is not just a security measure, but also prevents an accidentally configured broadcast server from disrupting the clients time synchronization.

17 ANNEX B.
17.1 ABOUT DAYLIGHT SAVING TIME
Daylight Saving Time (or Summer Time as it is called in many countries) is a way of getting more out of the summer days by advancing the clocks by one hour during the summer. Then, the sun will appear to rise one hour later in the morning when people are usually asleep anyway, at the benefit of one hour longer evenings when awake: The sunset and sunrise are one hour later than during normal time. DST could save energy (less artificial light is needed during the evening) and make the country more efficient in addition to the pleasing effect of lighter evenings. In the European Union, Daylight Saving Time (DST) begins and ends at 1 am Universal Time Coordinated (UTC) or Greenwich Mean Time (GMT). It starts the last Sunday in March, and ends the last Sunday in October. To make DST work, the clocks have to be adjusted one hour ahead when DST begins (during spring), and adjusted back one hour to standard time every autumn. There are many countries observing DST, and many who do not. Note: During the months March/April-September/October, the countries on the northern hemisphere are having their summer and may observe DST, while the countries in the southern hemisphere are having winter. During the rest of the year (September/OctoberMarch/April) is the opposite: Winter on the northern hemisphere, summer in the southern... and there might be DST in countries south of equator, but there are many exceptions to this. Daylight Saving Time is difficult to predict in future, many countries change the transition days/principles every year because of special happenings or conditions that has happened or will happen.

17.2 IS DST ALWAYS 1 HOUR AHEAD OF NORMAL TIME?

Today it is almost always 1 hour ahead of normal time, but during history there have been several variants of this, such as half adjustment (30 minutes) or double adjustment (2 hours), but adjustments of 20, 40 minutes have also been used. 2 hours adjustment was used in several countries during some years in the 40's and has also been used elsewhere a few times. Half adjustment was sometimes used in New Zealand in the first half of this century. Sometimes DST is used for longer periods than just one summer, as in the United States during World War II. From 3 Feb 1942 to 30 Sep 1945 most of United States had DST all year, it was called "War Time".

98

17.3 HOW DOES THE TRANSITION TO DST START?

When clicking on a city in The World Clock you will get information about that city, including when daylight saving start and ends this year, if the city has DST. Let's say that DST starts at 2:00 am local time and DST is one hour: DST start transition Local time DST or normal? HR:MI:SE 1:59:58 1:59:59 3:00:00 3:00:01 3:00:02 normal normal DST DST DST DST started, time advanced by one hour Comments

Note that local time is never anything between 2:00:00 - 2:59:59 at the transition from normal to DST, this hour is skipped and therefore this day has only 23 hours (instead of 24 hours). If someone has worked during this night from 0:00 to 8:00, they have only worked 7 hours, because of the skipped hour.

17.4 HOW DOES THE TRANSITION TO DST END?

Let's say that DST ends at 2:00 am local time and DST is one hour ahead of normal time: DST end transition Local time HR:MI:SE 0:59:59 1:00:00 1:00:01 1:59.58 1:59.59 1:00:00 1:00:01 1:59.58 1:59:59 2:00:00 2:00:01 DST or normal? DST DST DST DST DST normal normal normal normal normal normal Time is turned back to normal Comments

...3596 seconds from 1:00:02 to 1:59:57 daylight saving time not shown...

...3596 seconds from 1:00:02 to 1:59:57 normal time not shown...

Note that local time between 1:00:00 and 1:59:59 actually is repeated twice this day, first 99

during DST time, then clocks are turned back one hour to normal time, and the hour is repeated during normal time. To avoid confusion when referring to time within this hour, it is important to tell whether it happened before of after the change back to normal time. The day when DST ends has 25 hours. If someone has worked during this night from 0:00 to 8:00, they have worked 9 hours, because of the repeated hour.

18 ANNEX C.
18.1 TIME ZONE ABBREVIATIONS
There are several abbreviations often used when referring to time, such as e.g. 11:00 ET which means 11:00 Eastern Time or New York-time.

18.2 LIST OF ABBREVIATIONS

18.2.1 STANDARD UTC defines the universal time zone, which all the other time zones are relative to. It observes no daylight saving time (summer time). UTC is sometimes adjusted with "leap seconds" so that the difference between UTC time and the Earth's rotational time does not exceed 0.9 seconds. The offset between UTC and TAI is always an integral number of seconds. The last leap second added to UTC was on December 31, 1998 at 23:59:60 UTC (the last minute of 1998 had one extra second). There will be no leap second in June 2003, but maybe in December 2003, it will not be decided until July. UTC Coordinated Universal Time, civil time, the one most often used by "ordinary" people. UT Universal Time, based on the Earth's rotation, often used in Astronomy. TAI International Atomic Time, based on atomic clocks 18.2.2 OTHER ABBREVIATIONS

18.2.2.1 European Abbr. GMT BST IST WET CET Full name Greenwich Mean Time British Summer Time Irish Summer Time Western Europe Time Central Europe Time Time zone UTC UTC+1 hour UTC+1 hour UTC UTC+1 hour Example city London during winter London during summer Dublin during summer Lisbon during winter Lisbon during summer Paris during winter

WEST Western Europe Summer Time UTC+1 hour CEST Central Europe Summer Time

UTC+2 hours Paris during summer

100

EET MSK MSD

Eastern Europe Time Moscow Time Moscow Summer Time

UTC+2 hours Athens during winter UTC+3 UTC+4 Moscow during winter Moscow during summer

EEST Eastern Europe Summer Time UTC+3 hours Athens during summer

18.2.2.2 US and Canada Abbr. NST NDT AST ADT EST EDT ET CST CDT CT MST MDT MT PST PDT PT AKST AKDT HST Full name Newfoundland Standard Time Newfoundland Daylight Time Atlantic Standard Time Atlantic Daylight Time Eastern Standard Time Eastern Daylight Saving Time Eastern Time, as EST or EDT Central Standard Time Central Daylight Saving Time Central Time, either as CST or CDT Mountain Standard Time Mountain Daylight Saving Time Mountain Time, either as MST or MDT Pacific Standard Time Pacific Daylight Saving Time Time zone UTC-3:30 hours UTC-2:30 hours UTC-4 hours UTC-3 hours UTC-5 hours UTC-4 hours * UTC-6 hours UTC-5 hours * UTC-7 hours UTC-6 hours * UTC-8 hours UTC-7 hours Example city St. John's during winter St. John's during summer Bermuda during winter Bermuda during summer Indianapolis all year New York during summer New York Regina all year Chicago during summer Chicago Phoenix all year Denver during summer Denver Los Angeles during winter Los Angeles during summer Los Angeles Anchorage during winter Anchorage during summer

Pacific Time, either as PST or PDT * Alaska Standard Time Alaska Standard Daylight Saving Time Hawaiian Standard Time UTC-9 hours UTC-8 hours

UTC-10 hours Honolulu

* The actual time zone depends on the time and the place, some places are on standard time all year long, but most places observe daylight saving time in the summer.

18.2.2.3 Australia Abbr. EST/AEST Full name (Australian) Eastern Standard 101 Time zone UTC+10 hours Example city Brisbane

Time EDT/AEDT CST/ACST CDT/ACDT WST/AWST (Australian) Eastern Daylight Time (Australian) Central Standard Time (Australian) Central Daylight Time (Australian) Western Standard Time UTC+11 hours Canberra during summer

UTC+9.5 hours Darwin UTC+10.5 hours UTC+8 hours Adelaide during summer Perth

An A is sometimes prefixed to these abbreviations, to distinguish them from abbreviations in Northern America.

18.3 TIME ZONE LETTER ABBREVIATIONS

The basis for this is Z - Zulu time - Zero meridian time - the same as UTC. It's a convention to assign letters to time zones, where Z= Zero meridian, and Zulu is the word that represents the letter Z, when it's used in communication. It is sometimes used in the US Military and NATO in conjunction with 24 hour clocks, and is also popular to use in movies to reference time. Other letters/words are used for other time zones than UTC, most based on the right or reverse order of the Alphabet. Note that 'J' is skipped ('J' - Juliet refers to current local time of the observer). There are 25 time zones defined here, but 26 letters in the English alphabet. Letter Y X W V U T S R Q P O N Z A B Word Yankee X-ray Whiskey Victor Uniform Tango Sierra Romeo Quebec Papa Oscar November Zulu Alpha Bravo Difference UTC - 12 hours UTC - 11 hour UTC - 10 hour UTC - 9 hour UTC - 8 hour UTC - 7 hour UTC - 6 hour UTC - 5 hour UTC - 4 hour UTC - 3 hour UTC - 2 hour UTC - 1 hour same as UTC UTC + 1 hour UTC + 2 hours 102

C D E F G H I K L M

Charlie Delta Echo Foxtrot Golf Hotel India Kilo Lima Mike

UTC + 3 hours UTC + 4 hours UTC + 5 hours UTC + 6 hours UTC + 7 hours UTC + 8 hours UTC + 9 hours UTC + 10 hours UTC + 11 hours UTC + 12 hours

The International Date Line is between time zones M and Y (24 hours/one day differs)

18.4 TIME ZONE DESCRIPTIONS IN SOLARIS

# @(#)zone.tab 1.28 # # TZ zone descriptions # # From Paul Eggert <eggert@twinsun.com> (1996-08-05): # # This file contains a table with the following columns: # 1. ISO 3166 2-character country code. See the file `iso3166.tab'. # 2. Latitude and longitude of the zone's principal location # in ISO 6709 sign-degrees-minutes-seconds format, # either +-DDMM+-DDDMM or +-DDMMSS+-DDDMMSS, # first latitude (+ is north), then longitude (+ is east). # 3. Zone name used in value of TZ environment variable. # 4. Comments; present if and only if the country has multiple rows. # # Columns are separated by a single tab. # The table is sorted first by country, then an order within the country that # (1) makes some geographical sense, and # (2) puts the most populous zones first, where that does not contradict (1). # # Lines beginning with `#' are comments. # #country#code AD AE AF AG AI coordinates +4230+00131 +2518+05518 +3431+06912 +1703-06148 +1812-06304 TZ Europe/Andorra Asia/Dubai Asia/Kabul America/Antigua America/Anguilla comments

103

AL +4120+01950 Europe/Tirane AM +4011+04430 Asia/Yerevan AN +1211-06900 America/Curacao AO -0848+01314 Africa/Luanda AQ -7750+16636 Antarctica/McMurdo McMurdo Station, Ross Island AQ -9000+00000 Antarctica/South_Pole Amundsen-Scott Station, South Pole AQ -6734-06808 Antarctica/Rothera Rothera Station, Adelaide Island AQ -6448-06406 Antarctica/Palmer Palmer Station, Anvers Island AQ -6736+06253 Antarctica/Mawson Mawson Station, Holme Bay AQ -6835+07758 Antarctica/Davis Davis Station, Vestfold Hills AQ -6617+11031 Antarctica/Casey Casey Station, Bailey Peninsula AQ -7824+10654 Antarctica/Vostok Vostok Station, S Magnetic Pole AQ -6640+14001 Antarctica/DumontDUrville Dumont-d'Urville Base, Terre Adelie AQ -690022+0393524 Antarctica/Syowa Syowa Station, E Ongul I AR -3436-05827 America/Buenos_Aires E Argentina (BA, DF, SC, TF) AR -3124-06411 America/Cordoba most locations (CB,CC,CH,CN,ER,FM,LP,LR,MN,NQ,RN,SA,SE,SF,SJ,SL,TM) AR -2411-06518 America/Jujuy Jujuy (JY) AR -2828-06547 America/Catamarca Catamarca (CT) AR -3253-06849 America/Mendoza Mendoza (MZ) AS -1416-17042 Pacific/Pago_Pago AT +4813+01620 Europe/Vienna AU -3133+15905 Australia/Lord_Howe Lord Howe Island AU -4253+14719 Australia/Hobart Tasmania AU -3749+14458 Australia/Melbourne Victoria AU -3352+15113 Australia/Sydney New South Wales - most locations AU -3157+14127 Australia/Broken_Hill New South Wales - Yancowinna AU -2728+15302 Australia/Brisbane Queensland - most locations AU -2016+14900 Australia/Lindeman Queensland - Holiday Islands AU -3455+13835 Australia/Adelaide South Australia AU -1228+13050 Australia/Darwin Northern Territory AU -3157+11551 Australia/Perth Western Australia AW +1230-06858 America/Aruba AZ +4023+04951 Asia/Baku BA +4352+01825 Europe/Sarajevo BB +1306-05937 America/Barbados BD +2343+09025 Asia/Dhaka BE +5050+00420 Europe/Brussels BF +1222-00131 Africa/Ouagadougou BG +4241+02319 Europe/Sofia BH +2623+05035 Asia/Bahrain BI -0323+02922 Africa/Bujumbura BJ +0629+00237 Africa/Porto-Novo BM +3217-06446 Atlantic/Bermuda BN +0456+11455 Asia/Brunei BO -1630-06809 America/La_Paz BR -0351-03225 America/Noronha Atlantic islands BR -0127-04829 America/Belem Amapa, E Para BR -0343-03830 America/Fortaleza NE Brazil (MA, PI, CE, RN, PR) BR -0803-03454 America/Recife Pernambuco BR -0712-04812 America/Araguaina Tocantins 104

BR -0940-03543 America/Maceio Alagoas, Sergipe BR -2332-04637 America/Sao_Paulo S & SE Brazil (BA, GO, DF, MG, ES, RJ, SP, PR, SC, RS) BR -1535-05605 America/Cuiaba Mato Grosso, Mato Grosso do Sul BR -0846-06354 America/Porto_Velho W Para, Rondonia BR +0249-06040 America/Boa_Vista Roraima BR -0308-06001 America/Manaus E Amazonas BR -0640-06952 America/Eirunepe W Amazonas BR -0958-06748 America/Rio_Branco Acre BS +2505-07721 America/Nassau BT +2728+08939 Asia/Thimphu BW -2545+02555 Africa/Gaborone BY +5354+02734 Europe/Minsk BZ +1730-08812 America/Belize CA +4734-05243 America/St_Johns Newfoundland Island CA +4439-06336 America/Halifax Atlantic Time - Nova Scotia (most places), NB, W Labrador, E Quebec & PEI CA +4612-05957 America/Glace_Bay Atlantic Time - Nova Scotia - places that did not observe DST 1966-1971 CA +5320-06025 America/Goose_Bay Atlantic Time - E Labrador CA +4531-07334 America/Montreal Eastern Time - Ontario & Quebec - most locations CA +4901-08816 America/Nipigon Eastern Time - Ontario & Quebec - places that did not observe DST 1967-1973 CA +4823-08915 America/Thunder_Bay Eastern Time - Thunder Bay, Ontario CA +6608-06544 America/Pangnirtung Eastern Standard Time - Pangnirtung, Nunavut CA +6344-06828 America/Iqaluit Eastern Standard Time - east Nunavut CA +6245-09210 America/Rankin_Inlet Eastern Standard Time - central Nunavut CA +4953-09709 America/Winnipeg Central Time - Manitoba & west Ontario CA +4843-09429 America/Rainy_River Central Time - Rainy River & Fort Frances, Ontario CA +6903-10505 America/Cambridge_Bay Central Time - west Nunavut CA +5024-10439 America/Regina Central Standard Time - Saskatchewan most locations CA +5017-10750 America/Swift_Current Central Standard Time Saskatchewan - midwest CA +5333-11328 America/Edmonton Mountain Time - Alberta, east British Columbia & west Saskatchewan CA +6227-11421 America/Yellowknife Mountain Time - central Northwest Territories CA +6825-11330 America/Inuvik Mountain Time - west Northwest Territories CA +5946-12014 America/Dawson_Creek Mountain Standard Time - Dawson Creek & Fort Saint John, British Columbia CA +4916-12307 America/Vancouver Pacific Time - west British Columbia CA +6043-13503 America/Whitehorse Pacific Time - south Yukon CA +6404-13925 America/Dawson Pacific Time - north Yukon CC -1210+09655 Indian/Cocos CD -0418+01518 Africa/Kinshasa west Dem. Rep. of Congo CD -1140+02728 Africa/Lubumbashi east Dem. Rep. of Congo 105

CF +0422+01835 Africa/Bangui CG -0416+01517 Africa/Brazzaville CH +4723+00832 Europe/Zurich CI +0519-00402 Africa/Abidjan CK -2114-15946 Pacific/Rarotonga CL -3327-07040 America/Santiago most locations CL -2710-10927 Pacific/Easter Easter Island & Sala y Gomez CM +0403+00942 Africa/Douala CN +3114+12128 Asia/Shanghai east China - Beijing, Guangdong, Shanghai, etc. CN +4545+12641 Asia/Harbin Heilongjiang CN +2934+10635 Asia/Chongqing central China - Gansu, Guizhou, Sichuan, Yunnan, etc. CN +4348+08735 Asia/Urumqi Tibet & most of Xinjiang Uyghur CN +3929+07559 Asia/Kashgar southwest Xinjiang Uyghur CO +0436-07405 America/Bogota CR +0956-08405 America/Costa_Rica CU +2308-08222 America/Havana CV +1455-02331 Atlantic/Cape_Verde CX -1025+10543 Indian/Christmas CY +3510+03322 Asia/Nicosia CZ +5005+01426 Europe/Prague DE +5230+01322 Europe/Berlin DJ +1136+04309 Africa/Djibouti DK +5540+01235 Europe/Copenhagen DM +1518-06124 America/Dominica DO +1828-06954 America/Santo_Domingo DZ +3647+00303 Africa/Algiers EC -0210-07950 America/Guayaquil mainland EC -0054-08936 Pacific/Galapagos Galapagos Islands EE +5925+02445 Europe/Tallinn EG +3003+03115 Africa/Cairo EH +2709-01312 Africa/El_Aaiun ER +1520+03853 Africa/Asmera ES +4024-00341 Europe/Madrid mainland ES +3553-00519 Africa/Ceuta Ceuta & Melilla ES +2806-01524 Atlantic/Canary Canary Islands ET +0902+03842 Africa/Addis_Ababa FI +6010+02458 Europe/Helsinki FJ -1808+17825 Pacific/Fiji FK -5142-05751 Atlantic/Stanley FM +0931+13808 Pacific/Yap Yap FM +0725+15147 Pacific/Truk Truk (Chuuk) FM +0658+15813 Pacific/Ponape Ponape (Pohnpei) FM +0519+16259 Pacific/Kosrae Kosrae FO +6201-00646 Atlantic/Faeroe FR +4852+00220 Europe/Paris GA +0023+00927 Africa/Libreville GB +512830-0001845 Europe/London Great Britain GB +5435-00555 Europe/Belfast Northern Ireland GD +1203-06145 America/Grenada GE +4143+04449 Asia/Tbilisi 106

GF +0456-05220 America/Cayenne GH +0533-00013 Africa/Accra GI +3608-00521 Europe/Gibraltar GL +6411-05144 America/Godthab most locations GL +7646-01840 America/Danmarkshavn east coast, north of Scoresbysund GL +7030-02215 America/Scoresbysund Scoresbysund / Ittoqqortoormiit GL +7634-06847 America/Thule Thule / Pituffik GM +1328-01639 Africa/Banjul GN +0931-01343 Africa/Conakry GP +1614-06132 America/Guadeloupe GQ +0345+00847 Africa/Malabo GR +3758+02343 Europe/Athens GS -5416-03632 Atlantic/South_Georgia GT +1438-09031 America/Guatemala GU +1328+14445 Pacific/Guam GW +1151-01535 Africa/Bissau GY +0648-05810 America/Guyana HK +2217+11409 Asia/Hong_Kong HN +1406-08713 America/Tegucigalpa HR +4548+01558 Europe/Zagreb HT +1832-07220 America/Port-au-Prince HU +4730+01905 Europe/Budapest ID -0610+10648 Asia/Jakarta Java & Sumatra ID -0002+10920 Asia/Pontianak west & central Borneo ID -0507+11924 Asia/Makassar east & south Borneo, Celebes, Bali, Nusa Tengarra, west Timor ID -0232+14042 Asia/Jayapura Irian Jaya & the Moluccas IE +5320-00615 Europe/Dublin IL +3146+03514 Asia/Jerusalem IN +2232+08822 Asia/Calcutta IO -0720+07225 Indian/Chagos IQ +3321+04425 Asia/Baghdad IR +3540+05126 Asia/Tehran IS +6409-02151 Atlantic/Reykjavik IT +4154+01229 Europe/Rome JM +1800-07648 America/Jamaica JO +3157+03556 Asia/Amman JP +353916+1394441 Asia/Tokyo KE -0117+03649 Africa/Nairobi KG +4254+07436 Asia/Bishkek KH +1133+10455 Asia/Phnom_Penh KI +0125+17300 Pacific/Tarawa Gilbert Islands KI -0308-17105 Pacific/Enderbury Phoenix Islands KI +0152-15720 Pacific/Kiritimati Line Islands KM -1141+04316 Indian/Comoro KN +1718-06243 America/St_Kitts KP +3901+12545 Asia/Pyongyang KR +3733+12658 Asia/Seoul KW +2920+04759 Asia/Kuwait KY +1918-08123 America/Cayman KZ +4315+07657 Asia/Almaty most locations 107

KZ +4448+06528 KZ +5017+05710 KZ +4431+05016 KZ +5113+05121 LA +1758+10236 LB +3353+03530 LC +1401-06100 LI +4709+00931 LK +0656+07951 LR +0618-01047 LS -2928+02730 LT +5441+02519 LU +4936+00609 LV +5657+02406 LY +3254+01311 MA +3339-00735 MC +4342+00723 MD +4700+02850 MG -1855+04731 MH +0709+17112 MH +0905+16720 MK +4159+02126 ML +1239-00800 ML +1446-00301 MM +1647+09610 MN +4755+10653 MN +4801+09139 MN +4804+11430 MO +2214+11335 MP +1512+14545 MQ +1436-06105 MR +1806-01557 MS +1644-06213 MT +3554+01431 MU -2010+05730 MV +0410+07330 MW -1547+03500 MX +1924-09909 MX +2105-08646 MX +2058-08937 MX +2540-10019 Leon, Tamaulipas MX +2313-10625 MX +2838-10605 MX +2904-11058 MX +3232-11701 MY +0310+10142 MY +0133+11020 MZ -2558+03235 NA -2234+01706 NC -2216+16530

Asia/Qyzylorda Qyzylorda (Kyzylorda, Kzyl-Orda) Asia/Aqtobe Aqtobe (Aktobe) Asia/Aqtau Atyrau (Atirau, Gur'yev), Mangghystau (Mankistau) Asia/Oral West Kazakhstan Asia/Vientiane Asia/Beirut America/St_Lucia Europe/Vaduz Asia/Colombo Africa/Monrovia Africa/Maseru Europe/Vilnius Europe/Luxembourg Europe/Riga Africa/Tripoli Africa/Casablanca Europe/Monaco Europe/Chisinau Indian/Antananarivo Pacific/Majuro most locations Pacific/Kwajalein Kwajalein Europe/Skopje Africa/Bamako southwest Mali Africa/Timbuktu northeast Mali Asia/Rangoon Asia/Ulaanbaatar most locations Asia/Hovd Bayan-Olgiy, Govi-Altai, Hovd, Uvs, Zavkhan Asia/Choibalsan Dornod, Sukhbaatar Asia/Macau Pacific/Saipan America/Martinique Africa/Nouakchott America/Montserrat Europe/Malta Indian/Mauritius Indian/Maldives Africa/Blantyre America/Mexico_City Central Time - most locations America/Cancun Central Time - Quintana Roo America/Merida Central Time - Campeche, Yucatan America/Monterrey Central Time - Coahuila, Durango, Nuevo America/Mazatlan Mountain Time - S Baja, Nayarit, Sinaloa America/Chihuahua Mountain Time - Chihuahua America/Hermosillo Mountain Standard Time - Sonora America/Tijuana Pacific Time Asia/Kuala_Lumpur peninsular Malaysia Asia/Kuching Sabah & Sarawak Africa/Maputo Africa/Windhoek Pacific/Noumea 108

NE NF NG NI NL NO NP NR NU NZ NZ OM PA PE PF PF PF PG PH PK PL PM PN PR PS PT PT PT PW PY QA RE RO RU RU RU RU RU RU RU RU RU RU RU RU RU RU RW SA SB SC

+1331+00207 Africa/Niamey -2903+16758 Pacific/Norfolk +0627+00324 Africa/Lagos +1209-08617 America/Managua +5222+00454 Europe/Amsterdam +5955+01045 Europe/Oslo +2743+08519 Asia/Katmandu -0031+16655 Pacific/Nauru -1901+16955 Pacific/Niue -3652+17446 Pacific/Auckland most locations -4355-17630 Pacific/Chatham Chatham Islands +2336+05835 Asia/Muscat +0858-07932 America/Panama -1203-07703 America/Lima -1732-14934 Pacific/Tahiti Society Islands -0900-13930 Pacific/Marquesas Marquesas Islands -2308-13457 Pacific/Gambier Gambier Islands -0930+14710 Pacific/Port_Moresby +1435+12100 Asia/Manila +2452+06703 Asia/Karachi +5215+02100 Europe/Warsaw +4703-05620 America/Miquelon -2504-13005 Pacific/Pitcairn +182806-0660622 America/Puerto_Rico +3130+03428 Asia/Gaza +3843-00908 Europe/Lisbon mainland +3238-01654 Atlantic/Madeira Madeira Islands +3744-02540 Atlantic/Azores Azores +0720+13429 Pacific/Palau -2516-05740 America/Asuncion +2517+05132 Asia/Qatar -2052+05528 Indian/Reunion +4426+02606 Europe/Bucharest +5443+02030 Europe/Kaliningrad Moscow-01 - Kaliningrad +5545+03735 Europe/Moscow Moscow+00 - west Russia +5312+05009 Europe/Samara Moscow+01 - Caspian Sea +5651+06036 Asia/Yekaterinburg Moscow+02 - Urals +5500+07324 Asia/Omsk Moscow+03 - west Siberia +5502+08255 Asia/Novosibirsk Moscow+03 - Novosibirsk +5601+09250 Asia/Krasnoyarsk Moscow+04 - Yenisei River +5216+10420 Asia/Irkutsk Moscow+05 - Lake Baikal +6200+12940 Asia/Yakutsk Moscow+06 - Lena River +4310+13156 Asia/Vladivostok Moscow+07 - Amur River +4658+14242 Asia/Sakhalin Moscow+07 - Sakhalin Island +5934+15048 Asia/Magadan Moscow+08 - Magadan +5301+15839 Asia/Kamchatka Moscow+09 - Kamchatka +6445+17729 Asia/Anadyr Moscow+10 - Bering Sea -0157+03004 Africa/Kigali +2438+04643 Asia/Riyadh -0932+16012 Pacific/Guadalcanal -0440+05528 Indian/Mahe 109

SD +1536+03232 Africa/Khartoum SE +5920+01803 Europe/Stockholm SG +0117+10351 Asia/Singapore SH -1555-00542 Atlantic/St_Helena SI +4603+01431 Europe/Ljubljana SJ +7800+01600 Arctic/Longyearbyen Svalbard SJ +7059-00805 Atlantic/Jan_Mayen Jan Mayen SK +4809+01707 Europe/Bratislava SL +0830-01315 Africa/Freetown SM +4355+01228 Europe/San_Marino SN +1440-01726 Africa/Dakar SO +0204+04522 Africa/Mogadishu SR +0550-05510 America/Paramaribo ST +0020+00644 Africa/Sao_Tome SV +1342-08912 America/El_Salvador SY +3330+03618 Asia/Damascus SZ -2618+03106 Africa/Mbabane TC +2128-07108 America/Grand_Turk TD +1207+01503 Africa/Ndjamena TF -492110+0701303 Indian/Kerguelen TG +0608+00113 Africa/Lome TH +1345+10031 Asia/Bangkok TJ +3835+06848 Asia/Dushanbe TK -0922-17114 Pacific/Fakaofo TL -0833+12535 Asia/Dili TM +3757+05823 Asia/Ashgabat TN +3648+01011 Africa/Tunis TO -2110+17510 Pacific/Tongatapu TR +4101+02858 Europe/Istanbul TT +1039-06131 America/Port_of_Spain TV -0831+17913 Pacific/Funafuti TW +2503+12130 Asia/Taipei TZ -0648+03917 Africa/Dar_es_Salaam UA +5026+03031 Europe/Kiev most locations UA +4837+02218 Europe/Uzhgorod Ruthenia UA +4750+03510 Europe/Zaporozhye Zaporozh'ye, E Lugansk UA +4457+03406 Europe/Simferopol central Crimea UG +0019+03225 Africa/Kampala UM +1700-16830 Pacific/Johnston Johnston Atoll UM +2813-17722 Pacific/Midway Midway Islands UM +1917+16637 Pacific/Wake Wake Island US +404251-0740023 America/New_York Eastern Time US +421953-0830245 America/Detroit Eastern Time - Michigan - most locations US +381515-0854534 America/Louisville Eastern Time - Kentucky - Louisville area US +364947-0845057 America/Kentucky/Monticello Eastern Time - Kentucky Wayne County US +394606-0860929 America/Indianapolis Eastern Standard Time - Indiana most locations 110

US +382232-0862041 America/Indiana/Marengo Eastern Standard Time Indiana - Crawford County US +411745-0863730 America/Indiana/Knox Eastern Standard Time - Indiana Starke County US +384452-0850402 America/Indiana/Vevay Eastern Standard Time Indiana - Switzerland County US +415100-0873900 America/Chicago Central Time US +450628-0873651 America/Menominee Central Time - Michigan - Wisconsin border US +470659-1011757 America/North_Dakota/Center Central Time - North Dakota - Oliver County US +394421-1045903 America/Denver Mountain Time US +433649-1161209 America/Boise Mountain Time - south Idaho & east Oregon US +364708-1084111 America/Shiprock Mountain Time - Navajo US +332654-1120424 America/Phoenix Mountain Standard Time - Arizona US +340308-1181434 America/Los_Angeles Pacific Time US +611305-1495401 America/Anchorage Alaska Time US +581807-1342511 America/Juneau Alaska Time - Alaska panhandle US +593249-1394338 America/Yakutat Alaska Time - Alaska panhandle neck US +643004-1652423 America/Nome Alaska Time - west Alaska US +515248-1763929 America/Adak Aleutian Islands US +211825-1575130 Pacific/Honolulu Hawaii UY -3453-05611 America/Montevideo UZ +3940+06648 Asia/Samarkand west Uzbekistan UZ +4120+06918 Asia/Tashkent east Uzbekistan VA +4154+01227 Europe/Vatican VC +1309-06114 America/St_Vincent VE +1030-06656 America/Caracas VG +1827-06437 America/Tortola VI +1821-06456 America/St_Thomas VN +1045+10640 Asia/Saigon VU -1740+16825 Pacific/Efate WF -1318-17610 Pacific/Wallis WS -1350-17144 Pacific/Apia YE +1245+04512 Asia/Aden YT -1247+04514 Indian/Mayotte YU +4450+02030 Europe/Belgrade ZA -2615+02800 Africa/Johannesburg ZM -1525+02817 Africa/Lusaka ZW -1750+03103 Africa/Harare

18.5 TIME ZONES IN AIX

The system defines the following time zones and time zone names:
Note: Coordinated Universal Time (CUT) is the international time standard.

111

Time Zones Defined on the System Name CUT0GDT GMT0BST AZOREST1AZOREDT FALKST2FALKDT GRNLNDST3GRNLNDDT AST4ADT EST5EDT CST6CDT MST7MDT PST8PDT AST9ADT HST10HDT BST11BDT NZST-12NZDT MET-11METDT EET-10EETDT JST-9JSTDT KORST-9KORDT WAUST-8WAUDT TAIST-8TAIDT THAIST-7THAIDT TASHST-6TASHDT PAKST-5PAKDT WST-4WDT MEST-3MEDT SAUST-3SAUDT WET-2WET USAST-2USADT NFT-1DFT Time Zone Coordinated Universal Time United Kingdom Azores, Cape Verde Falkland Islands Greenland, East Brazil Central Brazil Eastern United States, Colombia Central United States, Honduras Mountain United States Pacific United States, Yukon Alaska Hawaii, Aleutian Islands Bering Strait New Zealand Solomon Islands Eastern Australia Japan Korea Western Australia Taiwan Thailand Central Asia Pakistan Gorki, Central Asia, Oman Turkey Saudi Arabia Finland South Africa Norway CUT Offset CUT CUT CUT -1 CUT -2 CUT -3 CUT -4 CUT -5 CUT -6 CUT -7 CUT -8 CUT -9 CUT -10 CUT -11 CUT +12 CUT +11 CUT +10 CUT +9 CUT +9 CUT +8 CUT +8 CUT +7 CUT +6 CUT +5 CUT +4 CUT +3 CUT +3 CUT +2 CUT +2 CUT +1

18.6 TIME ZONES IN CIRCUIT DOMAIN

18.6.1 ON SDM USING SDMCONFIG

112

113

18.7 TIME ZONES IN GGSN

Africa/Abidjan Africa/Addis_Ababa Africa/Asmera Africa/Bangui Africa/Bissau Africa/Brazzaville Africa/Cairo Africa/Ceuta Africa/Dakar Africa/Djibouti Africa/El_Aaiun Africa/Gaborone Africa/Accra Africa/Algiers Africa/Bamako Africa/Banjul Africa/Blantyre Africa/Bujumbura Africa/Casablanca Africa/Conakry Africa/Dar_es_Salaam Africa/Douala Africa/Freetown Africa/Harare 114

Africa/Johannesburg Africa/Khartoum Africa/Kinshasa Africa/Libreville Africa/Luanda Africa/Lusaka Africa/Maputo Africa/Mbabane Africa/Monrovia Africa/Ndjamena Africa/Nouakchott

Africa/Kampala Africa/Kigali Africa/Lagos Africa/Lome Africa/Lubumbashi Africa/Malabo Africa/Maseru Africa/Mogadishu Africa/Nairobi Africa/Niamey Africa/Ouagadougou

Africa/Porto-Novo Africa/Sao_Tome Africa/Timbuktu Africa/Tripoli Africa/Tunis Africa/Windhoek America/Adak America/Anchorage America/Anguilla America/Antigua America/Araguaina America/Aruba America/Asuncion America/Atka America/Barbados America/Belem America/Belize America/Boa_Vista America/Bogota America/Boise America/Buenos_Aires America/Cambridge_B America/Cancun America/Caracas America/Catamarca America/Cayenne America/Cayman America/Chicago America/Chihuahua America/Cordoba America/Costa_Rica America/Cuiaba America/Curacao America/Dawson America/Dawson_Creek America/Denver America/Detroit America/Dominica America/Edmonton America/El_Salvador America/Ensenada America/Fort_Wayne America/Fortaleza America/Glace_Bay America/Godthab America/Goose_Bay America/Grand_Turk America/Grenada America/Guadeloupe America/Guatemala America/Guayaquil America/Guyana America/Halifax America/Havana America/Indiana/Indianapolis America/Indiana/Knox America/Indiana/Marengo America/Indiana/Vevay America/Indianapolis America/Inuvik America/Iqaluit America/Jamaica America/Jujuy America/Juneau America/Knox_IN America/La_Paz America/Lima America/Los_Angeles America/Louisville America/Maceio America/Managua America/Manaus America/Martinique America/Mazatlan America/Mendoza America/Menominee 115

America/Mexico_City America/Miquelon America/Montevideo America/Montreal America/Montserrat America/Nassau America/New_York America/Nipigon America/Nome America/Noronha America/Panama America/Pangnirtung America/Paramaribo America/Phoenix America/Port-au-Prince America/Port_of_Spain America/Porto_Acre America/Porto_Velho America/Puerto_Rico America/Rainy_River America/Rankin_Inlet America/Regina America/Rosario America/Santiago America/Santo_Domingo America/Sao_Paulo America/Scoresbysund America/Shiprock America/St_Johns America/St_Kitts America/St_Lucia America/St_Thomas America/St_Vincent America/Swift_Current America/Tegucigalpa America/Thule America/Thunder_Bay America/Tijuana America/Tortola America/Vancouver America/Virgin America/Whitehorse America/Winnipeg America/Yakutat America/Yellowknife Antarctica/Casey Antarctica/Davis Antarctica/DumontDUrville Antarctica/Mawson Antarctica/McMurdo Antarctica/Palmer Antarctica/South_Pole Antarctica/Syowa Arctic/Longyearbyen Asia/Aden Asia/Almaty Asia/Amman Asia/Anadyr Asia/Aqtau Asia/Aqtobe Asia/Ashkhabad Asia/Baghdad Asia/Bahrain Asia/Baku Asia/Bangkok Asia/Beirut Asia/Bishkek Asia/Brunei Asia/Calcutta Asia/Chungking Asia/Colombo Asia/Dacca Asia/Damascus Asia/Dili Asia/Dubai Asia/Dushanbe Asia/Gaza Asia/Harbin Asia/Hong_Kong Asia/Irkutsk Asia/Istanbul Asia/Jakarta Asia/Jayapura Asia/Jerusalem Asia/Kabul Asia/Kamchatka Asia/Karachi Asia/Kashgar Asia/Katmandu Asia/Krasnoyarsk Asia/Kuala_Lumpur Asia/Kuching Asia/Kuwait Asia/Macao Asia/Magadan Asia/Manila Asia/Muscat Asia/Nicosia Asia/Novosibirsk Asia/Omsk Asia/Phnom_Penh Asia/Pyongyang 116

Asia/Qatar Asia/Rangoon Asia/Riyadh Asia/Riyadh87 Asia/Riyadh88 Asia/Riyadh89 Asia/Saigon Asia/Samarkand Asia/Seoul Asia/Shanghai Asia/Singapore Asia/Taipei Asia/Tashkent Asia/Tbilisi Asia/Tehran Asia/Tel_Aviv Asia/Thimbu Asia/Tokyo Asia/Ujung_Pandang Asia/Ulan_Bator Asia/Urumqi Asia/Vientiane Asia/Vladivostok Asia/Yakutsk Asia/Yekaterinburg Asia/Yerevan Atlantic/Azores Atlantic/Bermuda Atlantic/Canary Atlantic/Cape_Verde Atlantic/Faeroe Atlantic/Jan_Mayen Atlantic/Madeira Atlantic/Reykjavik Atlantic/South_Georgia Atlantic/St_Helena Atlantic/Stanley Australia/ACT Australia/Adelaide Australia/Brisbane Australia/Broken_Hill Australia/Canberra Australia/Darwin Australia/Hobart Australia/LHI Australia/Lindeman Australia/Lord_Howe Australia/Melbourne Australia/NSW Australia/North Australia/Perth Australia/Queensland Australia/South Australia/Sydney Australia/Tasmania Australia/Victoria Australia/West Australia/Yancowinna Brazil/Acre Brazil/DeNoronha Brazil/East Brazil/West CET CST6CDT Canada/Atlantic Canada/Central Canada/East-Saskatchewan Canada/Eastern Canada/Mountain Canada/Newfoundland Canada/Pacific Canada/Saskatchewan Canada/Yukon Chile/Continental Chile/EasterIsland Cuba EET EST EST5EDT Egypt Eire Etc/GMT Etc/GMT+0 Etc/GMT+1 Etc/GMT+10 Etc/GMT+11 Etc/GMT+12 Etc/GMT+2 Etc/GMT+3 Etc/GMT+4 Etc/GMT+5 Etc/GMT+6 Etc/GMT+7 Etc/GMT+8 Etc/GMT+9 Etc/GMT-0 Etc/GMT-1 Etc/GMT-10 Etc/GMT-11 Etc/GMT-12 Etc/GMT-13 Etc/GMT-14 117

Etc/GMT-2 Etc/GMT-3 Etc/GMT-4 Etc/GMT-5 Etc/GMT-6 Etc/GMT-7 Etc/GMT-8 Etc/GMT-9 Etc/GMT0 Etc/Greenwich Etc/UCT Etc/UTC Etc/Universal Etc/Zulu Europe/Amsterdam Europe/Andorra Europe/Athens Europe/Belfast Europe/Belgrade Europe/Berlin Europe/Bratislava Europe/Brussel Europe/Bucharest Europe/Budapes Europe/Chisinau Europe/Copenha Europe/Dublin Europe/Gibralt Europe/Helsinki Europe/Istanbu Europe/Kaliningrad Europe/Kiev Europe/Lisbon Europe/Ljublja Europe/London Europe/Luxembo Europe/Madrid Europe/Malta Europe/Minsk Europe/Monaco Europe/Moscow Europe/Oslo Europe/Paris Europe/Prague Europe/Riga Europe/Rome Europe/Samara Europe/San_Mar Europe/Sarajevo Europe/Simfero Europe/Skopje Europe/Sofia Europe/Stockholm Europe/Tallinn Europe/Tirane Europe/Vaduz Europe/Vatican Europe/Vienna Europe/Vilnius Europe/Warsaw Europe/Zagreb Europe/Zurich Factory GB GMT GMT+0 GMT-0 GMT0 Greenwich HST Hongkong Iceland Indian/Antananarivo Indian/Chagos Indian/Christmas Indian/Cocos Indian/Comoro Indian/Kerguel Indian/Mahe Indian/Maldive Indian/Mauritius Indian/Mayotte Indian/Reunion Iran Israel Jamaica Japan Kwajalein Libya MET MST MST7MDT Mexico/BajaNorte Mexico/BajaSur Mexico/General Mideast/Riyadh Mideast/Riyadh88 Mideast/Riyadh NZ NZ-CHAT Navajo PRC 118

PST8PDT Pacific/Auckland Pacific/Easter Pacific/Enderbury Pacific/Fiji Pacific/Galapagos Pacific/Guadalcanal Pacific/Honolulu Pacific/Kiritimati Pacific/Kwajalein Pacific/Marquesas Pacific/Nauru Pacific/Norfolk Pacific/Pago_Pago Pacific/Pitcairn Pacific/Port_Moresby Pacific/Saipan Pacific/Tahiti Pacific/Tongatapu Pacific/Wake Pacific/Yap Portugal ROK SystemV/AST4 SystemV/CST6 SystemV/EST5 SystemV/HST10 SystemV/MST7MDT SystemV/PST8PDT SystemV/YST9YDT UCT US/Aleutian US/Central US/Eastern US/Indiana-Starke US/Mountain US/Pacific-New UTC W-SU Zulu

Pacific/Apia Pacific/Chatha Pacific/Efate Pacific/Fakaof Pacific/Funafu Pacific/Gambie Pacific/Guam Pacific/Johnst Pacific/Kosrae Pacific/Majuro Pacific/Midway Pacific/Niue Pacific/Noumea Pacific/Palau Pacific/Ponape Pacific/Raroto Pacific/Samoa Pacific/Tarawa Pacific/Truk Pacific/Wallis Poland ROC Singapore SystemV/AST4AD SystemV/CST6CD SystemV/EST5ED SystemV/MST7 SystemV/PST8 SystemV/YST9 Turkey US/Alaska US/Arizona US/East-Indian US/Hawaii US/Michigan US/Pacific US/Samoa Universal WET

18.8 TIME ZONES IN HP-UX

# Mitteleuropaeische Zeit, Mitteleuropaeische Sommerzeit MEZ-1MESZ 0 3 25-31 3 1983-2038 0 MESZ-2 0 2 24-30 9 1983-1995 0 MEZ-1 0 2 25-31 10 1996-2038 0 MEZ-1 # Middle European Time, Middle European Time Daylight Savings Time 119

MET-1METDST 0 3 25-31 3 1983-2038 0 METDST-2 0 2 24-30 9 1983-1995 0 MET-1 0 2 25-31 10 1996-2038 0 MET-1 # Greenwich Mean Time, British Summer Time GMT0BST 0 3 25-31 3 1983-1984 0 BST-1 0 3 23-29 3 1985-1990 0 BST-1 0 3 25-31 3 1991-1995 0 BST-1 0 2 25-31 3 1996-2038 0 BST-1 0 1 25-31 10 1983-1985 0 GMT0 0 1 23-29 10 1986-1994 0 GMT0 0 1 18-24 10 1995 0 GMT0 0 1 25-31 10 1996-2038 0 GMT0 # Pacific Standard Time, Pacific Daylight Time PST8PDT 0 3 24-30 4 1970-1973 0 PDT7 0 3 6 1 1974 0-6 PDT7 0 3 22-28 2 1975 0 PDT7 0 3 24-30 4 1976-1986 0 PDT7 0 3 1-7 4 1987-2038 0 PDT7 0 1 25-31 10 1970-1973 0 PST8 0 1 24-30 11 1974 0 PST8 0 1 25-31 10 1975-2038 0 PST8 # Eastern Standard Time, Eastern Daylight Time EST5EDT 0 3 24-30 4 1970-1973 0 EDT4 0 3 6 1 1974 0-6 EDT4 0 3 22-28 2 1975 0 EDT4 0 3 24-30 4 1976-1986 0 EDT4 0 3 1-7 4 1987-2038 0 EDT4 0 1 25-31 10 1970-1973 0 EST5 0 1 24-30 11 1974 0 EST5 0 1 25-31 10 1975-2038 0 EST5 # Central Standard Time, Central Daylight Time CST6CDT 0 3 24-30 4 1970-1973 0 CDT5 0 3 6 1 1974 0-6 CDT5 0 3 22-28 2 1975 0 CDT5 0 3 24-30 4 1976-1986 0 CDT5 0 3 1-7 4 1987-2038 0 CDT5 0 1 25-31 10 1970-1973 0 CST6 0 1 24-30 11 1974 0 CST6 0 1 25-31 10 1975-2038 0 CST6 # Mountain Standard Time, Mountain Daylight Time MST7MDT 120

0 3 24-30 4 1970-1973 0 MDT6 0 3 6 1 1974 0-6 MDT6 0 3 22-28 2 1975 0 MDT6 0 3 24-30 4 1976-1986 0 MDT6 0 3 1-7 4 1987-2038 0 MDT6 0 1 25-31 10 1970-1973 0 MST7 0 1 24-30 11 1974 0 MST7 0 1 25-31 10 1975-2038 0 MST7 # Atlantic Standard Time, Atlantic Daylight Time AST4ADT 0 3 24-30 4 1970-1973 0 ADT3 0 3 6 1 1974 0-6 ADT3 0 3 22-28 2 1975 0 ADT3 0 3 24-30 4 1976-1986 0 ADT3 0 3 1-7 4 1987-2038 0 ADT3 0 1 25-31 10 1970-1973 0 AST4 0 1 24-30 11 1974 0 AST4 0 1 25-31 10 1975-2038 0 AST4 # Newfoundland Standard Time, Newfoundland Daylight Time NST3:30NDT 0 3 24-30 4 1970-1973 0 NDT2:30 0 3 6 1 1974 0-6 NDT2:30 0 3 22-28 2 1975 0 NDT2:30 0 3 24-30 4 1976-1986 0 NDT2:30 0 3 1-7 4 1987-2038 0 NDT2:30 0 1 25-31 10 1970-1973 0 NST3:30 0 1 24-30 11 1974 0 NST3:30 0 1 25-31 10 1975-2038 0 NST3:30 # Eastern Standard Time, Central Daylight Time (US: Indiana) EST5CDT 0 3 24-30 4 1970-1973 0 CDT5 0 3 6 1 1974 0-6 CDT5 0 3 22-28 2 1975 0 CDT5 0 3 24-30 4 1976-1986 0 CDT5 0 3 1-7 4 1987-2038 0 CDT5 0 1 25-31 10 1970-1973 0 EST5 0 1 24-30 11 1974 0 EST5 0 1 25-31 10 1975-2038 0 EST5 # Aleutian Standard Time, Aleutian Daylight Time AST10ADT 0 3 24-30 4 1970-1973 0 ADT9 0 3 6 1 1974 0-6 ADT9 0 3 22-28 2 1975 0 ADT9 0 3 24-30 4 1976-1986 0 ADT9 0 3 1-7 4 1987-2038 0 ADT9 0 1 25-31 10 1970-1973 0 AST10 0 1 24-30 11 1974 0 AST10 121

0 1 25-31 10 1975-2038 0 AST10 # Yukon Standard Time, Yukon Daylight Time YST9YDT 0 3 24-30 4 1970-1973 0 YDT8 0 3 6 1 1974 0-6 YDT8 0 3 22-28 2 1975 0 YDT8 0 3 24-30 4 1976-1986 0 YDT8 0 3 1-7 4 1987-2038 0 YDT8 0 1 25-31 10 1970-1973 0 YST9 0 1 24-30 11 1974 0 YST9 0 1 25-31 10 1975-2038 0 YST9 # Western European Time, Western European Time Daylight Savings Time WET0WETDST 0 3 25-31 3 1983-1984 0 WETDST-1 0 3 23-29 3 1985-1995 0 WETDST-1 0 2 25-31 3 1996-2038 0 WETDST-1 0 1 25-31 10 1983-1985 0 WET0 0 1 23-29 10 1986-1995 0 WET0 0 1 25-31 10 1996-2038 0 WET0 # Portuguese Winter Time, Portuguese Summer Time PWT0PST 0 2 25-31 3 1983-2038 0 PST-1 0 1 25-31 10 1983-2038 0 PWT0 # South Africa Standard Time SAST-2 0 1 1-7 3 1985-2038 0 SAST-2 # Australian Central Standard Time, Australian Central Daylight Time # (South Australia) # # This entry has been changed to allow for a later ending of # daylight savings time from 1995 onwards in South Australia. # It now ends in the last week of March. # CST-9:30CDT 0 3 25-31 10 1971-2038 0 CDT-10:30 0 1 27 2 1972 0-6 CST-9:30 0 1 1-7 3 1973-1994 0 CST-9:30 0 2 25-31 3 1995-2038 0 CST-9:30 # Australian Eastern Standard Time, Australian Eastern Daylight Time # # This entry has been changed to allow for a later ending of # daylight savings time from 1996 onwards. # It now ends in the last week of March. # # This entry has been changed to allow an earlier start of 122

# daylight savings time for Sydney Olympics 2000. # EST-10EDT 0 3 25-31 10 1971-1999 0 EDT-11 0 3 27 8 2000 0-6 EDT-11 0 3 25-31 10 2001-2038 0 EDT-11 0 1 27 2 1972 0-6 EST-10 0 1 1-7 3 1973-1985 0 EST-10 0 1 15-21 3 1986 0 EST-10 0 1 1-7 3 1987-1995 0 EST-10 0 2 25-31 3 1996-2038 0 EST-10 # New Zealand Standard Time, New Zealand Daylight Time # NZST-12NZDT 0 3 25-31 10 1985-1988 0 NZDT-13 0 3 8 10 1989 0-6 NZDT-13 0 3 1-7 10 1990-2038 0 NZDT-13 0 1 1-7 3 1985-1989 0 NZST-12 0 1 15-21 3 1990-2038 0 NZST-12 # Pacific Standard Time, Pacific Daylight Time (for Malaysia or Singapore) # PST-8PDT 0 1 1-7 4 1996-2038 0 PDT-9 0 1 25-31 10 1996-2038 0 PST-8 # Finland Standard Time, Finland Daylight Time # # This entry has been changed to allow for a later ending of # Daylight Savings Time from 1996 onwards. # It now ends on the last Sunday of October. # EET-2EETDST 0 4 25-31 3 1981-2038 0 EETDST-3 0 3 24-30 9 1981-1995 0 EET-2 0 3 25-31 10 1996-2038 0 EET-2 # The timezones named above should be used in preference to those below except # for dates prior to 1987 for Tasmania. US and Canada use the same rules so # the simpler timezone strings above will work for both countries. # Australian Eastern Standard Time, Australian Eastern Daylight Time (Tasmania) # (same as EST-10EDT for 1987 - 2038) # # This entry has been changed to allow for an earlier starting # and later ending of daylight savings time from 1995 onwards # in Tasmania. It starts in the first week of October and # ends in the last week of March. # # This entry has been changed to allow an earlier start of 123

# daylight savings time for Sydney Olympics 2000. # EST-10EDT#Tasmania 0 3 25-31 10 1971-1994 0 EDT#Tasmania-11 0 3 1-7 10 1995-1999 0 EDT#Tasmania-11 0 3 25-31 8 2000 0 EDT#Tasmania-11 0 3 1-7 10 2001-2038 0 EDT#Tasmania-11 0 1 27 2 1972 0-6 EST-10 0 1 1-7 3 1973-1994 0 EST-10 0 2 25-31 3 1995-2038 0 EST-10 # Australian Eastern Standard Time, Australian Eastern Daylight Time # # This entry has been changed to allow for a later ending of # daylight savings time from 1996 onwards. # It now ends in the last week of March. # (New South Wales) # # This entry has been changed to allow an earlier start of # daylight savings time for Sydney Olympics 2000. # EST-10EDT#NSW 0 3 25-31 10 1971-1999 0 EDT#NSW-11 0 3 27 8 2000 0-6 EDT#NSW-11 0 3 25-31 10 2001-2038 0 EDT#NSW-11 0 1 27 2 1972 0-6 EST-10 0 1 1-7 3 1973-1985 0 EST-10 0 1 15-21 3 1986 0 EST-10 0 2 1-7 3 1987-1995 0 EST-10 0 2 25-31 3 1996-2038 0 EST-10 # Australian Eastern Standard Time, Australian Eastern Daylight Time # # This entry has been changed to allow for a later ending of # daylight savings time from 1995 onwards. # It now ends in the last week of March. # (Victoria) # # This entry has been changed to allow an earlier start of # daylight savings time for Sydney Olympics 2000. # EST-10EDT#VIC 0 3 25-31 10 1971-1999 0 EDT#VIC-11 0 3 27 8 2000 0-6 EDT#VIC-11 0 3 25-31 10 2001-2038 0 EDT#VIC-11 0 1 27 2 1972 0-6 EST-10 0 1 1-7 3 1973-1985 0 EST-10 0 1 15-21 3 1986 0 EST-10 0 1 1-7 3 1987-1994 0 EST-10 0 2 25-31 3 1995-2038 0 EST-10 124

# Pacific Standard Time, Pacific Daylight Time (Canada) PST8PDT#Canada 0 3 24-30 4 1970-1973 0 PDT#Canada7 0 3 6 1 1974 0-6 PDT#Canada7 0 3 22-28 2 1975 0 PDT#Canada7 0 3 24-30 4 1976-1986 0 PDT#Canada7 0 3 1-7 4 1987-2038 0 PDT#Canada7 0 1 25-31 10 1970-1973 0 PST8 0 1 24-30 11 1974 0 PST8 0 1 25-31 10 1975-2038 0 PST8 # Mountain Standard Time, Mountain Daylight Time (Canada) MST7MDT#Canada 0 3 24-30 4 1970-1973 0 MDT#Canada6 0 3 6 1 1974 0-6 MDT#Canada6 0 3 22-28 2 1975 0 MDT#Canada6 0 3 24-30 4 1976-1986 0 MDT#Canada6 0 3 1-7 4 1987-2038 0 MDT#Canada6 0 1 25-31 10 1970-1973 0 MST7 0 1 24-30 11 1974 0 MST7 0 1 25-31 10 1975-2038 0 MST7 # Central Standard Time, Central Daylight Time (Canada) CST6CDT#Canada 0 3 24-30 4 1970-1973 0 CDT#Canada5 0 3 6 1 1974 0-6 CDT#Canada5 0 3 22-28 2 1975 0 CDT#Canada5 0 3 24-30 4 1976-1986 0 CDT#Canada5 0 3 1-7 4 1987-2038 0 CDT#Canada5 0 1 25-31 10 1970-1973 0 CST6 0 1 24-30 11 1974 0 CST6 0 1 25-31 10 1975-2038 0 CST6 # Eastern Standard Time, Eastern Daylight Time (Canada) EST5EDT#Canada 0 3 24-30 4 1970-1973 0 EDT#Canada4 0 3 6 1 1974 0-6 EDT#Canada4 0 3 22-28 2 1975 0 EDT#Canada4 0 3 24-30 4 1976-1986 0 EDT#Canada4 0 3 1-7 4 1987-2038 0 EDT#Canada4 0 1 25-31 10 1970-1973 0 EST5 0 1 24-30 11 1974 0 EST5 0 1 25-31 10 1975-2038 0 EST5 # Eastern Standard Time (US: Most of Indiana) # # This entry is added to correct the Indiana timezone because # Indiana does not observe Daylight Savings Time. The original # entry EST5CDT is kept to ensure backward compatibility. EST5EST 0 3 24-30 4 1970-1973 0 EST5 125

0 3 6 1 1974 0-6 EST5 0 3 22-28 2 1975 0 EST5 0 3 24-30 4 1976-1986 0 EST5 0 3 1-7 4 1987-2038 0 EST5 0 1 25-31 10 1970-1973 0 EST5 0 1 24-30 11 1974 0 EST5 0 1 25-31 10 1975-2038 0 EST5 # Eastern Standard Time, Central Daylight Time (US: Indiana) # # This entry is for backward compatibility only, the correct entry # is the EST5CDT entry above. This entry is incorrect because the # "6" in EST6CDT below should be a "5". Other than the "6" being # changed to "5", this entry and EST5CDT are the same and the # end result of using either is identical. # EST6CDT 0 3 24-30 4 1970-1973 0 CDT5 0 3 6 1 1974 0-6 CDT5 0 3 22-28 2 1975 0 CDT5 0 3 24-30 4 1976-1986 0 CDT5 0 3 1-7 4 1987-2038 0 CDT5 0 1 25-31 10 1970-1973 0 EST5 0 1 24-30 11 1974 0 EST5 0 1 25-31 10 1975-2038 0 EST5 # Western Russia (Moscow) Time, Western Russia (Moscow) Daylight Savings # Time WST-3WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-4 0 2 24-30 9 1983-1995 0 WST-3 0 2 25-31 10 1996-2038 0 WST-3 # Belorussia (minsk) Time, Belorussia (minsk) Daylight Savings Time WST-2WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-3 0 2 24-30 9 1983-1995 0 WST-2 0 2 25-31 10 1996-2038 0 WST-2 # European Russia (samara) Time, European Russia (samara) Daylight Savings #Time WST-4WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-5 0 2 24-30 9 1983-1995 0 WST-4 0 2 25-31 10 1996-2038 0 WST-4 # Urals (Ekaterinburg) Time, Urals (Ekaterinburg) Daylight Savings Time WST-5WSTDST 126

0 3 25-31 3 1983-2038 0 WSTDST-6 0 2 24-30 9 1983-1995 0 WST-5 0 2 25-31 10 1996-2038 0 WST-5 # Western Siberia (Omsk), Western Siberia (Omsk) Daylight Savings Time WST-6WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-7 0 2 24-30 9 1983-1995 0 WST-6 0 2 25-31 10 1996-2038 0 WST-6 # Middle Siberia (Krasnoyarsk) Time, Middle Siberia (Krasnoyarsk) # Daylight Savings Time WST-7WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-8 0 2 24-30 9 1983-1995 0 WST-7 0 2 25-31 10 1996-2038 0 WST-7 # Baikal lake (Irkutsk) Time, Baikal lake (Irkutsk) Daylight Savings Time WST-8WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-9 0 2 24-30 9 1983-1995 0 WST-8 0 2 25-31 10 1996-2038 0 WST-8 # Eastern Siberia (Yakutsk) Time, Eastern Siberia (Yakutsk) Daylight # Savings Time WST-9WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-10 0 2 24-30 9 1983-1995 0 WST-9 0 2 25-31 10 1996-2038 0 WST-9 # Far East (Khabarovsk) Time, Far East (Khabarovsk) Daylight Savings # Time WST-10WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-11 0 2 24-30 9 1983-1995 0 WST-10 0 2 25-31 10 1996-2038 0 WST-10 # Russia Pacific (magadan) Time, Russia Pacific (magadan) Daylight # Savings Time WST-11WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-12 0 2 24-30 9 1983-1995 0 WST-11 0 2 25-31 10 1996-2038 0 WST-11 # Kamchatka (Petropavlovsk-Kamchatskiy) Time, Kamchatka(Petropavlovsk 127

# -Kamchatskiy) Daylight Savings Time WST-12WSTDST 0 3 25-31 3 1983-2038 0 WSTDST-13 0 2 24-30 9 1983-1995 0 WST-12 0 2 25-31 10 1996-2038 0 WST-12

19 ANNEX D. NTP PATH, FILES AND COMMANDS RELATIONSHIP IN SOLARIS/AIX/HP-UX

Solaris (Sun) /etc/TIMEZONE /etc/default/init /etc/inet/ntp.conf /etc/init.d/xntpd driftfile/etc/inet/ntp.drift AIX (IBM) /etc/environment /etc/profile /etc/ntp.conf start src s xntpd HP-UX (HP) /etc/TIMEZONE /etc/ntp.conf /usr/sbin/xntpd driftfile/etc/ntp.drift

Starting xntpd on OMU: /OMU/local/usr/sbin/btime_ntp_start (to grant that the correct configuration file is used; remember that active OMU needs to listen to external NTP servers, and to synchronize passive OMU and broadcast NTP data to the internal network). The /etc/environment file contains variables specifying the basic environment for all processes. When a new process begins, the exec subroutine makes an array of strings available that have the form Name=Value. This array of strings is called the environment. Each name defined by one of the strings is called an

environment variable or shell variable. The exec subroutine allows the entire
environment to be set at one time. Environment variables are examined when a command starts running. The environment of a process is not changed by altering the /etc/environment file. Any processes that were started prior to the change to the /etc/environment file must be restarted if the change is to take effect for those processes. If the TZ variable is changed, the cron daemon must be restarted, because this variable is used to determine the current local time.
The Basic Environment

128

When you log in, the system sets environment variables from the environment file before reading your login profile, .profile. Between the variables make up the basic environment is:
TZ The time-zone information. The TZ environment variable is set by the /etc/environment file. The TZ environment variable has the following format (spaces inserted for readability):
std offset dst offset , rule

The fields within the TZ environment variable are defined as follows:

std and dst Designate the standard (std) and summer (dst) time zones. Only the std value along with the appropriate offset value is required. If the dst value is not specified, summer time does not apply. The values specified may be no less than three and no more than TZNAME_MAX bytes in length. The length of the variables corresponds to the %Z field of the date command; for libc and libbsd, TZNAME_MAX equals three characters. Any nonnumeric ASCII characters except the following may be entered into each field: a leading : (colon), a , (comma), a (minus sign), a + (plus sign), or the ASCII null character. Note: POSIX 1.0 reserves the leading : (colon) for an implementation-defined TZ specification. The operating system disallows the leading colon, selecting CUT0 and setting the %Z field to a null string.

An example of std and dst format is as follows:

EST5EDT EST 5

Specifies Eastern U.S. standard time. Specifies the offset, which is 5 hours behind Coordinated Universal Time (CUT).
EDT

Specifies the corresponding summer time zone abbreviation. Note: See "Time Zones" for a list of time zone names defined for the system. offset Denotes the value added to local time to equal Coordinated Universal Time (CUT). CUT is the international time standard that has largely replaced Greenwich Mean Time. The offset variable has the following format:
hh:mm:ss

129

The fields within the offset variable are defined as follows:

hh

mm

Specifies the dst offset in hours. This field is required. The hh value can range between the integers -12 and +11. A negative value indicates the time zone is east of the prime meridian; a positive value or no value indicates the time zone is west of the prime meridian. Specifies the dst offset detailed to the minute. This field is optional. If the mm value is present, it must be specified between 0 and 59 and preceded by a : (colon).
ss

Specifies the dst offset detailed to the second. The ss field is optional. If the ss value is present, it must be specified between 0 and 59 and preceded by a : (colon).

An offset variable must be specified with the std variable. An offset variable for the dst variable is optional. If no offset is specified with the dst variable, the system assumes that summer time is one hour ahead of standard time. As an example of offset syntax, Zurich is one hour ahead of CUT, so its offset is -1. Newfoundland is 1.5 hours ahead of eastern U.S. standard time zones. Its syntax can be stated as any of the following: 3:30, 03:30, +3:30, or 3:30:00.
rule The rule variable indicates when to change to and back from summer time. The rule variable has the following format:
start/time,end/time

The fields within the rule variable are defined as follows:

start end time

Specifies the change from standard to summer time. Specifies the return to standard time from summer time. Specifies when the time changes occur within the time zone. For example, if the time variable is encoded for 2 a.m. then the time changes when the time zone reaches 2 a.m. on the date specified in the start variable. Delimits the start date, end date, and time variables.
,

(Comma) Delimits two date and time pairs.

The start and end variables support a syntax for Julian time (J) and a syntax for leap years (M):
Jn

130

Mm.n.d

In the J syntax, the n variable has the value of 1 through 365. Leap days are not counted. In the M syntax, m is the month, n the week, and d the day of the week starting from day 0 (Sunday). The rule variable has the same format as the offset variable except no leading - (minus sign) or + (plus sign) is allowed. The default of the start variable is 02:00:00 (2 a.m.).
Note: The time zone offsets and time change points are interrelated and context-dependent. The rule variable's runtime execution semantics change as a function of the offsets. For example, if the summer time zone changes one hour, as in CST6CDT5, (the default 2 a.m.) summer time changes instantaneously from 2 a.m. to 3 a.m. CDT. The fall change is from 2 a.m. CDT to 1 a.m. CST. The respective changes for a time zone of CST6CDT4 are 2 a.m. CST to 4 a.m. CDT and 2 a.m. CDT to 12 a.m. CST.

In an example of the rule variable, if the law changed so that the Central United States experienced summer time between Julian 129 and Julian 131, the TZ variable would be stated as follows:
TZ=CST6CDT5,J129,J131

In this example, the dates indicated are May 09 and May 11,1993, respectively. (Use the date +%j command to get the Julian date number.) In another example, if the time changes were to occur at 2 a.m. CST and 19:30 CDT, respectively, the variables would be stated as follows:
TZ=CST6CDT5,J129,J131/19:30

In nonleap years, the fallback time change would be from 19:30 CDT to 18:30 CST on May 11 (1993). For the leap year (M) syntax, the spring ahead date would be 2 May and the fallback date is 9 May. The variables are stated as follows:
TZ=CST6CDT5,M5.1.0,M5.2.0

131

Some examples follow: "TZ=CST6" is the minimum required format. It only specifies the standard timezone. Summer (DST) timezone does not apply "TZ=CST6CDT" is a simplified format to specify both standard and summer timezones. It does not provide the rules for daylight saving, i.e. the starting and ending date and time. DST information is provided "TZ=CST6CDT5" explicitly specify the offset for DST to 5. This is optional. If no offset is specified with the dst variable, i.e. "TZ=CST6CDT" the system assumes that summer time is one hour ahead of standard time. It does not provide the rules for daylight saving, i.e. the starting and ending date and time. So it's incomplete format for a timezone with DST "TZ=CST6CDT5, J129, J131/19:30" is a complete format. It explicitly specify the starting and ending time for summer time (DST). If the time in the rule is not provided, system wil use default "02:00:00". This format is using "J Syntax". Julian date number is used for starting and ending date of DST. Leap days are not counted "TZ=EST5EDT,M4.1.0/02:00:00,M10.5.0/02:00:00" is a complete format. This format is using "M Syntax". It uses "month.week.day of the week starting from day 0 (Sunday)" to specify starting and ending date of DST. It's most popular format, since most laws are using month/week/day of week to rule the starting and ending date of DST.

20 ANNEX E. SPECIFIC SECTIONS TO BE PREPARED FOR THE DTM SOLUTION PER CUSTOMER
This annex presents an example of Summary for a customized document that can be prepared per Customer:

20.1 NTP GENERAL DESIGN FOR CUSTOMER NETWORK (S) 20.2 NTP DESIGN FOR CUSTOMER NETWORKS AS PER CUSTOMER STRATEGY 20.3 NES/SERVERS NETWORK A INCLUDED INTO THE THE THE CUSTOMER CUSTOMER CUSTOMER

20.4 NES/SERVERS INCLUDED INTO NETWORK B (IF APPLICABLE) 20.5 NES/SERVERS INCLUDED INTO NETWORK C (IF APPLICABLE)

132