KR20090084895A - Defining a stratum-1 configuration in a coordinated timing network - Google Patents

Abstract

A stratum-1 configuration for a timing network is defined. The stratum-1 configuration includes a single active stratum-1 server usable in ensuring that the servers in the network use the same primary reference time to synchronize their clocks. The servers in the network are synchronizing to the same root primary reference time and synchronization accuracyis not dependent on the quality of an external time source or of the existence of an external time source at the stratum-1 server. ® KIPO & WIPO 2009

Description

DEFINING A STRATUM-1 CONFIGURATION IN A COORDINATED TIMING NETWORK}

The present invention relates generally to time synchronization between networks as well as within a network of processing devices, and more specifically to a single activity for an integrated timing network that allows servers in a timing network to be synchronized at the same basic primary reference. It relates to defining a stratum-1 configuration with a primary time server.

For job execution and data preservation, computational systems that access shared data, such as Sysplex, manufactured by International Business Machines Corporation, Armonk, NY, are more accurate than the best case communication time between systems. It must be able to maintain time of day (TOD) clock synchronization. For example, at present, a timer, such as IBM Sysplex Timer®, is used to meet synchronization requirements. This timer requires expensive dedicated timing links and a separate outer box. IBM® and IBM Sysplex Timer® are registered trademarks of International Business Machines Corporation in Amonk, NY.

Networks such as Network Timing Protocol (NTP) provide time synchronization but do not meet the accuracy requirements of high-end systems. NTP requires each server to have access to an external time source that provides up to microsecond accuracy to ensure that all servers synchronize at the same reference time. . This is a problem for systems that are incapable of attaching to an external time server that provides this level of accuracy. In addition, the requirements of a GPS receiver or similar attachment of each system are considered inadequate for use for reasons of maintenance, security and reliability.

In light of the foregoing, there is a need for an ability to facilitate the provision of time synchronization. As one example, there is a need for the ability to designate a single active layer-1 server that ensures that servers in the network synchronize their clocks using the same primary reference time in a timing network.

Further advantages are obtained by overcoming the disadvantages of the prior art by providing an article of manufacture comprising at least one computer usable medium having computer readable program code logic to facilitate synchronization in a timing network. The computer readable program code logic may, when executed, define, for example, a configuration of a timing network, the configuration comprising a single server used as a clock source for one or more other servers in the timing network; And providing the configuration to each server in the timing network to allow one or more other servers to obtain timing information from a single server.

Methods and systems relating to one or more aspects of the present invention are also described and claimed herein.

Additional features and advantages are realized through the techniques of the present invention. Other embodiments and aspects of the present invention are described in detail herein and are considered as part of the claimed invention.

One or more aspects of the invention are specifically pointed out and distinctly claimed as an example of the claims at the end of the specification. The above and other objects, features and advantages of the present invention will become apparent from the following detailed description with reference to the accompanying drawings.

1A illustrates an example of a hybrid, integrated timing network incorporating one or more aspects of the present invention.

1B illustrates an example of an STP-only network incorporating one or more aspects of the present invention.

2 is a diagram illustrating an example of a layer-1 configuration information block according to an aspect of the present invention.

3 illustrates an example of a new layer-1 configuration information block according to an aspect of the present invention.

4 illustrates an invalid configuration according to one aspect of the present invention.

5 illustrates a single server layer-1 configuration in accordance with an aspect of the present invention.

Figure 6 illustrates one embodiment of logic related to creating a single server layer-1 configuration in accordance with an aspect of the present invention.

7 illustrates a dual server layer-1 configuration in accordance with an aspect of the present invention.

Figure 8 illustrates one embodiment of logic related to creating a dual server configuration in accordance with an aspect of the present invention.

9 is a diagram showing a triple configuration according to an aspect of the present invention.

Figure 10 illustrates one embodiment of logic related to generating a triple configuration in accordance with an aspect of the present invention.

11A illustrates an embodiment of a layer-1 configuration modification request block in accordance with an aspect of the present invention.

11B is a diagram illustrating an embodiment of a layer-1 configuration modification response block according to an aspect of the present invention.

12A is a diagram illustrating an embodiment of a configuration change notification request block according to an aspect of the present invention.

12B illustrates an embodiment of a configuration change notification response block in accordance with an aspect of the present invention.

13A is a diagram illustrating an embodiment of a CTN ID modification request block according to an aspect of the present invention.

13B illustrates an embodiment of a CTN ID modification response block in accordance with an aspect of the present invention.

14A illustrates an embodiment of a CTN parameter read request block in accordance with an aspect of the present invention.

14B illustrates an embodiment of a CTN parameter read response block in accordance with an aspect of the present invention.

Figure 15 illustrates one embodiment of logic associated with performing recovery of a failed active layer-1 server in accordance with an aspect of the present invention.

Figure 16 illustrates one embodiment of logic associated with a dual server layer-1 configuration recovery procedure in accordance with an aspect of the present invention.

Figure 17 illustrates one embodiment of logic associated with a triple layer-1 configuration recovery procedure in accordance with an aspect of the present invention.

18A illustrates one embodiment of logic related to console tidal recovery in accordance with an aspect of the present invention.

18B is a diagram showing the configuration of the console tidal recovery results according to an aspect of the present invention.

19A illustrates an embodiment of logic related to performing triple recovery in accordance with an aspect of the present invention.

19B illustrates a layer-1 factor after stopping active layer-1 check in accordance with an aspect of the present invention.

19C illustrates a layer-1 server argument after a link to active layer-1 is lost, in accordance with an aspect of the present invention.

19D illustrates a loss of a single linkless layer-1 factor in accordance with an aspect of the present invention.

20 illustrates an embodiment of logic related to performing an active layer-1 factor in accordance with an aspect of the present invention.

Figure 21 illustrates one embodiment of logic associated with performing an active layer-1 assignment in accordance with an aspect of the present invention.

22A illustrates one embodiment of a server state request request block, in accordance with an aspect of the present invention.

Figure 22B illustrates an embodiment of a server state request response block in accordance with an aspect of the present invention.

Figure 23A illustrates an embodiment of a server state write request block in accordance with an aspect of the present invention.

FIG. 23B illustrates an embodiment of a server state write response block in accordance with an aspect of the present invention. FIG.

24 depicts one embodiment of a processing environment for incorporating and using one or more aspects of the present invention.

25 is a more detailed view of the memory of FIG. 24, in accordance with an aspect of the present invention.

26 illustrates an example of a computer program product incorporating one or more aspects of the present invention.

According to one aspect of the invention, for a timing network, a layer comprising a single active layer-1 server useful for ensuring that servers in the network synchronize their clocks using the same primary reference time. The ability to define -1 configurations is provided. Thus, each server in the network synchronizes on the same basic primary reference, and the accuracy of the synchronization does not depend on the quality of the external time source or the presence of an external time source on the layer-1 server.

In another aspect of the present invention, the layer-1 configuration is kept with other information in the layer-1 configuration information block provided to each server in the network, which is used to ensure the integrity of the server. Because each server in the network is aware of the integrity of a layer-1 server, servers that indicate synchronization to other layer-1 servers are not allowed to join the network.

In another aspect of the present invention, a recovery procedure is provided for handling a failure of an active layer-1 server of a network.

Various networks can be configured to include layer-1 servers, one of which is a Coordinated Timing Network (CTN). In an integrated timing network, a plurality of separate computing systems maintain time synchronization to form an integrated timing network. Systems in an integrated timing network use a message-based protocol called Server Time Protocol (STP) to communicate timekeeping information between systems over existing high-speed data links. This allows the clocks in each system to be synchronized to the accuracy required by today's high performance computing systems. Because this protocol uses technology within the computational system, the accuracy of synchronization varies with the progress of the technology. The computing system that provides the STP facility is referred to herein as a time server or simply a server.

The server designated as the primary time server in the CTN provides the primary reference time to the CTN. A server in CTN that determines CST (estimation of time (TOD) clock for CTN) based on information from other servers in CTN is called a secondary time server. The primary time server can obtain its time from an external time source, which provides a means to synchronize the time clock in the CTN to a defined time standard.

Servers in the CTN that are in sync are assigned a predetermined value, called a stratum level, which defines the number of servers between the server and the primary time server. The primary time server operates at a hierarchy level of one, the secondary time server operates at two or more hierarchy levels, and the hierarchy level increases as the number of servers in the timing path to Layer-1 increases. In general, the quality of time-aligned information decreases as the hierarchy level increases. Unsynchronized servers are assigned a hierarchy level of zero.

The STP facility provides the procedures necessary to send, receive and process STP messages. STP messages are sent over one or more physical data links between servers. The data link established between two servers is called an STP path. STP facilities provide the convenience of establishing and maintaining an STP path.

STP messages include message commands and message responses. Two kinds of STP messages are supported: exchange time parameter (XTP) messages and STP control (STC) messages. XTP messages are used to exchange time alignment information that is used to determine the CST of the CTN. The STP control message is used to set and modify various CTN parameters required by each server in the CTN.

The CTN can operate as one of two types of configurations, i.e., a mixed CTN configuration or an STP-only CTN configuration. In a mixed CTN configuration, the servers are configured to be part of both the STP network and the external time reference (ETR) network. In a mixed CTN configuration, the servers in the CTN are configured with the same non-null ETR network ID, and a timer (eg, IBM System Timer) provides the primary time reference for the CTN. At least one server in the CTN must step with the timing signal provided by the complex timer before synchronization occurs in the CTN. Servers that are not stepped into the system are secondary time servers and achieve synchronization by exchanging STP signals.

As an example, each server stepping with the timing signal of the multiple timer receives the time protocol parameter and propagates the information to a secondary time server in the CTN using, for example, a CTN parameter update procedure. An example of this procedure is US Patent Application No. 11 / 468,352, filed on August 30, 2006, by Carlson et al., Entitled "Coordinated Timing Network Configuration Parameter Update Procedure." This patent document is hereby incorporated by reference in its entirety.

An example of a mixed CTN configuration 100 is described with reference to FIG. 1A. Hybrid CTN configuration 100 is coupled to, for example, server A 102 coupled to local area network (LAN) 104, coupled to server B 106 coupled to local area network 104 and local area network 110. Server C 108. Each server is, for example, a central processing complex based on jet / architecture® (z / Architecture®) supplied by International Business Machines Corporation. Z / Architecture® is a registered trademark of International Business Machines Corporation, Amonk, NY. One embodiment of the jet / architecture is disclosed in IBM Publication No. SA22-7832-04 published on September 4, 2005 under the name "z / Architecture Principles of Operation." This document is incorporated herein by reference in its entirety.

Each local area network is coupled to a console 120 that is used to provide time synchronization within the network. Local area network 104 and local area network 110 are also coupled to each other through wide area network (WAN) 112.

Servers A and B are coupled to the external reference network 114, and servers B and C are configured to be part of the STP network 116. Server B is at layer-1 level and server C is at layer-2 level. STP link 118 is used to combine the STP facility of Server B with the STP facility of Server C.

In an STP-only CTN, the servers in the CTN are configured to be part of the STP network and not configured to be part of the ETR network. An example of the STP dedicated network 150 will be described with reference to FIG. 1B. In this example, server A 152 and server B 154 are coupled to LAN 156 and server C 158 is coupled to LAN 160. Each server includes an STP facility 162, and each facility is coupled to each other via one or more STP links 164.

Also, LAN 156 is coupled to console 170 and LAN 160 is coupled to console 172. Console 170 is also coupled to an external time source (ETS) 174, such as dialing out to a telephone time server (eg, ACTS: NIST automatic computer time service). There is no ETR network in this network. Server B has a hierarchy level of 1 and servers A and C have a hierarchy level of 2.

Servers that must act as active layer-1 servers in the network, such as STP-only networks, are designated as part of the layer-1 configuration defined for the network. Layer-1 configuration is maintained at each server in the network and provides information about the configuration of the network, including, for example, the type of configuration defined for the network. The network may be configured as one of various types including, for example, the following.

a) Null Configuration-Layer-1 servers are not identified in an invalid configuration. The server remains asynchronous until attached to a server with a non-null layer-1 configuration. A layer-1 configuration on a server with a hierarchy level of zero is for example when the layer-1 configuration is not attached to any other server and the single CEC-CTN indicator (described later) in the layer-1 configuration information block is zero. Same as invalid configuration.

b) Single server definition-In a single server definition, the layer-1 configuration defines a single primary layer-1 server that acts as the active layer-1 server for the CTN. Without a primary layer-1 server, there will be no synchronization time in the CTN until a new layer-1 configuration is specified from the console.

The single server layer-1 configuration may also include an indication that the designated layer-1 server is a dedicated server (eg, a computational electronic complex (CEC) or CPC) in the CTN and that there are no other servers or additional servers that are part of the CTN. Can be. When indicating that the layer-1 configuration is a single CEC CTN, the configuration is a valid layer-1 configuration for the initialization state of the server following the power-on reset. When not specifying that a single server layer-1 configuration is a single CEC CTN, the configuration is not a valid layer-1 configuration for the initialization state of the server following a power-on reset and the layer-1 configuration is set to an invalid configuration.

c) Dual server configuration-In a dual server configuration, this configuration includes a primary layer-1 server and an alternate layer-1 server. The use of a dual server configuration provides a structure of alternate servers that can take over the duties of active layer-1 servers for the CTN. Alternate layer-1 servers may take over as active layer-1 without disrupting the CTN's synchronization capability when configured with the same connection as the primary layer-1 server to other servers in the CTN. A layer-1 server (primary or alternating) that acts as an active layer-1 server for the CTN is represented in a layer-1 configuration information block maintained at each server in the CTN as described below. A layer-1 server that is not an active layer-1 server is defined as an inactive layer-1 server.

The inactive layer-1 server in a dual server configuration takes over the duties of the active layer-1 server when it detects an active layer-1 failure. Active layer-1 failures are detected in dual server configurations when one of the following occurs:

When the console assisted recovery procedure is performed to indicate that an active layer-1 failure has occurred, or

● When a layer-1 system check signal is recognized.

An inactive layer-1 server in a dual server configuration performs console assist recovery when the inactive layer-1 server loses its attachment to the active layer-1 server.

d) Triple configuration-In the triple configuration, the layer-1 configuration includes a primary layer-1 server, an alternate layer-1 server and an arbiter server. The definition of the triple configuration provides a structure that allows alternate servers to take over the duties of an active layer-1 server for the CTN as defined for dual server configurations. In addition, the definition of the coordinator server is that, when configured with connections to both the primary tier-1 and alternate tier-1 servers, the inactive tier-1 and coordinator servers communicate with each other, resulting in an inactive tier-1 server failure and an inactive tier- It provides a structure that allows 1 to determine that it should take over as an active layer-1 server.

The inactive layer-1 server of the triple configuration takes over the duties of the active layer-1 when it recognizes an active layer-1 failure. The inactive layer-1 server recognizes an active layer-1 failure when any of the following occurs.

A triple recovery procedure is performed to indicate that an active layer-1 failure has occurred.

• A console tidal restore procedure has been performed to indicate that an active layer-1 failure has occurred.

The inactive layer-1 server performs a triple recovery procedure when the following conditions occur.

Inactive layer-1 server lost attachment to active layer-1 server and attached to coordinator.

The inactive layer-1 server recognizes the active layer-1 communication timeout and attaches to the coordinator.

The inactive layer-1 server performs console assist recovery when the inactive layer-1 server loses its attachment to the active layer-1 server and is not attached to the coordinator.

The inactive layer-1 server performs the active layer-1 acquisition procedure to take over the duties of the active layer-1 server for the CTN.

The active layer-1 server in the triple configuration relinquishes the duties of the active layer-1 server when it detects that this server has lost attachments to both the inactive layer-1 server and the coordinator server. The active layer-1 server performs an active layer-1 transfer procedure to relinquish the active layer-1 server's duties to the CTN.

In one example, layer-1 configuration information is maintained in a control block called a layer-1 configuration information block (SCIB), which is stored at each server in the network or accessible to each server. SCIB is used to identify the layer-1 configuration of the network.

An embodiment of the layer-1 configuration information block 200 will be described with reference to FIG. 2. The layer-1 configuration information block 200 includes the following fields, for example.

a) Primary layer-1 node descriptor 202: This field is valid when a single server, dual server, or triple definition is specified (described later) in the configuration type field of the configuration information block; Contains the node descriptor of the node descriptor.

b) Alternate Layer-1 Node Descriptor 204: This field is valid when a dual server or triple definition is specified in the Configuration Type field and, if valid, contains the node descriptor of the Alternate Layer-1 Server Node Descriptor.

c) Coordinator Node Descriptor 206: This field is valid when a triple definition is specified in the Configuration Type field, and includes the node descriptor of the Coordinator Server Node Descriptor.

d) Layer-1 Configuration Timestamp 208: This field contains a timestamp indicating when the layer-1 configuration information in this block is current at the server.

e) Configuration Type (CType) 210: This field specifies the type of layer-1 configuration as defined below.

Invalid definition-no node descriptor is valid.

• Single server definition-Only the primary layer-1 node descriptor is valid.

● Dual server definition: Primary tier-1 and alternate tier-1 node descriptors are valid.

• Triple definition: primary layer-1, alternating layer-1, and coordinator node descriptors are valid.

f) Active Layer-1 (A) 212: This field is valid when a dual server or triple definition is specified and indicates whether the primary layer-1 server or alternate layer-1 server is an active layer-1 server. .

g) Single CEC CTN (X) 214: This field is valid when the configuration type specifies a single server definition, e.g. 1, indicates that the CTN is a single CEC CTN. For example, when the field is zero, the CTN is not a single CEC CTN.

h) Recovery Configuration (R) 216: This field indicates whether the layer-1 configuration depicted by this block is the result of a layer-1 recovery operation or a console command.

i) Layer-1 Maximum Short Term Skew Rate Variation 218: This field indicates the maximum possible change in the skew rate of the physical oscillator at a layer-1 server that may occur during any given period (eg 60 seconds). Contains a predetermined value specifying. This field is used to form a value that is in the same format as the base-steering rate.

On machines that are unable to perform dynamic oscillator switching, this value is equal to the maximum layer-1 oscillator frequency drift that can occur over a specified period (eg 60 seconds). On machines capable of performing dynamic oscillator switching, this value is set to the skew tolerance of the maximum range specified for the oscillator. For example, on a machine that supports dynamic oscillator switching with an oscillator skew tolerance of +/- 2 ppm over a nominal frequency, the value is set equal to 4 ppm. Dynamic oscillator switching occurs when the physical oscillator used to drive the system TOD clock is switched from one oscillator to another.

In addition to the control block, another control block called a new layer-1 configuration information block (NSCIB) may be used to designate a new layer-1 configuration for the CTN. In addition, this control block can be used to specify an update to a CTN ID that should occur simultaneously with the layer-1 configuration change.

As one example, the NSCIB at the server is meaningful when the server is configured to be part of an STP-only CTN configuration or if the STP-migration bit of the NSCIB is one.

An embodiment of the new layer-1 configuration information block 300 is described with reference to FIG. 3. The new layer-1 configuration information block 300 includes the following fields, for example.

a) Primary Layer-1 Node Descriptor 302: This field is valid when a single server, dual server or triple definition is specified in the configuration type field and contains the node descriptor of the new primary layer-1 node descriptor.

b) Alternate Layer-1 Node Descriptor 304: This field is valid when a dual server or triple definition is specified in the Configuration Type field, and includes the node descriptor of the new alternate layer-1 node descriptor.

c) Coordinator Node Descriptor 306: This field is valid when a triple definition is specified in the Configuration Type field, and includes the node descriptor of the new Coordinator Node Descriptor.

d) Layer-1 Configuration Update Time 308: When the server is configured to be part of an STP-only CTN, this field contains a timestamp indicating when the values in this block are current for the CTN.

e) Configuration Type (CType) 310: This field specifies the type of layer-1 configuration as defined below.

Invalid definition-no node descriptor is valid.

• Single server definition-Only the primary layer-1 node descriptor is valid.

● Dual server definition: Primary tier-1 and alternate tier-1 node descriptors are valid.

• Triple definition: primary layer-1, alternating layer-1, and coordinator node descriptors are valid.

f) Active Layer-1 (A) 312: This field is valid when a dual server or triple definition is specified and indicates whether the primary layer-1 server or alternate layer-1 server is an active layer-1 server.

g) Change CTN ID (C) 314: When the server is configured to be part of an STP-only CTN, this field indicates whether a CTN ID change is required and whether the CTN ID is valid. This change occurs at layer-1 configuration update time.

CTN ID is a value used to identify the CTN. The CTN ID includes, for example, an STP network ID and an ETR network number. The STP network ID identifies the STP network, if any, configured for the server. The ETR network number identifies the ETR network number, if any, configured for this server.

h) STP migration configuration (S) 316: This field is meaningful when the server is not configured as an STP-only CTN, for example. This field indicates whether an STP-only migration layer-1 configuration is defined for the server. When the field is eg 1, the NSCIB includes a layer-1 configuration that should be current when the CTN ID at the server is modified to an STP only configuration. When the field is zero, for example, the STP dedicated migration layer-1 configuration is not defined for the server.

i) Single CEC CTN (X) 318: This field is valid when the configuration type specifies a single server definition, eg, when 1, indicates that the CTN is a single CEC CTN. For example, when the field is zero, the CTN is not a single CEC CTN.

j) Recovery Configuration (R) 320: This field indicates whether the layer-1 configuration depicted by this block is the result of a layer-1 recovery operation or a console command.

k) Layer-1 maximum short term skew rate change 322: This field specifies the maximum possible change in skew rate of the physical oscillator at a new layer-1 server that may occur during any given period (e.g. 60 seconds). It contains a predetermined value.

l) New CTN ID 324: This field is valid when the CTN-ID Change Indicator specifies a CTN ID Change Request and a valid CTN ID. This field specifies a new CTN ID.

If a new layer-1 configuration information block is not used to designate an update to a CTN ID, this block may not contain, for example, a CTN ID change bit or a new CTN ID.

The layer-1 configuration is initialized to an invalid configuration on the server when the machine is initially powered on. An example of an invalid configuration is shown in FIG. As shown, the invalid configuration 400 includes a plurality of servers 402 coupled to each other via one or more STP links 404. In this example, the hierarchy level of each server is zero, so there are no active layer-1 servers. However, the CTN ID is set to a special value which is set in this example using the local CTN ID modification console command (described later).

CTNs with an invalid layer-1 configuration cannot be synchronized because layer-1 is not specified and there is no reference time for the CTN. The layer-1 configuration for the CTN can be reset from an invalid configuration to an invalid configuration through a command such as a layer-1 configuration modification command described later.

Single server layer-1 may be generated from invalid configurations. The single server layer-1 configuration specifies a single layer-1 server and no alternate layer-1 or coordinator servers. An example of a single server layer-1 configuration is shown in FIG. As shown, the single server layer-1 configuration 500 includes a plurality of servers 502 coupled to each other via one or more STP links 504, where one of the servers, for example server A, is active. It is selected as the primary layer-1 server. Thus, server A has an indication of primary-S1, and its hierarchical level is equal to one. It should be noted that other servers have a hierarchy level greater than one, for example two or three.

One embodiment of logic associated with a single server layer-1 configuration is described with reference to FIG. Initially, the console issues a command, such as a modify layer-1 configuration command, to server A to specify a single server layer-1 configuration with server A as the primary layer-1 server (step 600).

Server A then indicates that the new Layer-1 configuration is current (step 602). In this example, server A issues a configuration change notification command to the console to provide this indication.

The other servers in the network then recognize the availability of the clock source and obtain the current layer-1 configuration and time control parameters for the CTN (step 604). As one example, this is performed by a server issuing a CTN Parameter Read STP control message to the clock source to obtain the current layer-1 configuration and time control parameters for the CTN.

In addition, the servers issue a configuration change machine check as an example to indicate the new layer-1 configuration (step 606). Servers also indicate timing state changes (synchronized available clock sources), for example by issuing a timing alert external interrupt. This ends the processing associated with generating a single server layer-1 configuration from the invalid configuration.

In addition to the foregoing, a dual server configuration can be created from existing invalidated configurations. The dual server layer-1 configuration specifies primary and alternating layer-1 servers, one of which can act as an active layer-1 server for the CTN. The server acting as a layer-1 server may be designated by the console when the layer-1 configuration is created and modified by the console at any time.

An example of a dual server layer-1 configuration is shown in FIG. As shown, server A 700 is represented as primary and the hierarchy level is equal to one. Server C 702 is marked as alternating and has a hierarchical level equal to two. Servers B 704 and D 706 have a hierarchical level equal to two and server E 708 has a hierarchical level equal to three.

One embodiment of logic associated with creating a dual server configuration is described with reference to FIG. Initially, the dual server hierarchy configuration specifies that server A is primary and active and server C is alternate (step 800). As one example, this is performed by the console issuing a layer-1 configuration modify command to server A.

Next, it is determined whether the force change bit in the layer-1 configuration modification command is zero (step 802). If 0, server A verifies that the validity change bit was attached directly to server C (step 804). As an example, this part is verified by exchanging messages with server C. If the verification result indicates that server A is directly attached to server C (step 806), server A plans to update the layer-1 configuration at step CTN (step 808), and an update occurs (step 809). Server A also issues a configuration change notification command to the console as a new layer-1 configuration as an example (step 810). Servers in the network also issue a configuration change machine check in response to the new layer-1 configuration being current (step 812).

Returning to step 802, if the validity change bit is set to 1, processing proceeds to step 808 where server A plans to update the layer-1 configuration in the CTN.

Returning to step 806, if server A is not attached to server C, the command is rejected (step 814) and the process ends.

In addition to creating a dual configuration from an existing invalid configuration, a triple configuration can also be generated from an existing invalid configuration. The triple tier-1 configuration specifies a primary tier-1 server, an alternate tier-1 server, and a coordinator server. One of the designated primary server and the alternate server may act as an active layer-1 server for the CTN. The server acting as the layer-1 server designated by the console at the time the layer-1 configuration is created may be modified by the console at any time. The coordinator server is used to help determine when the active layer-1 server is no longer part of the CTN.

An example of the triple configuration is shown in FIG. As shown, server A 900 is a primary tier-1 server and has a hierarchical level of one. Server C 902 is an alternate tier-1 server with a hierarchy level of 2 and server B 904 is also a coordinator server with a hierarchy level of 2. Server D 906 also has a hierarchical level of 2 and server E 908 has a hierarchical level of 3.

One embodiment of logic related to the generation of a triple configuration is described with reference to FIG. Initially, the console specifies a triple configuration, for example by issuing a layer-1 configuration modification command to server A, where server A is an active primary layer-1 server, server C is an alternate layer-1 server, and server B is Coordinator server (step 1000).

Next, it is determined whether the validity change bit in the layer-1 configuration modification command is zero (step 1002). If 0, server A verifies that the validity change bits are directly attached to servers C and B (step 1004). If server A has been directly attached to servers C and B (step 1006), server A plans a layer-1 configuration update at step CTN (step 1008), and an update occurs (step 1009). Server A also issues a configuration change notification command to the console in response to the new layer-1 configuration being current (step 1010). The servers then issue a configuration change machine check when the new layer-1 configuration is current (step 1012).

Returning to step 1002, if the change bit is equal to 1, connection verification is not performed, and processing proceeds to step 1008, where server A plans a layer-1 configuration update at CTN.

If the connection verification fails (step 1006), the command is rejected (step 1014) and the processing ends.

As mentioned above, various instructions are utilized when generating an invalid configuration. One such command is a layer-1 configuration modification command, which is used to specify a change to a layer-1 configuration for CTN. The command request includes a new layer-1 configuration information block that specifies how to modify the layer-1 configuration.

An embodiment of the layer-1 configuration modification command request block 1100 is described with reference to FIG. 11A. As an example, the layer-1 configuration modify command request block includes the following fields.

a) Length field 1102: This field indicates the length of this request block.

b) Command Code 1104: This field specifies a layer-1 configuration modify command.

c) command transaction number 1106: This field contains the value associated with the issue of the command. The command processing number is returned in the response block for the command.

d) CTN ID 1108: This field contains the CTN ID of the CTN targeted for the command.

e) Change Validity (F) 1110: This field indicates whether configuration verification should be performed for the command.

f) New Layer-1 Configuration Information Block 1112: This field contains a new Layer-1 configuration information block for CTN.

An embodiment of a response block for the layer-1 configuration modification command is described with reference to FIG. 11B. As an example, the layer-1 configuration modification response block includes the following fields.

a) Length 1152: This field contains the length of the command response block.

b) Response code 1154: This field contains a response code for the command.

c) Command Processing Number 1156: This field contains the value provided in the Command Processing Number field of the Command Request Block.

Referring to the operation, if the command specifies a new active layer-1 server for the CTN, the command is issued for the server designated as the active layer-1 server in the NSCIB. If the command is not issued for that server, the global command reject response code is returned. The new active layer-1 server issues a configuration change notification command asynchronously after the update is made in the CTN. When a command is issued for a server in a mixed CTN, the migration (S) field of the NSCIB is set to one. This field indicates that layer-1 configuration should be done when the CTN configuration is changed from mixed CTN to STP only configuration.

The command request block includes a field indicating whether configuration verification should be performed for that command. The Validity Change field is set to 1, for example, to indicate that the command should be performed without configuration verification. The Validity Change field is set to 0, for example, to indicate that the following configuration verification check should be performed before accepting the command.

If an invalid configuration is specified, it verifies that the receiving server is not a layer-0 server. The validity change field must be set to 1 to configure a layer-0 server as an active layer-1 server.

If a dual configuration is specified, the receiving server verifies the following:

If the receiving server is designated as the primary layer-1 server, this ensures that the receiving server is attached to the alternate layer-1 server.

If the receiving server is designated as an alternate layer-1 server, this ensures that the receiving server is attached to the primary layer-1 server.

If a triple configuration is specified, the receiving server verifies the following:

If the receiving server is designated as the primary layer-1 server, this ensures that the receiving server is attached to the alternate layer-1 server and the coordinator server.

If the receiving server is designated as an alternate layer-1 server, this ensures that the receiving server is attached to the primary layer-1 server and the coordinator server.

If the verification check fails, the command is not accepted and a response code is reported.

The other command described above is a configuration change notification (CCN) command. The configuration change notification command is used to notify the console of a specific configuration change in the CTN. This command is issued by servers in the network after configuration is done in the CTN. This command is issued for configuration parameter changes such as, for example, a layer-1 configuration change, a layer-1 configuration change and a CTN ID change, and / or a CTN ID change.

The configuration change occurs as a result of a layer-1 configuration modification command, as a result of the overall CTN ID modification command or as a result of a CTN recovery operation that causes a change in the active layer-1 server for the CTN.

An example of the command request block 1200 for a configuration change notification command will be described with reference to FIG. 12. In one embodiment, the command request block 1200 includes the following.

a) Length 1202: This field contains the length of the instruction block.

b) Command Code 1204: This field contains the specification of the configuration change notification command.

c) Command Processing Number 1206: This field contains a value associated with issuing the command. The command processing number is returned in the response block for the command.

d) CTN ID 1208: This field contains the CTN ID of the server sending the command.

e) Change Code: This field contains a code specifying the reported configuration change. This field indicates the following, for example.

• Layer-1 configuration change: The layer-1 configuration is changed as indicated by the current layer-1 configuration block.

● Layer-1 configuration change and CTN ID change: The layer-1 configuration and CTN ID are changed as indicated by the current layer-1 configuration block and the CTN ID field.

● Change of CTN ID only: The CTN ID is changed as indicated by the CTN ID field.

f) Reason code: This field contains a code that specifies the reason why a layer-1 configuration change is reported. This field is valid when a layer-1 configuration change is indicated in the change code and, for example, indicates one of the following.

• Layer-1 configuration modifications: Layer-1 configuration modifications are the result of a layer-1 configuration modification command.

Restore: Layer-1 configuration changes are the result of an STP facility recovery operation.

g) Current Layer-1 Configuration Information Block: This field contains the current layer-1 configuration information block for the server.

One embodiment of a command response block 1250 for a configuration change notification command is described with reference to FIG. 12B. In one embodiment, the command response block 1250 includes the following.

a) Length 1252: This field specifies the command response block length.

b) Response code 1254: This field contains a response code for the command.

c) Command Processing Number 1256: This field contains the value provided in the Command Processing Number field of the Command Request Block.

Another command that can be performed is a CNT ID modification command used to perform a local or global CTN ID change. This command can be used to modify the STP network ID component, the ETR network ID component, or both components of the CTN ID of the CTN. The validity indicator of the request block indicates which component of the CTN ID should be modified. The global command parameter of the request block specifies whether the command is a general command or a local command.

An example of the command request block 1300 for the CNT ID modification command will be described with reference to FIG. 13A. The CTN ID modification request block 1300 includes the following items, for example.

a) Length 1302: This field contains the instruction block length.

b) Command Code 1304: This field specifies a CTN ID modification command.

c) Command Processing Number 1306: This field contains the value associated with the command issuance. The command processing number is returned in the response block for the command.

d) CTN ID 1307: This field, when valid, contains the CTN ID of the CTN targeted for the command. The CTN ID is valid when the total CTN update indicator is eg 1 and must match the current CTN ID of the receiving server, otherwise a CTN ID mismatch error is recognized. This field is invalid and ignored when the total CTN update indicator is 0, for example.

e) Global CTN Update (G) 1308: This field indicates whether the command is a global update or a local update. When the command is a local update, this command is performed only at the receiving server. When the command is an aggregate command, it must be issued against the active layer-1 server.

f) New STP Network ID Valid (SV) 1310: This field indicates whether the new STP Network ID field is valid. If not valid, the STP network ID portion of the CTN ID is not modified by the command.

g) New ETR Network ID Valid (EV) 1312: This field indicates whether the new ETR Network ID field is valid. If not valid, the ETR network ID portion of the CTN ID is not modified by the command.

h) New STP network ID 1314: When the SV indicator is valid, this field contains the new STP network ID.

i) New ETR Network ID 1316: When the EV indicator is valid, this field contains the new ETR Network ID.

j) ETR Port 0 Manual Port Status 1318: When the EV indicator is valid, this field contains a manual port status code that specifies the intended status of ETR Port 0.

k) ETR Port 1 Manual Port Status 1320: When the EV indicator is valid, this field contains a manual port status code that specifies the intended status of ETR Port 1.

An embodiment of a command response block 1350 for a CTN ID modify command is described with reference to FIG. 13B. In one embodiment, the CTN ID modification command response block 1350 includes, for example, the following.

a) Length 1352: This field contains a value specifying the command response block length.

b) Response Code 1354: This field contains a response code for the command.

c) Command Processing Number 1356: This field contains the value provided in the Command Processing Number field of the Command Request Block.

As an example, if a CTN ID modification is issued as a local CTN update, the STP facility performs the update immediately and no configuration change notification command is issued to the console. In addition, if a CTN ID modification is issued as a total CTN update, the active layer-1 server issues a configuration change notification command to the console when the update is current.

If a CTN ID modification is issued as a total CTN update, the STP facility performs a CTN parameter update procedure to plan the CTN modification operation on each server of the CTN. The planned update time is set to a value that ensures that each server in the CTN receives the update information before the planned update time. The specified response code indicates that the operation was planned successfully in the CTN.

When an update is planned at the server, the server stores the planned parameter update information in console disk storage. In addition, when the parameter update is current at the server, the server stores the updated CTN parameter in console disk storage.

As one example, a command called a save CTN parameter command is issued by the server to store information. This command may include, for example, a command processing number as well as a length and command code field; CIIB; An STP facility enable indicator indicating whether the STP facility is enabled; A local clock source indicator indicating whether the server is designated as a local clock server; An active oscillator identifier identifying an oscillator that is active at the time of the save command; NCIIB; SCIB; A layer-1 based steering rate that includes the basic steering rate of the server when the server operates as a layer-1 server; NSCIB; PCSIB; TCPIB; LSOIB; A save timestamp indicating when the save command was issued; Oscillator identifier 0; Computed oscillator skew 0; Oscillator identifier 1; And a request block having an calculated oscillator skew 1 field. Many of these fields are described later with reference to FIG. 14B. The command response block for a command includes, for example, a length, a response code, and a command processing number.

Local CTN ID changes occur at the server as a result of CTN ID modification console commands issued as local commands. As an example, the server receiving the Modify CTN ID console command immediately makes a specified change to the CTN ID at the server (an example), leaving all established STP paths on the server uninitialized, and then at the STP length. Establish initiatives to perform initialization A configuration change machine check condition is generated when a CTN ID change occurs.

The total CTN ID update occurs at the server at the CTN ID update time specified in the new CTN ID block. The server makes a change to the CTN ID at the specified update time. After that change, the server does not recognize the CTN ID mismatch error that occurs as a result of the mismatch between the new CTN ID value and the old CTN ID value for the same period as the synchronization check threshold. CTN ID mismatch errors that occur as a result of mismatches other than between the new CTN ID value and the old CTN ID value are not ignored during this period. A configuration change machine check condition is generated when a CTN ID change occurs.

The active layer-1 server issues a configuration change notification console command after the CTN ID update that occurs as a result of the overall CTN ID update.

In addition to the above-described commands, the STP console interface includes commands for reading STP timing and configuration information from the server. The information provided by the read command is made available via the console display. An example of an instruction request block 1400 for a CTN parameter read command is described with reference to FIG. 14A. As an example, the CTN parameter read command request block 1400 includes, for example, the following.

a) Length 1402: This field contains a value specifying the instruction block length.

b) Command Code 1404: This field contains a value that designates a CTN parameter read command.

c) Command Processing Number 1406: This field contains the value associated with the command issuance. The command processing number is returned in the response block for the command.

One embodiment of a command response block 1450 for a CTN parameter read command is described with reference to FIG. 14B. As an example, the response block 1450 includes the following.

a) Length 1452: This field is used to indicate the command response block length.

b) Response Code 1454: This field contains a response code for the command.

c) Command Processing Number 1456: This field contains the value provided in the Command Processing Number field of the Command Request Block.

d) CTN ID Information Block 1458: This field contains a CTN ID Information Block (CIIB) for the server.

In one embodiment, the CTN ID information block includes a CTN ID for a server and code that specifies the status of ETR ports 0 and 1 in an invalid ETR network.

e) Maximum STP Version 1460: This field contains a value indicating the maximum STP version number supported by the server.

f) Active STP Version 1462: This field contains a value indicating the STP Version number currently active on the server.

g) Maximum Timing Hierarchy Level 1464: This field contains a value that specifies the maximum hierarchical level at which the server can be set in sync. Servers with layers greater than the maximum timing tier level are in an asynchronous timing state and an unusable clock source state.

h) Maximum Hierarchy Level 1466: This field contains a value that specifies the maximum hierarchical level that can be set for any server in the CTN.

i) Local Clock Source (L) 1468: This field specifies whether the server is designated as a local clock server.

j) STP Clock Source Status (C) 1470: This field specifies the clock source status of the server.

k) Active Oscillator (A) 1472: This field identifies the oscillator that is considered active by the STP facility.

l) Timing Mode (TMD) 1474: This field specifies the timing mode of the server.

m) STP Timing State (TST) 1476: This field specifies the timing state at the server.

n) CTN Type (CTNT) 1478: This field contains a code specifying the type of timing network configured at the server. Exemplary types include the following.

● No CTN defined: The server is not configured for appending to the CTN.

• STP Dedicated Timing Network: The server is configured for attachments to CTNs containing only STP networks.

Hybrid timing network: The server is configured for attachment to a CTN that includes both STP and ETR networks.

o) Hierarchy 1480: This field contains a value indicating the hierarchical level of the server.

p) New CTN ID Information Block (NCIIB) 1482: This field contains a new CIIB for the server. The new CTN ID update time is stored in Universal Time Coordinated (UTC) format.

As one example, the new CTN ID information block may include a new CTN ID; ETR Port 0 Manual Port Status; ETR Port 1 Manual Port Status; And a new CTN ID update time, which is, for example, a timestamp indicating when the new CTN ID should be current.

q) Current Layer-1 Configuration Information Block (SCIB) 1484: This field contains the current Layer-1 configuration block for the server.

r) New Layer-1 Configuration Information Block (NSCIB) 1486: This field contains a new Layer-1 configuration block for the server.

s) PRT (Primary Reference Time) Corrected Steering Information Block (PCSIB) 1488: This field contains the PCSIB for the server.

As an example, the PRT correction steering information block includes the following.

1. PRT Corrected Steering Rate Start Time: This field contains a timestamp indicating when the PRT corrected steering should start.

2. PRT Source Identifier: This field contains the source identifier at the primary reference.

3. Console dispersion: This field contains the console dispersion provided.

4. UTC variance: This field contains the provided UTC variance.

5. PRT Offset: This field contains the provided primary reference time offset.

6. PRT Timestamp: This field contains a timestamp corresponding to the provided PRT Timestamp.

t) Timezone Control Parameter Information Block (TCPIB) 1490: This field contains the TCPIB for the server. The new TZIB update time and the new DST offset update time are converted to UTC timestamp format.

As an example, the time zone control parameter information block includes, for example, the following items.

1. Active Local Time Code: This field contains a value that identifies whether the local time setting is in effect for the CTN, and if so, how its value is obtained. Examples include the following.

● No local time specified. The time zone offset and the DST offset are both zero.

● ATZIB valid with auto update-ATZIB is valid and specifies the local time setting for the CTN. The Active DST Offset, New DST Offset, and New DSTO Update Time fields of the TCPIB are valid and set based on the DST-on and DST-off algorithms in ATZIB. The TTO field is not valid.

● ATZIB valid without automatic update-ATZIB is valid and specifies a time zone offset for the CTN. None of the DST-on and DST-off algorithms specified in ATZIB are used. The active DST offset, new DST offset and new DSTO update time fields are valid. Use the set DST offset console command to modify the new DSTO update time and specify whether the local time should be standard time or DST when the update is current. The TTO field is not valid.

TTO field valid-The TTO field is valid and specifies the local time offset of the CTN and includes both time zone offsets and any daylight saving time offsets. The ATZIB, Active DST Offset, New DST Offset, and New DSTO Update Time fields are not valid.

2. New Local Time Code: This field contains a value that identifies whether a new TZIB is pending for the CTN. Examples include the following.

● No new local time specified.

● NTZIB valid with automatic update-NTZIB and NTZIB update times are valid and specify new time settings for the CTN. The new TZIB becomes current at the new TZIB update time. The active DST offset, new DST offset, and new DSTO update time are set based on the DST-on and DST-off algorithms provided in NTZIB when NTZIB is current.

● NTZIB valid without automatic update-The NTZIB and NTZIB update time fields are valid and specify the time zone and DST offset that should be current at the new TZIB update time. The DST-on and DST-off algorithms specified in TZIB are not used.

3. New TZIB DST (D): This field is valid when the new local time code is equal to a value indicating TZIB valid without automatic DST update, and the local time of the CTN must be set to daylight saving time when NTZIB is current. Indicates whether or not local time should be set to standard time when NTZIB is current.

4. Total Time Offset: This field, if valid, specifies the total time offset in effect at the STP facility as a result of the DST offset and time zone offset in effect at the server. This field is valid when the active timecode specifies the TTO field.

5. Active Time Zone Information Block (ATZIB): This field contains the Time Zone Information Block (TZIB) currently in effect at the server.

As an example, TZIB includes the following.

aa) Time Zone Algorithm Number: This field identifies the time zone algorithm number for this entity.

bb) Time zone offset: This field contains a value indicating a time zone different from UTC.

cc) Daylight Saving Time (DST) Offset: This field contains a value indicating the DST offset to be applied when daylight saving time is running. The time and date at which the DST offset is active for the CTN is specified by the DST-on algorithm. The time and date at which the DST offset for the server should be set to zero is specified by the DST-off algorithm.

dd) Standard Time Name: This field identifies the time zone when the DST offset is not implemented.

ee) Daylight Saving Time Name: This field identifies the time zone when the DST offset is performed.

ff) DST-on time name: This field specifies the algorithm used to calculate the date and time the DST offset should be applied. The offset is automatically applied when an automatic DST plan is run against the server.

gg) DST-Off Time Name: This field specifies the algorithm used to calculate the date and time the DST offset should be removed. Offsets are automatically removed when an automatic DST plan is run against the server.

6. New Time Zone Information Block (NTZIB): This field contains a time zone information block that, when valid, must replace the ATZIB starting at the time specified by the NTZIB update time.

7. Active Daylight Saving Time Offset (DSTO): This field contains a value indicating the DST offset currently running on the server.

8. New Daylight Saving Time Offset (NDSTO): This field contains a value specifying the offset at which the active DSTO should be replaced, starting at the time specified by the new DSTO update timestamp.

9. New TZIB Update Time: This field contains a timestamp that specifies when the new TZIB offset will take effect.

10. New DSTO Time: This field contains a timestamp that specifies when the new DST offset will take effect.

u) Leap Second Offset Information Block (LSOIB) 1492: This field contains the LSOIB for the server. The new LSO update time is converted to UTC timestamp format.

As an example, the leap second offset information block includes the following items, for example.

1. Active leap second offset (P) provided: This field indicates that the active leap second offset includes the value provided by the operator, for example when set to one. When this field is zero, for example, the active leap second offset contains the machine initialization value and has not been set by the operator.

2. Active Leap Second Offset (LSO): This field contains a value indicating the number of leap seconds currently running in the STP facility.

3. New Leap Second Offset (LSO): This field contains a value indicating the number of leap seconds that become active at the time specified by the LSO update time.

4. New Leap Second Offset (LSO) Update Time: This field contains a timestamp that specifies when the new leap second offset should be executed.

v) Oscillator Identifier 0 (1494): This field contains the identifier of Oscillator 0.

w) Computed Oscillator Skew 0 (COS0) 1496: This field contains a value that specifies the computed skew with respect to the nominal frequency of oscillator 0 installed in the server.

x) Oscillator Identifier 1 (1498): This field contains the identifier of Oscillator 1.

y) Computed Oscillator Skew 1 (COS1) 1499: This field contains a value specifying the computed skew with respect to the nominal frequency of Oscillator 1 installed in the server.

In one aspect of the invention, the information is used to ensure the integrity of the servers of the integrated timing network. This information is propagated to each server in the network. Servers on the network acquire the configuration, understand the configuration, and follow the same configuration. In one embodiment, the server cannot operate for more than a predetermined amount of time (e.g., freewheel period) without knowing the layer-1 configuration. If the server wants to join the network, the server obtains and uses this information. This information provides additional information as well as the status of the CTN.

According to another aspect of the present invention, the ability to configure alternate servers as part of a layer-1 configuration of an integrated timing network to function as an active layer-1 server in the event of a failure in the active layer-1 server. This prevents a single point of failure of the CTN so that the servers in the CTN can maintain or gain synchronization within the timing network despite the failure of the active layer-1 server.

As mentioned above, a layer-1 configuration may be defined to specify primary and alternating layer-1 servers for the CTN. The primary server typically acts as an active layer-1 server for the CTN and the alternate server acts as a backup server and is called an inactive layer-1 server. If the inactive layer-1 server detects a failure of the active layer-1 server, it indicates that the inactive layer-1 server has taken over its duties as the active layer-1 server of the CTN (eg, via the CTN parameter update procedure). Notify the CTN and drive the CTN based on its own time clock. A failed layer-1 server is set to layer-0 and can rejoin the network after recovery, but is not rejoined as a layer-1 server in this embodiment. Also, as an example, if the primary server rejoins the CTN as a layer-2 server, the primary server takes over the duties of the backup layer-1 server. The console may instruct the primary server to resume its role as the active layer-1 server of the CTN if desired.

An embodiment of logic related to failure detection and recovery of an active layer-1 server is described with reference to FIG. 15. Initially, the inactive layer-1 server detects a failure of the active layer-1 server (step 1500). Detecting a failure of an active layer-1 server includes, for example, a method of receiving a layer-1 system check signal (SCS); Via console assistance recovery, including communication with the console to determine if the active layer-1 server has entered a check stop or power off state; And triple recovery using a third party coordinator server to expel active layer-1 servers. This fault detection technique is described in detail later.

In response to detecting the active layer-1 failure, the inactive layer-1 server performs a takeover procedure (step 1502). In addition, if the active layer-1 server detects that it has entered a failure state (step 1504), the active layer-1 server performs a transfer procedure to relinquish its duties as the active layer-1 server of the CTN (step) 1506).

As an example, steps 1500 and 1502 performed by the inactive layer-1 server may be performed substantially in parallel with steps 1504 and 1506 performed by the active layer-1 server.

More details regarding fault detection and error recovery are described below with reference to various procedures based on the type of configuration. For example, layer-1 server recovery is performed only when alternate layer-1 servers are designated in the system-1 configuration of the CTN. Shifts are specified in both dual servers and triple configurations. Thus, recovery procedures are provided for both dual server layer-1 configuration recovery and triple layer-1 configuration recovery. This will be explained later on.

In dual layer-1 configuration recovery, an inactive layer-1 server in a dual server configuration takes over the duties of an active layer-1 server in response to an active layer-1 failure detection. One embodiment of logic for dual layer-1 configuration recovery is described with reference to FIG. Initially, the inactive layer-1 server detects a failure of the active layer-1 server (step 1600). Active layer-1 failure is detected in a dual server configuration, for example, when a console assistance recovery procedure is performed indicating that an active layer-1 failure has occurred or when a layer-1 system check signal is recognized. Each case will be described later.

In response to the detection of an active layer-1 server failure, the inactive layer-1 server performs an active layer-1 takeover procedure to take over the duties of the active layer-1 server of the CTN (step 1602). This completes the process of dual server layer-1 configuration recovery.

In addition to dual server layer-1 configuration recovery, triple layer-1 configuration recovery is provided. One embodiment of logic for triple layer-1 configuration recovery is described with reference to FIG. Initially, the triple layer inactive layer-1 server recognizes an active layer-1 failure (step 1700). For example, an inactive tier-1 server may have an active tier when a triple recovery procedure has been performed to indicate that an active layer-1 failure has occurred, or when a console assisted recovery procedure has been performed to indicate that an active layer-1 failure has occurred. -1 Recognize a fault.

In response to the detection of an active layer-1 failure, the inactive layer-1 server performs an active layer-1 takeover procedure to take over the duties of the active layer-1 server of the CTN (step 1702). The active layer-1 server also relinquishes the duties of the active layer-1 server in response to the detection that it has lost attachment to both the inactive layer-1 server and the coordinator server (step 1704). The active layer-1 server performs an active layer-1 assignment procedure to relinquish the active layer-1 server's duties in the CTN (described later).

Further, the inactive layer-1 server may be configured, for example, if the inactive layer-1 server loses attachment to the active layer-1 server and attaches to the coordinator; And / or perform a triple recovery procedure when the inactive layer-1 server recognizes the active layer-1 communication timeout and is attached to the coordinator (step 1706). The active layer-1 communication timeout is detected 2 seconds before the end of the freewheel interval of the CTN, for example, and causes the layer-1 factor to occur before a sync check condition is detected in the CTN. For more information on freewheel spacing, see US Application No. 11 / 468,352, filed on August 30, 2006, by Carlson et al., Entitled "Coordinated Timing Network Configuration Parameter Update Procedure." And the entire contents of this document are incorporated herein by reference.

In one embodiment, if triple recovery fails (step 1707), the inactive layer-1 server of the triple configuration performs dual server recovery as described with reference to FIG. 16 (step 1708). However, if triple recovery is successful, dual server recovery is bypassed. This completes the process of triple layer-1 configuration recovery.

More details about the various procedures performed during recovery are described later.

For example, one technique for detecting a failure at an active layer-1 server is to receive a layer-1 system check signal (SCS) at an inactive layer-1 server. This layer-1 system check signal indicates to the inactive layer-1 server of the dual server CTN configuration that it has entered a state that prevents the active layer-1 server from continuing to operate as the active layer-1 server of the CTN.

The inactive layer-1 server recognizes the SCS when it detects that the active layer-1 server has terminated the STP connection to the inactive layer-1 server. Inactive layer-1 detects that the active layer-1 server has terminated the STP connection when an offline signal is received on the last path of the STP path group associated with the active layer-1 server.

The active layer-1 server recognizes that the active layer-1 server has issued an SCS when it has closed all connections to the inactive layer-1 server. The active layer-1 server thinks that all STP connections to the inactive layer-1 server are terminated when an offline signal is sent to the last path in the STP path group associated with the inactive layer-1 server.

Another technique for detecting a failure is the console assistance recovery procedure, which is initiated by an inactive layer-1 server in a dual server or triple configuration to determine the status of the active layer-1 server. This procedure uses the information provided by the console to determine whether an active layer-1 fault condition exists.

One embodiment of logic associated with the console assistance recovery procedure is described with reference to FIG. 18A. Initially, the inactive layer-1 server requests server status (step 1800). In particular, the inactive layer-1 server issues an STP origination request server status console command with the node descriptor field of the same command request block as the node descriptor of the active layer-1 server. In response to the console receiving this request, the console attempts to communicate with the active layer-1 server to determine the status of the active layer-1 server.

After attempting to determine the status of the active layer-1 server, the console issues a write server status console command to the inactive layer-1 server and sets the status code of the request block to the best known state of the active layer-1 server (step 1804). ). If the inactive layer-1 server receives a recording server status console command indicating that the layer-1 server is in the check stop or power off state, the inactive layer-1 server recognizes the active layer-1 condition (step 1806). .

More details regarding an example of console assistance recovery will be described with reference to the configuration shown in FIG. 18B. As an example, in a dual server configuration, console assist recovery is performed by the inactive layer-1 server when the inactive layer-1 server detects an accessory server communication error to the active layer-1 server. In the following example, the active layer-1 server has entered a check state. The following operations are performed during console assistance recovery in the configuration of FIG. 18B.

1. Server D 1850 detects an accessory loss for Server A 1852.

2. Server D issues a request server status command to the console to request the status of server A.

3. The console queries Server A to determine its operating state.

4. The console issues a recording server state to server D indicating whether server A is in an active state (stop checking or powering off) or whether the operating state is unknown.

5. If server A is in an active state or its state is unknown, server D repeats the request server status command.

6. If the state of server A is inactive, server D performs a CTN parameter update procedure to plan a new layer-1 configuration to set itself as an active layer-1 server.

As one example, the integrated timing network parameter update procedure updates CTN parameters simultaneously in the timing network. As an example, the update procedure includes selecting one or more timing parameters to change and constructing an information response packet including the parameter to be changed and when the change should be made. The packet is then broadcast to other servers in the network. The receiving server determines whether communication with the clock source has been lost. This is typically accomplished by periodically receiving timing messages from nodes in the network used as clock sources. If it is determined that the loss of communication has lasted too long (this is defined earlier than the specified time in the network, it is a function of the maximum drift rate of the clock at the server relative to the clock of the server clock source, for example), and the receiving server has its timing parameter Declares that is not valid. To proceed, the server acquires a new timing parameter. If it is not too long, the timing parameter is still valid and the parameter is updated with the proposed future time at every server in the network.

7. When the layer-1 configuration change is executed, server D issues a configuration change notification to the console.

8. Server C 1854 is changed to Layer-3; Server F 1856 is changed to layer-2.

9. Configuration Changes A machine check occurs on every server in the network to report layer-1 configuration changes and layer level changes on servers C and F.

An additional recovery procedure performed is a triple recovery procedure. The triple recovery procedure is performed by an inactive layer-1 server in a triple configuration to determine whether a layer-1 failure has occurred.

One embodiment of logic regarding a triple recovery procedure is described with reference to FIG. 19A. Initially, the inactive layer-1 server is in the takeover mode (step 1900). A set coordinator argument mode message command is also issued to the coordinator server (step 1902). The set coordinator argument mode operation is issued via a message to the coordinator server by the alternate layer-1 server, for example, to put the coordinator into the argument mode. The receiving server returns to the coordinator argument status flag and the response block. In the message command data field, the active layer-1 communication timeout flag is set as follows: if the server does not have an attachment to the active layer server, the flag is set to 0, for example; If the server has an attachment to an active layer server and active layer-1 communication is recognized, the flag is set to 1, for example.

If the response to the set coordinator argument mode message command has an argument status flag equal to 1, the inactive layer-1 server recognizes an active layer-1 failure; If the response to the set coordinator argument mode message command has an argument status flag equal to 0, then the inactive layer-1 server does not recognize the active layer-1 failure and performs the following procedure: With a 1 configuration timeout flag, the server exits the takeover mode; If the response has an active layer-1 configuration timeout flag equal to 0 then inactive layer-1 remains in argument mode.

The inactive layer-1 server exits the argument mode when any of the following conditions occur.

The inactive layer-1 server receives a set coordinator argument message response containing an argument status flag equal to 0 and a communication timeout flag equal to one.

The inactive layer-1 server issues a reset coordinator argument mode command to the coordinator. The reset coordinator takeover mode operation is issued by the alternate layer-1 server to the coordinator server to cause the coordinator to be taken out of takeover mode. This action is returned to the coordinator server via a message.

Inactive layer-1 server performs an active layer-1 takeover procedure.

If the inactive layer-1 server receives the STP path message command established from the active layer-1 server while the inactive layer-1 server is in the takeover mode, the inactive layer-1 server issues a reset coordinator argument mode command to the coordinator; Establish an initiative to perform STP path initialization on the path to the active layer-1 server.

When the coordinator server receives a set coordinator argument mode message command from an inactive layer-1 server, the coordinator server enters coordinator argument mode. The coordinator server exits the coordinator argument mode when any of the following conditions occurs.

The coordinator responds to the set coordinator argument message command with a response containing an argument status flag equal to 0 and a communication timeout flag equal to one.

The coordinator accepts the reset coordinator argument mode command from the inactive layer-1 server.

The coordinator receives a layer-1 configuration update.

While in the coordinator argument mode, the coordinator is in one of the following coordinator argument states, that is, the argument pending state or the argument execution state. The mediator argument status is displayed in response to the set mediator argument mode command.

The coordinator enters the wait state when the coordinator enters coordinator takeover mode and there are two conditions: the coordinator is attached to the active layer-1 server and there is no active layer-1 communication timeout present in the coordinator. .

The argument waiting state indicates that the inactive layer-1 server cannot perform the active layer-1 argument. The coordinator leaves the argument wait state when the coordinator enters the argument execution state or when the coordinator leaves the coordinator argument mode.

The coordinator enters the argument execution state under the following circumstances.

● One of the conditions under which the coordinator enters coordinator takeover mode, the active layer-1 server is not attached to the coordinator, and the active layer-1 server is attached to the coordinator, and the active layer-1 communication timeout condition is recognized by the coordinator. When it existed.

● The coordinator is in a waiting state for arguments and the active layer-1 server is out of substates or an active layer-1 communication timeout is recognized.

The argument execution status indicates to the inactive layer-1 server that the inactive layer-1 server can perform active layer-1 arguments. If the coordinator enters the argument execution state after responding to the set coordinator argument command, the coordinator issues a coordinator argument execution command to the inactive tier-1 server (ie, sends a message) so that the inactive tier-1 server may Indicates that the transition has been made to the argument execution state.

When the coordinator enters the argument execution state, any remaining paths in the path group of the active layer-1 server go into an uninitialized state that indicates a communication error. While in the argument execution state, the coordinator responds with an argument execution state response to the Establish STP Path (ESP) message command from the active layer-1 server.

The coordinator leaves the argument wait state when it leaves the coordinator argument mode.

An example of layer-1 recovery of a triple configuration will be described with reference to FIG. 19B.

1. Server 1 (1950) is placed in the check stop state.

2. Server 2 1952 detects an accessory loss for Server 1.

3. Server 2 issues a set argument mode control command to the coordinator server.

4. The coordinator enters argument mode in response to the set argument mode command as follows.

If there is no attachment for Server 1, the coordinator responds that the Inactive Layer-1 server has entered the Takeover state, indicating that it can take over the duties of the Active Layer-1 server. When in the argument execution state, the coordinator server does not allow a path to be established with the active layer-1 server.

• If there is no attachment for Server 1, the coordinator responds that the inactive Layer-1 server has entered a wait state indicating that it cannot take over the duties of the Active Layer-1 server. If the coordinator loses the attachment to Server 1 while it is in the waiting state for the coordinator, the coordinator issues a coordinator argument status execution notification to Server 2.

5. The governor indicates that it is in argument execution state in the set argument mode command or with the governor argument status execution notification command for server 2.

6. Server 2 performs the CTN parameter update procedure to set itself as active layer-1.

7. When the layer-1 configuration change is current, server 2 issues a configuration change notification change to the console.

8. Configuration Changes A machine check occurs on all servers in the network to report layer-1 configuration changes.

As another example, referring to FIG. 19C, a recovery procedure for layer-1 server takeover is described after losing the link to active S1.

1. Referring to FIG. 19C, it is shown that server 2 1972 and coordinator 1974 have detected an accessory loss for server 1 1976.

2. Server 2 issues a set argument mode control command to the coordinator server.

3. The coordinator indicates that the coordinator has authenticated the arguments by indicating that the coordinator is in the argument execution state in response to a set argument mode command or with the coordinator argument status execution notification command for server 2.

4. Server 2 performs the CTN parameter update procedure to set itself as active layer-1.

5. When the layer-1 configuration change is current, server 2 issues a configuration change notification to the console.

6. Server 1 detects the loss of appendages for Servers 2 and 3 and performs the transfer procedure. Server 1 descends to Layer-3 as its subsidiary result for Server B.

7. Configuration Changes A machine check interrupt request has been issued on all servers in the network to report that the layer-1 configuration change and server 1 has gone to layer-3.

In the following example, the layer-1 argument is not performed. This is explained with reference to Fig. 19D. In this example,

1. Server 2 (1980) detects an accessory loss for Server 1 (1982).

2. Server 2 issues a set argument mode control command to coordinator server 1984.

3. The coordinator indicates that it is in the argument execution state in response to the set argument mode command, indicating that the inactive layer-1 server cannot take over the duties of the active layer-1 server.

4. Server 2 descends to Layer-3 without performing a recovery.

5. If the link is restored, server 2 issues a reset argument mode command to the coordinator.

6. Server 2 issues a configuration change machine check request to report the hierarchy level change.

In dual layer-1 recovery (Figure 16) and triple layer-1 recovery (Figure 17), the active layer-1 takeover procedure is performed by the inactive layer-1 server in response to the recognition of the active layer-1 failure. This procedure causes the inactive layer-1 server to take over the duties of the active layer-1 server of the CTN.

One embodiment of logic regarding active layer-1 arguments is described with reference to FIG. Initially, all remaining paths in the path group of the active layer-1 server are deinitialized and the URC indicates a communication error (step 2000).

In addition, the server sets its hierarchy level to 1 (step 2002), and the layer-1 configuration information block in the server and the console is modified (step 2004). As one example, the SCIB is modified such that the activation bit indicates a server as an active layer-1 server; The layer-1 maximum short term skew rate change field is set to a value of the server; The layer-1 configuration timestamp is set to the current time; The other fields are modified in such a way that they are not.

In addition to the foregoing, the server performs a CTN parameter update procedure to modify the layer-1 configuration information block of the CTN to the value of the updated SCIB (step 2006). The layer-1 configuration update time and the new layer-1 configuration information block are set to layer-1 configuration timestamps in the SCIB. This ends the active layer-1 acquisition procedure.

Another procedure performed is an active layer-1 transfer procedure, which is performed on a dual server or in a triple configuration when the active layer-1 server recognizes that an active layer-1 server has failed. Is performed by. This procedure causes the active layer-1 server to relinquish its duties as the active layer-1 server of the CTN.

One embodiment of logic relating to the active layer-1 transfer procedure is described with reference to FIG. As an example, the paths and path groups of the inactive layer-1 and coordinator server in the active layer-1 server are set to the non-initialized state and the URC indicates that the non-initialization is not complete (step 2100). The active layer-1 server also sets its hierarchy level to zero and becomes a secondary server (step 2102). The previous active layer-1 server as a secondary server sets its layer-1 configuration to an invalid configuration (step 2104). In addition, the server attempts to locate a potential clock source over its link (step 2106). This ends the abandonment process.

As mentioned above, the server status request command is used to request the operational status of the server specified by the node descriptor in the request block. The status of the specified server is provided asynchronously by the console using the server status recording command. One embodiment of the command request block for the server status request command is described with reference to Fig. 22A.

Server status request request block 2200 includes, for example, the following.

a) Length 2202: This field contains a value specifying the instruction block length.

b) Command Code 2204: This field specifies a server status read command.

c) Command Processing Number 2206: This field contains a value associated with issuing the command. The command processing number is returned in the response block for the command.

d) Node descriptor 2208: This field contains the node descriptor of the server for which status is desired.

An embodiment of the command response block 2250 of the server status request command is described with reference to FIG. 22B. Response block 2250 includes, for example, the following.

a) Length 2252: This field contains a value specifying the instruction block length.

b) Response code 2254: This field contains a response code for the command.

c) Command Processing Number 2256: This field contains the value provided in the Command Processing Number field of the Command Request Block.

The server status write command provides the operational status of the server specified in the request block. This command is issued by the console after accepting a server status request command. One embodiment of the command request block of the server status write command is described with reference to Fig. 23A. As an example, server status write request block 2300 includes the following.

a) Length 2302: This field contains a value specifying the instruction block length.

b) Command Code 2304: This field contains a value that specifies a server status recording command.

c) Command Processing Number 2306: This field contains the value associated with the issue of the command. The command processing number is returned in the response block for the command.

d) Status code 2308: This field contains a value indicating the status of the server specified by the node descriptor of the request block. The state includes, for example, the following items.

The server is operational.

Server status is unknown.

The server is in a check stopped state.

The server is powered off.

e) Node descriptor 2310: This field contains the node descriptor of the server for which status is reported.

One embodiment of the command response block of the server status write command is described with reference to FIG. 23B. As an example, server status write response block 2350 includes the following.

a) Length 2352: This field contains a value specifying the instruction block length.

b) Response code 2354: This field contains a response code for the command.

c) Command Processing Number 2356: This field contains the value provided in the Command Processing Number field of the Command Request Block.

In one embodiment, one or more aspects of the invention may be practiced in a processing environment based on one structure called a native architecture, but may emulate another structure called a guest architecture. By way of example, primitive structures are Power4 or PowerPC® structures provided by International Business Machines Corporation, Armonk, NY, or Intel® structures provided by Intel Corporation; Guest structures are also Jet / Architecture® from International Business Machines Corporation, Armonk, NY. The aspects of the jet / architecture are disclosed in IBM Publication No. SA22-7832-04, published in September 2005 under the name "Jet / Architecture Operating Principles", which is incorporated herein by reference in its entirety. . In such an environment, instructions and / or logic that are designated at the jet / architecture and designed to run on the jet / architecture machine are emulated to execute on structures other than the jet / architecture. An example of this processing environment will be described with reference to FIGS. 24 and 25.

Referring to FIG. 24, one embodiment of a processing environment incorporating and using one or more aspects of the present invention is shown. Processing environment 2400 includes, for example, raw central processing unit 2402, memory 2404 (eg, main memory), and one or more input / output (I / O) devices 2406, They are connected to one another, for example by one or more buses 2408 and / or other connecting means. By way of example, processing environment 2400 may include a PowerPC® processor, a pSeries® server, or an xSeries® server provided by International Business Machines Corporation, Armonk, NY; HP Superdome with Intel® Itanium® 2 processor from Hewlett Packard Company, Palo Alto, California; And / or other machines based on structures provided by IBM®, Hewlett Packard, Intel®, Sun Microsystems, and the like. PowerPC, PSeries, and X-Series are registered trademarks of International Business Machines Corporation, Amonk, NY. Intel and Itanium 2 are registered trademarks of Intel Corporation, Santa Clara, California.

The raw central processing unit 2402 includes one or more source registers 2410, such as one or more general purpose registers and / or one or more special purpose registers, used during processing within the environment. These registers contain information that indicates the state of the environment at any particular point in time.

The raw CPU 2402 executes instructions and code stored in the memory 2404. As one particular example, the central processing unit executes emulator code 2412 stored in memory 2404. This code allows a processing environment consisting of one structure to emulate another structure. For example, the emulator code 2412 allows machines based on non-jet / architecture machines, such as PowerPC processors, PSeries servers, X-Series servers, HP Superdome servers, etc. to emulate the jet / architecture and to use jet / architecture based Allows you to execute developed software and instructions.

More details regarding the emulator code 2412 will be described with reference to FIG. 25. Guest instructions 2502 include software instructions (eg, machine instructions) developed to execute on a structure other than that of native CPU 1002. For example, guest instructions 2502 may be designed to execute on jet / architecture processor 902, but instead are emulated on native CPU 2402 (eg, Intel Itanium 2 processor). As one example, emulator code 2412 includes an instruction fetch routine 2500 for obtaining one or more guest instructions 2502 from memory 2404 and optionally providing local buffering for the acquired instructions.

Emulator code 2412 also includes an instruction conversion routine 2504 for determining the type of guest instruction obtained and for providing one or more native instructions 2509 corresponding to the guest instructions. As an example, what is provided is the creation of a raw instruction stream for a given guest instruction, for example, during the conversion process. This involves identifying features and generating equivalent primitive commands. As another example, the provision of primitive instructions includes the selection of code segments in the emulator for guest instructions. For example, each guest instruction has an associated code segment in the emulator, the associated code segment comprising a sequence of one or more primitive instructions and the code segment selected and executed.

Emulator code 2412 also includes an emulation control routine 2506 that causes native instructions to be executed. The emulation control routine 2506 executes a native instruction routine that emulates one or more guest instructions obtained previously by the native CPU 2402, and returns control to the instruction fetch routine when it finishes executing the next guest instruction or guest. You can emulate the acquisition of instruction groups. Execution of the primitive instruction 2509 may include loading data from memory 2404 into a register as determined in a conversion routine; Storing data back from the register into memory; Or performing any type of arithmetic or logic operation. Each routine is implemented in software, for example, stored in memory and executed by the raw central processing unit 2402. As another example, one or more routines or operations may be implemented in firmware, hardware, software or any combination thereof. The registers of the emulated guest processor may be emulated using registers 2410 of the native CPU or each location in memory 2404. In each embodiment, the guest instruction 2502, the primitive instruction 2509, and the emulation code 2412 may be in the same memory or may be distributed among different memory devices.

As another embodiment, a data processing system suitable for storing and / or executing program code may utilize that at least one processor is coupled directly or indirectly to a memory element via a system bus. The memory element may include, for example, temporary storage of at least some program code to reduce the number of times the code is retrieved from local memory, bulk storage, and mass storage during execution. It provides cache memory.

Input / output (I / O) devices (such as but not limited to keyboards, displays, pointing devices, DASDs, tapes, CDs, DVDs, thumb drives, and other storage media) Can be coupled to the system via an O controller. Network adapters may also be coupled to the system such that the data processing system is coupled to other data processing systems or remote printers or storage devices via private or public networks. Modems, cable modems and Ethernet cards are some of the types of network adapters available.

One or more aspects of the invention may be included in an article of manufacture (eg, one or more computer program products) having, for example, a computer usable medium. The medium may include, for example, computer readable program code means or logic (eg, instructions, code, commands, etc.) to provide and facilitate the capabilities of the present invention. The article of manufacture may be included as part of a system (eg, a computer system) or sold separately.

An example of an article of manufacture or a computer program product containing one or more aspects of the present invention is described with reference to FIG. 26. Computer program product 2600 includes, for example, one or more computer usable media 2602 for storing computer readable program code means or logic 2604 for providing and facilitating one or more aspects of the present invention. do. The medium may be an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system (or device or device) or transmission medium. Examples of computer readable media include semiconductor or solid state memory, magnetic tape, removable computer diskettes, random access memory (RAM), read-only memory (ROM), rigid magnetic disks, and optical disks. Examples of optical discs are compact disc-read only memory (CD-ROM), compact disc-read / write (CD-R / W) and DVD.

A logical assembly or program instruction sequence of one or more interrelated modules defined by one or more computer readable program code means or logic instructs to carry out one or more aspects of the present invention.

Here, a description has been given of a facility for maintaining time synchronization by a plurality of separate computing systems to form an integrated timing network. Servers in the timing network use server-time protocols to deliver timely information over existing high-speed data links between systems that provide the power of the time clock in each system to match the accuracy required by today's high-performance computing systems. . Using STP over a high speed, low latency link provides the ability to synchronize all systems in the CTN with, for example, several microseconds of accuracy provided by a single server based on the baseline.

STP provides the ability to set and maintain time alignment information within the CTN, such as time zone, daylight saving time offset, and leap second offset. The information can be updated in the CTN in a planned and consistent fashion so that all changes occur simultaneously on all servers in the CTN. This prevents potential system exposure and disruption that occurs when the parameters are updated in a random manner, causing time skew between the computers.

CTN parameters can be set and read by the operator via the STP console interface. CTN parameters include server connectivity, local time information such as time zone and daylight saving time, and leap seconds required for UTC operations. The console itself is any element that has the ability to communicate with the STP facility and provide an operator interface for displaying and setting CTN parameters.

In one aspect of the invention, a single active layer-1 server is provided as a clock source for the network. The time clock of the active layer-1 server can be set to any time, but is generally set to an external reference time, such as dialup to UTC. Other servers are allowed to join the CTN if they have an unqualified layer-1 configuration known as an invalid configuration, or if the servers have a layer-1 configuration that matches the configuration of the primary time server. Thus, the synchronization accuracy within the CTN does not depend on the quality of the external time source even when there is an external time source in the layer-1 server. This ensures that servers in the CTN synchronize on the same basic primary reference.

In another aspect of the present invention, the alternate server is defined to be able to take over as an active layer server in the event of a failure of the active layer-1 server. This prevents a single point of failure of the CTN, allowing servers within the CTN to maintain or reacquire synchronization within the timing network despite the failure of an active layer-1 server.

Further information regarding the timing network is provided in the patent application below.

US Application No. 60 / 887,512 entitled "Server Time Protocol Messages and Methods"; US Application No. 60 / 887,544, entitled “Channel Subsystem Server Time Protocol Commands”; US Application No. 60 / 887,576 entitled "Methods and Systems for Forming Logical Paths Between Servers in an Integrated Timing Network"; US Application No. 60 / 887,584 entitled "Promoting Synchronization of Servers in an Integrated Timing Network"; US Application No. 60 / 887,586, entitled "Promoting Recovery in an Integrated Timing Network"; US Application No. 11 / 468,352, filed Aug. 30, 2006, entitled “Integrated Timing Network Configuration Parameter Update Procedure”; US Application No. 11 / 460,025, filed Jul. 26, 2006, entitled "Direct Acquisition with Application Information Useful for Determining Clock Accuracy"; US Application No. 11 / 223,886 entitled "Systems and Methods for TOD-Clock Steering"; US Application No. 11 / 532,168 entitled "Synchronization Signal for TOD-Clock Steering Adjustment"; US Application No. 11 / 468,501 entitled "Data Access Management Through Loops When Locking Equipment Changes"; US Application No. 11 / 223,878, entitled "Clock Filter Dispersion"; US Application No. 11 / 223,876 entitled "Methods and Systems for Clock Skew and Offset Evaluation"; US Application No. 11 / 223,577 entitled "Clock Offset and Skew Calculation Using T4 Timestamp"; And US Application No. 11 / 223,642 entitled "Systems and Methods of Calibrating TOD Clocks."

Advantageously, one or more aspects of the present invention can provide high quality timing information so that synchronization and accuracy requirements are met. Systems in CTN maintain strong synchronization with less stringent requirements of synchronization accuracy for external time sources such as UTC. There is no need to use expensive dedicated timing links and / or separate outer boxes. In addition, no requirement is required for each server to be attached to an external time server or to have a GPS.

Although one or more examples have been described herein, these are merely examples. Many variations can be made without departing from the spirit of the invention. For example, processing environments other than the examples provided herein may include one or more aspects of the present invention and / or may benefit from one or more aspects of the present invention. In addition, the environment does not need to be based on jet / architecture, but instead may be based on other structures provided by IBM, Intel, Sun Microsystems, and others. Furthermore, the environment may include a plurality of processors, may be partitioned, and / or coupled to other systems.

Moreover, although various control blocks have been described, these control blocks may each include additional information, less information, and / or different information. The location in the control block and the size of each field in the control block may be different in other embodiments.

The term "acquiring" as used herein includes, but is not limited to, fetching, receiving, having, providing, being provided, producing, developing, and the like.

The capabilities of one or more aspects of the invention may be implemented in software, firmware, hardware or any combination thereof. At least one program storage device may be provided that is readable by a machine that embodies at least one instruction program executable by the machine to perform the capabilities of the present invention.

The flowchart described herein is merely an example. Various changes may be made in the configurations or steps (or operations) described herein without departing from the spirit of the invention. For example, the steps may be performed in a different order and the steps may be added, deleted or modified. All such modifications are considered to form part of the present invention.

While various embodiments have been shown and described, it will be apparent to those skilled in the relevant art that various modifications, additions, substitutions, and the like may be made without departing from the spirit of the invention, and therefore, such various modifications, additions and Substitutions and the like are considered to be within the scope of the invention as defined in the claims.

Claims (10)

Obtaining information about the configuration of the integrated timing network by a first server of the one or more servers of the integrated timing network, the integrated timing network having a timing facility for clock synchronization, wherein the integrated timing network is at any time; Allow only one server to be a layer-1 server, the layer-1 server being characterized as providing a basic clock source for synchronization of all one or more servers in the unified timing network, the information being the one or more servers The information obtaining step, wherein the server comprises information indicating which of the servers can assume the duties of the layer-1 server, wherein the configuration is one of a plurality of types of configurations; Based on the obtained information, determining, by the first server, a task of the first server in the integrated timing network; In response to determining that the task is a layer-1 server, providing a default clock source for synchronization of the one or more servers; In response to determining that the task is not a layer-1 server, receiving basic clock synchronization from the layer-1 server. The method of claim 1, wherein the plurality of types of configurations include invalid configurations, single server configurations, dual server configurations, and triple configurations. The method of claim 1, wherein the information indicates that the server is in an invalid configuration state in which no primary active server is defined, and wherein the server determines that its task is a duty as an asynchronous server. 4. The method of claim 3, further comprising connecting the server to another server having an invalid layer-1 configuration, the server being synchronized in the integrated timing network in response to the connection. The method of claim 1, wherein the information indicates that the server is in a single server configuration in which a primary active server is defined, wherein the server has its task as the primary active server, or the primary active. Determining the task as a secondary server to receive timing information from the server. 6. The method of claim 5, wherein the determination is made based on information in a layer-1 configuration information block maintained at the server. The server of claim 1, wherein the information indicates that the server is in a dual server configuration in which a primary active server and a shift server are defined, wherein the server has its task as the primary active server, the shift server. Or as a server other than the primary active server or the alternate server. The server of claim 1, wherein the information indicates that the server is in a triple configuration state in which a primary active server, a shift server, and a coordinator server are defined, wherein the server is responsible for the primary active server. Determine a duty as an alternate server, the coordinator server, or any server other than the primary active server, the alternate server, and the coordinator server. 2. The method of claim 1, further comprising, in response to the occurrence of a predetermined condition, performing an operation by the server based on its determined task in the integrated timing network. The method of claim 1, wherein the server is in network communication with a primary active server via an integrated timing network configured to maintain time synchronization, and wherein the server receives a server time protocol message by the integrated timing network.

Images