Patent Description:
A cyclic redundancy check (CRC) is an error-detecting code commonly used to detect accidental changes to raw digital data communicated in digital networks and storage devices. The changes to raw digital data are in the form of bit flips. Blocks of digital data entering these systems are provided with a short error-check value attached to each packet of data. The CRC value is calculated based on the remainder of a polynomial division of the data content of the packet. Upon retrieval, the calculation is repeated and, in the event that the CRC value in the entered data packet does not match the CRC values in the output packet, corrective action can be taken against data corruption based on the CRC value.

CRCs are so called because the check (data verification) value is a redundancy (it expands the message without adding information) and the applied algorithm is based on cyclic codes. The popularity of the CRCs arise from their simple implementation in digital hardware, rather easy mathematical analysis, and particularly good detection of common errors caused by noise in transmission channels. Because the check value has a fixed length, the function that generates it is occasionally used as a hash function. The existing CRC error-detection methods have shortcomings that need to be addressed using an enhanced error-protection scheme.

<CIT> discloses integrity check values and frame check sequences for protection of Ethernet packets.

The invention is defined by independent claims <NUM> and <NUM> while preferred embodiments are described in dependent claims thereof.

However, for purposes of explanation, several embodiments of the subject technology are set forth in the following figures.

The detailed description set forth below is intended as a description of various configurations of the subject technology and is not intended to represent the only configurations in which the subject technology may be practiced. The appended drawings are incorporated herein and constitute part of the detailed description, which includes specific details for providing a thorough understanding of the subject technology. However, the subject technology is not limited to the specific details set forth herein and may be practiced without one or more of the specific details. In some instances, structures and components are shown in a block-diagram form in order to avoid obscuring the concepts of the subject technology.

The subject technology is directed to methods and systems for enhanced error protection of a payload using double-cyclic redundancy check (CRC). The double CRC of the subject technology is implemented in both media-access control security (MACsec) enabled or MACsec-disabled physical layers (PHYs). The disclosed double-CRC feature allows retaining the incoming CRC instead of having it stripped. In some aspects, the egress packet with the CRC is encrypted by the MACsec, and the encrypted packet is then transmitted with a new CRC (e.g., outer CRC) via a transmit MAC. When the double-CRC packet is received on the receiver side, the outer CRC is stripped by the receiving MAC and then decrypted by the MACsec logic. The decrypted packet will have the originally received CRC. This entire packet is sent out by the transmit MAC. An advantageous feature of the double CRC of the subject technology is that the original CRC is retained from start to finish.

This feature results in detection of any silent data corruption in the data path that enables dropping the corrupted packets prior to reaching the receiving device. In the existing solutions, at the MACsec-related PHYs, any bit flips in the data path will go out of the PHY as a silent error. This is because the CRC of incoming packet is stripped at the receive MACand then recomputed by the outgoing MAC. The recomputed CRC is on the corrupted data without being detected. The exiting solution is not foolproof and lacks reliability. The disclosed solution provides a high level of confidence that any silent corruption is detected via the PHY by generating the appropriate error condition. While the disclosed double-CRC technique can be implemented in hardware, some features of the double-CRC technique can be implemented in software or firmware.

<FIG> is a schematic diagram illustrating an example of a high-level view of a system <NUM> in which various aspects of the subject technology are implemented. The system <NUM> includes a first line card 100A (line card-A) in communication with a second line card 100B (line card-B). The first line card 100A and the second line card 100B may be, for example, parts of a digital network or a data storage facility. The first line card 100A includes a switch <NUM> and a first set of MACsec PHYs such as a MACsec PHY1, a MACsec PHY3, a MACsec PHY5 and a MACsec PHY7. In some aspects of the subject technology, the switch <NUM> can be an application-specific integrated circuit (ASIC). In a transmit (TX) path, the switch or ASIC <NUM> transmits packets to the MACsec PHYs, and in a receive (RX) path, the switch or ASIC <NUM> receives packets from the MACsec PHYs. The first set of MACsec PHYs are parts of first MAC PHYs in which the double-CRC scheme of the subject technology is implemented, as discussed in more detail herein. Each MACsec PHY is a security MAC PHY and, when enabled, is capable of encrypting the content of a received packet.

The second line card 100B is similar to the first line card 100A and includes a second set of MACsec PHYs such as a MACsec PHY2, a MACsec PHY4, a MACsec PHY6 and a MACsec PHY8. The second set of MACsec PHYs is communicatively coupled to a switch and/or ASIC <NUM>. The disclosed double-CRC scheme is also implemented in the second MAC PHYs that include the second set of MACsecs, as discussed in more detail herein.

<FIG> are schematic diagrams illustrating examples of double-CRC implementation, in accordance with some aspects of the subject technology. <FIG> shows a high-level view 200A of an example double-CRC scheme of the subject technology, which is implemented using a switch and/or ASIC <NUM>, a MACsec block <NUM>, a line <NUM>, a MACsec <NUM> and a switch and/or ASIC <NUM>. The switch and/or ASIC <NUM> and the MACsec <NUM> belong to the first line card 100A of <FIG>, and the switch and/or ASIC <NUM> and the MACsec block <NUM> belong to the second line card 100B of <FIG>. The switch and/or ASIC <NUM> sends a packet-plus-CRC <NUM> including a first CRC (CRC1) in an egress path to a MACsec block <NUM>. The MACsec block <NUM> encrypts the packet-plus-CRC <NUM> and adds a second CRC (CRC2) to the encrypted packet-plus-CRC <NUM> to generate a double-CRC packet <NUM>, which is transmitted via the line <NUM> to the MACsec block <NUM> of an ingress path. The output of the MACsec block <NUM> is a packet-plus-CRC <NUM>, which is the same as the original packet-plus-CRC <NUM> entered in the egress path.

<FIG> shows a more detailed implementation 200B of the example double-CRC scheme of <FIG>. In the implementation 200B, the egress path is shown to consist of a PHY <NUM> (PHY1) that includes an Ethernet MAC TX block <NUM>, the MACsec block <NUM> and an Ethernet MAC TX block <NUM>. The ingress path of the implementation 200B is similar to the egress path and consists of a PHY <NUM> (PHY2) that includes an Ethernet MAC RX block <NUM>, the MACsec block <NUM> and an Ethernet MAC TX block <NUM>.

The Ethernet MAC RX block <NUM> receives the packet-plus-CRC <NUM> and checks the CRC1 to detect any error in the packet data, and, if no error is detected, the CRC1 is retained and the packet-plus-CRC <NUM> is passed for encryption to the MACsec block <NUM>, where the encrypted packet-plus-CRC <NUM> is generated. The encrypted packet-plus-CRC <NUM> is sent to the Ethernet MAC TX block <NUM>, where the second CRC (CRC2) is appended to produce the double-CRC packet <NUM>, which is transmitted via line <NUM> to PHY <NUM>. In PHY <NUM>, the Ethernet MAC RX block <NUM> receives the double-CRC packet <NUM> and checks the CRC2 to detect whether any corruption in the packet data, and, if no corruption is detected, the CRC2 is removed and the encrypted packet-plus-CRC <NUM> is produced. The encrypted packet-plus-CRC <NUM> is similar to the encrypted packet-plus-CRC <NUM> and is passed for decryption to the MACsec block <NUM>, where the decrypted packet-plus-CRC <NUM> is generated. The decrypted packet-plus-CRC <NUM> is the same as the original packet-plus-CRC <NUM> that was received by the first PHY <NUM> and can be used to detect any silent error and then is transmitted by the Ethernet MAC TX block <NUM>. In one or more aspects, the same double-CRC scheme of <FIG> discussed above can be applied to the path in the opposite direction from PHY <NUM> to PHY <NUM>.

It is worth noting that with the double-CRC feature of the subject technology, the incoming CRC (CRC1) from the source ASIC/switch is retained, and because this CRC is retained through the entire egress and ingress data path, the destination MAC in the destination switch/ASIC will be able to identify any data bit corruption that would otherwise pass unnoticed through the system.

<FIG> are schematic diagrams illustrating examples of CRC-pass through implementation with a disabled MACsec feature, in accordance with some aspects of the subject technology. <FIG> shows a high-level view 300A of an example CRC-pass-through scheme of the subject technology, where the MACsec feature is disabled. The example double-CRC scheme of <FIG> is implemented using a switch and/or ASIC <NUM>, a MACsec block <NUM>, a line <NUM>, a MACsec block <NUM> and a switch and/or ASIC <NUM>. The switch and/or ASIC <NUM> and the MACsec block <NUM> belong to the first line card 100A of <FIG>, and the switch and/or ASIC <NUM> and the MACsec block <NUM> belong to the second line card 100B of <FIG>. The switch and/or ASIC <NUM> sends a packet-plus-CRC <NUM> including a first CRC (CRC1) in an egress path to a MACsec block <NUM>. The MACsec block <NUM> is programmed to forward the packet-plus-CRC <NUM> without appending a second CRC (CRC2) to the encrypted packet-plus-CRC <NUM> or encrypting it. Therefore, the packet-plus-CRC <NUM> is transmitted via the line <NUM> to the MACsec block <NUM>, which in turn is programmed to not append or replace the CRC in the received the packet-plus-CRC. Thus, the output of the MACsec block <NUM> is the same as the original packet-plus-CRC <NUM> entered in the egress path.

<FIG> shows a more detailed implementation 300B of the example double-CRC scheme of <FIG>. In the implementation 300B, the egress path consists of a PHY <NUM> (PHY1) that includes an Ethernet MAC TX block <NUM>, the MACsec block <NUM> and an Ethernet MAC TX block <NUM>. The ingress path of the implementation 300B is similar to the egress path and consists of a PHY <NUM> (PHY2) that includes an Ethernet MAC RX block <NUM>, the MACsec block <NUM> and an Ethernet MAC TX block <NUM>.

The Ethernet MAC RX block <NUM> receives the packet-plus-CRC <NUM> and checks the CRC1 to detect any error in the packet data, and, if no error is detected, the CRC1 is retained and the packet-plus-CRC <NUM> is passed to the MACsec block <NUM>, which can be programmed to be disabled. In one or more implementations, the MACsec block <NUM> can be entirely bypassed. Thus, the packet-plus-CRC <NUM> is sent to the Ethernet MAC TX block <NUM> unchanged. The Ethernet MAC TX block <NUM> is programmed to transmit, without appending, the packet-plus-CRC <NUM> to the PHY <NUM> via the line <NUM>. In the PHY <NUM>, the Ethernet MAC RX block <NUM> receives the packet-plus-CRC <NUM> and checks the CRC1 to detect whether any silent error occurred during transmission through the line <NUM> in the packet data, and, if no error is detected, the CRC1 is retained and the packet-plus-CRC <NUM> is passed to the MACsec block <NUM>, which can be programmed to be disabled. In some implementations, the MACsec block <NUM> can be entirely bypassed. Therefore, the packet-plus-CRC <NUM> - that is the same as the original packet-plus-CRC <NUM> that was received by the first PHY <NUM> - is transmitted by the Ethernet MAC TX block <NUM>. In one or more aspects, the same double-CRC scheme of FIG. 300B discussed above can be similarly applied to the path in the opposite direction from PHY <NUM> to PHY <NUM>.

It is worth noting that the example implementation of the double-CRC scheme can be used even when the MACsec feature is disabled in the PHY <NUM> and the incoming CRC from the source ASIC/switch (e.g., <NUM>) is retained. Because the original CRC is retained through the entire egress and ingress paths, the destination MAC in destination switch/ASIC (e.g., <NUM>) is able to identify any data bit corruption that otherwise would have passed through unnoticed.

<FIG> are schematic diagrams illustrating examples of existing normal CRC implementation. <FIG> shows a high-level view 400A of an example normal CRC scheme, which is described herein, highlighting the differences and advantageous features of the subject technology over the existing solution. The normal CRC scheme of high-level view 400A is implemented using a switch and/or ASIC <NUM>, the PHY <NUM> (PHY1, an egress path PHY), a line <NUM>, PHY <NUM> (PHY2, an ingress path PHY) and a switch and/or ASIC <NUM>. The switch and/or ASIC <NUM> and the PHY <NUM> belong to the first line card 100A of <FIG>, and the switch and/or ASIC <NUM> and the PHY <NUM> belong to the second line card 100B of <FIG>. The switch and/or ASIC <NUM> sends a packet-plus-CRC <NUM> including a first CRC (CRC1) in the egress path to the PHY <NUM>. The PHY <NUM> checks CRC1 and removes it and encrypts the packet and appends a new CRC (CRC2) to the encrypted packet to generate an encrypted packet-plus-CRC2 <NUM>, which is transmitted via the line <NUM> to the PHY <NUM> of the ingress path. In the PHY <NUM>, the CRC2 is checked and removed, the packet is decrypted and a new CRC (CRC3) is appended to the decrypted packet to generate a packet-plus-CRC3 <NUM>.

<FIG> shows a more detailed implementation 400B of the example normal CRC scheme of <FIG>. In the implementation 400B, the egress path is shown to consist of the PHY <NUM> (PHY1) that includes an Ethernet MAC RX block <NUM>, a MACsec block <NUM> and an Ethernet MAC TX block <NUM>. The ingress path of the implementation 400B is similar to the egress path and consists of the PHY <NUM> (PHY2) that includes an Ethernet MAC RX block <NUM>, a MACsec block <NUM> and an Ethernet MAC TX block <NUM>.

The Ethernet MAC RX block <NUM> receives the packet-plus-CRC <NUM> and checks the CRC <NUM> to detect any error in the packet data, and, if no error is detected, the CRC1 is removed and the packet <NUM> is passed for encryption to the MACsec block <NUM>, where the encrypted packet <NUM> is generated. The encrypted packet <NUM> is sent to the Ethernet MAC TX block <NUM>, where a new CRC (CRC2) is appended to the encrypted packet <NUM> to produce an encrypted packet-plus-CRC2 <NUM>, which is transmitted via the line <NUM> to the PHY <NUM>. In the PHY <NUM>, the Ethernet MAC RX block <NUM> receives the encrypted packet-plus-CRC2 <NUM>, checks and removes the CRC2 and produces the encrypted packet <NUM>. The encrypted packet <NUM> is passed to the MACsec block <NUM> for decryption, where the decrypted packet <NUM> is generated. The decrypted packet <NUM> is the same as the original packet-plus-CRC <NUM> that was received by the PHY <NUM>. The decrypted packet <NUM> is passed to the Ethernet MAC TX block <NUM>, where a new CRC (CRC3) is appended to the packet to generate a packet-plus-CRC3 <NUM>, which can be transmitted by the Ethernet MAC TX block <NUM>. The same normal CRC scheme of <FIG> discussed above can be applied to the path in the opposite direction from PHY <NUM> to PHY <NUM>.

According to the above description, in the existing CRC scheme, if there is any data corruption such as a data bit flip due to a memory corruption inside the PHYs (e.g., PHY <NUM> and PHY <NUM>), it can slip through as silent corruption, which the regular Ethernet CRC is not capable of capturing. This is because the CRC is recomputed by the transmit MAC (e.g., the Ethernet MAC TX block <NUM>), as described above.

<FIG> is a flow diagram illustrating an example process <NUM> for double-CRC implementation, in accordance with some aspects of the subject technology. The process <NUM> includes receiving a first packet (e.g., <NUM> of <FIG>) by a first PHY (e.g., <NUM> of <FIG>) (<NUM>). The first packet includes a source packet (e.g., the packet in <FIG>) and a first CRC (e.g., CRC1 of <FIG>). The process <NUM> also includes encrypting (e.g., by <NUM> of <FIG>) the first packet having the first CRC to generate an encrypted first packet (e.g., <NUM> of <FIG>) (<NUM>). The process <NUM> further includes appending a second CRC (e.g., CRC2 of <FIG>) to the encrypted first packet to produce a second packet (e.g., <NUM> of <FIG>) (<NUM>), and transmitting the second packet to a second PHY (e.g., <NUM> of <FIG>) via a transmission line (e.g., <NUM> of <FIG>) (<NUM>).

<FIG> is an electronic system within which some aspects of the subject technology are implemented. The electronic system <NUM> can be, and/or can be a part of, the network switch (e.g., <NUM> or <NUM> of <FIG>) of a data center or an enterprise network. The electronic system <NUM> may include various types of computer-readable media and interfaces for various other types of computer-readable media. The electronic system <NUM> includes a bus <NUM>, one or more processing units <NUM>, a system memory <NUM> (and/or buffer), a ROM <NUM>, a permanent storage device <NUM>, an input device interface <NUM>, an output device interface <NUM>, and one or more network interfaces <NUM>, or subsets and variations thereof.

The one or more processing units <NUM> can be a single processor or a multi-core processor in different implementations.

The ROM <NUM> stores static data and instructions that are needed by the one or more processing units <NUM> and other modules of the electronic system <NUM>. The permanent storage device <NUM> may be a nonvolatile memory unit that stores instructions and data, even when the electronic system <NUM> is off.

In one or more implementations, a removable storage device (such as a floppy disk or flash drive and its corresponding disk drive) may be used as the permanent storage device <NUM>. Similar to the permanent storage device <NUM>, the system memory <NUM> may be a read-and-write memory device. However, unlike the permanent storage device <NUM>, the system memory <NUM> may be a volatile read-and-write memory, such as random-access memory (RAM). The system memory <NUM> may store any of the instructions and data that one or more processing units <NUM> may need at runtime. From these various memory units, the one or more processing units <NUM> retrieves instructions to execute and data to process in order to execute the processes of one or more implementations.

Output devices that may be used with the output device interface <NUM> may include, for example, printers and display devices such as a liquid crystal display (LCD), a light-emitting diode (LED) display, an organic light-emitting diode (OLED) display, a flexible display, a flat-panel display, a solid-state display, a projector, or any other device for outputting information. One or more implementations may include devices that function as both input and output devices, such as touchscreens. In these implementations, feedback provided to the user can be any form of sensory feedback such as visual feedback, auditory feedback, or tactile feedback; and input from the user can be received in any form, including acoustic, speech, or tactile input.

Finally, as shown in <FIG>, the bus <NUM> also couples the electronic system <NUM> to one or more networks and/or to one or more network nodes, through the one or more network interfaces <NUM>. In this manner, the electronic system <NUM> can be a part of a network of computers (such as a LAN, or a wide-area network ("WAN")), or an Intranet, or a network of networks such as the Internet. Any or all components of the electronic system <NUM> can be used in conjunction with the subject disclosure.

The tangible computer-readable storage medium also can be nontransitory in nature.

For example, without limitation, the computer-readable medium can include any volatile semiconductor memory such as RAM, DRAM, SRAM, T-RAM, Z-RAM, and TTRAM.

Further, the computer-readable storage medium can include any nonsemiconductor memory such as optical disk storage, magnetic disk storage, magnetic tape, other magnetic storage devices, or any other medium capable of storing one or more instructions. In one or more implementations, the tangible computer-readable storage medium can be directly coupled to a computing device, while, in other implementations, the tangible computer-readable storage medium can be indirectly coupled to a computing device, e.g., via one or more wired connections, one or more wireless connections, or any combination thereof.

For example, instructions can be realized as executable or nonexecutable machine code or as instructions in a high-level language that can be compiled to produce executable or nonexecutable machine code. Computer-executable instructions also can be organized in any format including routines, subroutines, programs, data structures, objects, modules, applications, applets, and functions, among other resources. As recognized by those of skill in the art, details including, but not limited to, the number, structure, sequence, and organization of instructions can vary significantly without varying the underlying logic, function, processing, and output.

Various components and blocks may be arranged differently (e.g., arranged in a different order, or partitioned in a different way), all without departing from the scope of the subject technology.

It is understood that any specific order or hierarchy of blocks in the processes disclosed is an illustration of example approaches. Based upon design preferences, it is understood that the specific order or hierarchy of blocks in the processes may be rearranged, or that all illustrated blocks be performed. Any of the blocks may be performed simultaneously. In one or more implementations, multitasking and parallel processing may be advantageous.

As used in this specification and any claims of this application, the terms "base station," "receiver," "computer," "server," "processor," and "memory" all refer to electronic or other technological devices. For the purposes of the specification, the terms "display" or "displaying" mean displaying on an electronic device.

As used herein, the phrase "at least one of' preceding a series of items, with the term "and" or "or" to separate any of the items, modifies the list as a whole, rather than each member of the list (i.e., each item).

The predicate words "configured to," "operable to," and "programmed to" do not imply any particular tangible or intangible modification of a subject, but rather are intended to be used interchangeably.

Phrases such as "an aspect," "the aspect," "another aspect," "some aspects," "one or more aspects," "an implementation," "the implementation," "another implementation," "some implementations," "one or more implementations," "an embodiment," "the embodiment," "another embodiment," "some embodiments," "one or more embodiments," "a configuration," "the configuration," "another configuration," "some configurations," "one or more configurations," "the subject technology," "the disclosure," "the present disclosure," and other variations thereof and alike are for convenience and do not imply that a disclosure relating to such phrase(s) is essential to the subject technology or that such disclosure applies to all configurations of the subject technology. A phrase such as "an aspect" or "some aspects" may refer to one or more aspects and vice versa, and this applies similarly to other foregoing phrases.

" Any embodiment described herein as "exemplary" or as an "example" is not necessarily to be construed as preferred or advantageous over other embodiments. Furthermore, to the extent that the terms "include," "have," or the like are used in the description or the claims, such terms are intended to be inclusive in a manner similar to the term "comprise" as "comprise" is interpreted when employed as a transitional word in a claim.

Claim 1:
A method for enhanced error protection using double-cyclic redundancy check, CRC, the method comprising:
receiving a first packet (<NUM>, <NUM>, <NUM>), by a first physical layer, PHY, (<NUM>, <NUM>, <NUM>) the first packet (<NUM>, <NUM>, <NUM>) including a source packet and a first CRC (CRC1);
checking the first CRC (CRC1), by an Ethernet media-access control, MAC, receive, RX, block (<NUM>, <NUM>, <NUM>) of the first PHY (<NUM>, <NUM>, <NUM>);
when no error is detected, retaining the first CRC (CRC1) and encrypting the first packet (<NUM>, <NUM>, <NUM>) including the first CRC (CRC1) to generate an encrypted first packet (<NUM>);appending a second CRC (CRC2) to the encrypted first packet (<NUM>) to produce a second packet (<NUM>, <NUM>);
transmitting the second packet (<NUM>, <NUM>) to a second PHY (<NUM>, <NUM>, <NUM>) via a transmission line (<NUM>, <NUM>, <NUM>);
receiving, by the second PHY (<NUM>, <NUM>, <NUM>), the second packet (<NUM>, <NUM>) including the encrypted first packet (<NUM>) and the second CRC (CRC2);
checking, by the second PHY (<NUM>, <NUM>, <NUM>), the second CRC (CRC2) to detect whether the second packet (<NUM>, <NUM>) is corrupted; and
when the second PHY (<NUM>, <NUM>, <NUM>) determines the second packet (<NUM>, <NUM>) is not corrupted, removing, by the second PHY (<NUM>, <NUM>, <NUM>), the second CRC (CRC2) to retrieve the encrypted first packet (<NUM>) and to retain the first CRC (CRC1).