US9270395B2 - Method for robust PTP synchronization with default 1588V2 profile - Google Patents

Abstract

Exemplary methods for reducing sync time in a precision time protocol (PTP) network include receiving, by a first PTP slave port of a first network device, timing messages from a second PTP master port of a second network device. The methods include maintaining a PTP master clock based on timing information included in the timing messages received from the second network device via the first PTP port. The methods further include receiving, by a third PTP passive port of the first network device, timing messages from a fourth PTP master port of a third network device. The methods include determining the third PTP passive port is a protective passive port based on a stepsRemoved value of the third network device, and maintaining an auxiliary clock based on the timing information included in the timing messages received from the third network device via the third PTP port.

Description

FIELD

Embodiments of the invention relate to the field of packet networks; and more specifically, to clock synchronization over a network.

BACKGROUND

The Precision Time Protocol (PTP) is a protocol utilized for synchronizing clocks throughout a network. PTP was originally defined by the Institute of Electrical and Electronics Engineers (IEEE) 1588-2002 standard, entitled “Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems” (hereby incorporated by reference), and released in 2002. In 2008, a revised standard, IEEE 1588-2008 entitled “IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems” (hereby incorporated by reference) was released. This new version, also commonly known as PTP Version 2 (PTPv2), improves accuracy, precision, and robustness. IEEE 1588-2008 was initially utilized primarily by instrumentation and control applications. The telecom industry, however, has since adopted IEEE 1588-2008 as a solution for providing time synchronization for packet network applications such as mobile backhaul. These packet network applications, however, require microsecond or better time distribution over the network and high quality fault tolerance.

IEEE 1588-2008 defines a best master clock algorithm (BMCA), executed at each PTP clock in the PTP domain, for configuring the PTP clocks to be a grandmaster, boundary clock, or slave clock. By utilizing their BMCA to determine their roles in the PTP domain, the PTP clocks converge to form a synchronization tree. While the synchronization tree is being formed, all clocks start locking (i.e., synchronizing) to their masters. Typically, it requires several minutes for each PTP clock to synchronize to its master. After the synchronization tree is formed, if one or more of the PTP clocks or the network experience a fault, all the downstream clocks will rearrange/re-converge to form a new synchronization tree. During this re-convergence period, timing transients will occur as new master and slave ports are selected by the BMCAs. These timing transients result in a period of time where the clock quality advertised to the ultimate slave clocks is inaccurate. These timing transients persist until all PTP clocks in the synchronization tree actually acquire synchronization to their new masters. In other words, for several minutes, or perhaps an hour or longer in larger networks, the timing accuracy is not as good as advertised. This results in the application being provided with inadequate timing accuracy. The timing transients that occur during the re-convergence period are not acceptable by packet network applications in the telecom domain.

Known techniques, such as holdover, exist to work around certain failure/recovery scenarios. Such techniques, however, are inadequate for prolonged outages. Further, because the BMCA will advertise a clock quality that is not true during failure-induced rearrangements, holdover techniques will not work.

SUMMARY

Exemplary methods for reducing sync time in a first network device for supporting Precision Time Protocol (PTP) in a network are herein described. In one embodiment, the methods include receiving, by a first PTP port associated with the first network device configured as a PTP slave port, PTP timing messages from a second PTP port associated with a second network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the second network device. In one embodiment, the methods further include maintaining a PTP master clock based on the timing information included in the PTP timing messages received from the second network device via the first PTP port. In one embodiment, the methods further include receiving, by a third PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from a fourth PTP port associated with a third network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the third network device.

According to one embodiment, the methods include determining the third PTP port is a protective passive port based on a stepsRemoved value associated with the third network device, wherein a stepsRemoved value indicates a number of boundary clock levels a respective network device is away from a PTP grandmaster clock of the network. In one embodiment, in response to determining the third PTP port is a protective passive port, maintaining a PTP auxiliary clock based on the timing information included in the PTP timing messages received from the third network device via the third PTP port, wherein in an event that the first network device fails to receive PTP timing messages from the second network device via the first PTP port, the PTP auxiliary clock is utilized by the first network device to synchronize its PTP master clock to the PTP master clock maintained by the third network device.

In one aspect of the invention, determining the third PTP port is a protective passive port comprises determining the third network device has a stepsRemoved value that is one less than a stepsRemoved value of the first network device. In one embodiment, determining the third PTP port is a protective passive port further comprises receiving, by a fifth PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from an sixth PTP port associated with a fourth network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the fourth network device, and in response to determining the fourth network device has a stepsRemoved value that is equal to a stepsRemoved value of the first network device, determining the fifth PTP port is a non-protective passive port.

In one aspect of the invention, determining the third PTP port is a protective passive port comprises receiving, by a fifth PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from an sixth PTP port associated with a fourth network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the fourth network device, determining the third network device has a stepsRemoved value that is equal to a stepsRemoved value of the fourth network device, and determining the fourth PTP port associated with the third network device has a port identity (ID) that is less than a port ID of the sixth PTP port associated with the fourth network device.

According to one embodiment, the methods further include in response to determining a failure to receive PTP timing messages from the second network device via the first PTP port, configuring the first PTP port to be a PTP master port, configuring the third PTP port to be a PTP slave port, and utilizing information of the PTP auxiliary clock to synchronize the PTP master clock maintained by the first network device to the PTP master clock maintained by the third network device. In one embodiment, the methods further include applying a phase slope limit to the PTP master clock maintained by the first network device after the third PTP port has been configured to be a PTP slave port.

In one embodiment, the second network device and the third network device are a same network device configured to serve as a PTP grandmaster clock of the network. In an alternate embodiment, the second network device and the third network device are different network devices, wherein the second network device and the third network device are configured to serve as a PTP boundary clock of the network. In one embodiment, the second network device and the third network device are synchronized to the same grandmaster.

BRIEF DESCRIPTION OF THE DRAWINGS

Embodiments of the invention are illustrated by way of example and not limitation in the figures of the accompanying drawings in which like references indicate similar elements.

FIG. 1A illustrates a conventional PTP network.

FIG. 1B illustrates a conventional PTP network.

FIG. 1C illustrates a conventional PTP network.

FIG. 2 is a block diagram illustrating a network device for supporting PTP according to one embodiment.

FIG. 3A is a block diagram illustrating a PTP network according to one embodiment.

FIG. 3B is a block diagram illustrating a PTP network according to one embodiment.

FIG. 3C is a block diagram illustrating a PTP network according to one embodiment.

FIG. 3D is a block diagram illustrating a PTP network according to one embodiment.

FIG. 4 is a flow diagram illustrating a method for maintaining an auxiliary clock according to one embodiment.

FIG. 5 is a flow diagram illustrating a method for reducing sync time in a PTP network according to one embodiment.

DESCRIPTION OF EMBODIMENTS

In the following description, numerous specific details such as logic implementations, opcodes, means to specify operands, resource partitioning/sharing/duplication implementations, types and interrelationships of system components, and logic partitioning/integration choices are set forth in order to provide a more thorough understanding of the present invention. It will be appreciated, however, by one skilled in the art that the invention may be practiced without such specific details. In other instances, control structures, gate level circuits and full software instruction sequences have not been shown in detail in order not to obscure the invention. Those of ordinary skill in the art, with the included descriptions, will be able to implement appropriate functionality without undue experimentation.

References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to affect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.

In the following description and claims, the terms “coupled” and “connected,” along with their derivatives, may be used. It should be understood that these terms are not intended as synonyms for each other. “Coupled” is used to indicate that two or more elements, which may or may not be in direct physical or electrical contact with each other, co-operate or interact with each other. “Connected” is used to indicate the establishment of communication between two or more elements that are coupled with each other.

An electronic device or a computing device (e.g., an end station, a network device) stores and transmits (internally and/or with other electronic devices over a network) code (composed of software instructions) and data using machine-readable media, such as non-transitory machine-readable media (e.g., machine-readable storage media such as magnetic disks; optical disks; read only memory; flash memory devices; phase change memory) and transitory machine-readable transmission media (e.g., electrical, optical, acoustical or other form of propagated signals—such as carrier waves, infrared signals). In addition, such electronic devices include hardware, such as a set of one or more processors coupled to one or more other components—e.g., one or more non-transitory machine-readable storage media (to store code and/or data) and network connections (to transmit code and/or data using propagating signals), as well as user input/output devices (e.g., a keyboard, a touchscreen, and/or a display) in some cases. The coupling of the set of processors and other components is typically through one or more interconnects within the electronic devices (e.g., busses and possibly bridges). Thus, a non-transitory machine-readable medium of a given electronic device typically stores instructions for execution on one or more processors of that electronic device. One or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.

As used herein, a network device (e.g., a router, switch, bridge) is a piece of networking equipment, including hardware and software, which communicatively interconnects other equipment on the network (e.g., other network devices, end stations). Some network devices are “multiple services network devices” that provide support for multiple networking functions (e.g., routing, bridging, switching,Layer2 aggregation, session border control, Quality of Service, and/or subscriber management), and/or provide support for multiple application services (e.g., data, voice, and video). Subscriber end stations (e.g., servers, workstations, laptops, netbooks, palm tops, mobile phones, smartphones, multimedia phones, Voice Over Internet Protocol (VOIP) phones, user equipment, terminals, portable media players, GPS units, gaming systems, set-top boxes) access content/services provided over the Internet and/or content/services provided on auxiliary private networks (VPNs) overlaid on (e.g., tunneled through) the Internet. The content and/or services are typically provided by one or more end stations (e.g., server end stations) belonging to a service or content provider or end stations participating in a peer-to-peer (P2P) service, and may include, for example, public webpages (e.g., free content, store fronts, search services), private webpages (e.g., username/pas sword accessed webpages providing email services), and/or corporate networks over VPNs. Typically, subscriber end stations are coupled (e.g., through customer premise equipment coupled to an access network (wired or wirelessly)) to edge network devices, which are coupled (e.g., through one or more core network devices) to other edge network devices, which are coupled to other end stations (e.g., server end stations).

A network interface may be physical or auxiliary; and an interface address is an IP address assigned to a network interface, be it a physical network interface or auxiliary network interface. A physical network interface is hardware in a network device through which a network connection is made (e.g., wirelessly through a wireless network interface controller (WNIC) or through plugging in a cable to a port connected to a network interface controller (NIC)). Typically, a network device has multiple physical network interfaces. A auxiliary network interface may be associated with a physical network interface, with another auxiliary interface, or stand on its own (e.g., a loopback interface, a point to point protocol interface). A network interface (physical or auxiliary) may be numbered (a network interface with an IP address) or unnumbered (an network interface without an IP address). A loopback interface (and its loopback address) is a specific type of auxiliary network interface (and IP address) of a node (physical or auxiliary) often used for management purposes; where such an IP address is referred to as the nodal loopback address. The IP address(es) assigned to the network interface(s) of a network device, are referred to as IP addresses of that network device; at a more granular level, the IP address(es) assigned to network interface(s) assigned to a node implemented on a network device, can be referred to as IP addresses of that node.

IEEE 1588-2008 defines three types of PTP clocks: Ordinary Clock (OC), Boundary Clock (BC), and Transparent Clock (TC). An OC has one instance of the PTP protocol running (i.e., one PTP port). An OC can either provide timing to the PTP time domain (i.e., be the grandmaster, described in further details below) or can regenerate the timing from a grandmaster (i.e., be the slave, described in further details below). Alternatively, an OC can be configured to be Grandmaster-Only Ordinary Clock (GMOC), which only serves as the grandmaster, or a Slave-Only Ordinary Clock (SOOC), which only serves as a slave. A BC has more than one instance of the PTP protocol running (i.e., multiple PTP ports). A BC receives timing messages from an upstream master, synchronizes its local time of day to these timing messages, and distributes that local time of day to downstream slaves. The upstream masters can be BCs, OCs, GMOCs, or any combination thereof. The downstream slaves can be BCs, OCs, SOOCs, or any combination thereof. Thus, a BC provides intermediate timing regeneration between grandmasters and slave OCs. A BC needs to provide fault tolerance required by the telecom network devices. A TC is also situated between grandmasters and slave OCs/SOOCs, but does not regenerate timing signals.

Each PTP device periodically sends Announce messages via the master PTP ports to other PTP devices in the same PTP domain. Here, a PTP device refers to a network device that supports PTP. The Announce messages include clock information and identity of the sending PTP device's PTP clock, stepsRemoved value of the sending PTP device, and information concerning the grandmaster. A best master clock algorithm (BMCA) executed at each PTP clock utilizes information included in the received Announce messages to determine the role of the local master clock in the PTP domain. IEEE 1588-2008 defines three roles: grandmaster (GM), boundary clock (BC), and slave.

A GM provides the ultimate time source to all other PTP clocks in a PTP time domain. The GM derives its timing from a non-PTP source, and distributes this time into the PTP domain using PTP messages (e.g., PTP Sync messages) on the packet network. All PTP clocks (other than the GM) synchronize to one GM clock in a PTP time domain. As a result of the BMCA running on every clock, an OC, GMOC, or BC can take on the role as the GM.

A slave ordinary clock utilizes time codes included in PTP messages received from a grandmaster or a boundary clock to generate a local time that is an estimate of its domain's grandmaster time. This regenerated time is then provided to one or more non-PTP application that is running on the slave ordinary clock or attached to the slave ordinary clock via a non-PTP interface. Note that either an OC or SOOC can be a slave ordinary clock. A boundary clock (BC) utilizes time codes included in PTP messages received from an upstream master clock to regenerate the time codes and send them to downstream slaves. PTP clocks only synchronize to masters of the same PTP domain, which is identified by a PTP domain number.

IEEE 1588-2008 specifies that a PTP port can be configured to be in one of three states: master, slave, or passive. It shall be understood that PTP ports can be in one or more other states, including, for example, uncalibrated, listening, disabled, faulty, initialing state, etc. At any given moment, there is a maximum of only one PTP port in a PTP clock that can be configured to be in the slave state. Throughout the description, a PTP port configured to be in the master, slave, or passive state will simply be referred to as a PTP master port, PTP slave port, or PTP passive port, respectively. A PTP clock synchronizes its local master clock to the time codes received on a PTP slave port from a peer PTP master port. A PTP passive port is utilized for pruning the PTP network to avoid timing loops. Here, a “timing loop” refers to a phenomenon where a PTP clock is attempting to synchronize to itself by using timing codes that it originated.

PTP port configuration will now be described. When a PTP port receives an Announce message that indicates the sender has a worse clock as compared to the local master clock and all other master clocks seen by the local clock in the network according to the timing information in the Announce messages received on any local PTP port, the receiving port will be configured to be in the master state, and the peer PTP port will be configured to be in the slave state. When a PTP port receives an Announce message that indicates the sender has a clock which has similar quality as compared to the local master clock and all other master clocks seen by the local clock in the network according to the timing information in the Announce messages received on any local PTP port (e.g., they are syncing to the same grandmaster), then the receiving port can be configured to be either in the master or passive state, depending on stepsRemoved values and portIdentity of the receiving and transmitting PTP port. Here, “stepsRemoved” refers to the number of BC hops away the respective PTP clock is from the GM, and “portIdentity” is a unique value/identifier that is assigned to each PTP port in the PTP domain. A portIdentity uniquely identifies a PTP port, and comprises the clockIdentity and a portNumber. A clockIdentity uniquely identifies the PTP clock, and the portNumber is unique within that PTP clock. Note that PTP ports on a clock A will have lower portIdentities than PTP ports on a clock B if clock A has a clockIdentity that is lower than clock B.

The configuration of a PTP port (to be a PTP master or passive port) when the transmitting and receiving PTP clocks have similar quality will now be discussed. The receiving port will be configured to be a PTP master port (and the peer PTP port will be configured as a PTP passive port) if the receiving PTP clock's stepsRemoved value is lower than the sender. The receiving port will also be configured to be a PTP master port (and the peer PTP port will be configured as a PTP passive port) if the receiving PTP clock's stepsRemoved value is the same as the sender, but the receiving PTP port's portIdentity is lower than the sender's portIdentity. If, however, the receiving PTP clock's stepsRemoved value is the same as the sender, but the receiving PTP port's portIdentity is larger than the sender's portIdentity, then the receiving port will be configured to be a PTP passive port (and the peer PTP port will be configured as a PTP master port). Finally, if the receiving PTP clock has a stepsRemoved value that is larger than the stepsRemoved value of the sender (i.e., the receiving clock is “farther” from the GM as compared to the transmitting clock), then the receiving port will be configured to be a PTP passive port (and the peer PTP port will be configured as a PTP master port).

When all the PTP clocks in the network have settled/converged, the resulting links between the master, slave, and passive ports of the PTP clocks form a synchronization tree. Any change in a clock's quality, a clock failure, or a network failure will cause all downstream clocks to reacquire synchronization to a new master (i.e., form a new synchronization tree). While the PTP clocks re-converge to form the new synchronization tree, the accuracy of the PTP clocks involved in the re-convergence process will be impaired, which affects the accuracy of the time provided to the applications utilizing the clocks. Limitations of conventional PTP networks will now be described by way of illustration through the figures below, in which like references indicate similar elements.

FIGS. 1A-1C are block diagrams illustratingconventional PTP network100. Throughout the figures, various PTP master ports, PTP slave ports, and PTP passive ports will simply be referred to as M ports, S ports, and P ports, respectively. Referring first toFIG. 1A, which is a block diagram illustratingconventional PTP network100 that includes network devices101-110 communicatively coupled to each other as shown. In this illustrated configuration,network device101 has been configured to be the GM (herein referred to as GM101), network devices102-107 have been configured to be BCs (herein referred to as BCs102-107, respectively), and network devices108-110 have been configured to be SOOCs (herein referred to as SOOCs108-110, respectively). BCs102-107 have been assigned clockIdentities1-6, respectively. Thus, the portIdentities ofBC102 are the lowest and the portIdentities ofBC107 are the highest. In this example,network100 includes 2 BC levels. BCs102-104 belong to the first BC level (i.e., they are 1 BC level/hop away from GM101), and thus, each has a stepsRemoved value of 1. BCs105-107 belong to the second BC level (i.e., they are 2 BC levels/hops away from GM101), and thus, each has a stepsRemoved value of 2.

GM101 includesM port115 communicatively coupled toS port124 ofBC102,M port112 communicatively coupled toS port135 ofBC103, Mports114 and116 communicatively coupled toS port145 andP port146, respectively, ofBC104.BC102 includesS port124 as described above.BC102 further includesM port122 communicatively coupled toS port154 ofBC105, andM port123 communicatively coupled toS port164 ofBC106.BC103 includesS port135 as described above.BC103 further includesM port133 communicatively coupled toP port174 ofBC107, andM port134 communicatively coupled toP port141 ofBC104.

BC104 includesS port145,P port146, andP port141 as described above.BC104 further includesM port142 communicatively coupled toP port165 ofBC106, andM port143 communicatively coupled toS port175 ofBC107.BC105 includesS port154 as described above.BC105 further includesM port152 communicatively coupled toS port181 ofSOOC108, andM port153 communicatively coupled toP port161 ofBC106.BC106 includesS port164,P port165, andP port161 as described above.BC106 further includesM port162 communicatively coupled toS port182 ofSOOC109.BC107 includesP port174 andS port175 as described above.BC107 further includesM port172 communicatively coupled toS port183 ofSOOC110. SOOCs108-110 include S ports181-183, respectively, as described above.

Referring now toFIG. 1B, which is a block diagram illustratingconventional PTP network100.Network100 illustrated inFIG. 1B is similar tonetwork100 shown inFIG. 1A, except thatfault189 has occurred. InFIG. 1B, the PTP ports and links in bold are those which are affected byfault189. Due tofault189,BC104 is no longer able to receive PTP messages fromGM101 viaS port145, which prevents BC104 from syncing its local master clock toGM101 viaS port145. As a result, BC104 must select a new PTP port to be a slave port. In this example,BC104 reconfigures itsPTP port146 from passive to slave state, andPTP port145 from slave to master state (because only one PTP port can be a slave at a PTP clock). Thus,BC104 has selectedPTP port146 to be its new slave port.

The synchronization tree shown inFIG. 1B remains unchanged afterfault189 has occurred. A change in slave port, however, has occurred. When a conventional PTP clock selects a new slave port, it requires time to sync its local master clock to the new master clock through the new slave port. While this syncing process is occurring, all downstream PTP devices that rely on the PTP clock will also be affected. In this example,BC107 andSOOC110 will be affected. Embodiments of the present invention overcome these limitations by reducing the impact, e.g., by reducing the sync time, described in further details below.

Referring now toFIG. 1C, which is a block diagram illustratingconventional PTP network100.Network100 illustrated inFIG. 1C is similar tonetwork100 shown inFIG. 1A, except thatfault188 has occurred. InFIG. 1C, the PTP ports and links in bold are those which are affected byfault188. Due tofault188,BC102 is no longer able to receive PTP messages fromGM101 viaS port124, which prevents BC102 from syncing its local master clock toGM101 viaS port124. As a result, BC102 must select a new PTP port to be a slave port. In this example,BC102 reconfigures itsPTP port123 from master to slave state, andPTP port124 from slave to master state (because only one PTP port can be a slave at a PTP clock). Thus,BC102 has selectedPTP port123 to be its new slave port. In response toBC102 configuringPTP port123 to be a new slave port,BC106 reconfigures itsPTP port164 from slave state to master state. Further,BC106 has selected itsPTP port165 to be the new slave port. In order to avoid a timing loop,BC106 has also reconfigured itsPTP port161 to be a master port. The reconfiguration ofPTP port161 to be a master port, in turn, causes BC105 to reconfigure itsPTP port153 to be a slave port. Given that only one PTP port can be a slave port at a PTP clock,BC105 reconfigures itsPTP port154 from slave to master port. The reconfiguration ofPTP port154 to be a master port, in turn, causes BC102 to reconfigure itsPTP port122 from master state to passive state.

The new synchronization tree shown inFIG. 1C has resulted inBC102 changing its stepsRemoved value from 1 to 3. In other words,BC102 is now 3 BC levels away fromGM101. When a synchronization tree is rearranged, all downstream PTP devices will be affected. The time it takes for a synchronization tree to rearrange can be quite long, depending on the network size. Embodiments of the present invention overcome these limitations by reducing the impact, e.g., by reducing the sync time, described in further details below.

FIG. 2 is a block diagram illustratingnetwork device201 for supporting PTP according to one embodiment.Network device201 includes one or more PTP ports, for example PTP ports201-204. It shall be understood that more or less PTP ports can be included as part ofnetwork device201. PTP ports201-204 are responsible for forwarding received information concerning master clock quality and stepsRemoved values of other PTP master clocks in the network toclock manager210. Such information is included, for example, in received PTP Announce and/or Sync messages.

Clock manager210 determines the state (e.g., master, slave, passive) of PTP ports201-204 based on the received master clock quality and stepsRemoved values.Clock manager210 may determine the states of PTP ports201-204 using mechanisms similar to those described above. Other mechanisms for determining the state of each PTP port can be used without departing from the broader scope and spirit of the present invention. In the illustrated example,clock manager210 has configuredPTP port201 to be a PTP master port (herein referred to as an M port),PTP port202 to be a PTP slave port (herein referred to as an S port), and PTP ports203-204 as passive ports (herein referred to as P ports). It shall be understood thatclock manager210 can configure the PTP ports such that there are multiple instances ofM ports201, and/or P ports203-204.

Clock manager210 utilizes time codes received viaS port202 to maintain (i.e., sync)master clock211 to the master clock of the PTP device which is communicatively coupled toS port202. Throughout the description, the remote PTP clock which is communicatively coupled to the S port shall be referred to as the “main remote master clock”. The use of time codes in PTP timing messages (e.g., PTP Sync messages) to sync a local master clock to a main remote master clock is well known in the art. For the sake of brevity, it will not be discussed here.Network device201 further includesmessage generator213 for generating and sending PTP timing messages (e.g., Announce, Sync, etc.) viaM port201. PTP timing messages are generated based on at least information ofmaster clock211 and the stepsRemoved value ofnetwork device201. Generation and sending of PTP timing messages, such as, for example, Announce and Sync messages, are well known in the art, and will not be described here.

A conventional PTP device may include a passive port. PTP time codes received via a conventional passive port, however, are not processed. As a result, a conventional PTP device is not able to leverage off time codes received via a passive port to reduce the time it takes to sync the local master clock to a new master clock when the passive port is reconfigured to be a slave port. For example, inFIG. 1B, when BC104 switches from syncing its local master clock viaPTP port145 toPTP port146,BC104 is not able to reduce its sync time by leveraging off time codes received viaPTP port146 whilePTP port146 was in the passive state. Embodiments of the present invention overcome these limitations by processing time codes received from at least one PTP passive port.

In one embodiment,network device201 includes protective passive (PP)port identifier205 for identifying one or more passive ports as “protective passive” ports (herein referred to as PP ports) and one or more other passive ports (if any) as “non-protective passive” ports (herein referred to as NP ports). By identifying passive ports as “protective passive” ports,network device201 is able to maintain one or more local auxiliary clocks using timing information received via the PP ports. The one or more auxiliary clocks can then be utilized bynetwork device201 to reduce the amount of time required to sync to a new master clock, described in further details below.

In one embodiment,PP port identifier205 identifies one or more PP ports by determining a plurality of local PTP ports that have been configured as passive ports. In one embodiment,PP port identifier205 selects, from the identified plurality of passive ports, a first group of passive ports that are communicatively coupled to PTP devices with a stepsRemoved value that is 1 less than the stepsRemoved value ofnetwork device201. In one embodiment,PP port identifier205 configures each of the selected passive ports as a PP port. In an alternate embodiment,PP port identifier205 configures a predetermined number of the selected first group of passive ports that are communicatively coupled to remote PTP ports with the lowest portIdentities (among all PTP devices communicatively coupled to the selected first group of passive ports) as PP ports. In one embodiment, the predetermined number of passive ports to be configured as PP ports represents percentage. For example, if there are 10 passive ports in the selected first group of passive ports,PP port identifier205 may be configured to identify 30% (i.e.,3 out of 10) passive ports associated with remote PTP ports with the lowest portIdentities (among all PTP ports associated with the first group of passive ports) as PP ports. Alternatively, the predetermined number of passive ports to be configured as PP ports represents a raw number. For example, if there are 10 passive ports in the selected first group of passive ports,PP port identifier205 may be configured to identify a predetermined number of 2 passive ports associated with remote PTP ports with the lowest portIdentities (among all PTP ports associated with the first group of passive ports) as PP ports.

In one embodiment, ifPP port identifier205 determines that none of the passive ports are communicatively coupled to a PTP device that has a stepsRemoved value that is 1 less than the stepsRemoved value ofnetwork device201, thenPP port identifier205 identifies a predetermined number (either as a percentage or raw number, as described above) of passive ports that are communicatively coupled to the PTP ports with the lowest portIdentity as the PP ports.FIG. 2 illustrates by way of example, and not limitation,passive port203 has been identified as a NP port, andpassive port204 has been identified as a PP port. It shall be understood thatPP port identifier205 can configure the PTP passive ports such that there are multiple instances of NP ports and/or PP ports. In other words, there can be multiple NP ports and/or PP ports atnetwork device201.

In one embodiment, after one or more PP ports have been identified, contrary to a conventional PTP device, time codes received (e.g., as part of PTP Sync messages) via the identified PP ports are processed to sync one or more local auxiliary clocks to master clocks maintained by remote PTP devices that are communicatively coupled to the identified PP ports. Throughout the description, the master clock which is communicatively coupled to a PP port of local PTP device is referred to as the “monitored remote master clock”. For example, the master clock which is communicatively coupled toPP port204 shall be referred to as a monitored remote master clock ofnetwork device201.

In one embodiment,clock manager210 maintains an auxiliary clock for each identified PP port.Clock manager210 can approximate the clock frequency of each monitored remote master clock based on the time codes received via a respective PP port. The approximated clock frequency of each monitored remote master clock can then be used to sync a respective auxiliary clock to the respective monitored remote master clock. In the illustrated example,clock manager210 utilizes time codes received viaPP port204 to maintainauxiliary clock212.Clock manager210 approximates the clock frequency of the monitored remote master clock based on the time codes received viaPP port204. The approximated clock frequency of the monitored remote master clock can then be used to syncauxiliary clock212 to the monitored remote master clock.

In an event that networkdevice201 fails to receive PTP timing messages via its S port202 (e.g., due to a failure ofS port202, a failure of the peer master port that is communicatively coupled toS port202, or a failure of a network link),network device201 can configure itsS port202 to be a master port. Further,clock manager210 identifies one of the local PP ports to be a new slave port.Clock manager210 then causesmaster clock211 to start syncing to the auxiliary clock corresponding to the PP port that has been re-configured to be the new slave port. For example, in response to determining a failure to receive PTP timing messages viaS port202,clock manager210 reconfiguresPP port204 to be a new slave port, and starts syncingmaster clock211 toauxiliary clock212.

In one embodiment, whenclock manager210 starts syncingmaster clock211 to an auxiliary clock,clock manager210 applies phase slope limit214 (also commonly known as a “phase rate change limit”) in order to prevent the clock phase ofmaster clock211 from changing more than the value indicated byphase slope limit214. Continuing on with the above example,clock manager210 appliesphase slope limit214 whenclock manager210 starts syncingmaster clock211 toauxiliary clock212. By limiting the phase change,clock manager210 prevents timing disturbance to downstream PTP slave devices. In one embodiment,phase slope limit214 can be configured by a user (e.g., an operator) via an application programming interface (API).

In one embodiment, once the new slave port starts receiving PTP timing messages from the new main remote master clock (former monitored remote master clock),clock manager210 starts syncingmaster clock211 to the new main remote master clock. By syncing to an auxiliary clock (e.g., auxiliary clock212),clock manager210 is able to reduce the amount of time required to syncmaster clock211 to the new main remote master clock. Thus, contrary to a conventional PTP device,network device201 processes time codes received via at least one passive port in order to maintain at least one auxiliary clock, which is utilized to reduce the amount of time required to syncmaster clock211 to a new main remote master clock.

When a conventional PTP device selects a new slave port, there is a possibility that the new slave port will result in a new synchronization tree. For example, as illustrated inFIG. 1C, whenfault188 occurs andBC302 selectsPTP port123 as the new slave port, there is a re-convergence of the synchronization tree, resulting inBC102 changing from being 1 BC level away fromGM101 to being 3 BC levels away fromGM101. The re-convergence requires a long duration of time for the new synchronization tree to be pruned. Embodiments of the present invention overcome these limitations by selecting one or more passive ports that are communicatively coupled to remote PTP devices that have a stepsRemoved value that is one less than the stepsRemoved value of the local network device. In this way, when the local network device switches to syncing to the PP port, the hierarchy of the synchronization tree remains unaffected, thereby reducing the amount of time required for all downstream slave clocks to re-sync.

FIGS. 3A-3D are block diagrams illustratingPTP network300 according to one embodiment. Throughout the figures, various PTP master ports, PTP slave ports, non-protective passive ports, and protective passive ports will simply be referred to as M ports, S ports, NP ports, and PP ports, respectively. Referring first toFIG. 3A, which is a blockdiagram illustrating network100 that includes, but not limited to, network devices301-310 communicatively coupled to each other as shown. One or more of network devices301-310 can be implemented as part ofnetwork device201. In this illustrated configuration,network device301 has been configured to be the GM (herein referred to as GM301), network devices302-307 have been configured to be BCs (herein referred to as BCs302-307, respectively), and network devices308-310 have been configured to be SOOCs (herein referred to as SOOCs308-310, respectively). BCs302-307 have been assigned clockIdentities1-6, respectively. Thus, the portIdentities ofBC302 are the lowest and the portIdentities ofBC307 are the highest. In this example,network300 includes 2 BC levels. BCs302-304 belong to the first BC level (i.e., they are 1 BC level/hop away from GM301), and thus, each has a stepsRemoved value of 1. BCs305-307 belong to the second BC level (i.e., they are 2 BC levels/hops away from GM301), and thus, each has a stepsRemoved value of 2.

GM301 includes Mports315 and311 communicatively coupled toS port324 andPP port325, respectively, ofBC302, Mports312 and313 communicatively coupled toS port335 andPP port336, respectively, ofBC303, andM ports314 and316 communicatively coupled toS port345 andPP port346, respectively, ofBC304.BC302 includesS port324 andPP port325 as described above.BC302 further includesM port322 communicatively coupled toS port354 ofBC305,M port323 communicatively coupled toS port364 ofBC306, andM port324 communicatively coupled toNP port331 ofBC303.

BC303 includesS port335,PP port336, andNP port331 as described above.BC303 further includesM port332 communicatively coupled toPP port365 ofBC306,M port333 communicatively coupled toPP port374 ofBC307, andM port334 communicatively coupled toNP port341 ofBC304.BC304 includesS port345,PP port346, andNP port341 as described above.BC304 further includesM port342 communicatively coupled toS port375 ofBC307, andM port343 communicatively coupled toPP port355 ofBC305.

BC305 includesS port354 andPP port355 as described above.BC305 further includesM port352 communicatively coupled toS port381 ofSOOC308, andM port353 communicatively coupled toNP port361 ofBC306.BC306 includesS port364,PP port365, andNP port361 as described above.BC306 further includesM port362 communicatively coupled toS port382 ofSOOC309, andM port363 communicatively coupled toNP port371 ofBC307.BC307 includesPP port374,S port375, andNP port371 as described above.BC307 further includesM port372 communicatively coupled toS port383 ofSOOC310. SOOCs308-310 include S ports381-383, respectively, as described above.

The configuration ofnetwork300 is shown inFIG. 3A for illustrative purposes and not intended to be limitations of the present invention. Embodiments of the present invention apply equally to other network configurations having more or less network devices, arranged in more or less BC levels, and having more or less PTP ports configured to be in different states.

As described above,S port345 ofBC304 is communicatively coupled toM port314 ofGM301. Thus, from the perspective ofBC304,GM301 is the main remote master clock.BC304 includes two PTP passive ports (i.e.,PTP ports341 and346).BC304 has identified (e.g., by utilizing a PP port identifier similar to PP port identifier205) PTPpassive port346 as a PP port, and PTPpassive port341 as a NP passive port because PTPpassive port346 is communicatively coupled to a PTP device which has a stepsRemoved value of one less than the stepsRemoved value ofBC304. Here,GM301 has a stepsRemoved value of 0 andBC304 has a stepsRemoved value of 1. Thus, from the perspective ofBC304,GM301 is also the monitored remote master clock. As such, the clock manager (similar to clock manager210) ofBC304 utilizes time codes received in PTP timing messages (e.g., Sync messages) fromGM301 viaPP port346 to sync an auxiliary clock (similar to auxiliary clock212) to the monitored remote master clock.

Referring now toFIG. 3B, which is a blockdiagram illustrating network300 according to one embodiment.Network300 illustrated inFIG. 3B is similar tonetwork300 shown inFIG. 3A, except thatfault389 has occurred. InFIG. 3B, the PTP ports and links in bold are those which are affected byfault389. Due tofault389,BC304 is no longer able to receive PTP messages from its main remote master clock (i.e., GM301) viaS port345. The failure to receive time codes prevents BC304 from syncing its local master clock (similar to master clock211) toGM301 viaS port345. As a result, BC304 must select a new PTP port to be a slave port.

When a conventional PTP device switches to a new slave port (as illustrated inFIG. 1B), the conventional PTP device requires a long time to sync the local master clock to the new main remote master, and as a result all downstream PTP devices are affected. Embodiments ofBC304 overcome these limitations by processing time codes received viaPTP port346 while it was in the PP state to sync an auxiliary clock (similar to auxiliary clock212) to the monitored remote master clock (i.e., the master clock maintained by GM301). In one embodiment, in response to determining a failure to receive time codes from the main remote master clock via S port345 (e.g., due to fault389),BC304 reconfiguresPTP port345 from slave state to master state.BC304 starts syncing its local master clock (similar to master clock211) to the auxiliary clock (similar to auxiliary clock212) corresponding toPP port346. Further,BC304 reconfiguresPTP port346 from PP state to slave state. Thus,BC304 has selectedPTP port346 to be its new slave port. Here, althoughGM301 remains the main remote master clock, the time codes which BC304 now syncs its local master clock to are those received via thenew slave port346.

The amount oftime BC304 requires to sync its local master clock to the new main remote master clock is less than the amount of time that a conventional PTP device would require becauseBC304 is able to sync its local master clock to the auxiliary clock prior to syncing the local master clock to the new main remote master clock. In one embodiment, BC304 also applies a phase slope limit (similar to phase slope limit214) to the local master clock when the local master clock starts syncing to the auxiliary clock. In this way, the phase change in the local master clock can be controlled such that it would not disturb the timing of the downstream PTP devices (in this example,BC305,SOOC308,BC307, and SOOC310). Thus, by using mechanisms of the present invention,BC304 is able to handlefault389 such that it is transparent to all downstream PTP devices by using time codes received viaPTP port346 while it was in the PP state to sync the auxiliary clock to the monitored remote master clock.

Althoughfault389 has been described as the cause forBC304 failing to receive time codes viaS port345, one having ordinary skill in the art would recognize that the present invention is not limited to any particular type of fault. Embodiments of the present invention apply equally to any failure that prevents BC304 from receiving time codes viaS port345.

Referring now back toFIG. 3A for a moment. As described above,S port324 ofBC302 is communicatively coupled toM port315 ofGM301. Thus, from the perspective ofBC302,GM301 is the main remote master clock.BC302 includes one PTP passive port (i.e., PTP port325).BC302 has identified (e.g., by utilizing a PP port identifier similar to PP port identifier205) PTPpassive port325 as a PP port because PTPpassive port325 is communicatively coupled to a PTP device which has a stepsRemoved value of one less than the stepsRemoved value ofBC302. Here,GM301 has a stepsRemoved value of 0 andBC302 has a stepsRemoved value of 1. Thus, from the perspective ofBC302,GM301 is also the monitored remote master clock. As such, the clock manager (similar to clock manager210) ofBC302 utilizes time codes received in PTP timing messages (e.g., Sync messages) fromGM301 viaPP port325 to sync an auxiliary clock (similar to auxiliary clock212) to the monitored remote master clock.

Referring now toFIG. 3C, which is a blockdiagram illustrating network300 according to one embodiment.Network300 illustrated inFIG. 3C is similar tonetwork300 shown inFIG. 3A, except thatfault388 has occurred. InFIG. 3C, the PTP ports and links in bold are those which are affected byfault388. Due tofault388,BC302 is no longer able to receive PTP messages from its main remote master clock (i.e., GM301) viaS port324. The failure to receive time codes prevents BC302 from syncing its local master clock (similar to master clock211) toGM301 viaS port324. As a result, BC302 must select a new PTP port to be a slave port.

When a conventional PTP device switches to a new slave port (as illustrated inFIG. 1C), there is a possibility that a re-convergence may occur (i.e., a new synchronization tree may be formed), and as a result all downstream PTP devices are affected. For example, inFIG. 1C, whenBC102 selectsPTP port123 as the new slave port, BC102 changes from being one BC level away fromGM101 to three BC levels away fromGM101. This in turn requires all affected downstream PTP devices to select new master and slave ports. Such a re-convergence process requires a long time in order for all clocks in the network to settle to a reliable/accurate state. Embodiments ofBC302 overcome these limitations by selectingPTP port325 as the PP port becausePTP port325 is communicatively coupled to a remote PTP device (in this example, GM301) that has a stepsRemoved value of one less than the stepsRemoved value ofBC302. By selectingPTP port325 as the PP port,BC302 is able to prevent a re-convergence of the synchronization tree when the PP port is reconfigured to be a slave port. Here, beforeBC302 selects the new slave port,BC302 is one BC level away fromGM301. AfterBC302 selects the new slave port (i.e., PTP port325), BC302 remains one BC level away fromGM301. The synchronization tree remains unaffected by the selection of the new slave port, preventing all downstream PTP devices from having to select new master and slave ports. Thus, by utilizing mechanisms of the present invention,BC302 is able to prevent the formation of a new synchronization tree, thereby reducing the amount of time required by downstream PTP devices to sync up to the new master clock.

In one embodiment, in response to determining a failure to receive time codes from the main remote master clock via S port324 (e.g., due to fault388),BC302 reconfiguresPTP port324 from slave state to master state.BC302 starts syncing its local master clock (similar to master clock211) to the auxiliary clock (similar to auxiliary clock212) corresponding toPP port325. Further,BC302 reconfiguresPTP port325 from PP state to slave state. Thus,BC302 has selectedPTP port325 to be its new slave port. Here, althoughGM301 remains the main remote master clock, the time codes which BC302 now syncs its local master clock to are those received via thenew slave port325.

The amount oftime BC302 requires to sync its local master clock to the new main remote master clock is less than the amount of time that a conventional PTP device would require becauseBC302 is able to sync its local master clock to the auxiliary clock prior to syncing the local master clock to the new main remote master clock. In one embodiment, BC302 also applies a phase slope limit (similar to phase slope limit214) to the local master clock when the local master clock starts syncing to the auxiliary clock. In this way, the phase change in the local master clock can be controlled such that it would not disturb the timing of the downstream PTP devices (in this example,BC305,SOOC308,BC306, and SOOC309).

As described above, by using mechanisms of the present invention,BC302 is able to handlefault388 such that it is transparent to all downstream PTP devices. Here,BC302 selects a PP port such that it prevents a new synchronization tree from forming when the PP port is reconfigured to be a slave port. By preventing the synchronization tree from changing, sync time is reduced.BC302 further reduces the sync time by using time codes received viaPTP port325 while it was in the PP state to sync the auxiliary clock to the monitored remote master clock. To avoid disturbing the timing of downstream PTP devices,BC302 applies a phase slope limit to control the phase change of the master clock.

Althoughfault388 has been described as the cause forBC302 failing to receive time codes viaS port324, one having ordinary skill in the art would recognize that the present invention is not limited to any particular type of fault. Embodiments of the present invention apply equally to any failure that prevents BC302 from receiving time codes viaS port324.

Referring now back toFIG. 3A for a moment. As described above,S port375 ofBC307 is communicatively coupled toM port342 ofBC304. Thus, from the perspective ofBC307,BC304 is the main remote master clock.BC307 includes two PTP passive ports (i.e.,PTP ports371 and374).BC307 has identified (e.g., by utilizing a PP port identifier similar to PP port identifier205) PTPpassive port374 as a PP port because PTPpassive port374 is communicatively coupled to a PTP device which has a stepsRemoved value of one less than the stepsRemoved value ofBC307. Here,BC303 has a stepsRemoved value of 1 andBC307 has a stepsRemoved value of 2. Thus, from the perspective ofBC307,BC303 is the monitored remote master clock. As such, the clock manager (similar to clock manager210) ofBC307 utilizes time codes received in PTP timing messages (e.g., Sync messages) from BC303 viaPP port374 to sync an auxiliary clock (similar to auxiliary clock212) to the monitored remote master clock.

Referring now toFIG. 3D, which is a blockdiagram illustrating network300 according to one embodiment.Network300 illustrated inFIG. 3D is similar tonetwork300 shown inFIG. 3A, except thatfault390 has occurred. InFIG. 3D, the PTP ports and links in bold are those which are affected byfault390. Due tofault390,BC307 is no longer able to receive PTP messages from its main remote master clock (i.e., BC304) viaS port375. The failure to receive time codes prevents BC307 from syncing its local master clock (similar to master clock211) toBC304 viaS port375. As a result, BC307 must select a new PTP port to be a slave port.

When a conventional PTP device switches to a new slave port (as illustrated inFIG. 1C), there is a possibility that a re-convergence may occur (i.e., a new synchronization tree may be formed), and as a result all downstream PTP devices are affected. For example, inFIG. 1C, whenBC102 selectsPTP port123 as the new slave port, BC102 changes from being one BC level away fromGM101 to three BC levels away fromGM101. This in turn requires all affected downstream PTP devices to select new master and slave ports. Such a re-convergence process requires a long time in order for all clocks in the network to settle to a reliable/accurate state. Embodiments ofBC307 overcome these limitations by selecting PTP port374 (as opposed to PTP port371) as the PP port becausePTP port374 is communicatively coupled to a remote PTP device (in this example, BC303) that has a stepsRemoved value of one less than the stepsRemoved value ofBC307. By selecting PTP port374 (as opposed to PTP port371) as the PP port,BC307 is able to prevent a re-convergence of the synchronization tree when the PP port is reconfigured to be a slave port. Here, beforeBC307 selects the new slave port,BC307 is two BC levels away fromGM301. AfterBC307 selects the new slave port (i.e., PTP port374), BC307 remains two BC levels away fromGM301. The synchronization tree remains unaffected by the selection of the new slave port, preventing all downstream PTP devices from having to select new master and slave ports. Thus, by utilizing mechanisms of the present invention,BC307 is able to prevent the formation of a new synchronization tree, thereby reducing the amount of time required by downstream PTP devices to sync up to the new master clock. Note that a conventional PTP device, without the benefits ofPP port identifier205 of the present invention, may selectPTP port371 as the new slave port. This would cause a re-convergence of the synchronization tree becauseBC307 would be three BC levels away from GM301 (i.e., one more BC level away fromGM301 as compared to before the new slave port was selected).

In one embodiment, in response to determining a failure to receive time codes from the main remote master clock via S port375 (e.g., due to fault390),BC307 reconfiguresPTP port375 from slave state to master state.BC307 starts syncing its local master clock (similar to master clock211) to the auxiliary clock (similar to auxiliary clock212) corresponding toPP port374. Further,BC307 reconfiguresPTP port374 from PP state to slave state. Thus,BC307 has selectedPTP port374 to be its new slave port, and the time codes which BC307 now syncs its local master clock to are those received vianew slave port374.

The amount oftime BC307 requires to sync its local master clock to the new main remote master clock is less than the amount of time that a conventional PTP device would require becauseBC307 is able to sync its local master clock to the auxiliary clock prior to syncing the local master clock to the new main remote master clock. In one embodiment, BC307 also applies a phase slope limit (similar to phase slope limit214) to the local master clock when the local master clock starts syncing to the auxiliary clock. In this way, the phase change in the local master clock can be controlled such that it would not disturb the timing of the downstream PTP devices (in this example, SOOC310).

As described above, by using mechanisms of the present invention,BC307 is able to handlefault390 such that it is transparent to all downstream PTP devices. Here,BC307 selects a PP port such that it prevents a new synchronization tree from forming when the PP port is reconfigured to be a slave port. By preventing the synchronization tree from changing, sync time is reduced.BC307 further reduces the sync time by using time codes received viaPTP port374 while it was in the PP state to sync the auxiliary clock to the monitored remote master clock. To avoid disturbing the timing of downstream PTP devices,BC307 applies a phase slope limit to control the phase change of the master clock.

Althoughfault390 has been described as the cause forBC307 failing to receive time codes viaS port375, one having ordinary skill in the art would recognize that the present invention is not limited to any particular type of fault. Embodiments of the present invention apply equally to any failure that prevents BC307 from receiving time codes viaS port375.

FIG. 4 is a flowdiagram illustrating method400 for maintaining an auxiliary clock according to one embodiment. For example,method400 can be performed byPP port identifier205 andclock manager210, which can be implemented in software, firmware, hardware, or any combination thereof. The operations of this and other flow diagrams will be described with reference to the exemplary embodiments of the other diagrams. However, it should be understood that the operations of the flow diagrams can be performed by embodiments of the invention other than those discussed with reference to these other diagrams, and the embodiments of the invention discussed with reference to these other diagrams can perform operations different than those discussed with reference to the flow diagrams.

Referring now toFIG. 4, atblock405, the PP port identifier determines a plurality of PTP passive ports associated with a local network device, wherein each of the plurality of PTP passive ports is communicatively coupled to a corresponding peer PTP master port. For example, the PP port identifier ofnetwork device307 determinesPTP ports371 and374 as PTP passive ports which communicatively couple to corresponding peerPTP master ports363 and333, respectively.

Atblock410, the PP port identifier selects, from the determined plurality of PTP passive ports, one or more PTP passive ports wherein the corresponding peer PTP master port is associated with a remote network device that has a stepsRemoved value that is one less than a stepsRemoved value of the local network device. For example, the PP port identifier ofnetwork device307 identifies PTPpassive port374 as having a peerPTP master port333 associated withremote network device303 which has a stepsRemoved value of one less than the stepsRemoved value ofnetwork device307. Here,network device303 has a stepsRemoved value of one, andnetwork device307 has a stepsRemoved value of two.

Atblock415, the PP port identifier optionally configures all PTP passive ports of the selected PTP passive ports to be PP ports. For example, the PP port identifier ofnetwork device307 configures PTPpassive port374 to be the PP port. Alternatively, atblock420, the PP port identifier configures a predetermined number of the selected PTP passive ports with a corresponding peer PTP master port that has a lowest port identity to be a PP port. For example, ifnetwork device307 included multiple PTP passive ports that communicatively coupled to PTP devices having a stepsRemoved value that is one less than the stepsRemoved value ofnetwork device307, the PP port identifier ofnetwork device307 can configure a predetermined number of such PTP passive ports to be PP ports. Here, the predetermined number can be a percentage or raw number.

Atblock425, the clock manager maintains an auxiliary clock for each PP port using timing information included in timing messages received via the respective PP port. For example, the clock manager ofnetwork device307 utilizes time codes included in PTP timing messages (e.g., PTP Sync messages) received fromnetwork device303 viaPP port374 to maintain an auxiliary clock.

FIG. 5 is a flowdiagram illustrating method500 for reducing the time required for a PTP device to sync to a new master clock, according to one embodiment. For example,method500 can be performed byclock manager210, which can be implemented in software, firmware, hardware, or any combination thereof.

Referring now toFIG. 5, atblock505, the clock manager synchronizes a local PTP master clock to a first PTP master clock maintained by a first remote network device utilizing timing information included in timing messages received from the first remote network device via a PTP slave port associated with a local network device. For example, the clock manager ofnetwork device307 synchronizes its local PTP master clock to the PTP master clock maintained bynetwork device304 using time codes included in PTP timing messages (e.g., PTP Sync messages) received fromnetwork device304 viaPTP slave port375.

Atblock510, the clock manager maintains a local auxiliary clock for each protective passive (PP) port, wherein each auxiliary clock synchronizes its frequency to a respective monitored master clock using information included in PTP timing messages received via each respective PP port. For example, the clock manager ofnetwork device307 maintains an auxiliary clock corresponding toPP port374, by syncing the auxiliary clock to the PTP master clock maintained bynetwork device303 using time codes included in PTP timing messages (e.g., PTP Sync messages) received fromnetwork device303 viaPP port374.

Atblock515, the clock manager determines a failure to receive timing messages from the first remote network device via the PTP slave port associated with the local network device. For example, the clock manager ofnetwork device307 determines that PTP timing messages can no longer be received fromnetwork device304 via S port375 (e.g., due to fault390).

Atblock520, the clock manager configures the PTP slave port to be a PTP master port, and configure a first PP port associated with the local network device to be a new PTP slave port, wherein the first PP port is communicatively coupled to a second remote network device. For example, the clock manager ofnetwork device307 configuresPTP slave port375 to be a master port, and configuresPP port374 to be a new slave port.

Atblock525, the clock manager synchronizes the local master clock frequency to the frequency of the auxiliary clock corresponding to the first PP port, using phase slope limiting to control the timing disturbance to downstream slave devices. For example, the clock manager ofnetwork device307 syncs the frequency of the local master clock to the frequency of the auxiliary clock corresponding toPP port374, using a phase slope limit (similar to phase slope limit214) to control the phase change of the local master clock.

Atblock530, the clock manager synchronizes the local master clock to the monitored master clock corresponding to the first PP port using timing information included in PTP timing messages received via the new PTP slave port. For example, the clock manager ofnetwork device307 syncs the local master clock to the master clock maintained bynetwork device303 using time codes included in PTP timing messages (e.g., PTP Sync messages) received vianew slave port374.

Some portions of the preceding detailed descriptions have been presented in terms of algorithms and symbolic representations of transactions on data bits within a computer memory. These algorithmic descriptions and representations are the ways used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, conceived to be a self-consistent sequence of transactions leading to a desired result. The transactions are those requiring physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, principally for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

It should be borne in mind, however, that all of these and similar terms are to be associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless specifically stated otherwise as apparent from the above discussion, it is appreciated that throughout the description, discussions utilizing terms such as “processing” or “computing” or “calculating” or “determining” or “displaying” or the like, refer to the action and processes of a computer system, or similar electronic computing device, that manipulates and transforms data represented as physical (electronic) quantities within the computer system's registers and memories into other data similarly represented as physical quantities within the computer system memories or registers or other such information storage, transmission or display devices.

The algorithms and displays presented herein are not inherently related to any particular computer or other apparatus. Various general-purpose systems may be used with programs in accordance with the teachings herein, or it may prove convenient to construct more specialized apparatus to perform the required method transactions. The required structure for a variety of these systems will appear from the description above. In addition, embodiments of the present invention are not described with reference to any particular programming language. It will be appreciated that a variety of programming languages may be used to implement the teachings of embodiments of the invention as described herein.

In the foregoing specification, embodiments of the invention have been described with reference to specific exemplary embodiments thereof. It will be evident that various modifications may be made thereto without departing from the broader spirit and scope of the invention as set forth in the following claims. The specification and drawings are, accordingly, to be regarded in an illustrative sense rather than a restrictive sense.

Throughout the description, embodiments of the present invention have been presented through flow diagrams. It will be appreciated that the order of transactions and transactions described in these flow diagrams are only intended for illustrative purposes and not intended as a limitation of the present invention. One having ordinary skill in the art would recognize that variations can be made to the flow diagrams without departing from the broader spirit and scope of the invention as set forth in the following claims.

Claims (24)

What is claimed is:

1. A method in a first network device for supporting Precision Time Protocol (PTP) in a network, the method comprising:

receiving, by a first PTP port associated with the first network device configured as a PTP slave port, PTP timing messages from a second PTP port associated with a second network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the second network device;

maintaining a PTP master clock based on the timing information included in the PTP timing messages received from the second network device via the first PTP port;

receiving, by a third PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from a fourth PTP port associated with a third network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the third network device;

determining the third PTP port is a protective passive port based on a stepsRemoved value associated with the third network device, wherein a stepsRemoved value indicates a number of boundary clock levels a respective network device is away from a PTP grandmaster clock of the network; and

in response to determining the third PTP port is a protective passive port, maintaining a PTP auxiliary clock based on the timing information included in the PTP timing messages received from the third network device via the third PTP port, wherein in an event that the first network device fails to receive PTP timing messages from the second network device via the first PTP port, the PTP auxiliary clock is utilized by the first network device to synchronize its PTP master clock to the PTP master clock maintained by the third network device.

2. The method ofclaim 1, wherein determining the third PTP port is a protective passive port comprises:

determining the third network device has a stepsRemoved value that is one less than a stepsRemoved value of the first network device.

3. The method ofclaim 2, further comprising:

receiving, by a fifth PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from a sixth PTP port associated with a fourth network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the fourth network device; and

in response to determining the fourth network device has a stepsRemoved value that is equal to a stepsRemoved value of the first network device, determining the fifth PTP port is a non-protective passive port.

4. The method ofclaim 1, wherein determining the third PTP port is a protective passive port comprises:

receiving, by a fifth PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from a sixth PTP port associated with a fourth network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the fourth network device;

determining the third network device has a stepsRemoved value that is equal to a stepsRemoved value of the fourth network device; and

determining the fourth PTP port has a port identity (ID) that is less than a port ID of the sixth PTP port associated with the fourth network device.

5. The method ofclaim 1, further comprising:

in response to determining a failure to receive PTP timing messages from the second network device via the first PTP port:

configuring the first PTP port to be a PTP master port,

configuring the third PTP port to be a PTP slave port, and

utilizing information of the PTP auxiliary clock to synchronize the PTP master clock maintained by the first network device to the PTP master clock maintained by the third network device.

6. The method ofclaim 5, further comprising applying a phase slope limit to the PTP master clock maintained by the first network device after the third PTP port has been configured to be a PTP slave port.

7. The method ofclaim 1, wherein the second network device and the third network device are a same network device configured to serve as a PTP grandmaster clock of the network.

8. The method ofclaim 1, wherein the second network device and the third network device are different network devices, wherein the second network device and the third network device are configured to serve as a PTP boundary clock of the network.

9. A first network device for supporting Precision Time Protocol (PTP) in a network, the first network device comprising:

a first PTP port associated with the first network device configured as a PTP slave port, operative to receive PTP timing messages from a second PTP port associated with a second network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the second network device;

a third PTP port associated with the first network device configured as a PTP passive port, operative to receive PTP timing messages from a fourth PTP port associated with a third network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the third network device;

a set of one or more processors; and

a non-transitory machine-readable storage medium containing instructions, which when executed by the set of one or more processors, cause the first network device to:

maintain a PTP master clock based on the timing information included in the PTP timing messages received from the second network device via the first PTP port,

determine the third PTP port is a protective passive port based on a stepsRemoved value associated with the third network device, wherein a stepsRemoved value indicates a number of boundary clock levels a respective network device is away from a PTP grandmaster clock of the network, and

in response to determining the third PTP port is a protective passive port, maintain a PTP auxiliary clock based on the timing information included in the PTP timing messages received from the third network device via the third PTP port, wherein in an event that the first network device fails to receive PTP timing messages from the second network device via the first PTP port, the PTP auxiliary clock is utilized by the first network device to synchronize its PTP master clock to the PTP master clock maintained by the third network device.

10. The first network device ofclaim 9, wherein the instructions that cause the first network device to determine the third PTP port is a protective passive port comprises instructions, which when executed by the set of one or more processors, cause the first network device to determine the third network device has a stepsRemoved value that is one less than a stepsRemoved value of the first network device.

11. The first network device ofclaim 10, further comprising:

a fifth PTP port associated with the first network device configured as a PTP passive port, operative to receive PTP timing messages from a sixth PTP port associated with a fourth network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the fourth network device, wherein

the non-transitory machine-readable storage medium further containing instructions, which when executed by the set of one or more processors, cause the first network device to in response to determining the fourth network device has a stepsRemoved value that is equal to a stepsRemoved value of the first network device, determine the fifth PTP port is a non-protective passive port.

12. The first network device ofclaim 9, further comprising:

a fifth PTP port associated with the first network device configured as a PTP passive port, operative to receive PTP timing messages from a sixth PTP port associated with a fourth network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the fourth network device, wherein the instructions that cause the first network device to determine the third PTP port is a protective passive port comprises instructions,

which when executed by the set of one or more processors, cause the first network device to:

determine the third network device has a stepsRemoved value that is equal to a stepsRemoved value of the fourth network device, and

determine the fourth PTP port associated with the third network device has a port identity (ID) that is less than a port ID of the sixth PTP port associated with the fourth network device.

13. The first network device ofclaim 9, wherein the non-transitory machine-readable storage medium further containing instructions, which when executed by the set of one or more processors, cause the first network device to in response to determining a failure to receive PTP timing messages from the second network device via the first PTP port:

configure the first PTP port to be a PTP master port,

configure the third PTP port to be a PTP slave port, and

utilize information of the PTP auxiliary clock to synchronize the PTP master clock maintained by the first network device to the PTP master clock maintained by the third network device.

14. The first network device ofclaim 13, wherein the non-transitory machine-readable storage medium further containing instructions, which when executed by the set of one or more processors, cause the first network device to apply a phase slope limit to the PTP master clock maintained by the first network device after the third PTP port has been configured to be a PTP slave port.

15. The first network device ofclaim 9, wherein the second network device and the third network device are a same network device configured to serve as a PTP grandmaster clock of the network.

16. The first network device ofclaim 9, wherein the second network device and the third network device are different network devices, wherein the second network device and the third network device are configured to serve as a PTP boundary clock of the network.

17. A non-transitory computer-readable storage medium having computer instructions stored therein, which when executed by a processor of a first network device for supporting Precision Time Protocol (PTP) in a network, cause the first network device to perform operations comprising:

receiving, by a first PTP port associated with the first network device configured as a PTP slave port, PTP timing messages from a second PTP port associated with a second network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the second network device;

maintaining a PTP master clock based on the timing information included in the PTP timing messages received from the second network device via the first PTP port;

receiving, by a third PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from a fourth PTP port associated with a third network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the third network device;

determining the third PTP port is a protective passive port based on a stepsRemoved value associated with the third network device, wherein a stepsRemoved value indicates a number of boundary clock levels a respective network device is away from a PTP grandmaster clock of the network; and

in response to determining the third PTP port is a protective passive port, maintaining a PTP auxiliary clock based on the timing information included in the PTP timing messages received from the third network device via the third PTP port, wherein in an event that the first network device fails to receive PTP timing messages from the second network device via the first PTP port, the PTP auxiliary clock is utilized by the first network device to synchronize its PTP master clock to the PTP master clock maintained by the third network device.

18. The non-transitory computer-readable storage medium ofclaim 17, wherein determining the third PTP port is a protective passive port comprises:

determining the third network device has a stepsRemoved value that is one less than a stepsRemoved value of the first network device.

19. The non-transitory computer-readable storage medium ofclaim 18, the operations further comprising:

receiving, by a fifth PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from a sixth PTP port associated with a fourth network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the fourth network device; and

in response to determining the fourth network device has a stepsRemoved value that is equal to a stepsRemoved value of the first network device, determining the fifth PTP port is a non-protective passive port.

20. The non-transitory computer-readable storage medium ofclaim 17, wherein determining the third PTP port is a protective passive port comprises:

receiving, by a fifth PTP port associated with the first network device configured as a PTP passive port, PTP timing messages from a sixth PTP port associated with a fourth network device configured as a PTP master port, wherein the PTP timing messages include timing information of a PTP master clock maintained by the fourth network device;

determining the third network device has a stepsRemoved value that is equal to a stepsRemoved value of the fourth network device; and

determining the fourth PTP port has a port identity (ID) that is less than a port ID of the sixth PTP port associated with the fourth network device.

21. The non-transitory computer-readable storage medium ofclaim 17, the operations further comprising:

in response to determining a failure to receive PTP timing messages from the second network device via the first PTP port:

configuring the first PTP port to be a PTP master port,

configuring the third PTP port to be a PTP slave port, and

utilizing information of the PTP auxiliary clock to synchronize the PTP master clock maintained by the first network device to the PTP master clock maintained by the third network device.

22. The non-transitory computer-readable storage medium ofclaim 21, the operations further comprising applying a phase slope limit to the PTP master clock maintained by the first network device after the third PTP port has been configured to be a PTP slave port.

23. The non-transitory computer-readable storage medium ofclaim 17, wherein the second network device and the third network device are a same network device configured to serve as a PTP grandmaster clock of the network.

24. The non-transitory computer-readable storage medium ofclaim 17, wherein the second network device and the third network device are different network devices, wherein the second network device and the third network device are configured to serve as a PTP boundary clock of the network.

Images