Time synchronization based on lookup table

Abstract

This application relates to lookup table based time synchronization. Systems and methods are described herein for implementing a lookup table by a network node and performing or supporting time synchronization based on the lookup table. In one aspect, a network node can receive a packet. The network node can identify a few bits in the packet and determine one or more actions or functions corresponding to the few bits via the lookup table. In addition, the network node can execute / perform the determined one or more actions to support time synchronization.

Description

Technical Field

[0001] This disclosure generally relates to systems and methods for synchronization between network nodes. Background Technology

[0002] Timing and frequency synchronization among communicating network nodes is a critical issue in network performance. The accuracy of synchronization between network nodes affects the performance of systems attached to the network and also impacts the overall network performance. The IEEE 1588 protocol, known as the Precision Time Protocol (PTP), is a technique used to provide robust and cost-effective time synchronization for distributed systems. IEEE 1588 is designed for a significantly higher level of accuracy (e.g., approximately sub-microseconds) than other network synchronization protocols such as the Network Time Protocol (NTP).

[0003] IEEE 1588 is based on packet switching between network nodes, such as masters and slaves (also referred to as master nodes and slave nodes, respectively). Each slave can synchronize its clock (“slave clock” or SC) to the master's clock. To enhance fault tolerance, an election process determines which of several masters provides an accurate clock to the slaves at any given time. The master selected to provide an accurate clock is called the grandmaster (GM).

[0004] To synchronize time, participating network nodes can generate or obtain accurate timestamps for selected packets entering and / or leaving the network, and exchange these timestamps among different network nodes. In one instance, the time difference between a packet being transmitted from the first node and that packet being received at the second node can be determined based on the timestamps. Based on this time difference, slave nodes can adjust their clocks to synchronize with the master's clock. Summary of the Invention

[0005] On one hand, this application relates to a method comprising: determining a role of the device by a processor of the device; determining a table by the processor containing a list of one or more actions associated with the determined role of the device; receiving a packet for communication by a communication interface of the device; determining, by the communication interface, an action corresponding to a portion of the packet from the one or more actions associated with the determined role of the device in the table; and performing the action for communication by the communication interface.

[0006] On the other hand, this application relates to an apparatus comprising: a processor configured to: determine a role of the apparatus and determine a table containing a list of one or more actions associated with the determined role of the apparatus; and a communication interface configured to: receive packets for communication, determine an action corresponding to a portion of the packets from the one or more actions associated with the determined role of the apparatus in the table, and perform the action for communication.

[0007] On the other hand, this application relates to a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to: determine a role of a device; determine a table containing a list of one or more actions associated with the determined role of the device; cause a communication interface to receive a packet for communication; cause the communication interface to determine an action corresponding to a portion of the packet from the one or more actions associated with the determined role of the device in the table; and cause the communication interface to perform the action for communication. Attached Figure Description

[0008] The various objectives, aspects, features, and advantages of this disclosure will become more apparent and better understood through a detailed description taken in conjunction with the accompanying drawings, in which similar reference numerals identify corresponding elements. In the drawings, similar reference numerals generally indicate identical, functionally similar, and / or structurally similar elements.

[0009] Figure 1A It is a block diagram depicting a network environment comprising one or more access points communicating with one or more devices or stations, according to some embodiments.

[0010] Figure 1B and 1C This is a block diagram depicting a computing device used in conjunction with the methods and systems described herein, according to some embodiments.

[0011] Figure 2 A system for synchronizing time between network nodes is shown according to an embodiment.

[0012] Figure 3A The format of a Precision Time Protocol (PTP) packet as described in IEEE 1588 according to an embodiment is shown.

[0013] Figure 3B The format of the common header of a PTP packet according to an embodiment is shown.

[0014] Figure 4 A block diagram of a network device that performs synchronization based on a lookup table according to an embodiment is shown.

[0015] Figure 5A flowchart illustrating the process of a network device performing synchronization based on a lookup table according to an embodiment is shown.

[0016] Figure 6 An interactive diagram is shown illustrating the process of performing a two-step peer-to-peer link delay measurement based on a lookup table according to an embodiment.

[0017] Figure 7 An interactive diagram is shown illustrating the process of performing a one-step peer-to-peer link delay measurement based on a lookup table according to an embodiment.

[0018] Details of various embodiments of the method and system are set forth in the accompanying drawings and the following description. Detailed Implementation

[0019] The following IEEE standard, including any draft versions of such standard, is incorporated herein by reference in its entirety and forms part of this disclosure for all purposes: IEEE 1588. Although aspects of these standards may be referenced in this disclosure, this disclosure is in no way limited by these standards.

[0020] For the purpose of reading the descriptions of the various embodiments below, the following descriptions of the specification and its corresponding sections may be helpful:

[0021] Section A describes network and computing environments that may be useful for practicing the embodiments described herein; and

[0022] Chapter B describes an implementation of synchronization based on lookup tables.

[0023] A. Computing and Network Environment

[0024] Before discussing specific embodiments of this solution, it may be helpful to describe the operating environment and associated system components (e.g., hardware elements) in conjunction with the methods and systems described herein. References Figure 1A This describes an embodiment of a network environment. In a brief overview, the network environment includes a wireless communication system comprising one or more access points (APs) 106, one or more wireless communication devices 102, and network hardware components 192. The wireless communication devices 102 may, for example, include laptop computers 102, tablet computers 102, personal computers 102, and / or cellular phone devices 102. Details of embodiments of each wireless communication device 102 and / or AP 106 are provided below. Figure 1B and 1CThis will be described in more detail. In one embodiment, the network environment may be an ad hoc network environment, an infrastructure wireless network environment, a subnet environment, etc. AP 106 may be operatively coupled to network hardware 192 via a local area network (LAN) connection. Network hardware 192, which may include routers, gateways, switches, bridges, modems, system controllers, devices, etc., provides LAN connectivity for the communication system. Each of APs 106 may have an associated antenna or antenna array to communicate with wireless communication devices in its area. Wireless communication devices 102 may register with a specific AP 106 to receive services from the communication system (e.g., via SU-MIMO or MU-MIMO configuration). For direct connections (e.g., point-to-point communication), some wireless communication devices may communicate directly via allocated channels and communication protocols. Some wireless communication devices 102 may be mobile or relatively stationary relative to AP 106.

[0025] In some embodiments, AP 106 includes means or modules (comprising a combination of hardware and software) that allow wireless communication device 102 to connect to a wired network using Wi-Fi or other standards. AP 106 may sometimes be referred to as a wireless access point (WAP). AP 106 may be implemented (e.g., configured, designed, and / or built) for operation in a wireless local area network (WLAN). In some embodiments, AP 106 may be connected as a standalone device to a router (e.g., via a wired network). In other embodiments, AP 106 may be a component of a router. AP 106 may provide network access to multiple devices. AP 106 may, for example, connect to a wired Ethernet connection and use a radio frequency link to provide wireless connectivity for other devices 102 to utilize the wired connection. AP 106 may be implemented to support standards for transmitting and receiving data using one or more radio frequencies. Those standards and the frequencies they use may be defined by IEEE (e.g., the IEEE 802.11 standard). AP 106 may be configured and / or used to support public Internet hotspots and / or to extend the Wi-Fi signal range of a network.

[0026] In some embodiments, access point 106 may be used (e.g., in a home or building) for wireless networks (e.g., IEEE 802.11, Bluetooth, ZigBee, any other type of radio frequency-based network protocol and / or variations thereof). Each of the wireless communication devices 102 may include a built-in radio and / or be coupled to a radio. Such wireless communication devices 102 and / or access points 106 may operate in accordance with various aspects of this disclosure presented herein to enhance performance, reduce cost and / or size, and / or enhance broadband applications. Each wireless communication device 102 may have the capability to act as a client node attempting to access resources (e.g., data, and connections to networked nodes such as servers) via one or more access points 106.

[0027] The network connection may include any type and / or form of network and may include any of the following: point-to-point network, broadcast network, telecommunications network, data communication network, and computer network. The network topology may be bus, star, or ring topology. The network may be any such network topology known to those skilled in the art capable of supporting the operations described herein. In some embodiments, different types of data may be transmitted via different protocols. In other embodiments, the same type of data may be transmitted via different protocols.

[0028] The communication device 102 and access point 106 can be deployed as and / or performed on any type and form of computing device, such as a computer, network device or equipment capable of communicating and performing the operations described herein on any type and form of network. Figure 1B and 1C A block diagram depicting a computing device 100 that can be used to implement embodiments of wireless communication device 102 or AP 106. (See diagram for reference.) Figure 1B and 1C As shown, each computing device 100 includes a central processing unit 121 and a main memory unit 122. For example... Figure 1B As shown, computing device 100 may include storage device 128, mounting device 116, network interface 118, I / O controller 123, display devices 124a to 124n, keyboard 126, and pointing device 127, such as a mouse. Storage device 128 may include operating system and / or software. Figure 1C As shown, each computing device 100 may also include additional optional components, such as memory port 103, bridge 170, one or more input / output devices 130a to 130n, and cache memory 140 communicating with central processing unit 121.

[0029] Central processing unit 121 is any logic circuit system that responds to and processes instructions fetched from main memory unit 122. In many embodiments, central processing unit 121 is provided by, for example, a microprocessor unit manufactured by Intel Corporation of Santa Clara, California; a microprocessor unit manufactured by International Business Machines of White Plains, New York; or a microprocessor unit manufactured by Advanced Micro Devices of Sunnyvale, California. Computing device 100 may be based on any of these processors or any other processor capable of operating as described herein.

[0030] Main memory cell 122 may be one or more memory chips capable of storing data and allowing direct access from any storage location by microprocessor 121, such as any type or variant of static random access memory (SRAM), dynamic random access memory (DRAM), ferroelectric RAM (FRAM), NAND flash memory, NOR flash memory, and solid-state drive (SSD). Main memory 122 may be based on any of the memory chips described above or any other available memory chips capable of operating as described herein. Figure 1B In the embodiment shown, the processor 121 communicates with the main memory 122 via the system bus 150 (described in more detail below). Figure 1C An embodiment of computing device 100 is depicted, wherein the processor communicates directly with main memory 122 via memory port 103. For example, in Figure 1C In this context, the main memory 122 can be DRDRAM.

[0031] Figure 1C An embodiment is depicted in which the main processor 121 communicates directly with the cache memory 140 via a secondary bus, sometimes referred to as the back-side bus. In other embodiments, the main processor 121 communicates with the cache memory 140 using a system bus 150. The cache memory 140 typically has a faster response time than the main memory 122 and is provided by, for example, SRAM, BSRAM, or EDRAM. Figure 1CIn the illustrated embodiment, processor 121 communicates with various I / O devices 130 via a local system bus 150. Various buses can be used to connect central processing unit 121 to any of the I / O devices 130, such as VESA VL bus, ISA bus, EISA bus, Microchannel Architecture (MCA) bus, PCI bus, PCI-X bus, PCI-Express bus, or NuBus. For an embodiment where the I / O device is a video display 124, processor 121 may use an Advanced Graphics Port (AGP) to communicate with display 124. Figure 1C An embodiment of computer 100 is depicted, wherein the main processor 121 can communicate directly with I / O device 130b, for example, via HYPERTRANSPORT, RAPIDIO, or INFINIBAND communication technologies. Figure 1C An embodiment in which local bus and direct communication are mixed is also depicted: processor 121 communicates with I / O device 130a using local interconnect bus, while simultaneously communicating directly with I / O device 130b.

[0032] A variety of I / O devices 130a to 130n may exist in the computing device 100. Input devices include a keyboard, mouse, trackpad, trackball, microphone, dial pad, touchpad, touch screen, and drawing tablet. Output devices include a video display, speakers, inkjet printer, laser printer, projector, and dye-to-sublimation printer. The I / O devices can be... Figure 1B The I / O controller 123 shown controls the device. The I / O controller can control one or more I / O devices, such as a keyboard 126 and a pointing device 127 (e.g., a mouse or optical pen). Additionally, the I / O devices can provide storage devices and / or mounting media 116 for the computing device 100. In yet another embodiment, the computing device 100 can provide a USB connection (not shown) to receive a handheld USB storage device, such as a USB flash drive series device manufactured by Twintech Industry, Inc., Los Alamitos, California.

[0033] Refer again Figure 1BThe computing device 100 may support any suitable installation device 116, such as a disk drive, CD-ROM drive, CD-R / RW drive, DVD-ROM drive, flash memory drive, tape drive of various formats, USB device, hard disk drive, network interface, or any other device suitable for installing software and programs. The computing device 100 may further include storage devices for storing the operating system and other related software, and for storing application software programs (e.g., any program or software 120 for implementing (e.g., configured and / or designed for) the systems and methods described herein), such as one or more hard disk drives or redundant arrays of independent disks. Optionally, any of the installation devices 116 may also be used as storage devices. Furthermore, the operating system and software may run from bootable media.

[0034] In addition, computing device 100 may include network interface 118 to interface with network 104 via various connections, including but not limited to standard telephone lines, LAN or WAN links (e.g., 802.11, T1, T3, 56kb, X.25, SNA, DECNET), broadband connections (e.g., ISDN, Frame Relay, ATM, Gigabit Ethernet, Ethernet-over-SONET), wireless connections, or a combination of any or all of the above connections. A connection can be established using various communication protocols, such as TCP / IP, IPX, SPX, NetBIOS, Ethernet, ARCNET, SONET, SDH, Fiber Distributed Data Interface (FDDI), RS232, IEEE 802.11, IEEE 802.11a, IEEE 802.11b, IEEE 802.11g, IEEE 802.11n, IEEE 802.11ac, IEEE 802.11ad, CDMA, GSM, WiMax, and Direct Asynchronous Connection. In one embodiment, computing device 100 communicates with other computing devices 100' via any type and / or form of gateway or tunneling protocol (e.g., Secure Sockets Layer (SSL) or Transport Layer Security (TLS)). Network interface 118 may include a built-in network adapter, network interface card, PCMCIA network card, card bus network adapter, wireless network adapter, USB network adapter, modem, or any other device suitable for interfacing computing device 100 to any type of network capable of communicating and performing the operations described herein.

[0035] In some embodiments, computing device 100 may include or be connected to one or more display devices 124a to 124n. Therefore, any of the I / O devices 130a to 130n and / or the I / O controller 123 may include any type and / or form of suitable hardware, software, or a combination of hardware and software to support, enable, or provide connectivity and use of the display devices 124a to 124n by computing device 100. For example, computing device 100 may include any type and / or form of video adapter, video card, driver, and / or library to interface with, communicate with, connect to, or otherwise use the display devices 124a to 124n. In one embodiment, a video adapter may include multiple connectors to interface with the display devices 124a to 124n. In other embodiments, computing device 100 may include multiple video adapters, each connected to the display devices 124a to 124n. In some embodiments, any portion of the operating system of computing device 100 may be configured to use multiple displays 124a to 124n. In another embodiment, I / O device 130 may be a bridge between system bus 150 and external communication buses (such as USB bus, Apple Desktop bus, RS-232 serial connection, SCSI bus, FireWire bus, FireWire 800 bus, Ethernet bus, AppleTalk bus, Gigabit Ethernet bus, Asynchronous Transfer Mode bus, Fibre Channel bus, Serial Attached Small Computer System Interface bus, USB connection, or HDMI bus).

[0036] Figure 1B and 1CThe computing device 100 of the type described herein can operate under the control of an operating system that controls task scheduling and access to system resources. The computing device 100 can run any operating system, such as any version of Microsoft Windows, different versions of Unix and Linux, any version of MAC OS for Macintosh computers, any embedded operating system, any real-time operating system, any open-source operating system, any proprietary operating system, any operating system for mobile computing devices, or any other operating system capable of running on a computing device and performing the operations described herein. Typical operating systems include, but are not limited to: Android, produced by Google Inc.; Windows 7 and 8, produced by Microsoft Corporation of Redmond, Washington; MAC OS, produced by Apple Computer of Cupertino, California; WebOS, produced by Research In Motion (RIM); OS / 2, produced by International Business Machines of Armonk, New York; and Linux, a free operating system released by Caldera of Salt Lake City, Utah, or any type and / or form of Unix operating system.

[0037] Computer system 100 may be any workstation, telephone, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone or other portable telecommunications device, media playback device, gaming system, mobile computing device, or any other type and / or form of computing, telecommunications, or media device capable of communication. In some embodiments, computing device 100 may have a different processor, operating system, and input device consistent with said device. For example, in one embodiment, computing device 100 is a smartphone, mobile device, tablet computer, or personal digital assistant. Furthermore, computing device 100 may be any workstation, desktop computer, laptop or notebook computer, server, handheld computer, mobile phone, any other computer, or other form of computing or telecommunications device capable of communication and having sufficient processor power and memory capacity to perform the operations described herein.

[0038] The aspects of the operating environment and components described above will become apparent in the context of the systems and methods disclosed herein.

[0039] B. Synchronization based on lookup table

[0040] This document describes systems and methods for implementing lookup tables by network nodes and performing or supporting time synchronization based on said lookup tables. In one aspect, the network node may receive packets. The network node may identify several bits in the packets and determine one or more actions or functions corresponding to said bits via a lookup table. Additionally, the network node may execute / perform the determined one or more actions to support time synchronization.

[0041] Advantageously, the lookup tables disclosed herein allow various actions to be performed based on the PTP message type or to support time synchronization between different nodes. For example, IEEE 1588 2.0 allows the exchange of 0 to 1 in a reserved field containing 12 bits to provide instructions or commands to perform various actions, but IEEE 1588 2.1 no longer allows the exchange of 0 to 1 in a reserved field to provide such instructions or commands. In one aspect, one or more actions supported in IEEE 1588 2.0 can be performed while conforming to IEEE 1588 2.1 using an on-chip lookup table. Furthermore, actions different from those supported in IEEE 1588 2.0 or more effective actions than those supported in IEEE 1588 2.0 can be performed.

[0042] Figure 2 A system 200 for synchronizing time between network nodes is illustrated according to an embodiment. In some embodiments, the system 200 includes a master controller 202, a slave controller 204, and an intermediate node (e.g., a network switch) 206 interconnecting the master controller 202 and the slave controller 204. Each of the master controller 202, the slave controller 204, and the intermediate node 206 may be a device 102, an access point 106, network hardware 192, or any communication device.

[0043] The master controller 202 provides a clock to which the slave controller 204 is synchronized and, in some embodiments, provides a clock to which the intermediate node 206 is synchronized. The master clock 210 may be based on a Global Positioning System (GPS) clock or other accurate clock. The master controller 202 may include, for example, a GPS receiver (not shown) and a GPS clock adjustment circuitry (not shown), which the master controller 202 may use to keep the master clock 210 synchronized with a highly accurate external GPS clock. The master controller 202 may include one or more computers, such as server computers or a cluster of server computers. The master controller 202 is communicatively coupled to the slave controller 204 and one or more intermediate nodes 206 via a network 208. The network 208 may be a wired network (e.g., Ethernet) or a wireless network (e.g., Wi-Fi, cellular network, Bluetooth, etc.).

[0044] In some embodiments, the host controller 202 includes interfaces including a physical layer interface 218, a media access control (MAC) layer interface 216, and a network layer and above interface 214. In some embodiments, the host controller 202 also includes an IEEE 1588 protocol processor 212. Each of components 212, 214, 216, and 218 may be implemented in software, firmware, hardware, or a combination thereof.

[0045] In some embodiments, the IEEE 1588 protocol processor 212 operates to provide message generation and processing, and to maintain the state associated with the PTP at the host controller 202. The IEEE 1588 protocol processor 212 may include hardware functions (e.g., timestamping and / or classification) implemented in the physical interface and other functions implemented in software.

[0046] In some embodiments, the network and higher layer interface 214 is a component that handles Internet Protocol (IP) and higher layer (e.g., transport layer) communication, routing, and forwarding. The MAC layer interface 216 is a component that handles layer 2 packet headers and protocols. The physical layer interface 218 is a component that handles layer 1 protocol aspects and the reception / transmission of packets from / to the network media. The IEEE 1588 protocol processor 212, the network and higher layer interface 214, the MAC layer interface 216, and the physical layer interface 218 can be operated in combination to perform the operations described with respect to the master controller 202 described herein.

[0047] In some embodiments, slave controller 204 includes interfaces including a physical layer interface 248, a media access control (MAC) layer interface 246, and a network layer and higher layer interface 244. Slave controller 204 also includes an IEEE 1588 protocol processor 242. Each of components 242, 244, 246, and 248 may be implemented in software, firmware, hardware, or a combination thereof.

[0048] In some embodiments, the IEEE 1588 protocol processor 242 performs message generation and processing, and maintains the state associated with the PTP at the slave controller 204. The IEEE 1588 protocol processor 242 may include hardware functions implemented in the physical interface (e.g., timestamping and / or classification) and other functions implemented in software. The IEEE 1588 protocol processor 242 is operable to maintain synchronization between the slave clock 240 and the master clock (e.g., master clock 210).

[0049] In some embodiments, the network layer and higher layer interface 244 is a component that handles Internet Protocol (IP) and higher layers (e.g., the transport layer), routing, and forwarding. The MAC layer interface 246 is a component that handles layer 2 packet headers and protocols. The physical layer interface 248 is a component that handles layer 1 protocol aspects and the reception / transmission of packets from / to the network media. The IEEE 1588 protocol processor 242, the network and higher layer interface 244, the MAC layer interface 246, and the physical layer interface 248 can be operated in combination to perform the operations described with respect to the slave controller 204 described herein.

[0050] In some embodiments, intermediate node 206 includes interfaces including physical layer interfaces 228, 238, media access control (MAC) layer interfaces 226, 236, and network layer and higher layer interfaces 224, 234. In some embodiments, intermediate node 206 includes switch 220, which operates to route / switch incoming packets to outgoing interfaces. For example, packets from master 202 to slave 204 are received on first physical layer interface 228 and switched using switch 220 to second physical layer interface 238, and the packets are transmitted to slave 204 through second physical layer interface 238. In some embodiments, intermediate node 206 also includes IEEE 1588 protocol processor 222. Each of components 220, 222, 224, 226, 228, 234, 236, and 238 may be implemented in software, firmware, hardware, or a combination thereof.

[0051] In some embodiments, the IEEE 1588 protocol processor 222 is a component that determines the dwell time of PTP packets and updates the timestamp at intermediate node 206. The IEEE 1588 protocol processor 222 may include hardware functions (e.g., timestamping and / or classification) implemented in the physical layer (e.g., PHY) and other functions implemented in software. Note that if intermediate node 206 is a master and / or slave, the IEEE 1588 protocol processor 222 may also perform operations of the IEEE 1588 protocol processor 212 and / or the IEEE 1588 protocol processor 242 (e.g., message generation and processing, and maintenance of PTP-related states, etc.).

[0052] In some embodiments, network and higher layer interfaces 224, 234 include or perform operations to handle Internet Protocol (IP) and higher layers (e.g., transport layer), as well as routing and forwarding. In some embodiments, MAC layer interfaces 226, 236 include or perform operations to handle layer 2 packet headers and protocols. In some embodiments, physical layer interfaces 228, 238 include or perform operations to handle layer 1 protocol aspects and packet reception / transmission to / from the network media. The IEEE 1588 protocol processor 222, network and higher layer interfaces 224, 234, MAC layer interfaces 226, 236, physical layer interfaces 228, 238, and switch 220 may be combined to perform the operations described with respect to intermediate node 206 herein.

[0053] Figure 3A The format of a Precision Time Protocol (PTP) packet 300 conforming to the IEEE 1588 protocol is shown according to an embodiment. Packet 300 shows a sequence of headers for different protocol layers attached to the payload of PTP data 312. PTP may be located above the transport layer of an Open Systems Interconnection (OSI) protocol stack (e.g., User Datagram Protocol (UDP)). PTP data 312 may contain message formats for each type of PTP message, such as, but not limited to, SYNC, SYNC_FOLLOWUP, DELAY_REQ, and DELAY_RSP.

[0054] The PTP data 312 used for any type of PTP message is preceded by the PTP Common Header 316. The format of the Common Header 316 is as follows: Figure 3B As described. PTP data 312 and common header 316 can form PTP protocol data unit (PDU) 308. PTP PDU 308 can be processed by the master controller 202, slave controller 204, intermediate node 206 or appropriate PTP protocol processor (e.g., 212, 222 and 242 described above) in any network node participating in IEEE 1588 synchronization.

[0055] The PTP PDU 308 is preceded by the Transport Protocol Header 306. The Transport Protocol Header 306 indicates port-level information for protocol processing of the packet. In IEEE 1588, the Transport Protocol Header 306 may contain a User Datagram Protocol (UDP) header.

[0056] The transport protocol header 306 is preceded by the network protocol header 304 (also known as the "IP header 304") and the MAC layer header 302 (also known as the "Ethernet header 302").

[0057] Figure 3BThe format of the common header 316 of a PTP packet 300 according to an embodiment is shown. The common header 316 is, for example, attached to each PTP message according to IEEE 1588 2.1.

[0058] According to IEEE 1588 2.1, the common header 316 includes a messageType field 328 and a controlField 330. The messageType field 328 indicates the type of PTP message, and the controlField 330 indicates a specific operation. The common header 316 also includes a domainNumber field 332, a sourcePortIdentity field 334, and a sequenceIdentifier field 336. The domainNumber field 332 identifies a unique synchronization domain. The sourcePortIdentity 334 uniquely identifies the source port. The sequenceIdentifier 336 identifies the synchronization message exchange cycle. The common header 316 also includes a correctionField 340. The correction field 340 contains the dwell time determined by the intermediate nodes.

[0059] According to IEEE 1588 2.1, the common header 316 includes the minorVersionPTP field 322, the majorSdold field 320, the minorSdold field 324, and a reserved field 326. The minorVersionPTP field 322 may contain four bits to indicate the minor version number of the IEEE 1588PTP. The majorSdold field 320 may contain four of the most significant bits of the field identifier, while the minorSdold field 324 may contain eight of the least significant bits of the field identifier. The use of the reserved field 326 is not defined in IEEE 1588 2.1.

[0060] In one aspect, the fields corresponding to fields 322 and 324 in the common header 316 conforming to IEEE 1588 2.0 are also reserved fields. Therefore, according to IEEE 1588 2.0, various instructions or commands can be exchanged through those fields corresponding to fields 322 and 324. However, according to IEEE 1588 2.1, fields 322 and 324 are no longer reserved fields, and such instructions or commands conforming to IEEE 1588 2.0 may be provided without using fields 322 and 324.

[0061] Figure 4A block diagram is shown of a network device 400 that performs synchronization based on one or more lookup tables 480, 490 according to an embodiment. The network device 400 may be a master controller 202, an intermediate node 206, or a slave controller 204. In some embodiments, the network device 400 includes an ingress parser 430, an egress parser 440, a memory device 450, a controlled oscillator (NCO) 460, a processor 470, and one or more storage components storing tables 480, 490. These components may operate together to perform synchronization operations based on tables 480, 490. In some embodiments, the network device 400 includes a comparison... Figure 4 The more, fewer, or different components are displayed.

[0062] The entry resolver 430 is a communication interface (or network interface) component that receives entry packets 410 and processes or resolves the entry packets 410 to perform one or more actions based on the entry packets 410. In some embodiments, the entry resolver 430 includes a processing means (or processor) and a non-transitory computer-readable storage medium, wherein the processing means receives one or more instructions from the non-transitory computer-readable medium and executes the one or more instructions to perform the various functions of the entry resolver 430 described herein. The packet 410 may have as described regarding Figure 3A and 3B The format described. In one method, an entry parser 430 identifies one or more bits in a predetermined field (e.g., reserved field 326) of an entry packet 410 and applies the identified bits to a table 480 to determine a corresponding action. For example, the entry parser 430 may cause memory 450 to store a timestamp value or read a stored timestamp value. For example, the entry parser 430 may provide instructions or commands to be executed to processor 470. The entry parser 430 may generate an entry packet 420 and transmit the entry packet to another network device. The entry packet 420 may be the same as or modified from the entry packet 410.

[0063] Outgoing resolver 440 is a communication interface (or network interface) component that receives outgoing packets 425 and processes or resolves outgoing packets 425 to perform one or more actions based on outgoing packets 425. In some embodiments, outgoing resolver 440 includes processing means and non-transitory computer-readable medium, wherein the processing means receives one or more instructions from the non-transitory computer-readable medium and executes said one or more instructions to perform the various functions of outgoing resolver 440 described herein. Packet 425 may have as about Figure 3A and 3BThe format described. In one method, outgoing parser 440 identifies one or more bits in a predetermined field (e.g., reserved field 326) of outgoing packet 425 and applies the identified bits to table 490 to determine the corresponding action. For example, outgoing parser 440 may cause memory 450 to store a timestamp value or read a stored timestamp value. For example, outgoing parser 440 may provide instructions or commands to be executed to processor 470. Outgoing parser 440 may generate outgoing packet 415 and transmit outgoing packet 415 to another network device. Outgoing packet 415 may be the same as outgoing packet 425 or may be modified from outgoing packet 425.

[0064] Memory 450 is a storage component that stores one or more timestamp values ​​from incoming parser 430 and outgoing parser 440. Memory 450 can store the start of the timestamp value of incoming packet 410 upon request of an instruction or command to store the timestamp value from incoming parser 430. Memory 450 can also store the start of the timestamp value of outgoing packet 425 upon request of an instruction or command to store the timestamp value from outgoing parser 440. Memory 450 can also receive instructions or commands requesting timestamp values ​​from incoming parser 430, outgoing parser 440, or processor 470, and provide the requested timestamp values ​​in response to such instructions or commands.

[0065] NCO 460 is a controllable clock. In some embodiments, NCO 460 can output the clock's time value to the ingress parser 430, the egress parser 440, or the processor 470. In some embodiments, the clock can be adjusted upon request by instructions or commands to update the clock from the ingress parser 430, the egress parser 440, or the processor 470.

[0066] Processor 470 is a component that receives one or more instructions from a non-transitory computer-readable medium of device 400 and executes said one or more instructions to control the operation of ingress parser 430, egress parser 440, or other components of device 400. In some embodiments, processor 470 may execute one or more functions of ingress parser 430 or egress parser 440. In some embodiments, ingress parser 430 and / or egress parser 440 may execute one or more functions of processor 470, such that time synchronization can be performed immediately.

[0067] Table 480 is stored by a storage component of device 400. The storage component may be SRAM or any other storage component. Table 480 may contain a list of one or more actions that can be performed by entry parser 430. For example, entry parser 430 may apply one or more bits from a reserved field to table 480 to determine the corresponding action to be performed. In one aspect, table 480 may store a list of one or more actions for a specific role of network device 400 (e.g., master 202, intermediate node 206, or slave 204). Based on the assigned role, processor 470 may retrieve a subset of actions associated with the assigned role from a set of actions. Thus, table 480 may store several actions corresponding to several bits in the entry packet 410 for the role of device 400.

[0068] Table 490 is stored by a storage component of device 400. The storage component may be SRAM or any other storage component. Table 490 may contain a list of one or more actions that outgoing parser 440 can perform. For example, outgoing parser 440 may apply one or more bits from a reserved field to table 490 to determine the corresponding action to be performed. In one aspect, table 490 may store a list of one or more actions for a specific role of network device 400 (e.g., master 202, intermediate node 206, or slave 204). Based on the assigned role, processor 470 may retrieve a subset of actions associated with the assigned role from a set of actions. Thus, table 490 may store several actions corresponding to several bits in outgoing packet 425 for the role of device 400.

[0069] Figure 5 A flowchart illustrating a process 500 of a network device 400 performing synchronization based on a lookup table (e.g., table 480 or 490) according to an embodiment is shown. In some embodiments, process 500 may be executed by a processor 470, an ingress parser 430, an egress parser 440, or any combination thereof. In some embodiments, process 500 may be executed by different entities. In some embodiments, process 500 includes more than Figure 5 The steps shown in the text may be more, fewer, or different.

[0070] In one approach, processor 470 determines the role of device 400. Processor 470 may present a user interface that allows a user of the device to select or specify the role of device 400. For example, the device may be a master 202, an intermediate node 206, or a slave 204. In one aspect, the user may select or specify an operating mode of the device. For example, device 400 may operate in a mode to support specific capabilities (e.g., end-to-end delayed request-response TC without partial TC, end-to-end delayed request-response TC with partial TC mode, and peer / 802.1AS TC). The role of device 400 may be determined before device 400 is deployed or while device 400 is in operation. In some embodiments, step 510 may be performed by entering resolver 430 or exiting resolver 440.

[0071] In one method, processor 470 determines 520 a table containing a list of one or more actions associated with a determined role and / or operating mode of device 400. For example, processor 470 may determine one or more actions for the selected role and / or operating mode in the enter parser 430 and load the determined actions into table 480. Similarly, processor 470 may determine one or more actions for the selected role and / or operating mode in the exit parser 440 and load the determined actions into table 490. In some embodiments, the enter parser 430 or the exit parser 440 may perform step 520.

[0072] In one method, a communication interface receives packets 530 for communication. The communication interface may be an inbound resolver 430 or an outbound resolver 440. For example, the inbound resolver 430 of master controller 202 receives inbound packets 410 from the outbound resolver 440 of intermediate node 206 or slave controller 204. For example, the inbound resolver 430 of intermediate node 206 or slave controller 204 receives inbound packets 410 from the outbound resolver 440 of master controller 202. For example, the outbound resolver 440 of master controller 202 or slave controller 204 receives outbound packets 425 from a local switch, host processor, or external processor. For example, the outbound resolver 440 of intermediate node 206 receives outbound packets 425 from the outbound resolver 440 of master controller 202 or slave controller 204. In some embodiments, processor 470 detects the packet type and determines a table of one or more actions based on the determined packet type and the role and / or operating mode of device 400.

[0073] In one approach, the communication interface determines an action 540 corresponding to a portion of the packet. For example, the communication interface obtains one or more bits from a predetermined field (e.g., reserved field 326). The communication interface may apply the obtained one or more bits to a corresponding table (e.g., table 480 or 490) and determine or identify one or more actions corresponding to the one or more bits.

[0074] In one approach, the communication interface performs a determined action 550. For example, the communication interface may add a timestamp value to a packet or store a timestamp value in memory 450 according to a table (e.g., table 480 or 490).

[0075] Advantageously, the lookup tables disclosed herein allow various actions to be performed based on the PTP message type or to support time synchronization between different nodes. For example, IEEE 1588 2.0 allows the exchange of 0 to 1 in a reserved field containing 12 bits to provide instructions or commands to perform various actions, but IEEE 1588 2.1 no longer allows the exchange of 0 to 1 in a reserved field to provide such instructions or commands. In one aspect, one or more actions supported in IEEE 1588 2.0 can be performed while conforming to IEEE 1588 2.1 using an on-chip lookup table. Furthermore, actions different from those supported in IEEE 1588 2.0 or more effective actions than those supported in IEEE 1588 2.0 can be performed.

[0076] - Instance Roles and Operation Modes

[0077] In some embodiments, device 400 may be configured to operate as various roles in a 1588 system. For example, device 400 may be a TC (or intermediate node 206), SC (or slave 204), or GM (or master 202). In one approach, a user of device 400 may assign device 400 to operate as a specific role. For example, processor 470 presents a user interface that allows the user to select or specify a specific role for device 400. In one aspect, in addition to roles, operating modes of device 400 may also be assigned. For example, when acting as a TC, device 400 may support end-to-end delayed request-response TC without partial TC mode, end-to-end delayed request-response TC with partial TC mode, and peer / 802.1AS TC mode.

[0078]

[0079]

[0080] Table 1. Configurable Roles and Modes of Network Devices

[0081] When used as a GM or SC, device 400 can simultaneously support both peer-to-peer / 802.1AS mode and end-to-end delayed request-response mode. Therefore, for GM or SC, the peer-to-peer 802.1AS mode and end-to-end delayed request-response mode do not need to be configured.

[0082] -Enter / Exit 1588 Group Classifier

[0083] In one aspect, the incoming parser 430 or the outgoing parser 440 includes or is coupled to a packet classifier to classify the packets according to the type to which each incoming / outgoing packet belongs. A list of available packet types is provided below.

[0084] Support grouping packetIsSyncOneStep packetIsSyncTwoStep packetIsDelayRequest packetIsSyncFollowUp packetIsPdelayRequest packetIsPdelayResponseOneStep packetIsPdelayResponseTwoStep packetIsPdelayRespFollowUp packetIsDelayResponse Non-1588 group

[0085] Table 2. Available Grouping Types

[0086] In one implementation, event messages or packets can be identified because event messages (Sync, DelayRequest, PdelayRequest, and Pdelay_Response) are timing-critical messages and these messages can cause the hardware to perform timestamps to achieve high 1588 accuracy. Regarding the lookup-based engine, non-event message types or packets can be categorized or classified. For example, the parser can identify non-event message types (SyncFollowUp, PdelayRespFollowUp, and DelayResponse). Therefore, the communication interface (e.g., entering parser 430 or exiting parser 440) can perform various actions on non-event messages. By classifying non-event message types, the parser can process these messages or packets without the processor 470 performing MDIO accesses to construct the corresponding messages. By excluding MDIO accesses, the speed of device 400 can be improved.

[0087] -Enter Action List

[0088] For each incoming message type identified by the group classifier, various actions can be assigned. The following is a list of actions supported on the incoming side.

[0089]

[0090]

[0091] Table 3. Permitted Actions for Entering the Parser

[0092] POP_TS_INSERT_OTS: Entering resolver 430 can replace the original_timecode field of the corresponding 1588 packet with a timestamp stored in memory 450. Entering resolver 430 can store the timestamp, IP address / MAC address, domain number, and sequence number of the 1588 message in memory 450. This action is not performed when the MAC address from the corresponding 1588 packet matches the MAC address from memory 450. Similarly, this action is not performed when the domain number from the corresponding 1588 packet matches the domain number from memory 450. This action is not performed when the sequence number from the corresponding 1588 packet matches the sequence number from memory 450. Entering resolver 430 can perform UDP checksum and cyclic redundancy check (CRC) recalculation due to the modified packet content.

[0093] INSERT_RSV2: Entering parser 430 inserts the inbound SOP timestamp of the corresponding 1588 packet into the RESV2 field of the corresponding 1588 packet. It can also perform UDP checksum and CRC recalculation because the packet content has been modified.

[0094] PUSH_TS_memory: The entry resolver 430 can store the entry timestamp of the corresponding 1588 packet in memory 450. The entry timestamp may contain or indicate the time when the entry resolver 430 received the entry packet 410. In addition to the entry timestamp, the entry resolver 430 can also store the IP address / MAC address, domain number, and sequence number in memory 450. If the packet content is modified, the entry resolver 430 can perform UDP checksum and CRC recalculation.

[0095] SUB_TS_CF: Entering parser 430 allows updating the correction field for the corresponding 1588 packet. The new correction field can be the previous correction field in the corresponding 1588 packet minus the entry timestamp of the corresponding 1588 packet. UDP checksum and CRC recalculation can also be performed due to the modification of the packet content.

[0096] INSERT_TS_OTS: Entering parser 430 allows the entry timestamp of the corresponding 1588 packet to be inserted into the original_timecode field of the corresponding 1588 packet. Entering parser 430 can also perform UDP checksum and CRC recalculation because the packet content has been modified.

[0097] POP_TS_RESV2: Entering resolver 430 can replace the reserved fields of the corresponding 1588 packet with a timestamp stored in memory 450. Entering resolver 430 can store the timestamp, IP address / MAC address, domain number, and sequence number of the 1588 message in memory 450. This action is not required when the MAC address from the corresponding 1588 packet matches the MAC address from memory 450. Similarly, this action is not required when the domain number from the corresponding 1588 packet matches the domain number from memory 450. This action is not required when the sequence number from the corresponding 1588 packet matches the sequence number from memory 450. Processor 470 can perform UDP checksum and CRC recalculation due to the modified packet content.

[0098] NO_ACTION: No action was taken on the corresponding 1588 group in parser 430.

[0099] -Exit Action Table

[0100] For each outgoing message type identified by the group classifier, various actions can be assigned. The following is a list of actions supported on the outgoing side.

[0101] action RTL code parameters Version 1588 Pop TS from memory into OTS POP_INSERT_TS_OTS Version 2.0 CF = CF + (TXSOP - In-band (RXSOP)) ADD_TS_CF_INBAND Version 2.0 Push TS to memory PUSH_TS_memory Version 2.0 CF = CF + TXTS (New) ADD_TS_CF Version 2.1 Insert TS into OTS INSERT_TS_OTS Version 2.0 CF = CF + (Memory - In-band (RXSOP)) (New) ADD_TSMEM_CF Version 2.1 No action NO_ACTION

[0102] Table 4. Permitted Actions for Outgoing Parser

[0103] POP_TS_INSERT_OTS: Outgoing resolver 440 can replace the original_timecode field of the corresponding 1588 packet with a timestamp stored in memory 450. Outgoing resolver 440 can store the timestamp, IP address / MAC address, domain number, and sequence number of the 1588 message in memory 450. This action is not required when the MAC address from the corresponding 1588 packet matches the MAC address from memory 450. Similarly, this action is not required when the domain number from the corresponding 1588 packet matches the domain number from memory 450. This action is not required when the sequence number from the corresponding 1588 packet matches the sequence number from memory 450. Outgoing resolver 440 can perform UDP checksum and CRC recalculation due to the modification of packet content.

[0104] ADD_TS_CF_INBAND: Outgoing parser 440 can use the timestamp in the reserved field of the corresponding 1588 packet and the outgoing SOP timestamp of the corresponding 1588 packet to perform a correction field update for the corresponding 1588 packet. The new correction field can be the correction field in the corresponding 1588 packet - the timestamp in the reserved field + the outgoing SOP timestamp. Outgoing parser 440 can perform UDP checksum and CRC recalculation because the packet content has been modified.

[0105] PUSH_TS_memory: Outgoing resolver 440 can store the outgoing timestamp of the corresponding 1588 packet in memory 450. The outgoing timestamp may contain or indicate the time when outgoing resolver 440 received outgoing packet 425. In addition to the outgoing timestamp, outgoing resolver 440 may also store IP address / MAC address, domain number, and sequence number in memory 450. Outgoing resolver 440 may not perform UDP checksum and CRC recalculation because the packet content has not been modified.

[0106] ADD_TS_CF: Outgoing resolver 440 can perform a correction field update on the corresponding 1588 packet. The new correction field can be the previous correction field of the corresponding 1588 packet plus the outgoing timestamp of the corresponding 1588 packet. Outgoing resolver 440 can perform UDP checksum and CRC recalculation because the packet content has been modified.

[0107] INSERT_TS_OTS: Outgoing parser 440 can insert the outgoing SOP timestamp into the original_timecode field of the corresponding 1588 packet. Outgoing parser 440 can perform UDP checksum and CRC recalculation because the packet content has been modified.

[0108] ADD_TSMEM_CF: Outgoing resolver 440 can perform a correction field update using the timestamp in the reserved field and the outgoing SOP timestamp in the TSFIFO / memory 450. The new correction field can be the correction field in the corresponding 1588 packet - the timestamp in the reserved field + the outgoing SOP timestamp from the TSFIFO / memory 450. This action is not required when the MAC address from the corresponding 1588 packet matches the MAC address from the memory 450. Similarly, this action is not required when the domain number from the corresponding 1588 packet matches the domain number from the memory 450. This action is not required when the sequence number from the corresponding 1588 packet matches the sequence number from the memory 450. Outgoing resolver 440 can perform UDP checksum and CRC recalculation due to the modified packet content.

[0109] NO_ACTION: The parser did not perform any action on the corresponding 1588 packet.

[0110] - Predefined entry / exit action table

[0111] In one aspect, tables 480 and 490 can be determined or loaded based on the role of device 400. Additionally, tables 480 and 490 can be determined or loaded based on the selected operating mode of device 400. For example, when device 400 operates as a transparent clock, different actions can be loaded based on the selected operating mode (e.g., TC with partial TC mode, TC without partial TC mode, or TC in equivalent 802.1AS mode). Example actions for different operating modes are described below.

[0112]

[0113] Table 5. Permitted Actions for the Outgoing Parser of TC for Different Modes

[0114]

[0115]

[0116] Table 6. Permitted Actions for Entering the Parser for TCs in Different Modes

[0117] When device 400 operates as the Master Controller (GM) clock (or Master Controller 202), the following are predefined outgoing and incoming action tables. Note that the default settings for GM support both P2P / 802.1AS and E2E delayed request-response modes simultaneously, therefore, the actions for P2P / 802.1AS and E2E delayed request-response modes are not differentiated. Furthermore, the action table on the incoming side may vary depending on whether device 400 operates in non-in-band mode or in-band mode. The following are predefined action tables for GM.

[0118]

[0119] Table 7. Permitted Actions for GM in Different Modes

[0120] When device 400 operates as a slave clock (SC) or slave device 204, the following are the predefined outgoing and incoming action tables. Note that the default settings for SC support both P2P / 802.1AS and E2E delayed request-response modes simultaneously, therefore, the actions for P2P / 802.1AS and E2E delayed request-response modes are not differentiated. Furthermore, the action table on the incoming side may vary depending on whether the system is operating in non-in-band or in-band mode.

[0121]

[0122] Table 8. Permitted Actions for SC Used in Different Modes

[0123] -Follow-up Assistant Support- In version 1588v 2.1 using predefined lookup tables

[0124] When the corresponding port acts as the two-step master controller (GM) (or master controller 202), a follow-up assistant occurs. The relevant 1588 message can be sync.twostep and subsequent messages. The following is a table of outgoing actions for the GM used for the follow-up assistant.

[0125]

[0126] Table 9. Permitted Actions for GM in Different Modes

[0127] The GM can send a two-step synchronization message. The outgoing resolver 440 of the GM (or master controller 202) can receive the first outgoing packet 425 from, for example, a host processor or an external processor and identify the first outgoing packet 425 as a two-step synchronization message, for example, based on a classifier. The outgoing resolver 440 can access the action table 490 and execute the PUSH_TS_memory 450 action. The outgoing resolver 440 can also store the domain number, source MAC address, and sequence ID in memory 450. The outgoing resolver 440 of the GM (or master controller 202) can transmit the corresponding two-step synchronization message as the first outgoing packet 415 without requiring any packet modification to the intermediate node 206 or slave controller 204.

[0128] The GM can send subsequent messages with the same domain number, source MAC address, and sequence ID. Outgoing resolver 440 can receive the second outgoing packet 425' and identify the first outgoing packet as a subsequent message, for example, based on a classifier. Outgoing resolver 440 can access the action table and execute POP_INSERT_TS_OTS_action. When a match exists in the domain number, source MAC address, and sequence ID, outgoing resolver 440 can only update the original time field of the subsequent message. If the corresponding packet is an IPv4 or IPv6 packet, outgoing resolver 440 can also perform UDP checksum recalculation. Outgoing resolver 440 can perform CRC recalculation because the packet content has been modified. Outgoing resolver 440 can transmit the modified second outgoing packet 415' to intermediate node 206 or slave controller 204.

[0129] With a predefined GM table, device 400 can be configured to support or operate as both two-step GM and one-step GM. Based on the predefined action table, features or operations conforming to the IEEE 1588 2.0 protocol can be performed, while also conforming to the IEEE 1588v2.1 protocol.

[0130] - Supports delayed request / response mode (without partial TC) in TC

[0131] The Delayed Request-Response (TC) mode can not coexist with the peer-to-peer (P2P) mode. Therefore, all P2P-related messages can be commented as unavailable (N / A). The TC mode in the Delayed Request-Response (TC) mode calculates the dwell time for the corresponding event message. The relevant 1588 messages are ync.1step, sync.2step, follow-up, delay_req, and delay_response. The following is a table of relevant actions for the TC mode.

[0132]

[0133] Table 10. Permissible Outgoing Actions for TC Used in Delayed Request-Response Mode (No Partial TC)

[0134]

[0135] Table 11. Permitted Entry Actions for TC Used in Delayed Request Response Mode (No Partial TC)

[0136] -Enter Operation:

[0137] When used as a one-step TC, the relevant messages are the sync.1step, delay_req, and delay_response messages. First, the ingress resolver 430 of intermediate node 206 may receive an ingress packet 410 from master 202 or slave 204. In one instance, the ingress resolver 430 of intermediate node 206 may receive a request for synchronization (or SYNC) or a response to a delay measurement request (or DELAY_RESP) from master 202. In one instance, the ingress resolver 430 of intermediate node 206 may receive a request for delay measurement (or DELAY_REQ) from slave 204. For any of the event messages (e.g., sync.1step and delay_req messages), the ingress resolver 430 may update the correction field (CF) by performing a new CF = old_CF - ingress timestamp based on the ingress action table 480. If the corresponding packet is an IPv4 or IPv6 packet, the ingress resolver 430 may also perform a UDP checksum recalculation. Incoming parser 430 can perform CRC recalculation because the packet content has been modified. Incoming parser 430 of intermediate node 206 can transmit the modified incoming packet 420 containing the new CF value to master 202 or slave 204. In one instance, incoming parser 430 of intermediate node 206 can transmit a synchronization request (or SYNC) or a response to a delay measurement request (or DELAY_RESP) to slave 204. In one instance, incoming parser 430 of intermediate node 206 can transmit a delay measurement request (or DELAY_REQ) to master 202.

[0138] When device 400 is used as a two-step TC, the relevant messages are sync.2step, follow-up, delay_request, and delay_response. Entering parser 430 can respond to the sync.2step message by performing PUSH_TS_memory according to action table 480. Entering parser 430 may not perform any action on subsequent messages. Entering parser 430 can respond to the delay_req message by performing CF field updates according to action table 480.

[0139] -Outside operation:

[0140] When device 400 is used as a one-step TC, the relevant messages are sync.1step, delay_req, and delay_response messages. First, the outgoing resolver 440 of intermediate node 206 can receive outgoing packets 425 from master 202 or slave 204. In one instance, the outgoing resolver 440 of intermediate node 206 can receive a synchronization request (or SYNC) or a response to a delay measurement request (or DELAY_RESP) from master 202. In one instance, the outgoing resolver 440 of intermediate node 206 can receive a delay measurement request (or DELAY_REQ) from slave 204. On the outgoing side, for any of the event messages (sync.1step message and DelayRequest message), the outgoing resolver 440 can update the CF based on the outgoing action table 490 by performing a new CF = old_CF + entry timestamp. If the corresponding packet is an IPv4 or IPv6 packet, the outgoing resolver 440 can also perform a UDP checksum recalculation. Outgoing resolver 440 can perform CRC recalculation due to changes in packet content. Outgoing resolver 440 of intermediate node 206 can transmit a modified outgoing packet 415 containing the new CF value to master 202 or slave 204. In one instance, outgoing resolver 440 of intermediate node 206 can transmit a synchronization request (or SYNC) or a response to a delay measurement request (or DELAY_RESP) to slave 204. In one instance, outgoing resolver 440 of intermediate node 206 can transmit a delay measurement request (or DELAY_REQ) to master 202.

[0141] When device 400 is used as a two-step TC, the relevant messages are sync.2step, follow-up, delay_request, and delay_response messages. Outgoing parser 440 may respond to the sync.2step message by performing PUSH_TS_memory 450 according to action table 490. Outgoing parser 440 may not perform any action on subsequent messages. Outgoing parser 440 may respond to the delay_req message by performing CF field updates according to action table 490.

[0142] Using these operations, the dwell time of event messages can be calculated according to IEEE 1588.

[0143] - Supports delayed request-response mode (with partial TC) in TC

[0144] The Delayed Request-Response (TC) mode can coexist with the peer-to-peer (P2P) mode. Therefore, all P2P-related messages can be commented as N / A. The TC mode within the Delayed Request-Response (TC) mode calculates the dwell time for the corresponding event message. Related 1588 messages can be sync.1step, sync.2step, subsequent, delay_req, and delay_response messages. The following is a table of related actions for the TC mode.

[0145]

[0146] Table 12. Permissible Outgoing Actions for TC Used in Delayed Request-Response Mode (with Partial TC)

[0147]

[0148] Table 13. Permitted Entry Actions for TC Used in Delayed Request Response Mode (with Partial TC)

[0149] -Enter Operation:

[0150] When used as a one-step TC, the relevant messages are the sync.1step, delay_req, and delay_response messages. First, the ingress resolver 430 of intermediate node 206 can receive ingress packets 410 from master 202 or slave 204. In one instance, the ingress resolver 430 of intermediate node 206 can receive a request for synchronization (or SYNC) or a response to a delay measurement request (or DELAY_RESP) from master 202. In one instance, the ingress resolver 430 of intermediate node 206 can receive a request for delay measurement (or DELAY_REQ) from slave 204. For any of the event messages used in delay request mode (such as sync.1step and delay_req messages), the ingress resolver 430 can insert an ingress timestamp into the RESV2 field based on the ingress action table 480. If the corresponding packet is an IPv4 or IPv6 packet, the ingress resolver 430 can also perform a UDP checksum recalculation. Incoming parser 430 can perform CRC recalculation because the packet content has been modified. Incoming parser 430 of intermediate node 206 can transmit a modified incoming packet 420 containing the new CF value. In one instance, incoming parser 430 of intermediate node 206 can transmit a request for synchronization (or SYNC) or a response to a delay measurement request (or DELAY_RESP) to slave controller 204. In one instance, incoming parser 430 of intermediate node 206 can transmit a request for delay measurement (or DELAY_REQ) to master controller 202.

[0151] When device 400 is used as a two-step TC, the relevant messages are sync.2step, follow-up, delay_request, and delay_response. Entering parser 430 can respond to the sync.2step message by performing a lookup in the action table and executing PUSH_TS_memory 450. Entering parser 430 may not perform any action on subsequent messages. Entering parser 430 can perform the same operation in response to the delay_req message because it is within a one-step clock cycle.

[0152] -Outside operation:

[0153] When device 400 is used as a one-step TC, the relevant messages are sync.1step, delay_req, and delay_response messages. First, the outgoing resolver 440 of intermediate node 206 can receive outgoing packets 425 from master controller 202 or slave controller 204. In one instance, the outgoing resolver 440 of intermediate node 206 can receive a request for synchronization (or SYNC) or a response to a delay measurement request (or DELAY_RESP) from master controller 202. In one instance, the outgoing resolver 440 of intermediate node 206 can receive a request for delay measurement (or DELAY_REQ) from slave controller 204. For ports that are part of the 1588 network, on the outgoing side, for any of the event messages (sync.1step message and DelayRequest message) used in delay request mode, the outgoing resolver 440 can update the CF based on the outgoing action table 490 by performing the action: new CF = old_CF - resv2 value + entry timestamp. Note that the resv2 value is the inbound timestamp previously added by the inbound resolver 430. If the corresponding packet is an IPv4 or IPv6 packet, the outbound resolver 440 can also perform UDP checksum recalculation. The outbound resolver 440 can perform CRC recalculation because the packet content has been modified. The outbound resolver 440 of intermediate node 206 can transmit the modified outbound packet 415 containing the new CF value to the master 202 or slave 204. In one instance, the outbound resolver 440 of intermediate node 206 can transmit a synchronization request (or SYNC) or a response to a delay measurement request (or DELAY_RESP) to slave 204. In one instance, the outbound resolver 440 of intermediate node 206 can transmit a delay measurement request (or DELAY_REQ) to master 202. For ports not participating in the 1588 network, the outbound resolver 440 can ensure that the corresponding packets are forwarded to those ports that are disabled by 1588.

[0154] When device 400 operates as a two-step TC, for ports that are part of the 1588 network, the relevant messages are `sync.2step`, `follow-up`, `delay_request`, and `delay_response`. Outgoing resolver 440 can respond to the `sync.2step` message by performing a lookup in the action table and executing `PUSH_TS_memory` 450. Outgoing resolver 440 may not perform any action on subsequent messages. Outgoing resolver 440 can perform the same operation in response to the `delay_req` message because it is within a one-step clock cycle. For ports not participating in the 1588 network, outgoing resolver 440 can ensure that corresponding packets are forwarded to those ports where 1588 is disabled.

[0155] - Support peer-to-peer link delay measurement using predefined action tables

[0156] The peer-to-peer delay measurement related messages are Pdelay_req, Pdelay_response.1step, Pdelay_response.2step, and Pdelay_resp_followup. In one aspect, peer-to-peer delay measurement can occur in peer-to-peer mode but not in delay request-response mode. Therefore, for delay request-response mode, the actions for all peer-to-peer related messages can be N / A in the TC action table. For GM and SC, when device 400 operates in peer-to-peer mode, the actions for all peer-to-peer related messages can be meaningful.

[0157] Peer-to-peer link measurements can be performed between link partners (e.g., nodeA or delay_requester and nodeB or delay_responder). In one aspect, the device can operate as a delay requester, a delay responder, or both. The following is a table of actions for peer-to-peer related messages.

[0158]

[0159] Table 14. Permitted Actions for P2P Link Measurement

[0160] On the entry side, the action table can also be based on in-band or non-in-band control. For non-in-band mode, the timestamp of the entry packet 410 is captured and written to the TSFIFO / memory. For non-in-band mode, the processor 740 retrieves the entry timestamp via MDIO. For in-band mode, the entry timestamp can be inserted into a reserved field, allowing the processor 470 to retrieve the entry timestamp and the entry packet 410 without MDIO access.

[0161] Figure 6 An interactive diagram illustrating a process 600 for performing a two-step peer-to-peer link delay measurement based on a lookup table according to an embodiment is shown. In one aspect, the two-step peer-to-peer link delay measurement is performed in 802.1AS mode. In some embodiments, process 600 is performed by nodeA 606 and nodeB 604. nodeA 606 and nodeB 604 can be any network node (e.g., master 202, intermediate node 206, or slave 204). In some embodiments, process 600 is performed by other entities. In some embodiments, process 600 includes a step-by-step comparison... Figure 6 The steps shown in the text may be more, fewer, or different.

[0162] In one approach, at time T1, nodeA 606 transmits a Pdelay_req message or packet. The Pdelay_req message may contain a request to perform or initiate a delay measurement. For example, nodeA 606's outgoing resolver 440A may generate and transmit the Pdelay_req message at time T1. nodeA 606's outgoing resolver 440A may, in response to a PUSH_TS_memory command (e.g., a user-defined command), store time T1 in table 490A by nodeA 606's TSFIFO or memory 450A. Processor 470A may retrieve T1 via MDIO.

[0163] In one approach, at time T2, nodeB 604 receives a Pdelay_req message or a packet. For example, the inbound resolver 430B of nodeB 604 receives the Pdelay_req message at time T2. In non-in-band mode, inbound resolver 430B may, in response to the Pdelay_req message, store the timestamp value T2 in nodeB 604's TSFIFO or memory 450B according to table 480B. When in non-in-band mode, there may be no packet content modification. In in-band mode, inbound resolver 430B may, in response to an INSERT_RESV2 message (e.g., a user-defined command), insert the timestamp value T2 into a reserved field according to table 480B of nodeB 604. In in-band mode, CRC recalculation and UDP checksum recalculation may be performed due to packet content modification.

[0164] In one approach, at time T3, nodeB 604 responds to a Pdelay_req message or packet by transmitting a Pdelay_Resp.2step message or packet. The Pdelay_Resp.2step message may be a response message to the Pdelay_req message. The Pdelay_Resp.2step message may contain a timestamp value T2. For example, nodeB 604's outgoing resolver 440B generates and transmits the Pdelay_Resp.2step message at time T3. Outgoing resolver 440B may, in response to generating a Pdelay_req, store the timestamp value T3 in nodeB 604's action table 490B via nodeB's TSFIFO or memory 450B. nodeB 604's processor 480B may retrieve the timestamp values ​​T3 and T2 via MDIO.

[0165] In one approach, at time T4, nodeA 606 receives a Pdelay_resp message in response to a Pdelay_req on the RX side. The ingress parser 430A of nodeA 606 may receive the Pdelay_resp message at time T4. In non-in-band mode, the ingress parser 430A may, in response to a PUSH_TS_memory 450 (e.g., a user-defined command), store the timestamp value T4 in the TSFIFO or memory 450A of nodeA 606 according to table 480A. The processor 470A of nodeA 606 may retrieve the timestamp value T4 via MDIO access. In in-band mode, the ingress parser 430A may, in response to an INSERT_RESV2 (e.g., a user-defined command) message, insert the timestamp value T4 into a reserved field according to table 480A of nodeA 606. The processor 470A may retrieve the timestamp value T4 and the packet.

[0166] In one approach, at time TT5, nodeB 604 responds to a Pdelay_req message or packet by transmitting a Pdelay_Resp.2step message or packet. The Pdelay_resp_followup message may be a follow-up message provided after the Pdelay_resp.2step message. The Pdelay_resp_followup message may contain a timestamp value T3. Time TT5 may be before or after time T4. In one instance, the outgoing resolver 440B of node B 604 generates and transmits a Pdelay_response_followup message at time TT5, which may be a predetermined time after time T3.

[0167] In one approach, at time TT6, nodeA 606 receives a Pdelay_resp message in response to a Pdelay_req on the RX side. The ingress resolver 430A of nodeA 606 may receive the Pdelay_resp message at time TT6. In non-in-band mode, the ingress resolver 430A may, in response to PUSH_TS_memory 450, store the timestamp value T4 in nodeA 606's TSFIFO or memory 450 according to table 480A. The processor 470A of nodeA 606 may retrieve the timestamp value T4 via MDIO access. In in-band mode, the ingress resolver 430A may, in response to an INSERT_RESV2 message, insert the timestamp value T4 into a reserved field according to table 480A of nodeA 606. Based on timestamp value T4 and timestamp value T3, the processor 470A may determine or measure the latency in the peer link between nodeA 606 and nodeB 604 used for the ingress path. The outgoing path delay can be determined by the difference between the timestamp values ​​T1 and T2 between nodeA606 and nodeB604.

[0168] Figure 7 An interactive diagram illustrating a process 700 for performing a one-step peer-to-peer link delay measurement based on a lookup table according to an embodiment is shown. In one aspect, a one-step peer-to-peer link delay measurement is performed in 802.1AS mode. In some embodiments, process 700 is performed by nodeA 606 and nodeB 604. In some embodiments, process 700 is performed by other entities. In some embodiments, process 700 includes a step-by-step comparison... Figure 7 The steps shown in the text may be more, fewer, or different.

[0169] In one aspect, procedure 700 is similar to procedure 600, except that nodeB 604 transmits the Pdelay_resp.1step message or packet instead of the Pdelay_resp.2step message or packet, and nodeB 604 does not transmit the Pdelay_resp_followup message or packet. Therefore, detailed descriptions of its repeated parts have been omitted in this document for the sake of brevity.

[0170] In one aspect, nodeB 604 uses time T2 to generate a Pdelay_resp.1step message or packet. For example, nodeB 604's outgoing resolver 440B, in response to a Pdelay_req message, inserts a negative (or -T2) timestamp value T2 into the CF field of the corresponding Pdelay_resp.1step message. Outgoing resolver 440B may, in response to the instruction ADD_TS_CF (e.g., a user-defined command), update the CF using the outgoing timestamp value T3 according to action table 490B. Outgoing resolver 440B may transmit a Pdelay_resp.1step message containing the updated CF. Based on the updated CF, nodeA 606 can determine or measure the latency in the peer link between nodeA 606 and nodeB 604.

[0171] -User-defined entry and exit action table

[0172] In some embodiments, the list of one or more actions in tables 480, 490 may be edited or modified by a user of device 400. For example, processor 470 may present a user interface that allows a user to add or remove one or more actions to be performed. By allowing a user to add or modify one or more actions listed in tables 480, 490, device 400 may perform or support certain operations that are otherwise infeasible, or perform or support certain operations in an effective manner. For example, user-defined actions may support a two-step TC with a follow-up assistant.

[0173] - Support two-step TC with follow-up assistant using user-defined action tables

[0174] Users can configure exit and entry action tables as shown below to support two-step control calls (TCs) with follow-up assistants. Additionally, a flexible user-defined table, as shown below, can support both one-step and two-step TCs simultaneously.

[0175] Subsequent messages can exist in the delayed request-response pattern. Since the delayed request-response pattern may not coexist with the peer-to-peer pattern, the actions of all peer-related messages can be commented as N / A.

[0176]

[0177] Table 15. User-defined actions for two-step TC

[0178] In one approach, the inbound resolver 430 of a first port (e.g., port 0) receives a synchronization message or packet from the host 202. In response to a synchronization message applied to table 480, the inbound resolver 430 may perform a PUSH_TS_memory 450 action. The inbound resolver 430 may store the inbound timestamp of the synchronization message in memory 450. The inbound resolver 430 may also store IP address / MAC address, domain number, and sequence number in memory 450. No packet content may be modified. The inbound resolver 430 may forward the synchronization message to the outbound resolver 440 of a second port (e.g., port 1) based on the exchange lookup result.

[0179] In response to the synchronization message applied to table 490, outgoing resolver 440 may execute the PUSH_TS_memory 450 action. The outgoing timestamp (sync_egsop) of this synchronization message may be stored in memory 450. Outgoing resolver 440 may also store IP address / MAC address, domain number, and sequence number in memory 450. No packet content is modified at this time.

[0180] The enter parser 430 can receive subsequent messages. In response to the subsequent message applied to table 480, the enter parser 430 can perform the POP_TS_RESV2 action. Sync_igsop will be in the reserved field of the corresponding subsequent message (F_U_1). Since the packet content has been modified, the enter parser 430 can also perform UDP checksum recalculation and CRC recalculation. This new subsequent message (F_U_2) can be forwarded to the processor 470 based on the exchange lookup result. The processor 470 can send the subsequent message (F_U_2) back to the switch.

[0181] Outgoing resolver 440 on port 2 (PT1) can receive subsequent messages. In response to a subsequent message applied to table 490, outgoing resolver 440 can perform the ADD_TSMEM_CF action. Outgoing resolver 440 can pop sync_egsop from memory 450 of PT1. Outgoing resolver 440 can optionally perform ADD_TSMEM_CF based on the comparison results of IP address / MAC address, domain number, and sequence number. Outgoing resolver 440 can replace the correction field of F_U_2 with a new correction field. The new correction field can be equal to the old correction field of F_U_2 + Sync_egsop - Sync_igsop. Sync_igsop can be found in the reserved fields of F_U_2. With this, the dwell time can be calculated correctly. Furthermore, outgoing resolver 440 of PT1 can also perform UDP checksum recalculation and CRC recalculation.

[0182] In one aspect, user-defined lookup tables can efficiently support two-step TCs with subsequent assistance. For example, processor 470 may not perform MDIO accesses to retrieve the entry and exit timestamps for each synchronization message. Furthermore, processor 470 may not perform UDP checksum recalculation and CRC recalculation. Therefore, CPU load can be reduced to achieve computational efficiency and operational speed can be improved.

[0183] It features a user-defined action table and also supports one-step TC. For example, the enter parser 430 can insert `sync_igsop` into a reserved field. The exit parser 440 can perform the `ADD_TS_CF_INBAND` action based on the exit action table. With this, the dwell time of the one-step synchronization message can be correctly calculated and updated in the CF field of the corresponding one-step synchronization message.

[0184] The various embodiments disclosed herein relate to a method for supporting time synchronization. In some embodiments, the method includes determining a role of the device by a processor. In some embodiments, the method includes determining a table by the processor containing a list of one or more actions associated with the determined role of the device. In some embodiments, the method includes receiving packets for communication by a communication interface of the device. In some embodiments, the method includes determining an action corresponding to a portion of the packet by the communication interface from one or more actions associated with the determined role of the device in the table. In some embodiments, the method includes performing the action for communication by the communication interface.

[0185] In some embodiments, the method includes determining the type of a packet using a communication interface. In some embodiments, the table is determined based on the determined type of the packet.

[0186] In some embodiments, the packet is an incoming packet, and the communication interface is an incoming parser. In some embodiments, the method includes the incoming parser applying a portion of the incoming packet to a table to determine an action.

[0187] In some embodiments, the list includes two or more of the following actions: the entry parser replaces a first timestamp value of the original timestamp field in the entry packet with a stored timestamp value stored in the device's memory; the device's memory stores a second timestamp value of the entry timestamp of the entry packet; and the entry parser inserts a third timestamp value of the entry timestamp into the original timestamp field in the entry packet.

[0188] In some embodiments, the list includes two or more of the following actions: the entry parser inserts a third timestamp value of the entry timestamp into a reserved field in the entry packet; the entry parser updates a correction field in the entry packet based on a second timestamp value of the entry timestamp; and the entry parser replaces a fourth timestamp value in the reserved field of the entry packet with a stored timestamp value.

[0189] In some embodiments, the packet is an outgoing packet, and the communication interface is an outgoing resolver. In some embodiments, the method includes applying a portion of the outgoing packet to a table by the outgoing resolver to determine an action.

[0190] In some embodiments, the list includes two or more of the following actions: the outgoing parser replaces a first timestamp value of the original timestamp field in the outgoing packet with a stored timestamp value stored in the device's memory; the outgoing parser updates the correction field of the outgoing packet based on a second timestamp value of a reserved field in the outgoing packet and a third timestamp value of the outgoing timestamp of the outgoing packet; the device's memory stores a fourth timestamp value of the outgoing timestamp of the outgoing packet; and the outgoing parser inserts the third timestamp value of the outgoing timestamp into the original timestamp field in the outgoing packet.

[0191] In some embodiments, the list includes two or more of the following actions: updating the correction field of the outgoing packet by the outgoing resolver based on a fourth timestamp value of the outgoing timestamp; and performing the correction field update by the outgoing resolver based on a second timestamp value of the reserved field and a fifth timestamp value of the outgoing timestamp in the device's FIFO or memory.

[0192] In some embodiments, the packet is an outgoing packet, and the communication interface is an outgoing resolver. In some embodiments, the action for communication is to store the outgoing timestamp value of the outgoing packet in the device's memory. In some embodiments, the method further includes: storing a domain number, a source MAC address, and a sequence ID in the device's memory; receiving subsequent packets by the outgoing resolver; and in response to a subsequent packet having a stored domain number, a source MAC address, or a sequence ID, replacing the first timestamp value of the original timestamp field in the outgoing packet with the stored timestamp value stored in the device's memory by the outgoing resolver.

[0193] In some embodiments, the action for communication includes updating one or more fields in a packet by the communication interface and performing a CRC recalculation on the updated packet by the communication interface.

[0194] In some embodiments, the communication interface includes an inbound parser and an outbound parser. In some embodiments, the communication interface performs actions for communication including: the outbound parser transmitting a delay measurement request to another device at a first time based on one or more actions in a table; and the inbound parser receiving a delay response message from the other device at a second time in response to the delay measurement request based on one or more actions in the table.

[0195] In some embodiments, the action performed by the communication interface for communication includes: receiving another delay response message by the entry parser in response to a delay measurement request based on one or more actions in a table at a third time after a second time.

[0196] In some embodiments, the communication interface includes an ingress parser and an egress parser. In some embodiments, the communication interface performs actions for communication including: the ingress parser receiving a delay measurement request from another device at a first time based on one or more actions in a table, and the egress parser transmitting a delay response message to the other device at a second time in response to the delay measurement request based on one or more actions in the table.

[0197] In some embodiments, the action performed by the communication interface for communication includes: transmitting another delay response message to another device at a third time after a second time based on one or more actions in a table in response to a delay measurement request.

[0198] In some embodiments, the method further includes: receiving an instruction to update the table via a communication interface; and updating the table via the communication interface according to the instruction.

[0199] In some embodiments, the packet is an IEEE 1588 packet, wherein a portion of the packet is a reserved field in an IEEE 1588 packet.

[0200] The various embodiments disclosed herein relate to an apparatus for supporting time synchronization. In some embodiments, the apparatus includes a processor configured to determine a role of the apparatus and to determine a table containing a list of one or more actions associated with the determined role of the apparatus. In some embodiments, the apparatus includes a communication interface configured to: receive packets for communication, determine an action corresponding to a portion of the packet from one or more actions associated with the determined role of the apparatus in the table, and perform the action for communication.

[0201] In some embodiments, the packet is an IEEE 1588 packet, wherein a portion of the packet is a reserved field in an IEEE 1588 packet.

[0202] The various embodiments disclosed herein relate to a non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause one or more processors to: determine a role of a device; determine a table containing a list of one or more actions associated with the determined role of the device; cause a communication interface to receive packets for communication; cause the communication interface to determine, from the one or more actions associated with the determined role of the device in the table, an action corresponding to a portion of the packet; and cause the communication interface to perform the action for communication.

[0203] In some embodiments, the packet is an IEEE 1588 packet, wherein a portion of the packet is a reserved field in an IEEE 1588 packet.

[0204] It should be noted that certain paragraphs of this disclosure may refer to terms such as “first” and “second” in relation to transport spatial streams, probe frames, responses, and devices for the purpose of identifying or distinguishing one another or for other purposes. These terms are not intended to associate entities (e.g., first device and second device) merely temporally or sequentially, but in some cases, these entities may encompass such relationships. These terms also do not limit the number of possible entities that can operate within the system or environment. It should be understood that the system described above may provide many or each of those components, and these components may be provided on a standalone machine, or in some embodiments, on multiple machines in a distributed system. Furthermore, the systems and methods described above may be provided as one or more computer-readable programs or executable instructions embodied in one or more articles of art, such as floppy disks, hard disks, CD-ROMs, flash memory cards, PROMs, RAMs, ROMs, or magnetic tapes. The program may be implemented in any programming language such as LISP, PERL, C, C++, C#, or any bytecode language such as JAVA. The software program or executable instructions may be stored in one or more articles of art as object code.

[0205] While the foregoing written description of the methods and systems enables those skilled in the art to make and use the embodiments, it should be understood and appreciated that variations, combinations, and equivalents of specific embodiments, methods, and examples exist herein. Therefore, the methods and systems should not be limited to the embodiments, methods, and examples described above, but rather to all embodiments and methods within the scope and spirit of this disclosure.

Claims

1. A method comprising: determining, by a processor of a device, a role of the device, the role comprising one of a master, a slave, or a middle node; determining, by the processor, a table containing a list of one or more actions associated with the determined role of the device, wherein the one or more actions comprise different actions for modifying a timestamp value in a packet; receiving, by a communication interface of the device, the packet for communication; determining, by the communication interface, an action from the one or more actions in the table associated with the determined role of the device to modify a timestamp value in a portion of the packet using one or more bits in a field of the packet; and performing, by the communication interface, the action for communication of the packet on the packet.

2. The method of claim 1, further comprising: determining, by the communication interface, a type of the packet, wherein the table is determined according to the determined type of the packet.

3. The method of claim 1, wherein the packet is an ingress packet, wherein the communication interface is an ingress parser, the method further comprising: applying, by the ingress parser, the portion of the ingress packet to the table to determine the action.

4. The method of claim 3, wherein the list contains two or more actions of: replacing, by the ingress parser, a first timestamp value of an original time code field in the ingress packet with a stored timestamp value stored by a memory of the device; storing, by the memory of the device, a second timestamp value of an ingress timestamp of the ingress packet; and inserting, by the ingress parser, a third timestamp value of the ingress timestamp into the original time code field in the ingress packet.

5. The method of claim 4, wherein the list contains two or more actions of: inserting, by the ingress parser, the third timestamp value of the ingress timestamp into a reserved field in the ingress packet; updating, by the ingress parser, a correction field in the ingress packet based on the second timestamp value of the ingress timestamp; and replacing, by the ingress parser, a fourth timestamp value of the reserved field in the ingress packet with the stored timestamp value.

6. The method of claim 1, wherein the packet is an egress packet, wherein the communication interface is an egress parser, the method further comprising: applying, by the egress parser, the portion of the egress packet to the table to determine the action.

7. The method of claim 6, wherein the list contains two or more actions of: replacing, by the egress parser, a first timestamp value of an original time code field in the egress packet with a stored timestamp value stored by a memory of the device; updating, by the egress parser, a correction field of the egress packet based on a second timestamp value of a reserved field in the egress packet and a third timestamp value of an egress timestamp of the egress packet; storing, by the memory of the device, a fourth timestamp value of the egress timestamp of the egress packet; and inserting, by the egress parser, the third timestamp value of the egress timestamp into the original time code field in the egress packet.

8. The method of claim 7, wherein the list includes two or more actions of the following: updating, by the egress parser, the correction field of the egress packet based on the fourth timestamp value of the egress timestamp; and performing, by the egress parser, a correction field update based on the second timestamp value of the reserved field and a fifth timestamp value of the egress timestamp in a FIFO or the memory of the device.

9. The method of claim 1, wherein the packet is an egress packet, wherein the communication interface is an egress parser, wherein the action for communicating is storing, by a memory of the device, a timestamp value of an egress timestamp of the egress packet, the method further comprising: storing, by the memory of the device, a domain number, a source MAC address, and a sequence ID; receiving, by the egress parser, a subsequent packet; and in response to the subsequent packet having the stored domain number, source MAC address, or sequence ID, replacing, by the egress parser, a first timestamp value of an original time code field in the egress packet with a stored timestamp value stored by the memory of the device.

10. The method of claim 1, wherein the action for communicating includes: updating, by the communication interface, one or more fields in the packet, and performing, by the communication interface, a cyclic redundancy check (CRC) recalculation on the updated packet.

11. The method of claim 1, wherein the communication interface includes an ingress parser and an egress parser, wherein performing the action for communicating by the communication interface includes: transmitting, by the egress parser, a delay measurement request to another device at a first time based on one or more actions in the table; and receiving, by the ingress parser, a delay response message from the other device at a second time in response to the delay measurement request based on one or more actions in the table.

12. The method of claim 11, wherein performing the action for communicating by the communication interface includes: receiving, by the ingress parser, another delay response message at a third time after the second time in response to the delay measurement request based on one or more actions in the table.

13. The method of claim 1, wherein the communication interface includes an ingress parser and an egress parser, wherein performing the action for communicating by the communication interface includes: receiving, by the ingress parser, a delay measurement request from another device at a first time based on one or more actions in the table, and transmitting, by the egress parser, a delay response message to the other device at a second time in response to the delay measurement request based on one or more actions in the table.

14. The method of claim 13, wherein performing the action for communicating by the communication interface includes: transmitting, by the egress parser, another delay response message to the other device at a third time after the second time in response to the delay measurement request based on one or more actions in the table.

15. The method of claim 1, further comprising: receiving, by the communication interface, an instruction to update the table; and updating, by the communication interface, the table according to the instruction.

16. The method of claim 1, wherein the packet is an Institute of Electrical and Electronics Engineers (IEEE) 1588 packet, wherein the portion of the packet is a reserved field in the IEEE 1588 packet.

17. An apparatus comprising: a processor configured to: determine a role of the apparatus, the role comprising one of a master, a slave, or an intermediate node, and determine a table comprising a list of one or more actions associated with the determined role of the apparatus, wherein the one or more actions comprise different actions for modifying a timestamp value in a packet; and a communication interface configured to: receive the packet for communication, determine an action from the one or more actions in the table associated with the determined role of the apparatus to modify a timestamp value in a portion of the packet using one or more bits in a field of the packet, and perform the action for communication.

18. The apparatus of claim 17, wherein the packet is an Institute of Electrical and Electronics Engineers (IEEE) 1588 packet, wherein the portion of the packet is a reserved field in the IEEE 1588 packet.

19. A non-transitory computer-readable medium storing instructions that, when executed by one or more processors, cause the one or more processors to: determine a role of an apparatus, the role comprising one of a master, a slave, or an intermediate node; determine a table comprising a list of one or more actions associated with the determined role of the apparatus, wherein the one or more actions comprise different actions for modifying a timestamp value in a packet; cause a communication interface to receive the packet for communication; cause the communication interface to determine an action from the one or more actions in the table associated with the determined role of the apparatus to modify a timestamp value in a portion of the packet using one or more bits in a field of the packet; and cause the communication interface to perform the action on the packet for communication of the packet.

20. The non-transitory computer-readable medium of claim 19, wherein the packet is an Institute of Electrical and Electronics Engineers (IEEE) 1588 packet, wherein the portion of the packet is a reserved field in the IEEE 1588 packet.

Images