Embodiments are directed to timing synchronization between network nodes, such as, for example, based upon IEEE 1588. Example embodiments provide for a node in a IEEE 1588 message exchange to obtain the T3 timestamp without using its host interface to access the physical layer. Methods and systems include aspects of determining an egress timestamp corresponding to a time at which a first packet is transmitted from a physical interface of a first network entity on to a network media, storing the egress timestamp in a memory associated with the physical interface, receiving a second packet at the physical interface, retrieving the egress timestamp from the memory based upon the second packet, and updating the second packet with the retrieved egress timestamp. Embodiments may further include providing the updated second packet for protocol processing in the first network entity, or transmitting the updated second packet from the physical interface on to a network media.

BACKGROUND

1. Field of the Invention

Embodiments of this invention are related generally to synchronization between network entities.

2. Background Art

Timing and frequency synchronization among network entities that communicate with each other is an important issue in network performance. The accuracy of the synchronization between network nodes affects the performance of systems attached to the network and also the overall performance of the network. The IEEE 1588 protocol, referred to as the Precision Time Protocol (PTP) is a technique for providing robust cost-effective time synchronization for the distributed systems. IEEE 1588 is designed for substantially higher accuracy levels (e.g. on the order of submicroseconds) than the older network synchronization protocol known as the Network Time Protocol (NTP).

IEEE 1588 is based on packet exchanges between network entities (network nodes) defined as masters and as slaves (also referred to as master nodes and slave nodes, respectively). Each slave synchronizes its clock (“slave clock” or SC) to the clock of a master. To enhance fault tolerance, an election process may determine one among a plurality of masters to provide the accurate clock at any particular instant to the slaves. The master that is selected to provide the accurate clock is referred to as a grandmaster or GM.

IEEE 1588 implementations require that every participating network interface (e.g. port) takes very accurate timestamps of selected packet ingress and/or egress, and manages precisely synchronized time. By taking timestamps at the edge of the physical layer for a network interface very close to the network medium, the time difference between when a packet is transmitted from a first node to that packet being received at second node can be minimized.

For large networks however, particularly when packets traverses multiple hops from a source to a destination, the desired high accuracy may not be achieved without considering the packet queuing delays at intermediate nodes. Data traffic may cause long delays (on the order of milliseconds) of IEEE 1588 packets because the same network resources are shared by data traffic and IEEE 1588 packets. The latest version of the IEEE 1588 defines a transparent clock (TC) associated with respective intermediate nodes between a master and a slave. A network element that operates as a TC measures the residence time (e.g. queuing delay) that the IEEE 1588 packets experience at the network element itself, and may record that residence time in respective packets. Each IEEE 1588 slave then eliminates the synchronization error that results from residence time by using the residence time information found in the packets.

However, implementations of IEEE 1588 that are in common use at present have inefficiencies in notifying the network entities of the timestamps. Such inefficiencies can result in the IEEE 1588 implementation imposing a high burden upon processing resources at network nodes. Therefore, it is desired that more efficient techniques for network time synchronization are available.

DETAILED DESCRIPTION OF THE INVENTION

Embodiments provide for efficient timing synchronization between entities connected to a network. Some embodiments can be used to achieve synchronization in accordance with IEEE 1588 in any packet-switched network (for this disclosure, the term packet is used to include layer 3 packets and layer 2 frames, and the term packet-switched network is used to include frame-switched networks). Some embodiments are directed to reducing the processing overhead placed upon the host processor and delays incurred by synchronization-related processing. In an example embodiment, the egress timestamp of an outgoing message is saved in a memory associated with the physical interface through which the message egresses, and upon receiving the response message corresponding to the transmitted message the saved egress timestamp is recorded in the header of the response message before the response message is passed up the protocol stack. The egress timestamp corresponds to the time the message is transmitted on the physical network medium from the physical interface.

By saving the egress timestamp until the corresponding response is received and then recording the egress timestamp in the response, embodiments provide an efficient technique for informing the protocol processing entities of the egress and ingress timestamps of a request message. The egress timestamp can be inserted as a field in the header of selected protocol packets so that it is communicated inband, avoiding costs associated with additional data that changes the size of packets. By this technique, the requirement for relatively slow host interface (e.g. Media Independent Interface (MII) and/or Management Data Input/Output (MDIO) interface) access to a memory associated with the physical interface is reduced or eliminated.

The embodiments below are described primarily with respect to IEEE 1588. However, the embodiments and the features described herein can also be applied to timing and/or frequency synchronization techniques other than those consistent with IEEE 1588. Some embodiments can be applied to any technique which requires a protocol processing entity within a network node to acquire a precise timestamp of when a packet exits its physical interface.

FIG. 1Aillustrates a sequence diagram100of a message exchange for timing synchronization, in accordance with an embodiment. The illustrated message exchange involves three nodes: a master node (GM)102, an intermediate node106referred to as a transparent clock (TC), and a slave node104with a SC to be synchronized with the GM.

The message exchange, in accordance with IEEE 1588, begins with SYNC112packet transmitted by master102to slave104. SYNC112may be intercepted by one or more intermediate nodes106. Thus, SYNC112is transmitted by master102and may either be directly received by slave104or may first traverse through one or more intermediate nodes106before being forwarded to slave104.

SYNC112includes a timestamp T1 which represents the time SYNC112was transmitted by master102onto the network (e.g. egress start of packet time). T1 can be included in the body of the SYNC112packet. IEEE 1588 requires very high (e.g. submicrosecond or nanosecond) accuracy, which requires that T1 is captured at or very close to the actual time at which the message is physically transmitted on the network. Embodiments, therefore, utilize hardware at or very close to the physical interface to capture the timestamp to eliminate or minimize the difference in time between the timestamp and the actual transmission of the packet on the network. If the timestamp is captured before the actual transmission of the packet (e.g. at the MAC layer), then the captured timestamp in SYNC112may only be an approximation of the actual egress time. This is because there may be a delay before the packet is actually transmitted on the network medium. For example, when the network medium is an Ethernet, the actual transmission of the packet (e.g. the actual time at which the transmission of the packet from the physical interface onto the network is completed) is dependent on the collision sense multiple access/collision detection (CSMA/CD) protocol and can substantially differ from any timestamp of the packet taken before the actual transmission.

In embodiments where T1 is captured in hardware close to the physical interface at the start of the SYNC112packet, T1 may be recorded in the body just before the packet completes transmission.

Intermediate node106forwards SYNC112to slave104. SYNC112includes timestamp T1. SYNC112may include a correction value when it reaches slave104, which represents the delay (e.g. queuing delay) experienced by the packet at intermediate node106and other intermediate nodes, if any. The queuing delay may be determined by intermediate node106(or other intermediate node) by any internal mechanism. For example, a timestamp may be taken upon ingress of the packet to intermediate node106. A timestamp can again be taken upon egress of the packet from intermediate node106, and the difference of the timestamps may be determined as the delay (also referred to as “residence time”) at intermediate node106, which is then recorded as the correction value. The correction value may be recorded as a field in the header of SYNC112.

When multiple intermediate nodes106are encountered in the path between master and slave, each intermediate node106adds the delay encountered by the packet in the correction value. Thus, the correction value represents an aggregate residence time of the packet.

Intermediate node106may itself also act as a slave and use T1 to synchronize itself to master102. For example, in some embodiments, intermediate node106operates as a slave on the physical interface through which packets are received from master102, and operates as a master on the physical interface through which packets are forwarded to slave104.

When SYNC112reaches slave104, a timestamp T2 is captured upon ingress. T2 represents the ingress start of packet time for SYNC112at slave104. For enhanced accuracy, T2 is captured at or very close to the physical interface of slave104upon reading the start of packet from the network medium. T2 is then recorded in the SYNC112packet. According to an embodiment, T2 can be recorded in the header of SYNC112. Thereafter, SYNC112with T1 and T2 recorded is forwarded up the protocol stack of slave104to the protocol processing modules, such as, for example, IEEE 1588 protocol processing module.

Slave104may adjust T1 and/or T2 based upon the correction value that represents the residence times encountered by the packet enroute from master102to slave104. As noted above, the correction value (e.g. the aggregate correction value) is recorded by the intermediate nodes in the SYNC112header.

The adjustments to T1 and/or T2 based upon the correction value are performed so that T2 can be related to T1 in accordance with T2=T1+offset+propagation delay, where ‘offset’ refers to the offset of the slave from the master, and where ‘propagation delay’ is the cumulative propagation delay experienced by SYNC112enroute from master to slave. According to an embodiment, the adjustments include updating T2 by subtracting the correction value from T2.

The goal of the synchronization is to reduce or eliminate the offset. In order to determine the offset, the propagation delay must be determined. In order to determine the propagation delay between the slave and master, the slave creates a “delay request” (DELAY_REQ)116packet and transmits to the master. A timestamp T3 is captured upon the egress of DELAY_REQ116from the slave. T3 represents the egress start of packet time of DELAY_REQ116.

DELAY_REQ116may reach master102directly, or via one or more intermediate nodes intermediate node106. When DELAY_REQ116is first received, intermediate node106may include the delay incurred by the packet at that node in a correction value recorded in that packet. As in the case of the SYNC packet traversing an intermediate node (as described above), the correction value includes the residence times experienced by the packet at one or more intermediate packets.

DELAY_REQ116, having the recorded correction value, is forwarded by intermediate node106to master102.

Upon ingress of DELAY_REQ116, master102captures a timestamp T4. The timestamp T4 represents the time at which DELAY_REQ116entered master102.

Responsive to the receipt of DELAY_REQ116, master102, creates a “delay response” DELAY_RSP120message and transmits to slave104. DELAY_RSP120includes the T4 timestamp. According to an embodiment, DELAY_RSP120includes T4 as captured upon ingress of DELAY_REQ116and the correction value as recorded in DELAY_REQ116(e.g. T4 is not updated by the master based upon the correction value). According to another embodiment, T4 is updated by the master based upon the correction value, and the updated T4 is included in DELAY_RSP120.

DELAY_RSP120may reach slave104directly, or via one or more intermediate nodes intermediate node106.

Upon receiving DELAY_RSP120, slave104has received timestamps T1, T2, T3 and T4. Based upon these timestamps the slave clock can be synchronized124to that of the master. If any of the timestamps need to be adjusted based upon a corresponding correction value (e.g. representing residence time), then such adjustments are made before the synchronization. In an example embodiment, the difference between the SC and GM can be determined as ((T2−T1)+(T4−T3))/2.

FIG. 1Billustrates a sequence diagram101of another message exchange for timing synchronization, in accordance with an embodiment. Message exchange101is between the same network entities (e.g. master and slave, and none or one or more intermediate nodes) as message exchange100, and is also directed to synchronizing the slave.

Accordingly message exchange101includes a SYNC112′ between a master102′ and slave104′. SYNC112′ corresponds to SYNC112between master102and slave104described in relation to sequence100. Likewise, sequence101includes DELAY_REQ116′ and DELAY_RSP120′ which correspond respectively to DELAY_REQ116and DELAY_RSP120shown in sequence100.

However, in addition to messages corresponding to those in sequence100, sequence101also includes a “sync followup” (SYNC_FOLLOWUP)132transmitted by master102′ immediately following the SYNC112′. SYNC_FOLLOWUP132has recorded in it, the timestamp T1 captured when SYNC112′ was transmitted.

Thus, in embodiments where SYNC112′ and SYNC_FOLLOWUP132are transmitted by the master (e.g. known as “two-step” PTP), the actual timestamp T1 is transmitted using the SYNC_FOLLOWUP132, and SYNC112′ may not include a value for T1. SYNC_FOLLOWUP132may reach slave104directly, or via one or more intermediate nodes TC106.

FIG. 2illustrates a system200for synchronizing time between network entities, in accordance with an embodiment. The illustrated system includes a master202, slave204, and intermediate node (e.g. network switch)206which interconnects master102and slave204.

Master202provides the clock to which slave204, and, in some embodiments, switch206synchronizes. Master clock210may be based upon a global positioning system (GPS) clock or other accurate clock. Master202may include, for example, a GPS receiver (not shown) and GPS clock adjust circuitry (not shown) which may be used by master202to keep master clock210in synchronization with a highly accurate external GPS clock. Master202may include one or more computers, such as a server computer or cluster of server computers. Master202is coupled to slave204and one or more intermediate nodes206over a network208. Network208may include any network technology, such as, but not limited to Ethernet. Master202operates in accordance with the descriptions above related to one or both master102and master102′.

Master202includes a network protocol stack including a physical layer218, a media access control (MAC) layer216, and network layer and above214. Master202also includes a IEEE 1588 protocol module212. Each of the modules212-218can be implemented in software, firmware, hardware or a combination thereof.

IEEE 1588 protocol module212operates to provide the generation and processing of messages, and maintaining of state related to PTP at master202. IEEE 1588 protocol module212may include functions, such as timestamping and/or classification, implemented in the hardware in the physical interface and other functions implemented in software.

Network (layer 3) and higher layers214includes operations to process internet protocol (IP) and higher layer (e.g. transport layer), and routing and forwarding. MAC216includes operations to process layer 2 packet headers and protocols. Physical layer218includes operations to process layer 1 protocol aspects and receipt/transmission of packets from/to the network media. Physical layer218may be implemented in a PHY, such as that described below in relation toFIG. 4. Protocol modules212-218operate in combination to provide master202with operations described in relations to master102and102′ illustrated inFIGS. 1A and 1B.

Slave204includes a network protocol stack including a physical layer248, a media access control (MAC) layer246, and network layer and above244. Slave204also includes a IEEE 1588 protocol module242. Each of the modules242-248can be implemented in software, firmware, hardware or a combination thereof.

IEEE 1588 protocol module242operates to provide the generation and processing of messages, and maintaining of state related to PTP at slave204. IEEE 1588 protocol module242may include functions, such as timestamping and/or classification, implemented in the hardware in the physical interface and other functions implemented in software. IEEE 1588 module242operates to maintain synchronization of slave clock240with a master clock, such as master clock210.

Network (layer 3) and higher layers244includes operations to process internet protocol (IP) and higher layer (e.g. transport layer), and routing and forwarding. MAC246includes operations to process layer 2 packet headers and protocols. Physical layer248includes operations to process layer 1 protocol aspects and receipt/transmission of packets from/to the network media. Physical layer248may be implemented in a PHY, such as that described below in relation toFIG. 4. Protocol modules242-248operate in combination to provide slave204with operations described in relations to slave104and104′ illustrated inFIGS. 1A and 1B.

Intermediate node206includes a network protocol stack including a physical layer228and238, a media access control (MAC) layer226and236, and network layer and above224and234. Intermediate node206includes a switch220that operates to route/switch incoming packets to an outgoing interface. For example, packets from master202to slave204are received on a first physical interface and switched using switch220to a second physical interface through which the packet is transmitted to slave204. Intermediate node206also includes a IEEE 1588 protocol module222. Each of the modules220-228and234-238can be implemented in software, firmware, hardware or a combination thereof.

IEEE 1588 protocol module222operates to provide the determination of residence time of PTP packets and update of timestamps at intermediate node206. IEEE 1588 protocol module222may include functions, such as timestamping and/or classification, implemented in the hardware in the physical layer (e.g. PHY) and other functions implemented in software. Note that where intermediate node206can be a master and/or slave, in addition to the above operations of module222, operations described with respect to modules212and242such as, for example, generation and processing of messages, and maintaining of state related to PTP, can be provided by module222.

Network (layer 3) and higher layers224and234includes operations to process internet protocol (IP) and higher layer (e.g. transport layer), and routing and forwarding. MAC226and236includes operations to process layer 2 packet headers and protocols. Physical layer228and238includes operations to process layer 1 protocol aspects and receipt/transmission of packets from/to the network media. Physical layer228and238may be implemented in a PHY, such as that described below in relation toFIG. 4. Protocol modules222-226and234-236operate in combination to provide intermediate node206with operations described in relations to intermediate node106and106′ illustrated inFIGS. 1A and 1B.

FIG. 3Aillustrates a format for a Precision Time Protocol (PTP) packet300described in IEEE 1588, in accordance with an embodiment. Packet300illustrates a sequence of headers of the different protocol layers that are attached to the payload of PTP data312. PTP is located above the transport layer (e.g. user datagram protocol (UDP)) of the Open Systems Interconnect (OSI) protocol stack. PTP data312includes a message format for each type of PTP message such as, but not limited to, SYNC, SYNC_FOLLOWUP, DELAY_REQ and DELAY_RSP.

PTP data312, for any type of PTP message, is preceded by a PTP common header316. The format of the common header is described in relation toFIG. 3B. The PTP data312and common header316forms a PTP protocol data unit (PDU)308. The PTP PDU308may be processed by the respective PTP protocol processing modules (e.g.212,222, and242described above) in master, slave and/or intermediate node network entities participating in the IEEE 1588 synchronization.

PTP PDU308is preceded by a transport protocol header306. The transport protocol header indicates port level information for protocol processing of packets. In IEEE 1588 the transport protocol header306may include a user datagram protocol (UDP) header.

The transport protocol header306, is preceded by a network protocol header304and MAC layer header302. In the illustrated embodiment of an IEEE 1588 packet, network header304may be a IP header and MAC header may be an Ethernet header.

FIG. 3Billustrates format of a common header316of a PTP packet, in accordance with an embodiment. Common header316, for example, is attached to each PTP message in accordance with IEEE 1588.

Common header316includes three reserved fields: reserved(0)322, reserved(1)324and reserved(2)326. The use of the reserved fields are not defined in IEEE 1588.

Common header316also includes a messageType328and controlField330. MessageType328indicates the type of PTP message, and controlField330indicates a particular operation.

The common header316also includes the fields domainNumber332, sourcePortIdentity334and sequenceIdentifier336. DomainNumber332identifies a unique synchronization domain. SourcePortIdentity334uniquely identifies a source port. SequenceIdentifier336identifies the cycle of synchronization message exchange.

In addition, a correctionField340is also included in the common header316. The correction field340includes the residence times determined by the intermediate nodes.

FIG. 4illustrates a system400for time synchronization of network entities, in accordance with an embodiment. System400illustrates a line card402in a network entity participating in IEEE 1588 timing synchronization.

Line card402is coupled to an internal switch (not shown) via at least one communications bus404. The internal switch and bus404interconnects line card402to other line cards and processing devices of a networking device.

Line card402is configured to be connected to a network medium406, such as, but not limited to, an Ethernet network. Network medium406interconnects line card402to other network entities408, such as, for example, entities that perform as masters, slaves, and/or intermediate nodes in a IEEE 1588 synchronization network.

Line card402includes a network physical layer implementation (referred to as PHY)410, a processor412, a local memory414, a MAC protocol module416, a network and higher layer protocol module418, a IEEE 1588 protocol module420, and a communications infrastructure (e.g. bus) interconnecting410-420.

Processor412may include any processor that operates to execute sequences of instructions. Processor412may include, for example, a central processing unit (CPU), field programmable gate array (FPGA), application specific integrated circuit (ASIC), or digital signal processor (DSP).

Memory414includes a volatile storage memory local to line card402. Memory414may include a dynamic random access memory (DRAM), static random access memory (SRAM), flash memory, or other type of memory. Memory414may be utilized by processor412to store instructions for execution, configurations, and intermediate results of computations.

MAC protocol module416can be implemented in hardware, software, or as a combination thereof. MAC protocol module416operates to provide the media access control processing for transmitting and receiving packets from network medium406.

Network and higher layer protocol module418too can be implemented in hardware, software, or as a combination thereof. Network and higher layer protocol module418operates to provide the network and higher protocol layer processing for transmitting and receiving packets from network medium406. For example, generation and reading of packet headers for network layer and above, and routing, are example operations that may be performed by, or assisted in, network and higher layer protocols module418.

IEEE 1588 protocol module420provides for operations required in accordance with the IEEE 1588 protocol. IEEE 1588 protocol module420includes a PTP packet generation and decoding module424and a timing synchronization module426. PTP packet generation and decoding module424provides for generating packets for defined IEEE 1588 events (e.g. SYNC, DELAY_REQ and DELAY_RSP), and for decoding the IEEE 1588 packets that are received. Timing synchronization module426provides for determining and initiating the adjustment that is to be made to a local clock based upon the timestamps collected based upon the IEEE 1588 synchronization message exchange.

PHY410includes a physical interface432, a clock434, a timestamp generator436, and a IEEE 1588 timestamp insert and packet detection module438. PHY410also includes a timestamp memory442. Access to timestamp memory442may be controlled by timestamp memory controller444. According to an embodiment, PHY410is a chip. According to another embodiment, PHY410may be integrated, for example, with at least some MAC layer operations.

Physical interface432operates to transmit packet to, and receive packets from, the network medium406. According to an embodiment, physical interface432provides one or more Ethernet interfaces (e.g. Gigabit Ethernet or other Ethernet variant) and may include interfaces that use optical and/or electrical signaling to send and receive data. Physical interface432is typically at the edge of the PHY410, just before packets exit PHY410on to the network medium.

Clock434is a local clock which provides a timing signal for operations in PHY410. Clock434may be based upon a physical or logical clock. According to one embodiment, clock434is derived from a oscillator local to PHY410or network entity (not shown) that includes PHY410. According to another embodiment, clock434is based upon a logical clock recovered from data stream.

Timestamp generator436, upon being triggered by selected events such as, for example, the receipt of a PTP message or the transmitting of a PTP message, operates to determine a timestamp. Timestamp generator436captures the current time from clock434. Based upon the type of message for which the timestamp is captured, timestamp generator436may either store the timestamp in a memory for later use or may record (e.g. write) the timestamp in the packet.

IEEE 1588 timestamp insert and packet detection module438operates to detect the type of the incoming or outgoing message and to insert (e.g. record or write) the timestamp in the incoming or outgoing packet.

Timestamp memory controller444operates to control access to timestamp memory442. According to an embodiment, timestamp memory controller444can be configured to access timestamp entries based upon a combination of fields from the PTP common header320(e.g. domain number and sequence ID). Timestamp memory442is configured to store timestamps captured by timestamp generator436for ingress and egress packets. Other information from the packets that can be used to correlate packets of a message exchange (e.g. domain number and sequence ID from the common header320) may also be stored in association with the timestamps. According to an embodiment, timestamp memory442is configured as a first-in-first-out (FIFO) buffer.

Timestamp memory controller444may also include logic to handle receiving out of order accesses to the information stored in timestamp memory442. For example, upon receiving a request to access a timestamp having a later sequence ID than the lowest sequence ID in timestamp memory442, memory controller444may invalidate all entries that are associated with sequence IDs that are lower than the requested later sequence ID.

Communication between PHY410and MAC416occurs over a host interface440. Data (e.g. packets) as well as control can be communicated over host interface440. Host interface440may also be referred to as MII and/or MDIO interface.

FIG. 5illustrates a method500for synchronizing timing at a network node based upon a message exchange with another network node, in accordance with an embodiment. In embodiments, method500may be performed with steps502-518in the order shown, or in another order. In some embodiments, one or more of steps502-518may not be performed. According to an embodiment, method500may be performed by a slave node during synchronizing itself to a master node in accordance with the IEEE 1588 protocol. For example, method500may be performed by a slave node, such as slave204shown inFIG. 2, during a message exchange, such as the message exchanges100or101for timing synchronization, with a master node202. Using method500, slave204may obtain the T3 timestamp inband with exchanged IEEE 1588 messages, instead of having to access a local memory in the PHY over a relatively slow host interface.

Method500begins at operation502. At operation502, a timestamp corresponding to the time at which a packet is transmitted on to a network is determined. In order to ensure that the timestamp reflects the precise time at which the complete packet is transmitted on to the network, the timestamp is determined at or very close to the physical interface. For example, instead of capturing the timestamp when an outgoing packet is enqueued at the MAC layer, the timestamp is captured at the physical interface when the packet is actually transmitted from the physical interface. By obtaining the timestamp at or very close to the physical interface, any delays that occur between when a packet is enqueued for transmission (e.g. at the MAC layer) and the actual transmission are eliminated or substantially reduced.

In the example embodiment using IEEE 1588, a slave node transmits a DELAY_REQ packet to a master node. A timestamp T3, which corresponds to the time at which the DELAY_REQ is transmitted on to the network, is determined by the slave node. If the network is an Ethernet, for example, there may be some delay between the time that the DELAY_REQ is enqueued for transmission at the MAC layer and its actual transmission. As the message exchange is directed to measuring the propagation delay between the slave and master nodes at a high accuracy level (e.g. in submicroseconds or nanoseconds), any inaccuracies in timestamps due to such delays can be significant. By determining the timestamp at or very close to the physical interface, timestamp inaccuracy due to such delays are minimized.

The determination of the timestamp may be performed by a timestamping module (e.g. timestamp generator436) in the PHY hardware based upon a local clock. The timestamping module may be triggered to capture a timestamp upon the PHY detecting the transmission of a predetermined type of message. For example, the timestamping module may be triggered each time the transmission of the IEEE 1588 packet from the PHY is detected.

At operation504, the determined timestamp is stored in a memory (e.g. timestamp memory442) associated with the physical interface through which the packet was transmitted. According to an embodiment, the timestamp is stored in a FIFO memory located on a PHY which includes the physical interface. The timestamp can be stored in a FIFO in a manner that the entry can be accessed based upon field values of the packet for which the timestamp was determined. Other organizations of the memory associated with the physical interface are possible, for example, the memory may include a content addressable memory (CAM) to store the identifier associated with each timestamp.

In the example embodiment using IEEE 1588, the T3 timestamp is stored in a FIFO memory such that it is indexed based upon one or more fields of the header of the packet for which the timestamp was determined. For example, the stored entry may include, in addition to the timestamp, the domain number and sequence ID from the common header of the PTP packet for which the timestamp was determined. In some embodiments, in addition to the domain number and sequence ID, the source port ID from the common header is also stored along with the timestamp.

At operation506, a second packet is received at the physical interface, where the second packet is responsive to the first packet transmitted at operation502. In accordance with the example embodiment using IEEE 1588, the second packet may be the DELAY_RSP sent by the master node in response to receiving the DELAY_REQ from the slave node.

At operation508, the timestamp that was stored at operation506is retrieved. The timestamp is retrieved based upon information from the received second packet. In the example embodiment using IEEE 1588, the domain number, sequence ID and source port ID from the common header of the DELAY_RSP may be used to retrieve the stored timestamp from the memory. In accordance with IEEE 1588, in PTP packets belonging to one synchronization cycle (e.g. corresponding SYNC, SYNC_FOLLOWUP, DELAY_REQ and DELAY_RSP) use the domain number, sequence ID and source port ID in their headers.

At operation510, the received second packet is updated with the retrieved timestamp information. Updating the received second packet may be performed by writing the timestamp in the second packet. In the example embodiment using IEEE 1588, the retrieved timestamp (T3) is written in a reserved field of the common header of the DELAY_RSP message. The updating of the header can also include updating one or more checksum (e.g. cyclic redundancy check) values includes in the header and/or packet.

At operation512, the received second packet updated with the timestamp information is provided to a protocol processing module. For example, the updated second packet is input to a ingress packet buffer from which it is subsequently retrieved for processing by one or more protocol modules. The protocol modules may include processing for UDP/IP packets. The protocol modules may also include processing for higher layer protocols, such as, but not limited to IEEE 1588.

A higher layer protocol entity, such as PTP 1588 module420, can selectively control whether T3 is captured and held in a local memory of the PHY until the corresponding response is received. For example, when the DELAY_REQ is generated by module420, a reserved field in the common header (e.g. reserved(1) shown inFIG. 3B) can be configured to indicate that T3 should be captured and held in a local memory of the PHY until the corresponding response is received. Alternatively, the reserved(1) field can be interpreted by the PHY such that the PHY stores the captured T3 in a local memory and informs the processor, which then causes the MAC or higher layer protocols to read the local memory of the PHY to obtain T3. The MAC or higher layer protocols then hold T3 until the corresponding T4 is received in order to perform the synchronization. However, the read of the local memory of the PHY by the processor (e.g., MAC or higher layer protocols) occurs over the host interface (e.g.440) which may cause delays and also place an unnecessary burden on the processor.

In embodiments of the present invention, the need for host interface access by the processor to obtain T3 (or other timestamp) is eliminated by holding T3 in local memory of the PHY until the corresponding response is received, and then recording T3 in the header of that response.

At operation514, the protocol processing module obtains the first timestamp and a second timestamp from the received second packet. In the example embodiment using IEEE 1588, a protocol module extracts the T3 timestamp and a T4 timestamp from the DELAY_RSP packet. The T3 and T4 timestamps represent the egress and ingress times, respectively, of the corresponding DELAY_REQ packet. The T4 timestamp is captured by the master node upon ingress of the DELAY_REQ, and recorded in the DELAY_RSP before transmitting the DELAY_RSP to the slave node. According to an embodiment, T3 is extracted from the common header and T4 is obtained from the DELAY_RSP body.

At operation516, a correction for a clock is determined based at least upon the obtained first and second timestamps. In the example embodiment using IEEE 1588, a correction is determined for the local clock at the slave node. The correction is based upon the T3 and T4 timestamps, and may further be based upon a T1 and a T2 timestamp acquired earlier.

At operation518, the clock is adjusted based upon the determined adjustment.

FIG. 6illustrates a method600for a master clock to transmit egress timestamp, in accordance with an embodiment. In embodiments, method600may be performed with steps602-612in the order shown, or in another order. In some embodiments, one or more of steps602-612may not be performed. According to an embodiment, method600may be performed by a master node during synchronizing by a slave node in accordance with the IEEE 1588 protocol. For example, method600may be performed by a master node, such as master202shown inFIG. 2, during a message exchange, such as the message exchanges100or101for timing synchronization, with a slave node204. Using method600, master202may obtain the T1 timestamp for transmission with the SYNC_FOLLOWUP message without having to access a local memory in the PHY over a relatively slow host interface.

Method600begins with operation602. At operation602, a timestamp is determined. The timestamp corresponds to the time that a packet is transmitted on to a network. In order to ensure that the timestamp precisely reflects the time at which the complete packet is transmitted on to the network, the timestamp is captured at or very close to the physical interface.

At operation604, the determined timestamp is stored in a memory associated with the physical interface through which the packet was transmitted. According to an embodiment, the timestamp is stored in a FIFO memory. The timestamp can be stored in a FIFO in a manner that the entry can be accessed based upon field values of the packet for which the timestamp was determined.

In an example embodiment using IEEE 1588, the T1 timestamp is stored in a FIFO memory upon a SYNC packet being transmitted by the master such that the stored timestamp is indexed based upon one or more fields of the header of the packet for which the timestamp was determined. For example, the stored entry may include, in addition to the timestamp, the domain number and sequence identifier from the common header of the PTP packet for which the timestamp was determined. In some embodiments, in addition to the domain number and sequence identifier, the source port identifier from the common header is also stored along with the timestamp.

At operation606, a second packet is received at the physical interface to be transmitted out of the physical interface. In accordance with the example embodiment using IEEE 1588, the second packet may be the SYNC_FOLLOWUP sent by the master node immediately following the SYNC.

At operation608, the timestamp stored at operation604is retrieved. The timestamp is retrieved based upon information from the received second packet (e.g. SYNC_FOLLOWUP). In the example embodiment using IEEE 1588, the domain number, sequence identifier and source port identifier from the common header of the SYNC_FOLLOWUP may be used to retrieve the stored timestamp from the memory.

At operation610, the second packet is updated to include the retrieved timestamp. In the example embodiment using IEEE 1588, the SYNC_FOLLOWUP packet is updated by writing the T1 timestamp in the PTP data.

At operation612, the updated second packet is transmitted out of the physical interface.

The representative functions of the communications device described herein may be implemented in hardware, software, or some combination thereof. For instance, processes500and600can be implemented using computer processors, computer logic, ASIC, FPGA, DSP, etc., as will be understood by those skilled in the arts based on the discussion given herein. Accordingly, any processor that performs the processing functions described herein is within the scope and spirit of the present invention.

The breadth and scope of the present invention should not be limited by any of the above-described example embodiments, but should be defined only in accordance with the following claims and their equivalents.