WO2017130034A1 - A method of timing loop prevention for the precision time protocol (ptp) with g.8275.1 profile - Google Patents

A method of timing loop prevention for the precision time protocol (ptp) with g.8275.1 profile Download PDF

Info

Publication number
WO2017130034A1
WO2017130034A1 PCT/IB2016/050860 IB2016050860W WO2017130034A1 WO 2017130034 A1 WO2017130034 A1 WO 2017130034A1 IB 2016050860 W IB2016050860 W IB 2016050860W WO 2017130034 A1 WO2017130034 A1 WO 2017130034A1
Authority
WO
WIPO (PCT)
Prior art keywords
clock
network node
identifier
local
port
Prior art date
Application number
PCT/IB2016/050860
Other languages
French (fr)
Inventor
Adam FLEETWOOD
Qun Zheng
Kenneth Chung Leung CHAN
Original Assignee
Telefonaktiebolaget Lm Ericsson (Publ)
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Telefonaktiebolaget Lm Ericsson (Publ) filed Critical Telefonaktiebolaget Lm Ericsson (Publ)
Publication of WO2017130034A1 publication Critical patent/WO2017130034A1/en

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0658—Clock or time synchronisation among packet nodes
    • H04J3/0661—Clock or time synchronisation among packet nodes using timestamps
    • H04J3/0667—Bidirectional timestamps, e.g. NTP or PTP for compensation of clock drift and for compensation of propagation delays
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0641—Change of the master or reference, e.g. take-over or failure of the master
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04J—MULTIPLEX COMMUNICATION
    • H04J3/00—Time-division multiplex systems
    • H04J3/02—Details
    • H04J3/06—Synchronising arrangements
    • H04J3/0635—Clock or time synchronisation in a network
    • H04J3/0638—Clock or time synchronisation among nodes; Internode synchronisation
    • H04J3/0644—External master-clock

Definitions

  • Embodiments of the invention relate to the field of packet networks; and more specifically, to clock synchronization over a network.
  • PTP Precision Time Protocol
  • IEEE 1588-2002 Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems
  • PTPv2 PTP Version 2
  • a time distribution system includes one or more communication media (i.e., network segments) and one or more clocks.
  • An ordinary clock is a device typically having a single network connection and is either the source of (i.e., a "master") or destination for (i.e., a "slave") a synchronization reference.
  • a boundary clock typically has multiple network connections and can accurately synchronize one network segment to another.
  • a synchronization master is selected for each of the network segments in the system.
  • the root timing reference is called the grandmaster.
  • the grandmaster transmits synchronization information to the clocks residing on its network segment.
  • the boundary clocks with a presence on that segment can then relay accurate time to the other segments to which they are also connected.
  • Multicast-broadcast single-frequency network in Long Term Evolution (LTE) networks, LTE- Advanced (LTE-A) uplink coordinated multi-point (CoMP) operation, LTE Time-Division Duplex (LTE TDD), etc.
  • MMSFN Multicast-broadcast single-frequency network
  • LTE Long Term Evolution
  • LTE-A LTE- Advanced
  • CoMP uplink coordinated multi-point
  • LTE TDD LTE Time-Division Duplex
  • ITU-T International Telecommunication Union
  • G.8275.1 Telecom Profile was developed as an extension of the PTP IEEE 1588-2008 to provide full timing support.
  • the G.8275.1 profile defines a method of synchronizing frequency and time between network nodes by monitoring a combination of an external Layer 1 ("LI") electrical signal and received timing packets.
  • LI Layer 1
  • Each profile defines a Best Master Clock Algorithm (BMCA) which is to be used by all PTP Clocks within a PTP domain to determine a "best' clock (or "Best-Master") upon which a local clock in the network node is to rely upon.
  • BMCA Best Master Clock Algorithm
  • the Best-Master can be determined by comparing the contents of received Announce messages with the node's own local clock characteristics, referred to as the default data set (defaultDS or "DO").
  • the winning clock is referred to as the Best-Master and is used by the network node as a source of synchronization for the local clock. This is a perpetual process, as received Announce messages and characteristics of the node's local clock may change at any time.
  • the BMCA is used to determine a state of each PTP port coupling the network node to other nodes of the network.
  • a PTP port is a logical access point of a PTP network node for PTP communications to the network.
  • IEEE 1588-2008 specifies that a PTP port can resolve 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. According to the G8275.1 and the IEEE 1588 default profiles, at any given moment, there is a maximum of only one PTP port in a PTP network node that can resolve to be in the slave state.
  • a network node synchronizes a local 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.
  • a "timing loop" refers to a phenomenon where a PTP clock is attempting to synchronize to a timing signal (or a timing clock) that the PTP clock has originated.
  • the Best-Master can be determined by comparing the contents of an Announce message received at the port, a Best External Master determined as well as the node's own local clock's default characteristics (DO).
  • DO node's own local clock's default characteristics
  • G.8275.1 a different mechanism is used to determine the state of a PTP port.
  • the G.8275.1 Profile further introduces two new parameters into the BMCA Algorithm that can contribute to determining the Best-Master of a clock as well as a state of a PTP port: notSlave, and localPriority. "notSlave" is a parameter defined locally for each PTP port.
  • the localPriority settings of a PTP port and the default data set DO are used to determine the Best-Master within a node.
  • This parameter takes precedence over some other parameter (such as a number of hops ("stepsRemoved"), PTP-Clock identities, PTP port identities, and PTP port numbers) which can be used in determining the Best-Master for a clock of the node.
  • the localPriority setting is only known locally (i.e., within the node) and is not advertised to other nodes. Therefore, with respect to remote nodes, the Best-Master and the PTP port states may be determined in a non-reciprocal manner.
  • One general aspect includes a method in a first network node of a precision time protocol (PTP) network of preventing timing loops, where the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node.
  • the method includes receiving, at a first port from the set of ports, an announce message from a second port of a second network node, where the announce message includes an identifier and characteristics of a grandmaster clock, and where the grandmaster clock is a source of time for clock synchronization for a second local clock of the second network node; determining whether the identifier of the grandmaster clock is identical to a local identifier of the first local clock of the first network node.
  • the method continues with in response to determining that the identifier of the grandmaster clock is identical to the local identifier of the first local clock, discarding the announce message received at the first port causing the characteristics of the grandmaster clock to be ignored when determining a best master clock for the first local clock, where the best master clock is to be used as a source of synchronization for the first local clock of the first network node.
  • the method includes using the characteristics of the grandmaster clock when determining the best master clock for the first local clock of the first network node.
  • One general aspect includes a method in a first network node of a precision time protocol (FTP) network of preventing timing loops, where the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node, and where the first local clock of the first network node is synchronized according to a current best master clock,.
  • FTP precision time protocol
  • the method includes determining a new best master clock for the first local clock of the first network node; determining whether a first identifier of the current best master clock for the first local clock is to be included in an exclusion list; and responsive to determining that the first identifier is to be included in the exclusion list, adding the first identifier in the exclusion list causing any announce messages including the first identifier to be ignored during a predetermined period of time when determining a next best master clock for the first local clock of the first network node.
  • One general aspect includes a first network node of a precision time protocol (PTP) network, where the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node.
  • the first network node includes one or more processors and a non-transitory computer readable storage medium, said non-transitory computer readable storage medium containing instructions, which when executed by the one or more processors, causes the first network node to: receive, at a first port from the set of ports, an announce message from a second port of a second network node, where the announce message includes an identifier and characteristics of a grandmaster clock, and where the grandmaster clock is a source of time for clock synchronization for a second local clock of the second network node.
  • PTP precision time protocol
  • the first network node is further to determine whether the identifier of the grandmaster clock is identical to a local identifier of the first local clock of the first network node. In response to determining that the identifier of the grandmaster clock is identical to the local identifier of the first local clock, the first network node is further to discard the announce message received at the first port causing the characteristics of the grandmaster clock to be ignored when determining a best master clock for the first local clock, where the best master clock is to be used as a source of synchronization for the first clock of the first network node.
  • the first network node In response to determining that the identifier of the grandmaster clock is not identical to the local identifier of the first local clock, the first network node is to use the characteristics of the grandmaster clock when determining the best master clock for the first local clock of the first network node.
  • One general aspect includes a first network node of a precision time protocol (PTP) network of preventing timing loops, where the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node, and where the first local clock of the first network node is synchronized according to a current best master clock, and the first network node is to: determine a new best master clock for the first local clock of the first network node; determine whether a first identifier of the current best master clock for the first local clock is to be included in an exclusion list; and responsive to determining that the first identifier is to be included in the exclusion list, to add the first identifier in the exclusion list causing any announce messages including the first identifier to be ignored during a predetermined period of time when determining a next best master clock for the first local clock of the first network node.
  • PTP precision time protocol
  • Figure 1A illustrates an exemplary configuration scenario of network devices resulting in a timing loop due to a local parameter set for PTP ports of the network devices in accordance with some embodiments of the invention.
  • Figure IB illustrates another exemplary configuration scenario of network nodes resulting in a timing loop due to the local priority parameter set for PTP ports of the network nodes in accordance with some embodiments of the invention.
  • Figure 1C is an exemplary configuration scenario of network nodes resulting in a timing loop due to a local parameter set for PTP ports of the network node in accordance with some embodiments of the invention.
  • FIG. 2A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some
  • Figure 2B illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments of the invention.
  • Figure 3B illustrates exemplary operations for processing Announce messages in accordance with some embodiments of the invention.
  • Figure 3C illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments of the invention.
  • FIG. 4A illustrates exemplary operations performed in a network device of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some embodiments of the invention.
  • PTP Precision Time Protocol
  • Figure 4B illustrates exemplary operations of an enhanced BMCA state determination algorithm in accordance with some embodiments of the invention.
  • Figure 4C illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments of the invention.
  • Figure 5A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention.
  • Figure 5B illustrates an exemplary way to implement a special-purpose network device according to some embodiments of the invention.
  • 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.
  • Bracketed text and blocks with dashed borders may be used herein to illustrate optional operations that add additional features to embodiments of the invention. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the invention.
  • 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.
  • a network device which includes a local clock that support PTP i.e., a PTP clock
  • a PTP network node a network device which includes a local clock that support PTP
  • a PTP clock a local clock that support PTP
  • a network node may include multiple local clocks which can be independently synchronized according to PTP and hence include multiple PTP clocks.
  • IEEE 1588-2008, and the G8275.1 profile define three types of PTP clocks: Ordinary Clock (OC), Boundary Clock (BC, and Transparent Clock (TC).
  • An OC includes one PTP port and 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).
  • 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.
  • GMOC Grandmaster-Only Ordinary Clock
  • SOOC Slave-Only Ordinary Clock
  • a BC has more than one PTP ports.
  • a BC receives Announce messages from an upstream master, synchronizes its local time of day to an upstream master, 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.
  • 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.
  • a PTP domain is a logical grouping of PTP clocks communicating with each other using the PTP protocol.
  • PTP domains are used to partition a network within an administrative entity.
  • the PTP messages and data sets are associated with a domain and therefore, the PTP protocol is independent for different domains.
  • a PTP port is a logical access point of a PTP clock for PTP communications to the network.
  • Each PTP clock periodically sends Announce messages via the master PTP ports to other PTP clocks in the same PTP domain.
  • the Announce messages include clock information and an identifier indicating the identity of the sending PTP clock, a number of hops ( stepsRemoved) of the sending PTP clock, and information concerning the grandmaster.
  • a best master clock algorithm (BMCA) executed at each PTP network node utilizes information included in the received Announce messages to determine the role of the local 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 a GM clock within the PTP time domain.
  • PTP messages e.g., PTP Sync messages
  • All PTP clocks (other than the GM) synchronize to a GM clock within the PTP time domain.
  • 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 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.
  • a PTP network node may include one or more PTP ports enabling the PTP network device to be coupled with other network nodes in the network.
  • IEEE 1588-2008 specifies that a PTP port can resolve 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. According to the G8275.1 and the IEEE 1588 default profiles, at any given moment, there is a maximum of only one PTP port in a PTP clock that can resolve to be in the slave state.
  • a PTP clock synchronizes a local 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.
  • a "timing loop” refers to a phenomenon where a PTP clock is attempting to synchronize to a timing signal (or a timing clock) that the PTP clock has originated.
  • a PTP port state is determined by comparing the contents of an Announce message received at the port, a Best External Master determined as well as the node's own local clock's default characteristics that is referred to as default data set or "DO.”
  • DO default data set
  • G.8275.1 a different mechanism is used to determine the state of a PTP port.
  • the G.8275.1 Profile introduces two new parameters into the BMCA Algorithm that contribute to determining the Best-Master of a clock as well as a state of a PTP port: notSlave, and localPriority.
  • "notSlave” is a parameter defined locally for each PTP port.
  • the Announce message that is observed on the PTP port is not used to determine the state of the PTP port.
  • the PTP port cannot placed in the slave state and it is simply put into a master state, and thus, will advertise the current Best Master of the node.
  • the notSlave parameter ensures that a PTP port will always enter into a master state irrespective of the Announce message that is observed locally.
  • this parameter is only known locally; other nodes within a PTP network will not know the incapability of the PTP port to enter into a slave state.
  • the localPriority parameter is a local per-port attribute.
  • the localPriority settings of a PTP port is used in combination with other parameters to determine the Best- Master within a node. This parameter takes precedence over some other parameters/attributes (such as a number of hops ("stepsRemoved"), PTP-Clock-Identities, PTP port identities, and PTP port numbers) which can be used in determining the Best-Master of the node.
  • the localPriority parameter is only known locally (i.e., within the node) and is not advertised to other nodes. Therefore, with respect to remote nodes, the Best-Master and the PTP port states may be determined in a non-reciprocal manner.
  • FIG. 1A illustrates an exemplary configuration scenario of network devices resulting in a timing loop due to a local parameter set for PTP ports of the network devices in accordance with some embodiments.
  • Figure 1A illustrates operations at three moments in time: Time 1 (Tl), Time 2 (T3), and Time 3 (T3).
  • TBCs telecom boundary clocks
  • T-BCs telecom boundary clocks
  • I initialing state
  • a local priority parameter e.g.,
  • the network node 101 comes online first. Then 102 is initialized and receives an Announce message from network node 101.
  • the configured local priority value of the receiving port is appended to the Announce message and considered within the BMCA.
  • port 121 receives the Announce message from port 111.
  • the BMCA running on the network node 102 determines a best master clock for the clock of the network node and the states of the ports based on the Announce messages and local properties.
  • the BMCA compares the timing characteristics of the clock (received in the Announce message) received from port with the characteristics received at port 122 from 112, as well as with the default data set DO of the local clock, while considering the local priority parameter of the ports.
  • the BMCA of G8275.1 profile all characteristics of the two clocks (i.e., of network nodes 101 and 102) are identical, the deciding factor for determining the best master for the clock of network node 102 is the local priority parameter.
  • the port 121 resolves to a slave state, while forcing the port 122 to resolve to a master state.
  • An Announce message is then advertised, at operation (d), from port 122 to port 112, which causes the state of the port 112 to resolve to a slave state caused by the local priority value of port 112 being set to 1.
  • the local priority parameter takes precedence in the BMCA over some of the other state determining factors, a timing loop occurs, and persists between the two network nodes.
  • the present exemplary scenario 1 may be considered a misconfiguration of the network nodes
  • the topology presented in the scenario of Figure 1 A is exemplary only and that different (e.g., more complicated) topologies may allow similar timing loops to occur without a misconfiguration being apparent.
  • Figure IB illustrates another exemplary configuration scenario of network nodes resulting in a timing loop due to the local priority parameter set for PTP ports of the network nodes in accordance with some embodiments.
  • the arrows 250, 251, 252, 253, and 254 indicate the order and direction of propagation of Announce messages from a port of a first node to a peer port in another node.
  • the arrow 270 indicates the direction of the synchronization process of the clocks within the PTP domain including the nodes 201, 202, 203, and 204.
  • the network node 201 broadcasts an Announce message 250 through the master port 211 including information indicating characteristics of a grandmaster clock (GM).
  • GM grandmaster clock
  • the grandmaster of the PTP domain is the network node 201, thus the identifier of the grandmaster clock transmitted within the Announce message 250 is the identifier of the local clock of the network node 201.
  • the characteristics of the grandmaster clock of network node 201 is propagated to network node 203 and 204 through the Announce messages 251, 252 and 253. These Announce messages are used to determine a best master clock for synchronizing the respective clocks of the other network nodes of the PTP domain (i.e., network nodes 202, 203, and 204).
  • network node 204 This causes network node 204 to transmit in the Announce message 263 to network node 202 the characteristics of grandmaster clock of network node 201 even though the grandmaster clock of network node 201 is no longer valid due to the interruption of the connection resulting in a timing loop.
  • This timing loop would not be considered to be a network misconfiguration.
  • the PTP port 242 in network node 204 remains in a master state as the PTP port 241 is simply "better", and not “better by topology" due to its local priority setting. This temporary timing loop will persist for up to 32 seconds.
  • the 32 second period is a product of the maximum time between Announce messages (1/8 seconds), and the maximum tolerated number of hops (i.e., StepsRemoved (which is 255, as defined in the ITU-T G.8275.1 Profile Recommendation).
  • Figure 1C is an exemplary configuration scenario of network nodes resulting in a timing loop due to a local parameter set for PTP ports of the network node in accordance with some embodiments.
  • the timing loop is possible due to the lack of configuration of the notSlave attribute.
  • the arrows 350, 351, 352, 353, and 354 indicate the order and direction of propagation of Announce messages from a port of a first node to a peer port in another node of the PTP domain.
  • the arrow 370 indicates the direction of the synchronization process of the clocks within the PTP domain including the devices 301, 302, 303, and 304.
  • the network node 301 broadcasts an Announce message 350 through the master port 311 including characteristics of a grandmaster clock (GM).
  • GM grandmaster clock
  • the grandmaster of the PTP domain is the network node 301, thus the clock identity of the grandmaster transmitted within of the Announce message 350 is the clock identity of the local clock of the network node 301 as identified in the default data set of the local clock of the network node 301.
  • the grandmaster clock of network device 301 is propagated to network node 303 and 304 through the Announce messages 351, 352 and 353.
  • the Announce messages are used in determination of best master clocks for synchronizing the clocks of the other network nodes of the PTP network.
  • the loss of connection between network node 301 and network node 302 at time T2 e.g., An Announce Receipt Timeout occurs on network node 302 from the GM 301
  • the lack of configuration of the port 341 with a notSlave attribute causes the Announce message received from network node 303 (Which still includes an identifier of the grandmaster clock of network node 301) to be considered for the best master clock at time T2 from the perspective of network node 304.
  • Timing loop 371 This causes network node 304 to transmit in the Announce message 363 to network node 302 the characteristics of grandmaster clock of network node 301 even though the grandmaster clock of network node 301 is no longer valid due to the interruption of the connection resulting in a timing loop 371.
  • the timing loop is temporary however it persists for up to 32 seconds at which point network node 302 will break the loop as the number of hope (or steps removed) will have reached 255.
  • a node can enter into a Holdover state for multiple reasons, a common reason being when Announce messages are no longer received from the selected Best-Master.
  • the Holdover state has two sub-states: Holdover-In-Specification (HO-IS), and Holdover-Out-of-Specification (HO-OoS).
  • HO-IS Holdover-In-Specification
  • HO-OoS Holdover-Out-of-Specification
  • network node 302 may enter into a holdover node (e.g., it may enter a holdover-in-specification mode), and network node 303 and network node 304 will synchronize to network node 302 holdover clock.
  • the clock of network node 302 degrades to a holdover-out-of-specification clock, then the timing loop will repeat itself.
  • timing loops may be caused by the use of local parameters (e.g., localPriority and notSlave parameters) configured for PTP ports of a network node, which are not shared with other nodes of the PTP domain in Announce messages.
  • the local parameters are introduced with the G8275.1 profile.
  • the timing loops may be due to other causes (e.g., misconfigurations, failures of network nodes, etc.).
  • Figure 2A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some embodiments.
  • PTP Precision Time Protocol
  • the network node is a first network node which includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node.
  • the default characteristics e.g., "defaultDS,” which can also be referred to as DO
  • DO includes information that describes the characteristics of the first local clock of the network node with respect to the clock
  • the default characteristics includes a local identifier of the first local clock (e.g., "defaultDS. clockldentity" as defined in IEEE 1588-2008) and other parameter values defining characteristics of the first local clock that can be used in the BMCA to compare clocks and determine a best master clock for the first local clock.
  • the first network node one or more applications can run according to the first local clock.
  • the first network node is similar to network node 102 or 101 from Figures 1A, 2B, and Figures 5A-B.
  • the network node receives, at a first PTP port from the set of ports, a PTP Announce message from a second PTP port of a second network node, where the PTP Announce message includes an identifier and characteristics of a grandmaster clock.
  • the identifier of the grandmaster clock is a value that uniquely identifies, within the PTP domain, the clock that serves as a source of synchronization for a second local clock of the second network node (i.e., the network node transmitting the PTP Announce message).
  • the identifier can be included in a "grandmasterldentity" field of the PTP Announce message as defined in the different versions of the IEEE 1588 standard and the G8271.5 profile.
  • the local identifier of the first local clock is a value that uniquely identifies the local clock within the PTP domain.
  • the local identifier of the first local clock can be included in the "defaultDS.clockldentity" field as defined in the different versions of the IEEE 1588 standard and the G8271.5 profile.
  • Erbest an external best master clock on the first PTP port
  • a value of a local priority parameter of the first PTP port is configured to be of higher precedence than other local priority parameter values of the first network node.
  • the local priority parameter value of the first PTP port indicates that clock characteristics included in PTP Announce messages received at the first PTP port are to be used when determining the PTP best master clock of the first network node.
  • the local priority parameter is a local attribute used in the BMCA for the determination of the external best master for a port (Erbest) and in the determination of the external best master for a node (Ebest).
  • a local priority value can be assigned for each PTP port, as well as for a local clock of the network node.
  • Each Announce message received on a port is appended with the local priority value set for that port before a data set comparison algorithm (as performed within the BMCA) is invoked.
  • the local priority parameter is not transmitted in PTP Announce messages.
  • This attribute is used as a tie-breaker in the data set comparison algorithm, in the event that all other previous attributes of the data sets being compared are equal.
  • the local priority attribute is set via the configurable, unsigned integer, port data set member "portDS.localPriority.”
  • the data type for this attribute is UInteger8.
  • the range of values for this attribute is ⁇ 1-255 ⁇ with a default value being set at 128.
  • LP local priority
  • the embodiments present a mechanism in which a local clock of a network node is no longer forced to use the clock characteristics of the Announce messages received at a PTP port which has a local priority of higher precedence than the rest of the PTP ports in the node and the local clock of the node.
  • the network node discards the PTP Announce message received at the first PTP port regardless of the value of the local priority parameter of the first PTP port causing the characteristics of the grandmaster clock of the local clock of the second network node to be ignored when determining the PTP best master clock for the first local clock of the first network node even if the local priority of the port is of higher precedence than the rest of the PTP ports and the first local clock of the node.
  • discarding the PTP Announce message results in avoiding timing loops that would otherwise occur when a value of the local priority parameter of the first PTP port is of higher precedence than other local priority parameter values in the first network node.
  • Figure 2B illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments.
  • Figure 2B illustrates network node 101 and network node 102 of Figure 1 A with similar initial configuration settings.
  • the same reference numbers are retained for corresponding operations.
  • the exemplary scenario 1 of Figure 2B will be described with reference to the operations of the flow diagram of Figure 2A. However, it should be understood that the operations of the flow diagram can be performed by embodiments of the invention other than those discussed with reference to Figure 2B, and the embodiments of the invention discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagram.
  • FIG 2B illustrates operations at three moments in time: Time 1 (Tl), Time 2 (T2), and Time 3 (T3).
  • TBCs, or T-BCs the two telecom boundary clocks (TBCs, or T-BCs) of Figure 1A are illustrated (101, and 102), each of which includes two PTP ports that can act either as a "Master” or “Slave” (or Passive) depending upon circumstance, illustrated herein as boxes “M” and "S.”
  • TTCs telecom boundary clocks
  • the value of the local priority parameter for port 112 and port 121 indicates that clock characteristics included in PTP Announce messages received at each of one of these ports are to be used when determining the PTP best master clock of the first network node.
  • the network node 101 comes online first. Then network node 102 is initialized and receives an Announce message from network node 101. At time Tl, the Announce message is received at port 121 and port 122 from ports 111 and 122 respectively.
  • the configured LP of the receiving port e.g., 121 is appended to the Announce message and considered within the BMCA.
  • the BMCA running on the network node 102 determines, at operation cl, whether an identifier of a grandmaster clock included in the Announce Message (e.g., "grandmasterldentity") is identical to an identifier of the local clock (e.g., "defaultDS.clockldentity") of the network node 102.
  • the identifier of the grandmaster clock (GM-ID) included in the Announce message sent by network node 101 is different from the identifier of the local clock (Clock-ID) of network node 102.
  • the identifier of the grandmaster for network node 101 is clock identifier of the local clock of network node 101 which is different from the identifier of the local clock of network node 102.
  • a best master clock for the network node 102 and port states are determined based on the Announce messages and local settings (in other words the network node may use the clock characteristics received in the Announce message from the second network node when determining the PTP best master clock for the local clock of the first network node).
  • the network node 102 compares the timing characteristics of the grandmaster clock received from port 111 with the characteristics received at port 122 from port 112, as well as with the characteristics of its local clock (i.e., characteristics included in the default data set DO of the local clock of network node 102), and considers the local priority parameter of the ports when determining the best master clock for the local clock of the network node 102 and the states of the ports 121 and 122.
  • the BMCA considers a set of attributes set for each local clock within the PTP domain. For example, the BMCA considers values of a clock class parameter, values of a clock accuracy parameter, values of a variance parameter (e.g., "offsetScaledLogVariance"), and values of a priority parameter (e.g., "priority2"). According to the BMCA of G8275.1 profile, all these attributes of the two clocks (i.e., local clocks of network node 101 and 102) are identical.
  • the deciding factor for determining the best master for network node 102 is the value of the local priority. Since the value of the local priority of port 121 is set to 1, the best master clock for the node is determined to be the grandmaster clock received in the Announce message received at port 121. The state of port 121 resolves to a slave state, while forcing the state of port 122 to resolve to a master state.
  • the local clock of network node 102 is synchronized with the grandmaster of network node 101 and corresponding data sets which represent the current characteristics of the local clock are updated for the network node 102 (e.g., a current data set "currentDS"; a parent data set "parentDS”; and timePropertiesDS). Further an Announce message is then advertised from port 122 to port 112 at operation (d), including the identifier of the grandmaster clock, which is the identifier of the local clock of network node 101.
  • network node 101 determines at operation (el) whether the identifier of the grandmaster clock included in the Announce message (e.g., included in a "grandmasterldentity" field of the PTP Announce message) received from port 122 is identical to the identifier of the local clock of network node 101. Since the local clock of network node 101 was selected as a best master clock at network node 102, the identifier of the grandmaster clock received at port 112 from port 122 is identical to the identifier of the local clock of network node 101.
  • the identifier of the grandmaster clock included in the Announce message e.g., included in a "grandmasterldentity" field of the PTP Announce message
  • discarding the PTP Announce message results in avoiding timing loops that would have otherwise been caused by the value of the local priority parameter of the first PTP port being of higher precedence than other local priority parameter values in the first network node.
  • a current best master clock used to synchronize the local clock of a network node can change for multiple reasons. For example the receipt of a Loss- Announce message, the Ebest selected as the best master is determined to be unusable, or the receipt of different Announce Messages, to name a few, are events that can cause a change of the best master clock.
  • the identifier of the current best master i.e., the identifier of the clock currently serving as a source of synchronization to a local clock of a network node
  • the identifier of the current best master is entered into a Temporary Exclusion Table for a determined period of time if it is determined that the new best master clock is different than the current best master clock.
  • FIG. 3A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some
  • the network node includes a local clock that is associated with a default data set (e.g., "defaultDS" or DO) indicating default timing characteristics for the local clock within the PTP domain.
  • the local clock is synchronized according to a current best master clock of the PTP domain.
  • the current best master clock can have the default characteristics of the local clock or alternatively it can have characteristics of an external clock.
  • the external clock was determined to be the best external clock according to BMCA (i.e., Ebest) at the time of selection of this current best master clock.
  • the characteristics of the current best master clock include characteristics and an identifier of a grandmaster clock to which the network node's clock is synchronized. For example, the characteristics and identifier of the grandmaster clock can be identified in a parent data set "parentDS" as defined in IEEE 1588.
  • the network node determines a new best master clock for the local clock of the network node.
  • the BMCA data set algorithm is run and a new best master clock is identified.
  • the network node determines whether an identifier of the current best master clock for the local clock is to be included in an exclusion list. In some embodiments, the network node determines that the identifier of the current best master clock is to be included in the exclusion list by comparing the characteristics of the current best master clock with the characteristics of the new best master clock and determining (at operation 514) whether the two sets of characteristics are different.
  • the current best master clock upon detection of a new best master clock that is different from the current best master clock, the current best master clock is excluded from becoming a source of synchronization for the local clock of the network node for a
  • the predetermined period of time is calculated based on the announce rate (i.e., the rate at which Announce messages are generated and sent from a network node).
  • the predetermined period of time can be the product of the announce-rate and the maximum tolerated number of hops (steps removed).
  • the announce rate is standardized (e.g., every 1/8 second in G.8275.1)
  • the predetermined period of time can be 1/8 * 255 «32 seconds.
  • the predetermined period of time can be calculated differently without departing from the scope of the present invention.
  • the network node in addition to adding the identifier of the current best master clock to the exclusion, the network node further adds to the exclusion table, at operation 516, a number of hops associated with the identifier of the current best master clock, and a timing value indicating the predetermined period of time during which the identifier is to remain in the exclusion.
  • the number of hops associated with the current best master clock represents a distance measured by the number of boundary clocks between the local clock and a grandmaster of the PTP domain (i.e., the grandmaster of the current best master clock).
  • the number of hops is the value of the "stepsRemoved" field associated with the current best master clock.
  • the timing value is the current local time of day in the system.
  • Announce messages including the identifier of a grandmaster clock that is included in the exclusion list are ignored, in alternative embodiments, additional conditions can be verified prior to ignoring or invalidating the Announce messages. For example, as will be described in further details below, a number of hops associated with a grandmaster clock of an Announce message can also be considered before invalidating the Announce message.
  • FIG. 3B illustrates exemplary operations for processing Announce messages in accordance with some embodiments.
  • the BMCA is executed at the network node (e.g., upon receipt of an Announce message at one of the PTP ports of the network node).
  • Flow moves to operation 604, at which the network node determines whether any timers associated with clock identifiers included in the exclusion table have expired. If any timers have expired, flow moves to operation 606, at which the corresponding clock identifiers are removed from the temporary exclusion table. Once the clock identifiers are removed from the temporary exclusion table, the flow of operations moves to operation to operation 607.
  • flow moves to operation 607, where the network node determines if the identifier of the grandmaster clock received in the Announce message is included in the exclusion table. If the identifier of the grandmaster clock is not in the exclusion list, flow then moves to operation 502 at which the BMCA data set algorithm is run to determine the new best master clock for the local clock of the network node. The operations of Figure 3A can then be performed and the newly identified best master clock can be used to determine whether the identifier of the current best master clock should be included in the temporary exclusion list.
  • a number of hops associated with the identifier of the grandmaster of the Announce message e.g., a value of the "stepsRemoved" field in the Announce message
  • This approach described with reference to Figures 3A-B has the advantage of removing the possibility of selecting a network node already contributing to the timing chain by enforcing that any newly selected grandmaster (i.e., a grandmaster of a new best master clock) is not present in the exclusion list prior to being used as a best master clock for the network node if the number of hops associated with the identifier of the grandmaster is greater than the number of hops stored for that clock identifier in the temporary exclusion list plus 1. This compensates for the inability of a node to recognize a timing loop.
  • any newly selected grandmaster i.e., a grandmaster of a new best master clock
  • Figure 3C illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments.
  • Figure 3C illustrates network nodes 201, 202, 203 and 204 of Figure IB with similar initial configuration settings.
  • the arrow 280 indicates the direction of the synchronization process of the clocks within the PTP network including the devices 201, 202, 203, and 204.
  • the arrows 290, 291, 292, 293, 295, 295, 296 and 297 indicate the order and direction of propagation of Announce messages from a port of a first node to a peer port in another node.
  • the network node 201 acting as a grandmaster node of the PTP domain, broadcasts an Announce message 290 through the master port 211 including characteristics of a grandmaster clock (GM).
  • the grandmaster of the PTP domain is the network node 201, thus the identifier of the grandmaster clock transmitted within the Announce message 290 is the identifier of the local clock of the network node 201 as identified in the default data set of the local clock of the network node 201.
  • the characteristics of the grandmaster clock of network device 201 are propagated to network node 203, 204 and 202 through the Announce messages 291, 292 and 293.
  • Announce messages are used in the determination of respective best master clocks for the local clocks of the other network nodes of the PTP domain (i.e., network nodes 202, 203, and 204).
  • the grandmaster clock of network node 201 is still active and continuously transmits PTP messages to the nodes of the network domain (202, 203, and 204).
  • the states of each port of the nodes are determined based on the BMCA and the local attributes set for each port. For example, the local priority parameter of port 241 is set to 1 causing the port 241 to resolve to a slave state and the state of the port 242 to resolve to a master state.
  • the network nodes 201, 202, 203 and 204 are operative to perform the operations described with reference to Figures 3A-B.
  • the mechanisms described with reference to Figures 3A-B enable the network node 202 to discard the Announce Message 297 received from network node 204 (which also includes the identifier of the grandmaster of network node 201) until after a timeout period has expired for that identifier.
  • the network node 202 may further verify whether the difference between a number of hops (e.g., a value of "stepsRemoved" field) received in the Announce message and the value stored in the exclusion table for that identifier is more than 1 prior to ignoring the message. In the meantime, network node 202 may initiate a holdover process.
  • a number of hops e.g., a value of "stepsRemoved" field
  • scenario 2 of Figure 3C provides an example of configuration and topology in which a timing loop is prevented by performing the operations described with reference to Figures 3A-B.
  • Figures 3 A-B are described with respect to the exemplary scenario 2 of Figure 3C, one of ordinary skill in the art will recognize that the topology presented in the scenario of Figure 3C is exemplary only and that the mechanism described with respect to Figures 3A-B can be used to prevent timing loops in different (e.g., more complicated or more simple) topologies.
  • the embodiments described with respect to Figures 3A-C can be used independently or in combinations with the embodiments of Figures 2A-B such that the two techniques can be used to prevent the occurrence of timing loops in a PTP network.
  • the two techniques can be used in combination or independently to prevent timing loops due to local settings (such as the localPriority and notSlave parameters).
  • the operations 400 of Figure 2A can be performed in a network node prior to the operations of Figures 3A-B.
  • FIG. 4A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some
  • the network node is a first network node which includes a local clock that is associated with a default data set (DO) indicating default characteristics for the local clock.
  • DO data set
  • the first network node receives, at a first PTP port, a first PTP Announce message from a second PTP port of a second network node, wherein the first PTP Announce message includes PTP timing characteristics maintained by the second network node, and the first PTP port is configured with a not slave parameter set to true indicating that PTP timing
  • the determination that a state of the first PTP port is a passive state is performed according to an enhanced BMCA state determination algorithm as illustrated in Figure 4B.
  • the enhanced BMCA state determination algorithm includes additional decision branches 902 and 904 leading to the state of a PTP port being determined as passive when certain criteria are satisfied even if the notSlave parameter is set to true for that particular PTP port.
  • the IEEE1588 Default Profile it is a protocol violation to have two peer PTP ports persist in the Master state. One of the ports must yield to its peer and transition to a Passive or Slave state.
  • Figure 4B illustrates exemplary operations of an enhanced BMCA state determination algorithm in accordance with some embodiments.
  • a network node determines a state of a given port "r" by executing the enhanced BMCA state determination algorithm as illustrated in Figure 4B.
  • DO i.e., the defaultDS of the local clock of a network node
  • Erbest i.e., the best master clock for that port "r”
  • Port r would be the Ebest and therefore set to a slave state.
  • a peer PTP port would expect not to observe an Announce message from this PTP port, and it is therefore appropriate to place PTP port r into a passive state instead of being set to a master state (as it would have been the case according to the standard BMCA state algorithm).
  • Figure 4C illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments.
  • the arrow 390 indicates the direction of the
  • the network node 301 broadcasts an Announce message through the master port 311 including characteristics of a grandmaster clock (GM). These characteristics are used to synchronize the clock of the other network nodes of the PTP network.
  • GM grandmaster clock
  • connection is lost between the between network node 301 and network node 302 at time T2 (e.g., An Announce Receipt Timeout occurs on network node 302 from the T-GM (at time T2)).
  • a timing loop is prevented in this case.
  • the only option is to transition into Holdover and no timing Loop occurs.
  • inventions described with respect to Figures 4A-C can be used independently or in combinations with the embodiments of Figures 2A-B, and/or the embodiments of Figures 3A- D such that the three techniques can be used to prevent the occurrence of timing loops in a PTP network.
  • the three techniques can be used to prevent timing loops due to local settings (such as localPriority and notSlave).
  • Exemplary network devices as described below can be used to implement the operations and embodiments described with respect to Figures 2A-B, 3A-C and 4A-C.
  • An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine -readable media (also called computer-readable media), such as machine -readable storage media (e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory) and machine -readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals).
  • machine -readable media also called computer-readable media
  • machine -readable storage media e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory
  • machine -readable transmission media also called a carrier
  • carrier e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared
  • an electronic device e.g., a computer
  • includes hardware and software such as a set of one or more processors coupled to one or more machine -readable storage media to store code for execution on the set of processors and/or to store data.
  • an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower nonvolatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device.
  • volatile memory e.g., dynamic random access memory (DRAM), static random access memory (SRAM)
  • Typical electronic devices also include a set or one or more physical network interface(s) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices.
  • network connections to transmit and/or receive code and/or data using propagating signals.
  • One or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.
  • a network device is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices).
  • Some network devices are "multiple services network devices" that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 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
  • VOIP Voice Over Internet Protocol
  • user equipment 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
  • VOIP Voice Over Internet Protocol
  • VPNs auxiliary private networks
  • 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.,
  • 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)).
  • WNIC wireless network interface controller
  • NIC network interface controller
  • a network device has multiple physical network interfaces.
  • An 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 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.
  • Figure 5A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention.
  • Figure 5A shows NDs 800A-H, and their connectivity by way of lines between 800A-800B, 800B-800C, 800C-800D, 800D-800E, 800E-800F, 800F-800G, and 800A-800G, as well as between 800H and each of 800A, 800C, 800D, and 800G.
  • These NDs are physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link).
  • NDs 800A, 800E, and 800F An additional line extending from NDs 800A, 800E, and 800F illustrates that these NDs act as ingress and egress points for the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs may be called core NDs).
  • Two of the exemplary ND implementations in Figure 5A are: 1) a special-purpose network device 802 that uses custom application-specific integrated-circuits (ASICs) and a special-purpose operating system (OS); and 2) a general purpose network device 804 that uses common off-the-shelf (COTS) processors and a standard OS.
  • ASICs application-specific integrated-circuits
  • OS special-purpose operating system
  • COTS common off-the-shelf
  • the special-purpose network device 802 includes networking hardware 810 comprising compute resource(s) 812 (which typically include a set of one or more processors), forwarding resource(s) 814 (which typically include one or more ASICs and/or network processors), and physical network interfaces (NIs) 816 (sometimes called physical ports), as well as non-transitory machine readable storage media 818 having stored therein networking software 820.
  • a physical NI is hardware in a ND through which a network connection (e.g., wirelessly through a wireless network interface controller (WNIC) or through plugging in a cable to a physical port connected to a network interface controller (NIC)) is made, such as those shown by the connectivity between NDs 800A-H.
  • WNIC wireless network interface controller
  • NIC network interface controller
  • the networking software 820 may be executed by the networking hardware 810 to instantiate a set of one or more networking software instance(s) 822.
  • Each of the networking software instance(s) 822, and that part of the networking hardware 810 that executes that network software instance form a separate virtual network element 830A-R.
  • Each of the virtual network element(s) (VNEs) 830A-R includes a control communication and configuration module 832A- R (sometimes referred to as a local control module or control communication module) and forwarding table(s) 834A-R, such that a given virtual network element (e.g., 830A) includes the control communication and configuration module (e.g., 832A), a set of one or more forwarding table(s) (e.g., 834A), and that portion of the networking hardware 810 that executes the virtual network element (e.g., 830A).
  • a control communication and configuration module 832A- R sometimes referred to as a local control module or control communication module
  • forwarding table(s) 834A-R forwarding table(s) 834A-R
  • the networking software 820 further includes PTP protocol engine (PTP PE) 821, which when executed instantiate one or more PTP PE Instances 833A-R which enable the prevention of timing loops within a PTP domain as described with the various embodiments of Figures 2A-4C.
  • PTP PE PTP protocol engine
  • the special-purpose network device 802 is often physically and/or logically considered to include: 1) a ND control plane 824 (sometimes referred to as a control plane) comprising the compute resource(s) 812 that execute the control communication and configuration module(s) 832A-R; and 2) a ND forwarding plane 826 (sometimes referred to as a forwarding plane, a data plane, or a media plane) comprising the forwarding resource(s) 814 that utilize the forwarding table(s) 834A-R and the physical NIs 816.
  • a ND control plane 824 (sometimes referred to as a control plane) comprising the compute resource(s) 812 that execute the control communication and configuration module(s) 832A-R
  • a ND forwarding plane 826 sometimes referred to as a forwarding plane, a data plane, or a media plane
  • the forwarding resource(s) 814 that utilize the forwarding table(s) 834A-R and the physical NIs 816.
  • the ND control plane 824 (the compute resource(s) 812 executing the control communication and configuration module(s) 832A-R) is typically responsible for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) and storing that routing information in the forwarding table(s) 834A-R, and the ND forwarding plane 826 is responsible for receiving that data on the physical NIs 816 and forwarding that data out the appropriate ones of the physical NIs 816 based on the forwarding table(s) 834A-R.
  • data e.g., packets
  • the ND forwarding plane 826 is responsible for receiving that data on the physical NIs 816 and forwarding that data out the appropriate ones of the physical NIs 816 based on the forwarding table(s) 834A-R.
  • Figure 5B illustrates an exemplary way to implement the special-purpose network device 802 according to some embodiments of the invention.
  • Figure 5B shows a special- purpose network device including cards 838 (typically hot pluggable). While in some embodiments the cards 838 are of two types (one or more that operate as the ND forwarding plane 826 (sometimes called line cards), and one or more that operate to implement the ND control plane 824 (sometimes called control cards)), alternative embodiments may combine functionality onto a single card and/or include additional card types (e.g., one additional type of card is called a service card, resource card, or multi-application card).
  • additional card types e.g., one additional type of card is called a service card, resource card, or multi-application card.
  • a service card can provide specialized processing (e.g., Layer 4 to Layer 7 services (e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over IP (VoIP) Session Border Controller, Mobile Wireless Gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) Gateway)).
  • Layer 4 to Layer 7 services e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over IP (VoIP) Session Border Controller, Mobile Wireless Gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) Gateway)
  • GPRS General Pack
  • the general purpose network device 804 includes hardware 840 comprising a set of one or more processor(s) 842 (which are often COTS processors) and network interface controller(s) 844 (NICs; also known as network interface cards) (which include physical NIs 846), as well as non-transitory machine readable storage media 848 having stored therein software 850.
  • processor(s) 842 execute the software 850 to instantiate one or more sets of one or more applications 864A-R.
  • the virtualization layer 854 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 862A-R called software containers that may each be used to execute one (or more) of the sets of applications 864A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from each other and separate from the kernel space in which the operating system is run; and where the set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes.
  • the virtualization layer 854 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 862A-R called software containers that may each be used to execute one (or more) of the sets of applications 864A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from
  • the virtualization layer 854 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 864A-R is run on top of a guest operating system within an instance 862A-R called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that is run on top of the hypervisor - the guest operating system and application may not know they are running on a virtual machine as opposed to running on a "bare metal" host electronic device, or through para-virtualization the operating system and/or application may be aware of the presence of virtualization for optimization purposes.
  • a hypervisor sometimes referred to as a virtual machine monitor (VMM)
  • VMM virtual machine monitor
  • one, some or all of the applications are implemented as unikernel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library operating system (LibOS) including dri vers/libraries of OS services) that provide the particular OS services needed by the application.
  • libraries e.g., from a library operating system (LibOS) including dri vers/libraries of OS services
  • unikernel can be implemented to run directly on hardware 840, directly on a hypervisor (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or in a software container
  • embodiments can be implemented fully with unikernels running directly on a hypervisor represented by virtualization layer 854, unikernels running within software containers represented by instances 562A-R, or as a combination of unikernels and the above-described techniques (e.g. , unikernels and virtual machines both run directly on a hypervisor, unikernels and sets of applications that are run in different software containers).
  • the instantiation of the one or more sets of one or more applications 864A-R, as well as virtualization if implemented, are collectively referred to as software instance(s) 852.
  • the virtual network element(s) 860A-R perform similar functionality to the virtual network element(s) 830A-R - e.g., similar to the control communication and configuration module(s) 832A and forwarding table(s) 834A (this virtualization of the hardware 840 is sometimes referred to as network function virtualization (NFV)).
  • NFV network function virtualization
  • CPE customer premise equipment
  • each instance 862A-R corresponding to one VNE 860A-R
  • alternative embodiments may implement this correspondence at a finer level granularity (e.g., line card virtual machines virtualize line cards, control card virtual machine virtualize control cards, etc.); it should be understood that the techniques described herein with reference to a correspondence of instances 862A-R to VNEs also apply to embodiments where such a finer level of granularity and/or unikernels are used.
  • the virtualization layer 854 includes a virtual switch that provides similar forwarding services as a physical Ethernet switch. Specifically, this virtual switch forwards traffic between instances 562A-R and the NIC(s) 844, as well as optionally between the instances 862A-R; in addition, this virtual switch may enforce network isolation between the VNEs 860A-R that by policy are not permitted to communicate with each other (e.g., by honoring virtual local area networks (VLANs)).
  • VLANs virtual local area networks
  • the third exemplary ND implementation in Figure 5A is a hybrid network device 806, which includes both custom ASICs/special-purpose OS and COTS processors/standard OS in a single ND or a single card within an ND.
  • a platform VM i.e., a VM that that implements the functionality of the special-purpose network device 802 could provide for para-virtualization to the networking hardware present in the hybrid network device 806.
  • NE network element
  • each of the VNEs receives data on the physical NIs (e.g., 816, 846) and forwards that data out the appropriate ones of the physical NIs (e.g., 816, 846).
  • a VNE implementing IP router functionality forwards IP packets on the basis of some of the IP header information in the IP packet; where IP header information includes source IP address, destination IP address, source port, destination port (where "source port" and
  • destination port refer herein to protocol ports, as opposed to physical ports of a ND), transport protocol (e.g., user datagram protocol (UDP), Transmission Control Protocol (TCP), and differentiated services (DSCP) values.
  • transport protocol e.g., user datagram protocol (UDP), Transmission Control Protocol (TCP), and differentiated services (DSCP) values.
  • a network interface may be physical or virtual; and in the context of IP, an interface address is an IP address assigned to a NI, be it a physical NI or virtual NI.
  • a virtual NI may be associated with a physical NI, with another virtual interface, or stand on its own (e.g., a loopback interface, a point-to-point protocol interface).
  • a NI physical or virtual
  • a loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) of a NE/VNE (physical or virtual) often used for management purposes; where such an IP address is referred to as the nodal loopback address.
  • IP addresses of that ND are referred to as IP addresses of that ND; at a more granular level, the IP address(es) assigned to NI(s) assigned to a NE/VNE implemented on a ND can be referred to as IP addresses of that NE/VNE.
  • a local clock for each network node may include more than one local clock per node, where each local clock is associated with a set of one or more PTP ports and a set of default characteristics.
  • multiple local clocks of a single network node may be part of the same PTP domain, while in other embodiments, different local clocks of a same network node may be part of different PTP domains.
  • the local clocks of a single network node may be synchronized to the same best master clock or alternatively to different best master clocks. The embodiments described herein apply for each local clock and its associated PTP port in a network device.

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Synchronisation In Digital Transmission Systems (AREA)

Abstract

Methods and apparatuses in a PTP network are described. A network node receives, at a first port, an Announce message from a second port of a second network node, where the Announce message includes an identifier and characteristics of a grandmaster clock, and where the grandmaster clock is a source of time for clock synchronization for a second local clock of the second network node. The network node determines whether the identifier of the grandmaster is identical to a local identifier of the local clock of the first network node. In response to determining that the identifier of the grandmaster clock is identical to the identifier of the local clock, the network node discards the Announce message received at the first port causing the characteristics of the grandmaster clock to be ignored when determining a best master clock for the first local clock.

Description

A METHOD OF TIMING LOOP PREVENTION FOR THE PRECISION TIME PROTOCOL (PTP) WITH G.8275.1 PROFILE
CROSS-REFERENCE TO RELATED APPLICATIONS
[0001] This application claims the benefit of U.S. Provisional Application No. 62/287,866, filed January 27th, 2016, which is hereby incorporated by reference.
TECHNICAL FIELD
[0002] Embodiments of the invention relate to the field of packet networks; and more specifically, to clock synchronization over a network.
BACKGROUND
[0003] 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 version, 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.
[0004] The IEEE 1588 standards describe a hierarchical master-slave architecture for clock distribution. Under this architecture, a time distribution system includes one or more communication media (i.e., network segments) and one or more clocks. An ordinary clock is a device typically having a single network connection and is either the source of (i.e., a "master") or destination for (i.e., a "slave") a synchronization reference. A boundary clock typically has multiple network connections and can accurately synchronize one network segment to another. A synchronization master is selected for each of the network segments in the system. The root timing reference is called the grandmaster. The grandmaster transmits synchronization information to the clocks residing on its network segment. The boundary clocks with a presence on that segment can then relay accurate time to the other segments to which they are also connected.
[0005] However, specific needs for telecom deployments resulted in alternate PTP profiles being defined. For example, Multicast-broadcast single-frequency network (MBSFN) in Long Term Evolution (LTE) networks, LTE- Advanced (LTE-A) uplink coordinated multi-point (CoMP) operation, LTE Time-Division Duplex (LTE TDD), etc., rely upon very accurate frequency, phase, and/or time synchronization.
[0006] Accordingly, the ITU-T (International Telecommunication Union (ITU)
Telecommunication Standardization Sector) G.8275.1 Telecom Profile was developed as an extension of the PTP IEEE 1588-2008 to provide full timing support. The G.8275.1 profile defines a method of synchronizing frequency and time between network nodes by monitoring a combination of an external Layer 1 ("LI") electrical signal and received timing packets.
[0007] Each profile defines a Best Master Clock Algorithm (BMCA) which is to be used by all PTP Clocks within a PTP domain to determine a "best' clock (or "Best-Master") upon which a local clock in the network node is to rely upon. From the perspective of a singular network node, the Best-Master can be determined by comparing the contents of received Announce messages with the node's own local clock characteristics, referred to as the default data set (defaultDS or "DO"). The winning clock is referred to as the Best-Master and is used by the network node as a source of synchronization for the local clock. This is a perpetual process, as received Announce messages and characteristics of the node's local clock may change at any time. Further in a network node, the BMCA is used to determine a state of each PTP port coupling the network node to other nodes of the network. A PTP port is a logical access point of a PTP network node for PTP communications to the network. IEEE 1588-2008 specifies that a PTP port can resolve 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. According to the G8275.1 and the IEEE 1588 default profiles, at any given moment, there is a maximum of only one PTP port in a PTP network node that can resolve to be in the slave state. A network node synchronizes a local 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 a timing signal (or a timing clock) that the PTP clock has originated.
[0008] In the IEEE-1588 BMCA, the Best-Master can be determined by comparing the contents of an Announce message received at the port, a Best External Master determined as well as the node's own local clock's default characteristics (DO). However in G.8275.1 a different mechanism is used to determine the state of a PTP port. The G.8275.1 Profile further introduces two new parameters into the BMCA Algorithm that can contribute to determining the Best-Master of a clock as well as a state of a PTP port: notSlave, and localPriority. "notSlave" is a parameter defined locally for each PTP port. When the "notSlave" parameter is set to TRUE for a PTP port (G.8275.1 defines the notSlave parameter = True as the default setting for each PTP port), the Announce message that is observed on the PTP port is not used to determine the state of the PTP port state. The PTP port is simply put into a Master State, and thus, will advertise the current Best Master of the node. Therefore the notSlave parameter ensures that a PTP port will always enter into a Master State irrespective of the Announce message that is observed locally. However, this parameter is only known locally; other nodes within a PTP network will not know the incapability of the PTP port to enter into a Slave state.
[0009] In addition, the localPriority settings of a PTP port and the default data set DO are used to determine the Best-Master within a node. This parameter takes precedence over some other parameter (such as a number of hops ("stepsRemoved"), PTP-Clock identities, PTP port identities, and PTP port numbers) which can be used in determining the Best-Master for a clock of the node. Similarly to the notSlave setting, the localPriority setting is only known locally (i.e., within the node) and is not advertised to other nodes. Therefore, with respect to remote nodes, the Best-Master and the PTP port states may be determined in a non-reciprocal manner.
[0010] The addition of these two settings (notSlave and localPriority) introduces local properties that are used to determine the Best- Master of a PTP clock and the states of its associated PTP ports. However these local properties are not relayed to other nodes (e.g., to the peer ports) in the Announce message. It follows that local properties (e.g., localPriority setting, and notSlave setting) can take precedence over shared parameters which are received in an Announce message. These properties create scenarios in which it is no longer a protocol violation to have two connected peer PTP ports in the Master state, and the timing topology doesn't necessarily settle in a tree structure. This creates inconsistent results within the timing network, which makes the G.8275.1 Profile prone to timing loops.
SUMMARY
[0011] Methods and apparatuses for preventing timing loops in precision time protocol (PTP) network are described.
[0012] One general aspect includes a method in a first network node of a precision time protocol (PTP) network of preventing timing loops, where the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node. The method includes receiving, at a first port from the set of ports, an announce message from a second port of a second network node, where the announce message includes an identifier and characteristics of a grandmaster clock, and where the grandmaster clock is a source of time for clock synchronization for a second local clock of the second network node; determining whether the identifier of the grandmaster clock is identical to a local identifier of the first local clock of the first network node. The method continues with in response to determining that the identifier of the grandmaster clock is identical to the local identifier of the first local clock, discarding the announce message received at the first port causing the characteristics of the grandmaster clock to be ignored when determining a best master clock for the first local clock, where the best master clock is to be used as a source of synchronization for the first local clock of the first network node. Alterntively in response to determining that the identifier of the grandmaster clock is not identical to the local identifier of the first local clock, the method includes using the characteristics of the grandmaster clock when determining the best master clock for the first local clock of the first network node.
[0013] One general aspect includes a method in a first network node of a precision time protocol (FTP) network of preventing timing loops, where the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node, and where the first local clock of the first network node is synchronized according to a current best master clock,. The method includes determining a new best master clock for the first local clock of the first network node; determining whether a first identifier of the current best master clock for the first local clock is to be included in an exclusion list; and responsive to determining that the first identifier is to be included in the exclusion list, adding the first identifier in the exclusion list causing any announce messages including the first identifier to be ignored during a predetermined period of time when determining a next best master clock for the first local clock of the first network node.
[0014] One general aspect includes a first network node of a precision time protocol (PTP) network, where the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node. The first network node includes one or more processors and a non-transitory computer readable storage medium, said non-transitory computer readable storage medium containing instructions, which when executed by the one or more processors, causes the first network node to: receive, at a first port from the set of ports, an announce message from a second port of a second network node, where the announce message includes an identifier and characteristics of a grandmaster clock, and where the grandmaster clock is a source of time for clock synchronization for a second local clock of the second network node. The first network node is further to determine whether the identifier of the grandmaster clock is identical to a local identifier of the first local clock of the first network node. In response to determining that the identifier of the grandmaster clock is identical to the local identifier of the first local clock, the first network node is further to discard the announce message received at the first port causing the characteristics of the grandmaster clock to be ignored when determining a best master clock for the first local clock, where the best master clock is to be used as a source of synchronization for the first clock of the first network node. In response to determining that the identifier of the grandmaster clock is not identical to the local identifier of the first local clock, the first network node is to use the characteristics of the grandmaster clock when determining the best master clock for the first local clock of the first network node.
[0015] One general aspect includes a first network node of a precision time protocol (PTP) network of preventing timing loops, where the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node, and where the first local clock of the first network node is synchronized according to a current best master clock, and the first network node is to: determine a new best master clock for the first local clock of the first network node; determine whether a first identifier of the current best master clock for the first local clock is to be included in an exclusion list; and responsive to determining that the first identifier is to be included in the exclusion list, to add the first identifier in the exclusion list causing any announce messages including the first identifier to be ignored during a predetermined period of time when determining a next best master clock for the first local clock of the first network node.
BRIEF DESCRIPTION OF THE DRAWINGS
[0016] The invention may best be understood by referring to the following description and accompanying drawings that are used to illustrate embodiments of the invention. In the drawings:
[0017] Figure 1A illustrates an exemplary configuration scenario of network devices resulting in a timing loop due to a local parameter set for PTP ports of the network devices in accordance with some embodiments of the invention.
[0018] Figure IB illustrates another exemplary configuration scenario of network nodes resulting in a timing loop due to the local priority parameter set for PTP ports of the network nodes in accordance with some embodiments of the invention.
[0019] Figure 1C is an exemplary configuration scenario of network nodes resulting in a timing loop due to a local parameter set for PTP ports of the network node in accordance with some embodiments of the invention.
[0020] Figure 2A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some
embodiments of the invention.
[0021] Figure 2B illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments of the invention. [0022] Figure 3A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some
embodiments of the invention.
[0023] Figure 3B illustrates exemplary operations for processing Announce messages in accordance with some embodiments of the invention.
[0024] Figure 3C illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments of the invention.
[0025] Figure 4A illustrates exemplary operations performed in a network device of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some embodiments of the invention.
[0026] Figure 4B illustrates exemplary operations of an enhanced BMCA state determination algorithm in accordance with some embodiments of the invention.
[0027] Figure 4C illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments of the invention.
[0028] Figure 5A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention.
[0029] Figure 5B illustrates an exemplary way to implement a special-purpose network device according to some embodiments of the invention.
DESCRIPTION OF EMBODIMENTS
[0030] The following description describes methods and apparatus for preventing timing loops in a PTP network. 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.
[0031] 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.
[0032] Bracketed text and blocks with dashed borders (e.g., large dashes, small dashes, dot- dash, and dots) may be used herein to illustrate optional operations that add additional features to embodiments of the invention. However, such notation should not be taken to mean that these are the only options or optional operations, and/or that blocks with solid borders are not optional in certain embodiments of the invention.
[0033] 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.
[0034] In the following description a network device which includes a local clock that support PTP (i.e., a PTP clock) is referred to as a PTP network node. While the embodiments described below refer to a single local clock of a PTP network node, in other embodiments, a network node may include multiple local clocks which can be independently synchronized according to PTP and hence include multiple PTP clocks. IEEE 1588-2008, and the G8275.1 profile define three types of PTP clocks: Ordinary Clock (OC), Boundary Clock (BC, and Transparent Clock (TC). An OC includes one PTP port and 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 PTP ports. A BC receives Announce messages from an upstream master, synchronizes its local time of day to an upstream master, 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.
[0035] A PTP domain is a logical grouping of PTP clocks communicating with each other using the PTP protocol. PTP domains are used to partition a network within an administrative entity. The PTP messages and data sets are associated with a domain and therefore, the PTP protocol is independent for different domains. A PTP port is a logical access point of a PTP clock for PTP communications to the network. Each PTP clock periodically sends Announce messages via the master PTP ports to other PTP clocks in the same PTP domain. The Announce messages include clock information and an identifier indicating the identity of the sending PTP clock, a number of hops ( stepsRemoved) of the sending PTP clock, and information concerning the grandmaster. A best master clock algorithm (BMCA) executed at each PTP network node utilizes information included in the received Announce messages to determine the role of the local clock in the PTP domain. IEEE 1588-2008 defines three roles: grandmaster (GM), boundary clock (BC), and slave.
[0036] 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 a GM clock within the 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.
[0037] 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.
[0038] A PTP network node may include one or more PTP ports enabling the PTP network device to be coupled with other network nodes in the network. IEEE 1588-2008 specifies that a PTP port can resolve 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. According to the G8275.1 and the IEEE 1588 default profiles, at any given moment, there is a maximum of only one PTP port in a PTP clock that can resolve to be in the slave state. A PTP clock synchronizes a local 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 a timing signal (or a timing clock) that the PTP clock has originated. [0039] In the IEEE-1588 BMCA, a PTP port state is determined by comparing the contents of an Announce message received at the port, a Best External Master determined as well as the node's own local clock's default characteristics that is referred to as default data set or "DO." However in G.8275.1 a different mechanism is used to determine the state of a PTP port. The G.8275.1 Profile introduces two new parameters into the BMCA Algorithm that contribute to determining the Best-Master of a clock as well as a state of a PTP port: notSlave, and localPriority. "notSlave" is a parameter defined locally for each PTP port. When the local parameter "notSlave" is set to TRUE for a port (G.8275.1 defines the notSlave parameter = True as the default setting for each PTP port), the Announce message that is observed on the PTP port is not used to determine the state of the PTP port. The PTP port cannot placed in the slave state and it is simply put into a master state, and thus, will advertise the current Best Master of the node. Therefore the notSlave parameter ensures that a PTP port will always enter into a master state irrespective of the Announce message that is observed locally. However, this parameter is only known locally; other nodes within a PTP network will not know the incapability of the PTP port to enter into a slave state.
[0040] Similarly the localPriority parameter is a local per-port attribute. The localPriority settings of a PTP port is used in combination with other parameters to determine the Best- Master within a node. This parameter takes precedence over some other parameters/attributes (such as a number of hops ("stepsRemoved"), PTP-Clock-Identities, PTP port identities, and PTP port numbers) which can be used in determining the Best-Master of the node. Similarly to notSlave, the localPriority parameter is only known locally (i.e., within the node) and is not advertised to other nodes. Therefore, with respect to remote nodes, the Best-Master and the PTP port states may be determined in a non-reciprocal manner.
[0041] The addition of these two settings (notSlave and localPriority) introduces local properties that are used to determine the Best- Master of a PTP clock and the states of its associated PTP ports. However these local properties are not relayed to other nodes (e.g., to the peer ports) in the Announce message. It follows that local properties (e.g., localPriority setting, and notSlave setting) can take precedence over shared parameters which are received in an Announce message. These properties create scenarios in which it is no longer a protocol violation to have two connected peer PTP ports in the master state, and the timing topology doesn't necessarily settle in a tree structure. This creates inconsistent results within the timing network, which makes the G.8275.1 Profile prone to timing loops.
[0042] Exemplary timing loop scenarios caused by local settings of PTP ports introduced in G8275.1 profile. [0043] Figure 1A illustrates an exemplary configuration scenario of network devices resulting in a timing loop due to a local parameter set for PTP ports of the network devices in accordance with some embodiments. Figure 1A illustrates operations at three moments in time: Time 1 (Tl), Time 2 (T3), and Time 3 (T3). For each moment, two telecom boundary clocks (TBCs, or T-BCs) are illustrated (101, and 102), each of which including two PTP ports that can act either as a "Master" or "Slave" (or Passive) depending upon circumstance, illustrated herein as boxes "M" and "S." At an initial stage (e.g., when a network node 102 is turned on or is connected to network node 101 at Tl) a port of a T-BC is in an initialing state (I).
[0044] To simplify the description, we assume that a local priority parameter (e.g.,
"localPriority" as defined in G8275.1) of port 112 is set to 1 (LP=1) and that local priority of port 121 is set to 1 (LP=1). Further the local priority parameter is set to a default value which is 128 for the local clock of each one of the network nodes and for the other PTP ports (111, and 122), such that the local priority parameter for port 112 and for port 121 has a value of higher precedence than each one of the other ports of the same node and the local priority of the local clock.
[0045] In the illustrated exemplary scenario the network node 101 comes online first. Then 102 is initialized and receives an Announce message from network node 101. According to the G.8275.1 Profile when an Announce message is received on a PTP port, the configured local priority value of the receiving port is appended to the Announce message and considered within the BMCA. For example port 121 receives the Announce message from port 111. At time T2, the BMCA running on the network node 102 determines a best master clock for the clock of the network node and the states of the ports based on the Announce messages and local properties. The BMCA compares the timing characteristics of the clock (received in the Announce message) received from port with the characteristics received at port 122 from 112, as well as with the default data set DO of the local clock, while considering the local priority parameter of the ports. According to the BMCA of G8275.1 profile, all characteristics of the two clocks (i.e., of network nodes 101 and 102) are identical, the deciding factor for determining the best master for the clock of network node 102 is the local priority parameter. Since LP=1 for network node 102 and the other local priority values (i.e., the local priority values of the other PTP port and of the default data set of the local clock) are set to 128, the port 121 resolves to a slave state, while forcing the port 122 to resolve to a master state. An Announce message is then advertised, at operation (d), from port 122 to port 112, which causes the state of the port 112 to resolve to a slave state caused by the local priority value of port 112 being set to 1. Thus, because the local priority parameter takes precedence in the BMCA over some of the other state determining factors, a timing loop occurs, and persists between the two network nodes. [0046] While in some embodiments, the present exemplary scenario 1 may be considered a misconfiguration of the network nodes, one of ordinary skill in the art will recognize that the topology presented in the scenario of Figure 1 A is exemplary only and that different (e.g., more complicated) topologies may allow similar timing loops to occur without a misconfiguration being apparent.
[0047] Figure IB illustrates another exemplary configuration scenario of network nodes resulting in a timing loop due to the local priority parameter set for PTP ports of the network nodes in accordance with some embodiments. In this figure the arrows 250, 251, 252, 253, and 254 indicate the order and direction of propagation of Announce messages from a port of a first node to a peer port in another node. The arrow 270 indicates the direction of the synchronization process of the clocks within the PTP domain including the nodes 201, 202, 203, and 204. The network node 201 broadcasts an Announce message 250 through the master port 211 including information indicating characteristics of a grandmaster clock (GM). In this exemplary scenario 2, the grandmaster of the PTP domain is the network node 201, thus the identifier of the grandmaster clock transmitted within the Announce message 250 is the identifier of the local clock of the network node 201. The characteristics of the grandmaster clock of network node 201 is propagated to network node 203 and 204 through the Announce messages 251, 252 and 253. These Announce messages are used to determine a best master clock for synchronizing the respective clocks of the other network nodes of the PTP domain (i.e., network nodes 202, 203, and 204).
[0048] In one embodiment, the loss of connection between network node 201 and network node 202 (e.g., An Announce Receipt Timeout occurs on network node 202 from the T-GM 201 (at time T2), as well as the configurations associated with the port 241 of network node 204 (where LP=1) causes the Announce message 262 received from network node 203 (Which still includes an identifier of the grandmaster clock of network node 201) to be considered for the best master clock at time T2 from the perspective of network node 204. This causes network node 204 to transmit in the Announce message 263 to network node 202 the characteristics of grandmaster clock of network node 201 even though the grandmaster clock of network node 201 is no longer valid due to the interruption of the connection resulting in a timing loop. This timing loop would not be considered to be a network misconfiguration. In this example, all PTP ports are configured with notSlave = FALSE and therefore can enter a slave or passive state. The PTP port 242 in network node 204 remains in a master state as the PTP port 241 is simply "better", and not "better by topology" due to its local priority setting. This temporary timing loop will persist for up to 32 seconds. The 32 second period is a product of the maximum time between Announce messages (1/8 seconds), and the maximum tolerated number of hops (i.e., StepsRemoved (which is 255, as defined in the ITU-T G.8275.1 Profile Recommendation).
[0049] One of ordinary skill in the art will recognize that the topology presented in the scenario of Figure IB is exemplary only and that different or more complicated topologies, as well as other configuration settings may allow similar timing loops to occur.
[0050] Figure 1C is an exemplary configuration scenario of network nodes resulting in a timing loop due to a local parameter set for PTP ports of the network node in accordance with some embodiments. In exemplary scenario 3, the timing loop is possible due to the lack of configuration of the notSlave attribute. In this figure the arrows 350, 351, 352, 353, and 354 indicate the order and direction of propagation of Announce messages from a port of a first node to a peer port in another node of the PTP domain. The arrow 370 indicates the direction of the synchronization process of the clocks within the PTP domain including the devices 301, 302, 303, and 304. The network node 301 broadcasts an Announce message 350 through the master port 311 including characteristics of a grandmaster clock (GM). In this exemplary scenario 3, the grandmaster of the PTP domain is the network node 301, thus the clock identity of the grandmaster transmitted within of the Announce message 350 is the clock identity of the local clock of the network node 301 as identified in the default data set of the local clock of the network node 301. The grandmaster clock of network device 301 is propagated to network node 303 and 304 through the Announce messages 351, 352 and 353. The Announce messages are used in determination of best master clocks for synchronizing the clocks of the other network nodes of the PTP network.
[0051] In one embodiment, the loss of connection between network node 301 and network node 302 at time T2 (e.g., An Announce Receipt Timeout occurs on network node 302 from the GM 301), as well as the lack of configuration of the port 341 with a notSlave attribute causes the Announce message received from network node 303 (Which still includes an identifier of the grandmaster clock of network node 301) to be considered for the best master clock at time T2 from the perspective of network node 304. This causes network node 304 to transmit in the Announce message 363 to network node 302 the characteristics of grandmaster clock of network node 301 even though the grandmaster clock of network node 301 is no longer valid due to the interruption of the connection resulting in a timing loop 371. In this exemplary scenario, the timing loop is temporary however it persists for up to 32 seconds at which point network node 302 will break the loop as the number of hope (or steps removed) will have reached 255.
Further, it is an intent of the G.8275.1 profile to protect downstream nodes from upstream failures with a "Holdover" process. A node can enter into a Holdover state for multiple reasons, a common reason being when Announce messages are no longer received from the selected Best-Master. The Holdover state has two sub-states: Holdover-In-Specification (HO-IS), and Holdover-Out-of-Specification (HO-OoS). In some embodiments, network node 302 may enter into a holdover node (e.g., it may enter a holdover-in-specification mode), and network node 303 and network node 304 will synchronize to network node 302 holdover clock. In some embodiments, if the clock of network node 302 degrades to a holdover-out-of-specification clock, then the timing loop will repeat itself.
[0052] Preventing Timing Loops in FTP Networks by invalidating Announce Messages
[0053] The present invention provides techniques for preventing timing loops in a PTP domain. In some embodiments, timing loops may be caused by the use of local parameters (e.g., localPriority and notSlave parameters) configured for PTP ports of a network node, which are not shared with other nodes of the PTP domain in Announce messages. The local parameters are introduced with the G8275.1 profile. In other embodiments, the timing loops may be due to other causes (e.g., misconfigurations, failures of network nodes, etc.). Figure 2A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some embodiments. The network node is a first network node which includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node. The default characteristics (e.g., "defaultDS," which can also be referred to as DO) includes information that describes the characteristics of the first local clock of the network node with respect to the clock
synchronization protocol (e.g., PTP). The default characteristics includes a local identifier of the first local clock (e.g., "defaultDS. clockldentity" as defined in IEEE 1588-2008) and other parameter values defining characteristics of the first local clock that can be used in the BMCA to compare clocks and determine a best master clock for the first local clock. In the first network node, one or more applications can run according to the first local clock. In an exemplary scenario, the first network node is similar to network node 102 or 101 from Figures 1A, 2B, and Figures 5A-B.
[0054] At operation 402, the network node receives, at a first PTP port from the set of ports, a PTP Announce message from a second PTP port of a second network node, where the PTP Announce message includes an identifier and characteristics of a grandmaster clock. The identifier of the grandmaster clock is a value that uniquely identifies, within the PTP domain, the clock that serves as a source of synchronization for a second local clock of the second network node (i.e., the network node transmitting the PTP Announce message). For example, the identifier can be included in a "grandmasterldentity" field of the PTP Announce message as defined in the different versions of the IEEE 1588 standard and the G8271.5 profile. Flow then moves to operation 404, at which the network node determines whether the identifier of the grandmaster clock is identical to a local identifier of the first local clock of the first network node. The local identifier of the first local clock is a value that uniquely identifies the local clock within the PTP domain. For example, the local identifier of the first local clock can be included in the "defaultDS.clockldentity" field as defined in the different versions of the IEEE 1588 standard and the G8271.5 profile. Flow then moves to operation 406, at which in response to determining that the identifier of the grandmaster clock is identical to the local identifier of the first local clock of the first network node, the first network node discards the PTP Announce message received at the first PTP port causing the characteristics of the grandmaster clock to be ignored when determining a PTP best master clock for the first local clock of the first network node. Discarding the PTP Announce message received at the first PTP port causes an external best master clock on the first PTP port (Erbest) to resolve to an empty set when the BMCA is run for that port. As a consequence, the characteristics of the grandmaster clock of the second local clock of the second network node are ignored when determining the PTP best master clock for the first local clock of the first network node.
[0055] In some embodiments, a value of a local priority parameter of the first PTP port is configured to be of higher precedence than other local priority parameter values of the first network node. The local priority parameter value of the first PTP port indicates that clock characteristics included in PTP Announce messages received at the first PTP port are to be used when determining the PTP best master clock of the first network node. The local priority parameter is a local attribute used in the BMCA for the determination of the external best master for a port (Erbest) and in the determination of the external best master for a node (Ebest). A local priority value can be assigned for each PTP port, as well as for a local clock of the network node. Each Announce message received on a port is appended with the local priority value set for that port before a data set comparison algorithm (as performed within the BMCA) is invoked. As discussed previously, the local priority parameter is not transmitted in PTP Announce messages. This attribute is used as a tie-breaker in the data set comparison algorithm, in the event that all other previous attributes of the data sets being compared are equal. In the profile G8271.5, the local priority attribute is set via the configurable, unsigned integer, port data set member "portDS.localPriority." The data type for this attribute is UInteger8. The range of values for this attribute is { 1-255} with a default value being set at 128. However, when a local priority (LP) parameter of a port is set to a value (e.g., LP = 1) that is of higher precedence than the value of the local priority parameter of the other PTP ports of the node, as well as of higher precedence than the local priority of the local clock of the node, the local clock of the network node is forced to use the timing characteristics of the Announce messages received at that port. [0056] The embodiments present a mechanism in which a local clock of a network node is no longer forced to use the clock characteristics of the Announce messages received at a PTP port which has a local priority of higher precedence than the rest of the PTP ports in the node and the local clock of the node. Therefore in some embodiments, when the identifier of the grandmaster clock is determined to be identical to the local identifier of the local clock of the first network node (at operation 404), the network node discards the PTP Announce message received at the first PTP port regardless of the value of the local priority parameter of the first PTP port causing the characteristics of the grandmaster clock of the local clock of the second network node to be ignored when determining the PTP best master clock for the first local clock of the first network node even if the local priority of the port is of higher precedence than the rest of the PTP ports and the first local clock of the node. As will be shown with an exemplary scenario 1 (described with reference to Figure 2 A below), in these embodiments, discarding the PTP Announce message results in avoiding timing loops that would otherwise occur when a value of the local priority parameter of the first PTP port is of higher precedence than other local priority parameter values in the first network node.
[0057] Referring back to Figure 2A, alternatively flow moves from operation 404 to operation 408, at which in response to determining that the identifier of the grandmaster clock, received in the Announce message from the second network node, is not identical to the local identifier of the local clock of the first network node, the first network node uses the characteristics of the grandmaster clock when determining the PTP best master clock for the first local clock of the first network node.
[0058] Figure 2B illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments. Figure 2B illustrates network node 101 and network node 102 of Figure 1 A with similar initial configuration settings. In the following description the same reference numbers are retained for corresponding operations. The exemplary scenario 1 of Figure 2B will be described with reference to the operations of the flow diagram of Figure 2A. However, it should be understood that the operations of the flow diagram can be performed by embodiments of the invention other than those discussed with reference to Figure 2B, and the embodiments of the invention discussed with reference to these other figures can perform operations different than those discussed with reference to the flow diagram.
[0059] Figure 2B illustrates operations at three moments in time: Time 1 (Tl), Time 2 (T2), and Time 3 (T3). For each moment, the two telecom boundary clocks (TBCs, or T-BCs) of Figure 1A are illustrated (101, and 102), each of which includes two PTP ports that can act either as a "Master" or "Slave" (or Passive) depending upon circumstance, illustrated herein as boxes "M" and "S." At an initial stage (e.g., when a network node 102 is turned on or is connected to network node 101 Tl) a port of a T-BC is in an initialing state (illustrated herein as boxes I).
[0060] Similarly to Figure 1A, the local priority parameter of port 112 and port 121 is set to a value of 1 (LP=1). Further the local priority parameter/attribute for each one of the local clocks of the network node (101 and 102) and for the other PTP ports (111, and 122) is set to a default value which is 128, resulting in that the local priority parameter of port 112 and port 121 has a value of higher precedence than each one of the other ports of the same node and the local priority value of the local clock of the node. Thus, the value of the local priority parameter for port 112 and port 121 indicates that clock characteristics included in PTP Announce messages received at each of one of these ports are to be used when determining the PTP best master clock of the first network node.
[0061] In the illustrated exemplary scenario the network node 101 comes online first. Then network node 102 is initialized and receives an Announce message from network node 101. At time Tl, the Announce message is received at port 121 and port 122 from ports 111 and 122 respectively. The configured LP of the receiving port (e.g., 121) is appended to the Announce message and considered within the BMCA. At time T2, the BMCA running on the network node 102 determines, at operation cl, whether an identifier of a grandmaster clock included in the Announce Message (e.g., "grandmasterldentity") is identical to an identifier of the local clock (e.g., "defaultDS.clockldentity") of the network node 102. In the illustrated exemplary scenario 1 , the identifier of the grandmaster clock (GM-ID) included in the Announce message sent by network node 101 is different from the identifier of the local clock (Clock-ID) of network node 102. In this particular example, the identifier of the grandmaster for network node 101 is clock identifier of the local clock of network node 101 which is different from the identifier of the local clock of network node 102.
[0062] At operation c2, a best master clock for the network node 102 and port states are determined based on the Announce messages and local settings (in other words the network node may use the clock characteristics received in the Announce message from the second network node when determining the PTP best master clock for the local clock of the first network node). The network node 102 compares the timing characteristics of the grandmaster clock received from port 111 with the characteristics received at port 122 from port 112, as well as with the characteristics of its local clock (i.e., characteristics included in the default data set DO of the local clock of network node 102), and considers the local priority parameter of the ports when determining the best master clock for the local clock of the network node 102 and the states of the ports 121 and 122. For the sake of brevity, the BMCA will not be discussed here in details, however it is performed as described in G8275.1 profile, which is herein incorporated by reference. The BMCA considers a set of attributes set for each local clock within the PTP domain. For example, the BMCA considers values of a clock class parameter, values of a clock accuracy parameter, values of a variance parameter (e.g., "offsetScaledLogVariance"), and values of a priority parameter (e.g., "priority2"). According to the BMCA of G8275.1 profile, all these attributes of the two clocks (i.e., local clocks of network node 101 and 102) are identical. Therefore, the deciding factor for determining the best master for network node 102 is the value of the local priority. Since the value of the local priority of port 121 is set to 1, the best master clock for the node is determined to be the grandmaster clock received in the Announce message received at port 121. The state of port 121 resolves to a slave state, while forcing the state of port 122 to resolve to a master state. Once the best master block is determined for node 102, the local clock of network node 102 is synchronized with the grandmaster of network node 101 and corresponding data sets which represent the current characteristics of the local clock are updated for the network node 102 (e.g., a current data set "currentDS"; a parent data set "parentDS"; and timePropertiesDS). Further an Announce message is then advertised from port 122 to port 112 at operation (d), including the identifier of the grandmaster clock, which is the identifier of the local clock of network node 101.
[0063] At time T3, upon receipt of the Announce message, network node 101 determines at operation (el) whether the identifier of the grandmaster clock included in the Announce message (e.g., included in a "grandmasterldentity" field of the PTP Announce message) received from port 122 is identical to the identifier of the local clock of network node 101. Since the local clock of network node 101 was selected as a best master clock at network node 102, the identifier of the grandmaster clock received at port 112 from port 122 is identical to the identifier of the local clock of network node 101. Thus, at operation (e2) in response to determining that the identifier of the grandmaster clock included in the Announce message is identical to the identifier of the local clock (in other words upon determination that the network node 101 is acting as a source of synchronization for the network node 102), the network node 101 discards the Announce message received from port 122 regardless of the value of the local priority parameter set for port 112 (LP=1). The PTP Announce message received at the first PTP port 112 is discarded regardless of the value of the local priority parameter (PL=1) of the first PTP port 112 causing the timing characteristics of the grandmaster clock of network node (102) to be ignored when determining the best master clock of the first network node 101. In these embodiments, discarding the PTP Announce message results in avoiding timing loops that would have otherwise been caused by the value of the local priority parameter of the first PTP port being of higher precedence than other local priority parameter values in the first network node. [0064] Thus the embodiments presented above present techniques which invalidate PTP Announce messages that have the same grandmaster identification (e.g., the same
"grandmasterldentity" value) as the identifier of the local clock (e.g., "defaultDS.clockldentity") enabling a PTP network to avoid entering timing loops caused by local priority settings. In other words prior to using an Announce message in the determination of a synchronization source a network node verifies that the source of synchronization (i.e., the grandmaster of the PTP domain) is not the network node itself. These new approaches remove the possibility of encountering static or permanent timing loops.
[0065] Preventing Timing Loops Using a Temporary Exclusion Table
[0066] According to some embodiments, another approach can further be used to prevent timing loops in a PTP network. In some embodiments, a current best master clock used to synchronize the local clock of a network node can change for multiple reasons. For example the receipt of a Loss- Announce message, the Ebest selected as the best master is determined to be unusable, or the receipt of different Announce Messages, to name a few, are events that can cause a change of the best master clock. When a new best master clock is identified, for any reason, the identifier of the current best master (i.e., the identifier of the clock currently serving as a source of synchronization to a local clock of a network node) is entered into a Temporary Exclusion Table for a determined period of time if it is determined that the new best master clock is different than the current best master clock.
[0067] Figure 3A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some
embodiments. The network node includes a local clock that is associated with a default data set (e.g., "defaultDS" or DO) indicating default timing characteristics for the local clock within the PTP domain. The local clock is synchronized according to a current best master clock of the PTP domain. In some embodiments, the current best master clock can have the default characteristics of the local clock or alternatively it can have characteristics of an external clock. The external clock was determined to be the best external clock according to BMCA (i.e., Ebest) at the time of selection of this current best master clock. The characteristics of the current best master clock include characteristics and an identifier of a grandmaster clock to which the network node's clock is synchronized. For example, the characteristics and identifier of the grandmaster clock can be identified in a parent data set "parentDS" as defined in IEEE 1588.
[0068] At operation 502, the network node determines a new best master clock for the local clock of the network node. At this operation, the BMCA data set algorithm is run and a new best master clock is identified. At operation 504, the network node determines whether an identifier of the current best master clock for the local clock is to be included in an exclusion list. In some embodiments, the network node determines that the identifier of the current best master clock is to be included in the exclusion list by comparing the characteristics of the current best master clock with the characteristics of the new best master clock and determining (at operation 514) whether the two sets of characteristics are different. Responsive to determining that the identifier of the current best master clock is to be included in an exclusion list, flow moves to operation 506, at which the network node adds the identifier to the exclusion list causing any PTP Announce messages including this identifier to be ignored during a predetermined period of time when determining a next best master clock of the first network node.
[0069] Thus according to these embodiments upon detection of a new best master clock that is different from the current best master clock, the current best master clock is excluded from becoming a source of synchronization for the local clock of the network node for a
predetermined period of time. The identifier of the current best master clock of a network node later removed, as described with reference to Figure 3B, after the predetermined period of time has expired. In some embodiments, the predetermined period of time is calculated based on the announce rate (i.e., the rate at which Announce messages are generated and sent from a network node). For example, the predetermined period of time can be the product of the announce-rate and the maximum tolerated number of hops (steps removed). In one example, where the announce rate is standardized (e.g., every 1/8 second in G.8275.1), the predetermined period of time can be 1/8 * 255«32 seconds. In other embodiments, the predetermined period of time can be calculated differently without departing from the scope of the present invention.
[0070] While in some embodiments, only the identifier of the current best master clock is added to the exclusion list, in other embodiments, in addition to adding the identifier of the current best master clock to the exclusion, the network node further adds to the exclusion table, at operation 516, a number of hops associated with the identifier of the current best master clock, and a timing value indicating the predetermined period of time during which the identifier is to remain in the exclusion. The number of hops associated with the current best master clock represents a distance measured by the number of boundary clocks between the local clock and a grandmaster of the PTP domain (i.e., the grandmaster of the current best master clock). For example, the number of hops is the value of the "stepsRemoved" field associated with the current best master clock. In some embodiments, the timing value is the current local time of day in the system.
[0071] Referring back to operation 504, when the network node determines that the first identifier of the current best master clock is not to be included in an exclusion list, flow moves to operation 508, at which the BMCA port state algorithm is run. [0072] When an identifier of a clock is temporary added to the exclusion list, any Announce message that is received at the network node and includes the identifier of this clock as the ID of its grandmaster clock is ignored. This approach causes, all Erbest Announce messages that contain an identification of a grandmaster which was a previous best master clock for the local clock to be invalidated for an adequate duration (i.e., for the predetermined period of time) ensuring that no timing loops occur. This approach can act as a safety net for the scenarios in which an IEEE 1588 MASTER-MASTER protocol violation is unavoidable and prevents against the re-entry of a node into a timing chain in which it is already contributing.
[0073] While in some embodiments, all Announce messages including the identifier of a grandmaster clock that is included in the exclusion list are ignored, in alternative embodiments, additional conditions can be verified prior to ignoring or invalidating the Announce messages. For example, as will be described in further details below, a number of hops associated with a grandmaster clock of an Announce message can also be considered before invalidating the Announce message.
[0074] Figure 3B illustrates exemplary operations for processing Announce messages in accordance with some embodiments. The BMCA is executed at the network node (e.g., upon receipt of an Announce message at one of the PTP ports of the network node). Flow moves to operation 604, at which the network node determines whether any timers associated with clock identifiers included in the exclusion table have expired. If any timers have expired, flow moves to operation 606, at which the corresponding clock identifiers are removed from the temporary exclusion table. Once the clock identifiers are removed from the temporary exclusion table, the flow of operations moves to operation to operation 607. Alternatively, if no timers have expired flow moves to operation 607, where the network node determines if the identifier of the grandmaster clock received in the Announce message is included in the exclusion table. If the identifier of the grandmaster clock is not in the exclusion list, flow then moves to operation 502 at which the BMCA data set algorithm is run to determine the new best master clock for the local clock of the network node. The operations of Figure 3A can then be performed and the newly identified best master clock can be used to determine whether the identifier of the current best master clock should be included in the temporary exclusion list.
[0075] Referring back to operation 607, when the identifier of the grandmaster clock is found in the exclusion list, flow then moves to operation 608, at which the network node determines whether the a number of hops associated with the identifier of the grandmaster of the Announce message (e.g., a value of the "stepsRemoved" field in the Announce message) is strictly greater than a number of hops stored for that clock identifier in the temporary exclusion list plus 1 (e.g., the value of the "stepsRemoved" associated with the identifier of the grandmaster clock when it was first added to the temporary exclusion table). If this condition is satisfied (i.e., the number of hops associated with the identifier of the grandmaster of the Announce message is strictly greater than a number of hops stored for that clock identifier in the temporary exclusion list plus 1), then flow moves to operation 610 at which the Erbest for that port is set to be an empty set (i.e., causing the Announce message including the identifier of the grandmaster to be ignored when computing the Ebest for the network node). Flow then moves to operation 502 and to the following operations of Figure 3 A. Alternatively, if the condition is not satisfied (i.e., the number of hops associated with the identifier of the grandmaster of the Announce message is smaller than or equal to the number of hops stored for that clock identifier in the temporary exclusion list plus 1), then flow moves to operation 502 at which the BMCA data set algorithm is run to determine the new best master clock for the local clock of the network node. The operations of Figure 3A can then be performed and the newly identified best master clock can be used to determine whether the identifier of the current best master clock should be included in the temporary exclusion list.
[0076] This approach described with reference to Figures 3A-B has the advantage of removing the possibility of selecting a network node already contributing to the timing chain by enforcing that any newly selected grandmaster (i.e., a grandmaster of a new best master clock) is not present in the exclusion list prior to being used as a best master clock for the network node if the number of hops associated with the identifier of the grandmaster is greater than the number of hops stored for that clock identifier in the temporary exclusion list plus 1. This compensates for the inability of a node to recognize a timing loop.
[0077] Figure 3C illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments. Figure 3C illustrates network nodes 201, 202, 203 and 204 of Figure IB with similar initial configuration settings. In the following description the same reference numbers are retained for corresponding steps. The arrow 280 indicates the direction of the synchronization process of the clocks within the PTP network including the devices 201, 202, 203, and 204. In this figure the arrows 290, 291, 292, 293, 295, 295, 296 and 297 indicate the order and direction of propagation of Announce messages from a port of a first node to a peer port in another node. At time Tl, the network node 201, acting as a grandmaster node of the PTP domain, broadcasts an Announce message 290 through the master port 211 including characteristics of a grandmaster clock (GM). In this exemplary scenario 2, the grandmaster of the PTP domain is the network node 201, thus the identifier of the grandmaster clock transmitted within the Announce message 290 is the identifier of the local clock of the network node 201 as identified in the default data set of the local clock of the network node 201. The characteristics of the grandmaster clock of network device 201 are propagated to network node 203, 204 and 202 through the Announce messages 291, 292 and 293. These Announce messages are used in the determination of respective best master clocks for the local clocks of the other network nodes of the PTP domain (i.e., network nodes 202, 203, and 204). At time Tl, the grandmaster clock of network node 201 is still active and continuously transmits PTP messages to the nodes of the network domain (202, 203, and 204). The states of each port of the nodes are determined based on the BMCA and the local attributes set for each port. For example, the local priority parameter of port 241 is set to 1 causing the port 241 to resolve to a slave state and the state of the port 242 to resolve to a master state.
[0078] The network nodes 201, 202, 203 and 204 are operative to perform the operations described with reference to Figures 3A-B. In contrast to the prior art exemplary scenario 2 of Figure IB, where a timing loop occurs in the network domain, the mechanisms described with reference to Figures 3A-B, enable the network node 202 to discard the Announce Message 297 received from network node 204 (which also includes the identifier of the grandmaster of network node 201) until after a timeout period has expired for that identifier.
[0079] When a new best master for the network node 202, the previous best master
(grandmaster of 201) is added to the exclusion table. Thus upon receipt of an Announce message 297 (new Erbest) from network node 204 (which still includes an identifier of the grandmaster clock of network node 201), the network node 202 ignores the Announce message 297 receiver at port 223 causing the grandmaster clock of node 201 to no longer be considered in the determination of the best master clock for the local clock of the network node 202. In some embodiments, the node 202 may further verify whether the difference between a number of hops (e.g., a value of "stepsRemoved" field) received in the Announce message and the value stored in the exclusion table for that identifier is more than 1 prior to ignoring the message. In the meantime, network node 202 may initiate a holdover process.
[0080] Following the expiration of the predetermined period of time, the identifier of the grandmaster clock of network node 201 is removed from the exclusion table as described with reference to operations 604 and 606 of Figure 3B At that point, the timing loop will have already been cleared due to the propagation of the new grandmaster in the PTP domain (e.g., the new grandmaster can be the local clock of network node 202). Thus scenario 2 of Figure 3C provides an example of configuration and topology in which a timing loop is prevented by performing the operations described with reference to Figures 3A-B. While in some embodiments, the operations of Figures 3 A-B are described with respect to the exemplary scenario 2 of Figure 3C, one of ordinary skill in the art will recognize that the topology presented in the scenario of Figure 3C is exemplary only and that the mechanism described with respect to Figures 3A-B can be used to prevent timing loops in different (e.g., more complicated or more simple) topologies. [0081] Further the embodiments described with respect to Figures 3A-C can be used independently or in combinations with the embodiments of Figures 2A-B such that the two techniques can be used to prevent the occurrence of timing loops in a PTP network. In particular the two techniques can be used in combination or independently to prevent timing loops due to local settings (such as the localPriority and notSlave parameters). For example the operations 400 of Figure 2A can be performed in a network node prior to the operations of Figures 3A-B.
[0082] Preventing Timing Loops with a modified BMCA state determination algorithm
[0083] Figure 4A illustrates exemplary operations performed in a network node of a Precision Time Protocol (PTP) network for preventing timing loops in accordance with some
embodiments. The network node is a first network node which includes a local clock that is associated with a default data set (DO) indicating default characteristics for the local clock. At operation 702, the first network node receives, at a first PTP port, a first PTP Announce message from a second PTP port of a second network node, wherein the first PTP Announce message includes PTP timing characteristics maintained by the second network node, and the first PTP port is configured with a not slave parameter set to true indicating that PTP timing
characteristics of Announce messages received at the first PTP port are to be ignored when determining a best master clock for the first network node. Flow then moves to operation 704 at which the first network node determines that a state of the first PTP port is a passive state based on timing characteristics maintained by the second network node regardless of the first PTP port being configured with a not slave parameter set to true.
[0084] In some embodiments, the determination that a state of the first PTP port is a passive state is performed according to an enhanced BMCA state determination algorithm as illustrated in Figure 4B. The enhanced BMCA state determination algorithm includes additional decision branches 902 and 904 leading to the state of a PTP port being determined as passive when certain criteria are satisfied even if the notSlave parameter is set to true for that particular PTP port. In the IEEE1588 Default Profile it is a protocol violation to have two peer PTP ports persist in the Master state. One of the ports must yield to its peer and transition to a Passive or Slave state.
[0085] In the ITU-T G.8275.1/Y.1368.1 Recommendation it is stated that the objective of adding the notSlave=True setting is such that the computation of best master for the node will not use the information contained in any Announce message received on a port where the notSlave attribute is set the TRUE. The recommendation also states that while this attribute is set to TRUE, a PTP port will always enter the Master state. However as illustrated with reference to scenario 3 of Figure 1C, this may cause timing loops within a PTP network. The present invention proposes to modify the BMCA state determination algorithm of the ITU-T G.8275.1/Y.1368.1 Recommendation to allow a PTP port with the notSlave=TRUE, to still enter into a Passive state. The behavior is similar to that of a PTP port with the notSlave=FALSE, except that the Erbest does not participate in the Ebest selection process, and therefore cannot enter into a slave state. This conforms to the reasoning provided within the recommendation, and maintains the BMCA symmetry between nodes of the PTP domain.
[0086] Figure 4B illustrates exemplary operations of an enhanced BMCA state determination algorithm in accordance with some embodiments. Decision points 902, and 904 are inserted in the appropriate location of the flow to ensure that a PTP port which is configured with a notSlave = True can transition to a Passive state when appropriate. In operation, a network node determines a state of a given port "r" by executing the enhanced BMCA state determination algorithm as illustrated in Figure 4B.
[0087] Decision Point 902:
[0088] If DO (i.e., the defaultDS of the local clock of a network node) is not better, or better by topology than Erbest (i.e., the best master clock for that port "r") at this point in the state decision tree, it would imply that notSlave = TRUE for PTP port "r". It also implies that if notSlave was set to FALSE, then Port r would be the Ebest and therefore set to a slave state. A peer PTP port would expect not to observe an Announce message from this PTP port, and it is therefore appropriate to place PTP port r into a passive state instead of being set to a master state (as it would have been the case according to the standard BMCA state algorithm).
[0089] Decision Point 904:
[0090] If there exists an Erbest (i.e., the best master clock for that port "r") that is better than Ebest (i.e., the best master clock for the node) it implies at this point in the state decision tree that notSlave = TRUE for PTP port "r." It also implies that if notSlave is set to FALSE, then PTP port r would be the Ebest, and therefore set to a slave state. A peer PTP port would expect not to observe an Announce message from this Port, and it is therefore appropriate to place PTP port r into a passive state instead of being set to a master state (as it would have been the case according to the standard BMCA state algorithm).
[0091] Thus these embodiments remove inconsistencies in the BMCA caused by the introduction of local parameters (e.g., localPriority and notSlave), and eliminate timing loop possibilities.
[0092] Figure 4C illustrates an exemplary scenario in which a timing loop is prevented in accordance with some embodiments. The arrow 390 indicates the direction of the
synchronization process of the clocks within the PTP network including the network nodes 301, 302, 303, and 304. At time Tl, the network node 301 broadcasts an Announce message through the master port 311 including characteristics of a grandmaster clock (GM). These characteristics are used to synchronize the clock of the other network nodes of the PTP network. At time T2 connection is lost between the between network node 301 and network node 302 at time T2 (e.g., An Announce Receipt Timeout occurs on network node 302 from the T-GM (at time T2)). However in contrast to the exemplary case of Figure 1C, a timing loop is prevented in this case. Network node 304, which is configured with notSlave=True, will transition into a Passive state instead of being forced to a master state. This results in the port 323 of network node 302 to not receive an Announce Message from network node 304. Thus, when connection is lost between the between network nodes 301 and 302 at time T2 (due to a failure of network node 301 or to a failure of the link between 301 and 302), from the perspective of the network node 302, the only option is to transition into Holdover and no timing Loop occurs.
[0093] The embodiments described with respect to Figures 4A-C can be used independently or in combinations with the embodiments of Figures 2A-B, and/or the embodiments of Figures 3A- D such that the three techniques can be used to prevent the occurrence of timing loops in a PTP network. In particular the three techniques can be used to prevent timing loops due to local settings (such as localPriority and notSlave).
[0094] Exemplary Architecture
[0095] Exemplary network devices as described below can be used to implement the operations and embodiments described with respect to Figures 2A-B, 3A-C and 4A-C.
[0096] An electronic device stores and transmits (internally and/or with other electronic devices over a network) code (which is composed of software instructions and which is sometimes referred to as computer program code or a computer program) and/or data using machine -readable media (also called computer-readable media), such as machine -readable storage media (e.g., magnetic disks, optical disks, read only memory (ROM), flash memory devices, phase change memory) and machine -readable transmission media (also called a carrier) (e.g., electrical, optical, radio, acoustical or other form of propagated signals - such as carrier waves, infrared signals). Thus, an electronic device (e.g., a computer) includes hardware and software, such as a set of one or more processors coupled to one or more machine -readable storage media to store code for execution on the set of processors and/or to store data. For instance, an electronic device may include non-volatile memory containing the code since the non-volatile memory can persist code/data even when the electronic device is turned off (when power is removed), and while the electronic device is turned on that part of the code that is to be executed by the processor(s) of that electronic device is typically copied from the slower nonvolatile memory into volatile memory (e.g., dynamic random access memory (DRAM), static random access memory (SRAM)) of that electronic device. Typical electronic devices also include a set or one or more physical network interface(s) to establish network connections (to transmit and/or receive code and/or data using propagating signals) with other electronic devices. One or more parts of an embodiment of the invention may be implemented using different combinations of software, firmware, and/or hardware.
[0097] A network device (ND) is an electronic device that communicatively interconnects other electronic devices on the network (e.g., other network devices, end-user devices). Some network devices are "multiple services network devices" that provide support for multiple networking functions (e.g., routing, bridging, switching, Layer 2 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/password 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).
[0098] 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. An 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.
[0099] Figure 5A illustrates connectivity between network devices (NDs) within an exemplary network, as well as three exemplary implementations of the NDs, according to some embodiments of the invention. Figure 5A shows NDs 800A-H, and their connectivity by way of lines between 800A-800B, 800B-800C, 800C-800D, 800D-800E, 800E-800F, 800F-800G, and 800A-800G, as well as between 800H and each of 800A, 800C, 800D, and 800G. These NDs are physical devices, and the connectivity between these NDs can be wireless or wired (often referred to as a link). An additional line extending from NDs 800A, 800E, and 800F illustrates that these NDs act as ingress and egress points for the network (and thus, these NDs are sometimes referred to as edge NDs; while the other NDs may be called core NDs).
[00100] Two of the exemplary ND implementations in Figure 5A are: 1) a special-purpose network device 802 that uses custom application-specific integrated-circuits (ASICs) and a special-purpose operating system (OS); and 2) a general purpose network device 804 that uses common off-the-shelf (COTS) processors and a standard OS.
[00101] The special-purpose network device 802 includes networking hardware 810 comprising compute resource(s) 812 (which typically include a set of one or more processors), forwarding resource(s) 814 (which typically include one or more ASICs and/or network processors), and physical network interfaces (NIs) 816 (sometimes called physical ports), as well as non-transitory machine readable storage media 818 having stored therein networking software 820. A physical NI is hardware in a ND through which a network connection (e.g., wirelessly through a wireless network interface controller (WNIC) or through plugging in a cable to a physical port connected to a network interface controller (NIC)) is made, such as those shown by the connectivity between NDs 800A-H. During operation, the networking software 820 may be executed by the networking hardware 810 to instantiate a set of one or more networking software instance(s) 822. Each of the networking software instance(s) 822, and that part of the networking hardware 810 that executes that network software instance (be it hardware dedicated to that networking software instance and/or time slices of hardware temporally shared by that networking software instance with others of the networking software instance(s) 822), form a separate virtual network element 830A-R. Each of the virtual network element(s) (VNEs) 830A-R includes a control communication and configuration module 832A- R (sometimes referred to as a local control module or control communication module) and forwarding table(s) 834A-R, such that a given virtual network element (e.g., 830A) includes the control communication and configuration module (e.g., 832A), a set of one or more forwarding table(s) (e.g., 834A), and that portion of the networking hardware 810 that executes the virtual network element (e.g., 830A). The networking software 820 further includes PTP protocol engine (PTP PE) 821, which when executed instantiate one or more PTP PE Instances 833A-R which enable the prevention of timing loops within a PTP domain as described with the various embodiments of Figures 2A-4C.
[00102] The special-purpose network device 802 is often physically and/or logically considered to include: 1) a ND control plane 824 (sometimes referred to as a control plane) comprising the compute resource(s) 812 that execute the control communication and configuration module(s) 832A-R; and 2) a ND forwarding plane 826 (sometimes referred to as a forwarding plane, a data plane, or a media plane) comprising the forwarding resource(s) 814 that utilize the forwarding table(s) 834A-R and the physical NIs 816. By way of example, where the ND is a router (or is implementing routing functionality), the ND control plane 824 (the compute resource(s) 812 executing the control communication and configuration module(s) 832A-R) is typically responsible for participating in controlling how data (e.g., packets) is to be routed (e.g., the next hop for the data and the outgoing physical NI for that data) and storing that routing information in the forwarding table(s) 834A-R, and the ND forwarding plane 826 is responsible for receiving that data on the physical NIs 816 and forwarding that data out the appropriate ones of the physical NIs 816 based on the forwarding table(s) 834A-R.
[00103] Figure 5B illustrates an exemplary way to implement the special-purpose network device 802 according to some embodiments of the invention. Figure 5B shows a special- purpose network device including cards 838 (typically hot pluggable). While in some embodiments the cards 838 are of two types (one or more that operate as the ND forwarding plane 826 (sometimes called line cards), and one or more that operate to implement the ND control plane 824 (sometimes called control cards)), alternative embodiments may combine functionality onto a single card and/or include additional card types (e.g., one additional type of card is called a service card, resource card, or multi-application card). A service card can provide specialized processing (e.g., Layer 4 to Layer 7 services (e.g., firewall, Internet Protocol Security (IPsec), Secure Sockets Layer (SSL) / Transport Layer Security (TLS), Intrusion Detection System (IDS), peer-to-peer (P2P), Voice over IP (VoIP) Session Border Controller, Mobile Wireless Gateways (Gateway General Packet Radio Service (GPRS) Support Node (GGSN), Evolved Packet Core (EPC) Gateway)). By way of example, a service card may be used to terminate IPsec tunnels and execute the attendant authentication and encryption algorithms. These cards are coupled together through one or more interconnect mechanisms illustrated as backplane 836 (e.g., a first full mesh coupling the line cards and a second full mesh coupling all of the cards). [00104] Returning to Figure 5A, the general purpose network device 804 includes hardware 840 comprising a set of one or more processor(s) 842 (which are often COTS processors) and network interface controller(s) 844 (NICs; also known as network interface cards) (which include physical NIs 846), as well as non-transitory machine readable storage media 848 having stored therein software 850. During operation, the processor(s) 842 execute the software 850 to instantiate one or more sets of one or more applications 864A-R. While one embodiment does not implement virtualization, alternative embodiments may use different forms of virtualization. For example, in one such alternative embodiment the virtualization layer 854 represents the kernel of an operating system (or a shim executing on a base operating system) that allows for the creation of multiple instances 862A-R called software containers that may each be used to execute one (or more) of the sets of applications 864A-R; where the multiple software containers (also called virtualization engines, virtual private servers, or jails) are user spaces (typically a virtual memory space) that are separate from each other and separate from the kernel space in which the operating system is run; and where the set of applications running in a given user space, unless explicitly allowed, cannot access the memory of the other processes. In another such alternative embodiment the virtualization layer 854 represents a hypervisor (sometimes referred to as a virtual machine monitor (VMM)) or a hypervisor executing on top of a host operating system, and each of the sets of applications 864A-R is run on top of a guest operating system within an instance 862A-R called a virtual machine (which may in some cases be considered a tightly isolated form of software container) that is run on top of the hypervisor - the guest operating system and application may not know they are running on a virtual machine as opposed to running on a "bare metal" host electronic device, or through para-virtualization the operating system and/or application may be aware of the presence of virtualization for optimization purposes. In yet other alternative embodiments, one, some or all of the applications are implemented as unikernel(s), which can be generated by compiling directly with an application only a limited set of libraries (e.g., from a library operating system (LibOS) including dri vers/libraries of OS services) that provide the particular OS services needed by the application. As a unikernel can be implemented to run directly on hardware 840, directly on a hypervisor (in which case the unikernel is sometimes described as running within a LibOS virtual machine), or in a software container, embodiments can be implemented fully with unikernels running directly on a hypervisor represented by virtualization layer 854, unikernels running within software containers represented by instances 562A-R, or as a combination of unikernels and the above-described techniques (e.g. , unikernels and virtual machines both run directly on a hypervisor, unikernels and sets of applications that are run in different software containers). [00105] The instantiation of the one or more sets of one or more applications 864A-R, as well as virtualization if implemented, are collectively referred to as software instance(s) 852. Each set of applications 864A-R, corresponding virtualization construct (e.g., instance 862A-R) if implemented, and that part of the hardware 840 that executes them (be it hardware dedicated to that execution and/or time slices of hardware temporally shared), forms a separate virtual network element(s) 860A-R.
[00106] The virtual network element(s) 860A-R perform similar functionality to the virtual network element(s) 830A-R - e.g., similar to the control communication and configuration module(s) 832A and forwarding table(s) 834A (this virtualization of the hardware 840 is sometimes referred to as network function virtualization (NFV)). Thus, NFV may be used to consolidate many network equipment types onto industry standard high volume server hardware, physical switches, and physical storage, which could be located in Data centers, NDs, and customer premise equipment (CPE). While embodiments of the invention are illustrated with each instance 862A-R corresponding to one VNE 860A-R, alternative embodiments may implement this correspondence at a finer level granularity (e.g., line card virtual machines virtualize line cards, control card virtual machine virtualize control cards, etc.); it should be understood that the techniques described herein with reference to a correspondence of instances 862A-R to VNEs also apply to embodiments where such a finer level of granularity and/or unikernels are used.
[00107] In certain embodiments, the virtualization layer 854 includes a virtual switch that provides similar forwarding services as a physical Ethernet switch. Specifically, this virtual switch forwards traffic between instances 562A-R and the NIC(s) 844, as well as optionally between the instances 862A-R; in addition, this virtual switch may enforce network isolation between the VNEs 860A-R that by policy are not permitted to communicate with each other (e.g., by honoring virtual local area networks (VLANs)).
[00108] The third exemplary ND implementation in Figure 5A is a hybrid network device 806, which includes both custom ASICs/special-purpose OS and COTS processors/standard OS in a single ND or a single card within an ND. In certain embodiments of such a hybrid network device, a platform VM (i.e., a VM that that implements the functionality of the special-purpose network device 802) could provide for para-virtualization to the networking hardware present in the hybrid network device 806.
[00109] Regardless of the above exemplary implementations of an ND, when a single one of multiple VNEs implemented by an ND is being considered (e.g., only one of the VNEs is part of a given virtual network) or where only a single VNE is currently being implemented by an ND, the shortened term network element (NE) is sometimes used to refer to that VNE. Also in all of the above exemplary implementations, each of the VNEs (e.g., VNE(s) 830A-R, VNEs 860A-R, and those in the hybrid network device 806) receives data on the physical NIs (e.g., 816, 846) and forwards that data out the appropriate ones of the physical NIs (e.g., 816, 846). For example, a VNE implementing IP router functionality forwards IP packets on the basis of some of the IP header information in the IP packet; where IP header information includes source IP address, destination IP address, source port, destination port (where "source port" and
"destination port" refer herein to protocol ports, as opposed to physical ports of a ND), transport protocol (e.g., user datagram protocol (UDP), Transmission Control Protocol (TCP), and differentiated services (DSCP) values.
[00110] A network interface (NI) may be physical or virtual; and in the context of IP, an interface address is an IP address assigned to a NI, be it a physical NI or virtual NI. A virtual NI may be associated with a physical NI, with another virtual interface, or stand on its own (e.g., a loopback interface, a point-to-point protocol interface). A NI (physical or virtual) may be numbered (a NI with an IP address) or unnumbered (a NI without an IP address). A loopback interface (and its loopback address) is a specific type of virtual NI (and IP address) of a NE/VNE (physical or virtual) 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 NI(s) of a ND are referred to as IP addresses of that ND; at a more granular level, the IP address(es) assigned to NI(s) assigned to a NE/VNE implemented on a ND can be referred to as IP addresses of that NE/VNE.
[00111] 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.
[00112] 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.
[00113] 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.
[00114] While the flow diagrams in the figures show a particular order of operations performed by certain embodiments of the invention, it should be understood that such order is exemplary (e.g., alternative embodiments may perform the operations in a different order, combine certain operations, overlap certain operations, etc.).
[00115] While embodiments are described with reference to IEEE 1588, and profile G8275.1, those skilled in the art will recognize that the invention is not limited to these embodiments, and can be practiced on present as well as future versions of timing protocols without departing from the scope of the present invention.
[00116] While various embodiments are described with reference to a local clock for each network node (e.g., a first local clock of the first network node and a second local clock of the second network node), other embodiments may include more than one local clock per node, where each local clock is associated with a set of one or more PTP ports and a set of default characteristics. In some embodiments, multiple local clocks of a single network node may be part of the same PTP domain, while in other embodiments, different local clocks of a same network node may be part of different PTP domains. In some embodiments, the local clocks of a single network node may be synchronized to the same best master clock or alternatively to different best master clocks. The embodiments described herein apply for each local clock and its associated PTP port in a network device.
[00117] While the invention has been described in terms of several embodiments, those skilled in the art will recognize that the invention is not limited to the embodiments described, can be practiced with modification and alteration within the spirit and scope of the appended claims. The description is thus to be regarded as illustrative instead of limiting.

Claims

CLAIMS What is claimed is:
1. A method in a first network node of a Precision Time Protocol (PTP) network of preventing timing loops, wherein the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node, the method comprising:
receiving (402), at a first port from the set of ports, an Announce message from a second port of a second network node, wherein the Announce message includes an identifier and characteristics of a grandmaster clock, and wherein the grandmaster clock is a source of time for clock synchronization for a second local clock of the second network node;
determining (404) whether the identifier of the grandmaster clock is identical to a local identifier of the first local clock of the first network node;
in response to determining that the identifier of the grandmaster clock is identical to the local identifier of the first local clock, discarding (406) the Announce message received at the first port causing the characteristics of the grandmaster clock to be ignored when determining a best master clock for the first local clock, wherein the best master clock is to be used as a source of synchronization for the first local clock of the first network node; and
in response to determining that the identifier of the grandmaster clock is not identical to the local identifier of the first local clock, using (408) the characteristics of the grandmaster clock when determining the best master clock for the first local clock of the first network node.
2. The method of claim 1, wherein discarding the Announce message received at the first port causes (412) an external best master clock on the first port to resolve to an empty set which causes the characteristics of the grandmaster clock to be ignored when determining the best master clock of the first network node.
3. The method of claim 1, wherein a value of a local priority parameter of the first port is configured to be of higher precedence than other local priority parameter values of the first network node indicating that clock characteristics included in Announce messages received at the first port are to be used when determining the best master clock of the first network node, and wherein discarding (406) the Announce message received at the first port is performed regardless of the value of the local priority parameter of the first port causing the characteristics of the grandmaster clock to be ignored when determining the best master clock of the first network node.
4. The method of claim 3, wherein discarding (406) the Announce message results in avoiding timing loops in the FTP network caused by the value of the local priority parameter of the first port being of higher precedence than other local priority parameter values in the first network node.
5. The method of claim 1, wherein the first local clock of the first network node is synchronized according to a current best master clock, the method further comprising:
determining (502) a new best master clock for the first local clock of the first network node;
determining (504) whether a first identifier of the current best master clock for the first local clock is to be included in an exclusion list; and
responsive to determining that the first identifier is to be included in the exclusion list, adding (506) the first identifier in the exclusion list causing any Announce messages including the first identifier to be ignored during a predetermined period of time when determining a next best master clock for the first local clock of the first network node.
6. The method of claim 5, wherein determining whether the first identifier is to be included in the exclusion list includes:
determining (514) whether characteristics of the new best master clock are different from characteristics of the current best master clock.
7. The method of claim 5, wherein adding the first identifier in the exclusion list further includes adding (516) a number of hops associated with the first identifier of the current best master clock, and a timing value indicating a predetermined period of time during which the first identifier is to remain in the exclusion list, wherein the number of hops indicate a distance between the first local clock and a grandmaster clock of the current best master clock.
8. The method of claim 7 further comprising:
receiving a new Announce message including an identifier of a new grandmaster clock; determining (607) whether the identifier of the new grandmaster clock is included in the exclusion list; and
in response to determining that the identifier of the new grandmaster clock is included in the exclusion list, determining (608) whether a new number of hops associated with the identifier of the new grandmaster clock is greater than a stored number of hops associated with the identifier of the new grandmaster clock in the exclusion list plus one; and
in response to determining that the new number of hops associated with the identifier of the new grandmaster clock is greater than the stored number of hops plus one, ignoring (610) the new Announce message when determining the next best master clock for the first local clock of the first network node.
9. The method of claim 5, wherein the exclusion list includes one or more identifiers of one or more clocks respectively associated with one or more exclusion timers indicating a respective predetermined period of time during which each one of the one or more identifiers is to remain in the exclusion list, and wherein the method further comprises:
Determining (604), prior to determining the new best master clock, whether the
exclusion list includes an expired exclusion timer associated with an identifier of a second grandmaster clock indicating that the identifier is to be removed from the exclusion list;
Removing (606) the identifier of the second grandmaster clock from the exclusion list causing Announce messages including the identifier of the second grandmaster clock to be used when determining a best master clock for the first network node after an expiration of the exclusion timer.
10. The method of claim 1, wherein the FTP is based upon the ITU-T (International Telecommunication Union (ITU) Telecommunication Standardization Sector) G.8275.1 Telecom Profile.
11. A first network node of a Precision Time Protocol (PTP) network, wherein the first network node includes a first local clock that is associated with default characteristics and a set of one or more ports in the first network node, the first network node comprising:
one or more processors and a non-transitory computer readable storage medium, said non-transitory computer readable storage medium containing instructions, which when executed by the one or more processors, causes the first network node to: receive (402), at a first port from the set of ports, an Announce message from a second port of a second network node, wherein the Announce message includes an identifier and characteristics of a grandmaster clock, and wherein the grandmaster clock is a source of time for clock
synchronization for a second local clock of the second network node; determine (404) whether the identifier of the grandmaster clock is identical to a local identifier of the first local clock of the first network node;
in response to determining that the identifier of the grandmaster clock is identical to the local identifier of the first local clock, discard (406) the Announce message received at the first port causing the characteristics of the grandmaster clock to be ignored when determining a best master clock for the first local clock, wherein the best master clock is to be used as a source of synchronization for the first clock of the first network node; and in response to determining that the identifier of the grandmaster clock is not identical to the local identifier of the first local clock, use (408) the characteristics of the grandmaster clock when determining the best master clock for the first local clock of the first network node.
12. The first network node of claim 11, wherein to discard the Announce message received at the first port causes (412) an external best master clock on the first port to resolve to an empty set which causes the characteristics of the grandmaster clock to be ignored when determining the best master clock of the first network node.
13. The first network node of claim 11, wherein a value of a local priority parameter of the first port is configured to be of higher precedence than other local priority parameter values of the first network node indicating that clock characteristics included in Announce messages received at the first port are to be used when determining the best master clock of the first network node, and wherein to discard (406) the Announce message received at the first port is performed regardless of the value of the local priority parameter of the first port causing the characteristics of the grandmaster clock to be ignored when determining the best master clock of the first network node.
14. The first network node of claim 13, wherein to discard (406) the Announce message results in avoiding timing loops in the PTP network caused by the value of the local priority parameter of the first port being of higher precedence than other local priority parameter values in the first network node.
15. The first network node of claim 11, wherein the first local clock of the first network node is synchronized according to a current best master clock, and the first network node is further to: determine (502) a new best master clock for the first local clock of the first network node;
determine (504) whether a first identifier of the current best master clock for the first local clock is to be included in an exclusion list; and
responsive to determining that the first identifier is to be included in the exclusion list, to add (506) the first identifier in the exclusion list causing any Announce messages including the first identifier to be ignored during a predetermined period of time when determining a next best master clock for the first local clock of the first network node.
16. The first network node of claim 15, wherein to determine whether the first identifier is to be included in the exclusion list includes:
determining (514) whether characteristics of the new best master clock are different from characteristics of the current best master clock.
17. The first network node of claim 15, wherein to add the first identifier in the exclusion list further includes to add (516) a number of hops associated with the first identifier of the current best master clock, and a timing value indicating a predetermined period of time during which the first identifier is to remain in the exclusion list, wherein the number of hops indicate a distance between the first local clock and a grandmaster clock of the current best master clock.
18. The first network node of claim 17, wherein the first network node is further to:
receive a new Announce message at a third port including an identifier of a new
grandmaster clock;
determine (607) whether the identifier of the new grandmaster clock is included in the exclusion list;
in response to determining that the identifier of the new grandmaster clock is included in the exclusion list, determine (608) whether a new number of hops associated with the identifier of the new grandmaster clock is greater than a stored number of hops associated with the identifier of the new grandmaster clock in the exclusion list plus one; and
in response to determining that the new number of hops associated with the identifier of the new grandmaster clock is greater than the stored number of hops plus one, ignore (610) the new Announce message when determining the next best master clock for the first local clock of the first network node.
19. The first network node of claim 15, wherein the exclusion list includes one or more identifiers of one or more clocks respectively associated with one or more exclusion timers indicating a respective predetermined period of time during which each one of the one or more identifiers is to remain in the exclusion list, and wherein the first network node is further to: determine (604), prior to determining the new best master clock, whether the exclusion list includes an expired exclusion timer associated with an identifier of a second grandmaster clock indicating that the identifier is to be removed from the exclusion list; and
remove (606) the identifier of the second grandmaster clock from the exclusion list causing Announce messages including the identifier of the second grandmaster clock to be used when determining a best master clock for the first network node after an expiration of the exclusion timer.
20. The first network node of claim 11, wherein the PTP is based upon the ITU-T
(International Telecommunication Union (ITU) Telecommunication Standardization Sector) G.8275.1 Telecom Profile.
PCT/IB2016/050860 2016-01-27 2016-02-17 A method of timing loop prevention for the precision time protocol (ptp) with g.8275.1 profile WO2017130034A1 (en)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US201662287866P 2016-01-27 2016-01-27
US62/287,866 2016-01-27

Publications (1)

Publication Number Publication Date
WO2017130034A1 true WO2017130034A1 (en) 2017-08-03

Family

ID=55446838

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/IB2016/050860 WO2017130034A1 (en) 2016-01-27 2016-02-17 A method of timing loop prevention for the precision time protocol (ptp) with g.8275.1 profile

Country Status (1)

Country Link
WO (1) WO2017130034A1 (en)

Cited By (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020020936A1 (en) * 2018-07-25 2020-01-30 Continental Automotive Gmbh Clock topology in an ethernet network
WO2020020932A1 (en) * 2018-07-25 2020-01-30 Continental Automotive Gmbh Topology discovery in an automotive ethernet network
CN112260791A (en) * 2020-12-18 2021-01-22 之江实验室 Improved clock synchronization super-master clock hot backup method
CN112367137A (en) * 2019-09-06 2021-02-12 华为技术有限公司 Method, device, system and storage medium for realizing clock source selection
WO2021139692A1 (en) * 2020-01-06 2021-07-15 华为技术有限公司 Clock port attribute recovery method, device, and system
US11336687B2 (en) 2020-01-03 2022-05-17 Disney Enterprises, Inc. System and method for providing security for master clocks
CN115102660A (en) * 2022-08-26 2022-09-23 深圳市英特瑞半导体科技有限公司 Method, device, equipment and storage medium for breaking damage based on synchronous Ethernet
WO2022206614A1 (en) * 2021-04-02 2022-10-06 烽火通信科技股份有限公司 Packet synchronization channel failure handling method and device
EP3902164A4 (en) * 2018-12-18 2022-12-07 China Mobile Communication Co., Ltd. Research Institute Method for determining port status and network node
WO2023274160A1 (en) * 2021-06-30 2023-01-05 中兴通讯股份有限公司 Method for avoiding clock looping, and upstream network element, downstream network element and storage medium
EP4145729A4 (en) * 2020-05-20 2023-11-08 Huawei Technologies Co., Ltd. Port state configuration method, apparatus, system, and storage medium
WO2023236048A1 (en) * 2022-06-07 2023-12-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and network device for ptp clock synchronization
US11973855B2 (en) 2021-08-25 2024-04-30 Siemens Canada Limited PTP transparent clock with inter-VLAN forwarding

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130227008A1 (en) * 2012-02-27 2013-08-29 Cisco Technology, Inc. Clock synchronization based on predefined grandmaster
WO2014169458A1 (en) * 2013-04-18 2014-10-23 Telefonaktiebolaget L M Ericsson (Publ) Node and method for selecting synchronization source
EP2941065A1 (en) * 2012-12-31 2015-11-04 ZTE Corporation Time synchronization method and system

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20130227008A1 (en) * 2012-02-27 2013-08-29 Cisco Technology, Inc. Clock synchronization based on predefined grandmaster
EP2941065A1 (en) * 2012-12-31 2015-11-04 ZTE Corporation Time synchronization method and system
WO2014169458A1 (en) * 2013-04-18 2014-10-23 Telefonaktiebolaget L M Ericsson (Publ) Node and method for selecting synchronization source

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
"IEEE Standard for a Precision Clock Synchronization Protocol for Networked Measurement and Control Systems", IEEE 1588-2008, 2008
"Precision time protocol telecom profile for phase/time synchronization with full timing support from the network; G.8275.1/Y.1369.1 (07/14)", no. G.8275.1/Y.1369.1 (07/14), 22 July 2014 (2014-07-22), pages 1 - 42, XP044172653, Retrieved from the Internet <URL:http://mirror.itu.int/dms/pay/itu-t/rec/g/T-REC-G.8275.1-201407-S!!PDF-E.pdf> [retrieved on 20150505] *
PETER MEYER MICROSEMI CORPORATION USA: "BMCA and Clock Models [G.8275.2];(R-C-WD)", ITU-T DRAFT ; STUDY PERIOD 2013-2016, INTERNATIONAL TELECOMMUNICATION UNION, GENEVA ; CH, vol. 13/15, 18 September 2015 (2015-09-18), pages 1 - 16, XP044148435 *
STANDARD FOR A PRECISION CLOCK SYNCHRONIZATION PROTOCOL FOR NETWORKED MEASUREMENT AND CONTROL SYSTEMS, 2002

Cited By (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2020020932A1 (en) * 2018-07-25 2020-01-30 Continental Automotive Gmbh Topology discovery in an automotive ethernet network
WO2020020936A1 (en) * 2018-07-25 2020-01-30 Continental Automotive Gmbh Clock topology in an ethernet network
CN112425101A (en) * 2018-07-25 2021-02-26 大陆汽车有限公司 Clock topology in Ethernet networks
US11546074B2 (en) 2018-07-25 2023-01-03 Continental Automotive Gmbh Clock topology in an ethernet network
US11316604B2 (en) 2018-07-25 2022-04-26 Continental Automotive Gmbh Topology discovery in an automotive ethernet network
EP3902164A4 (en) * 2018-12-18 2022-12-07 China Mobile Communication Co., Ltd. Research Institute Method for determining port status and network node
CN112367137A (en) * 2019-09-06 2021-02-12 华为技术有限公司 Method, device, system and storage medium for realizing clock source selection
CN114448548A (en) * 2019-09-06 2022-05-06 华为技术有限公司 Method, device, system and storage medium for realizing clock source selection
US11336687B2 (en) 2020-01-03 2022-05-17 Disney Enterprises, Inc. System and method for providing security for master clocks
KR20220108816A (en) * 2020-01-06 2022-08-03 후아웨이 테크놀러지 컴퍼니 리미티드 Method, device, and system for restoring clock port properties
KR102684118B1 (en) 2020-01-06 2024-07-10 후아웨이 테크놀러지 컴퍼니 리미티드 Methods for restoring clock port properties, devices, and systems
JP7451721B2 (en) 2020-01-06 2024-03-18 華為技術有限公司 Clock port attribute recovery methods, devices, and systems
WO2021139692A1 (en) * 2020-01-06 2021-07-15 华为技术有限公司 Clock port attribute recovery method, device, and system
JP2023509491A (en) * 2020-01-06 2023-03-08 華為技術有限公司 CLOCK PORT ATTRIBUTE RECOVERY METHOD, DEVICE AND SYSTEM
EP4145729A4 (en) * 2020-05-20 2023-11-08 Huawei Technologies Co., Ltd. Port state configuration method, apparatus, system, and storage medium
CN112260791A (en) * 2020-12-18 2021-01-22 之江实验室 Improved clock synchronization super-master clock hot backup method
WO2022206614A1 (en) * 2021-04-02 2022-10-06 烽火通信科技股份有限公司 Packet synchronization channel failure handling method and device
WO2023274160A1 (en) * 2021-06-30 2023-01-05 中兴通讯股份有限公司 Method for avoiding clock looping, and upstream network element, downstream network element and storage medium
US11973855B2 (en) 2021-08-25 2024-04-30 Siemens Canada Limited PTP transparent clock with inter-VLAN forwarding
WO2023236048A1 (en) * 2022-06-07 2023-12-14 Telefonaktiebolaget Lm Ericsson (Publ) Method and network device for ptp clock synchronization
CN115102660B (en) * 2022-08-26 2022-11-04 深圳市英特瑞半导体科技有限公司 Method, device, equipment and storage medium for breaking based on synchronous Ethernet
CN115102660A (en) * 2022-08-26 2022-09-23 深圳市英特瑞半导体科技有限公司 Method, device, equipment and storage medium for breaking damage based on synchronous Ethernet

Similar Documents

Publication Publication Date Title
WO2017130034A1 (en) A method of timing loop prevention for the precision time protocol (ptp) with g.8275.1 profile
US11665089B2 (en) Mechanism for hitless resynchronization during SDN controller upgrades between incompatible versions
US9692690B2 (en) Method and system for path monitoring in a software-defined networking (SDN) system
US9686199B2 (en) Method and system for implementing ethernet OAM in a software-defined networking (SDN) system
US9880829B2 (en) Method and apparatus for performing hitless update of line cards of a network device
EP3304812B1 (en) Method and system for resynchronization of forwarding states in a network forwarding device
EP3459225B1 (en) Methods and apparatus for enabling live virtual machine (vm) migration in software-defined networking networks
US20160080505A1 (en) Method and system of session-aware load balancing
EP3382955B1 (en) Service function chaining (sfc) communication methods and devices
US20150326469A1 (en) Oam aided explicit path report via igp
WO2018188425A1 (en) Vxlan single-homing and dual-homing hybrid access method and apparatus, pe device and storage medium
EP3378205A1 (en) Service based intelligent packet-in buffering mechanism for openflow switches by having variable buffer timeouts
EP3494670B1 (en) Method and apparatus for updating multiple multiprotocol label switching (mpls) bidirectional forwarding detection (bfd) sessions
US11340933B2 (en) Method and apparatus for secrets injection into containers for 5G network elements
US9917871B2 (en) Optimizing media bitrate with explicit network feedback on one client only
US20160080249A1 (en) Prevent vrrp master / master split in active / standby icr system
US11368381B2 (en) Optimizing tunnel monitoring in SDN
EP3529964A1 (en) Service aware switch-over of tcp-flows
WO2017175033A1 (en) Method and apparatus for enabling non stop routing (nsr) in a packet network
EP3932044B1 (en) Automatic distribution of dynamic host configuration protocol (dhcp) keys via link layer discovery protocol (lldp)
US20180139127A1 (en) Border leaf traffic convergence in a software defined network
US11451637B2 (en) Method for migration of session accounting to a different stateful accounting peer
US20230007105A1 (en) Mechanism to enable third party services and applications discovery in distributed edge computing environment
EP3622667B1 (en) A method and apparatus for enhancing multicast group membership protocol(s)
WO2022023999A1 (en) Method and apparatus for secrets injection into containers for 5g network elements

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 16707212

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16707212

Country of ref document: EP

Kind code of ref document: A1