Ethernet fault management systems and methods
View Patent ↗Ethernet fault management systems and methods using programmable Type-Length-Value (TLV) offsets combine software-based Operations, Administration, and Maintenance (OAM) protocol support with hardware-based fault management support to delegate generation and processing of OAM protocol messages to hardware devices with the software-based protocol support used to program hardware based on fixed offsets in the OAM protocol messages. The hardware can be designed to be flexible since the hardware can be agnostic to the logic within the OAM protocol which would reside in the software. The Ethernet fault management systems and methods combine the flexibility of software-based approaches with the speed and efficiency of hardware-based approaches.
1. An Ethernet fault management method, comprising: receiving, from a remote Maintenance End Point, a first control packet with objects present therein; passing a copy of the first control packet to software; analyzing the first control packet in the software to determine the objects present therein and associated offsets; programming a hardware device using the software based on the determined objects present and the associated offsets such that the hardware device is configured to process subsequent control packets from the remote MEP rather than the subsequent control packets being processed in the software, wherein the hardware device is programmed to look for specific contents in the subsequent control packets at the associated offsets and to act upon any change in contents at the associated offsets; and receiving the subsequent control packets from the remote MEP and processing the subsequent control packets in the hardware device based on the programming.
2. The Ethernet fault management method of claim 1 , further comprising:
detecting a mismatch by the hardware device; and
raising an interrupt or sending a control packet associated with the mismatch to the software for processing.
3. The Ethernet fault management method of claim 1 , wherein the hardware device comprises one of a Field Programmable Gate Array, an Application Specific Integrated Circuit, and a Network Processor.
4. The Ethernet fault management method of claim 1 , wherein the objects comprise Type-Length-Value (TLV) objects.
5. The Ethernet fault management method of claim 4 , further comprising:
updating the software to support extensibility of the TLV objects.
6. The Ethernet fault management method of claim 4 , wherein the TLV objects comprise at least one Organization-Specific TLV.
7. The Ethernet fault management method of claim 4 , wherein the TLV objects comprise an Interface Status TLV and a Port Status TLV.
8. The Ethernet fault management method of claim 7 , further comprising:
removing the LOC for the LAG if any one of the ports spread across the different hardware devices has the LOC cleared.
9. The Ethernet fault management method of claim 1 , wherein the control packets comprise Protocol Data Units in accordance with Connectivity Fault Management.
10. The Ethernet fault management method of claim 1 , wherein the control packets comprise Continuity Check Messages (CCMs).
11. The Ethernet fault management method of claim 1 , further comprising:
determining a Link Aggregation Group (LAG) comprises ports spread across different hardware devices;
programming a software shim layer on each of the different hardware devices responsive to the determining;
processing faults at the software shim layer on each of the different hardware devices; and
generating a Loss of Continuity (LOC) for the LAG if LOC is present on each of the ports spread across the different hardware devices.
12. An Ethernet node, comprising: a port communicatively coupled to a remote device; a hardware device associated with the port; and a processor configured to execute software; wherein the port, the hardware device, and the processor are cooperatively configured to: receive, from the remote device, a first control packet with objects present therein; pass a copy of the first control packet to the software; analyze the first control packet with the software to determine the objects present therein and associated offsets; program the hardware device using the software based on the determined objects present and the associated offsets such that the hardware device is configured to process subsequent control packets from the remote device rather than the subsequent control packets being processed in the software, wherein the hardware device is programmed to look for specific contents in the subsequent control packets at the associated offsets and to act upon any change in contents at the associated offsets; and receive the subsequent control packets from the remote device and process the subsequent control packets in the hardware device based on the programming.
13. The Ethernet node of claim 12 , wherein the port, the hardware device, and the processor are further cooperatively configured to:
detect a mismatch by the hardware device; and
raise an interrupt or send a control packet associated with the mismatch to the software for processing.
14. The Ethernet node of claim 12 , wherein the hardware device comprises one of a Field Programmable Gate Array, an Application Specific Integrated Circuit, and a Network Processor.
15. The Ethernet node of claim 12 , wherein the objects comprise Type-Length-Value (TLV) objects.
16. The Ethernet node of claim 15 , wherein the TLV objects comprise at least one Organization-Specific TLV, an Interface Status TLV, and a Port Status TLV.
17. The Ethernet node of claim 12 , wherein the port, the hardware device, and the processor are further cooperatively configured to: update the software to support extensibility of the TLV objects.
18. The Ethernet node of claim 12 , wherein the control packets comprise Protocol Data Units in accordance with Connectivity Fault Management.
19. The Ethernet node of claim 12 , wherein the port, the hardware device, and the processor are further cooperatively configured to:
determine a Link Aggregation Group (LAG) in which the port participates in comprises ports spread across different hardware devices;
program a software shim layer responsive to the determining;
process faults at the software shim layer;
generate a Loss of Continuity (LOC) for the LAG if LOC is present on each of the software shim layers spread across the different hardware devices; and
remove the LOC for the LAG if any one of the ports spread across the different hardware devices has the LOC cleared.
20. A network, comprising: a plurality of interconnected nodes each supporting Connectivity Fault Management Ethernet; wherein each of the plurality of interconnected nodes comprises: a port communicatively coupled to another node of the plurality of interconnected nodes; a hardware device associated with the port; and a processor configured to execute software; wherein the port, the hardware device, and the processor are cooperatively configured to: receive, from the another node, a first control packet with Type-Length-Value (TLV) objects present therein; pass a copy of the first control packet to the software; analyze the first control packet with the software to determine the TLV objects present therein and associated offsets; program the hardware device using the software based on the determined TLV objects present and the associated offsets such that the hardware device is configured to process a subsequent control packet from the other node rather than the subsequent control packet being processed with the software, wherein the hardware device is programmed to look for specific contents in the subsequent control packets at the associated offsets and to act upon any change in contents at the associated offsets; and receive the subsequent control packet from the other node and process the subsequent control packet in the hardware device based on the programming.