Hardware-assisted digital fault relay for sub-50ms optical protection

Optical networks and nodes are described herein, including an optical network comprising a head-end node and a tail-end node. A line module of the head-end node receives fault information, generates a fault packet, and sends the fault packet to a first node controller identified by first packet forwarding information included in a packet header of the fault packet. The first node controller retrieves second packet forwarding information using the first packet forwarding information, updates the packet header, and sends the fault packet to the tail-end node identified by the second packet forwarding information. A second node controller of the tail-end node retrieves third packet forwarding information using the second packet forwarding information, updates the packet header, and sends the fault packet to an optical protection switching module (OPSM) of the tail-end node identified by the second packet forwarding information. The OPSM switches an optical switch based on the fault information.

BACKGROUND ART

Optical networking is a communication means that utilizes signals encoded in light to transmit information (e.g., data) as an optical signal in various types of telecommunications networks. Optical networking may be used in relatively short-range networking applications such as in a local area network (LAN) or in long-range networking applications spanning countries, continents, and oceans. Generally, optical networks utilize optical amplifiers, a light source such as lasers or LEDs, and wave division multiplexing to enable high-bandwidth, transcontinental communication.

Optical networks are a critical component of the global Internet backbone. This infrastructure acts as the underlay, providing the plumbing for all other communications to take place (e.g., access, metro, and long-haul). In the traditional 7-layer OSI model, optical networks constitute the Layer 1 (also referred to as the “digital layer”) functions, providing digital transmission of bit streams transparently across varying distances over a chosen physical media (in this case, optical). Optical networks also encompass an entire class of devices (which are referred to as “Layer 0” or the “optical layer”), which purely deal with optical photonic transmission and wavelength division multiplexing (WDM). This includes amplification, (re-)generation and optical add/drop multiplexing (OADM). The most widely adopted Layer 1/Layer 0 transport networking technologies today, referred to as Optical Transport Networks (OTN), are based on ITU-T standards. Both these classes of networks are connection-oriented and circuit-switched in nature.

Optical networks may experience a failure between a transmitting node (i.e., an upstream node or head-end node) and a receiving node (i.e., a downstream node or tail-end node). Traditionally, optical networks, such as integrated coherent DWDM networks, handling these failures may implement protection schemes at either Layer 0 or Layer 1, which, when activated, causes the optical signal to be transmitted on a protection path between the head-end node and the tail-end node, instead of on a working path between the same nodes (referred to hereinafter as “1+1 optical protection switching”).

However, in certain optical configurations, 1+1 optical protection switching based solely on fault monitoring at Layer 0 is insufficient. Fault monitoring at Layer 1 is desired in order to reliably perform the 1+1 optical protection switching at Layer 0.

SUMMARY OF THE INVENTION

A method and system are disclosed. In one aspect, the problem of implementing 1+1 optical protection switching based on fault monitoring at Layer 1 is addressed through a head-end node, comprising: a node controller; and a line module comprising a processor and a non-transitory processor-readable medium storing processor-executable instructions that when executed by the processor cause the processor to: receive fault information related to a fault; generate a fault packet comprising a packet header and the fault information, the packet header including first packet forwarding information identifying the node controller as a first destination; and send the fault packet to the node controller identified by the first packet forwarding information; and wherein the node controller comprises packet forwarding circuitry configured to: retrieve second packet forwarding information from a table using at least a portion of the first packet forwarding information as a key, the second packet forwarding information identifying a tail-end node as a second destination; update the packet header of the fault packet with the second packet forwarding information; and send the fault packet toward the tail-end node identified by the second packet forwarding information.

In another aspect, the problem of implementing 1+1 optical protection switching based on fault monitoring at Layer 1 is addressed through a tail-end node, comprising: an optical protection switching module comprising a first line port connected to a working path, a second line port connected to a protection path, a system port, and an optical switch coupled to the first line port to receive first optical signals from the working path and the second line port to receive second optical signals from the protection path for selectively switching optical signals from the first line port or the second line port to the system port; and a node controller comprising packet forwarding circuitry configured to: receive a fault packet comprising a packet header and fault information related to a fault, the packet header including first packet forwarding information identifying the tail-end node as a first destination; retrieve second packet forwarding information from a table using at least a portion of the first packet forwarding information as a key, the second packet forwarding information identifying the optical protection switching module as a second destination; update the packet header of the fault packet with the second packet forwarding information; and send the fault packet to the optical protection switching module identified by the second packet forwarding information; and wherein the optical protection switching module further comprises a processor and a non-transitory processor-readable medium storing processor-executable instructions that when executed by the processor cause the processor to switch the optical switch based on the fault information.

In yet another aspect, the problem of implementing 1+1 optical protection switching based on fault monitoring at Layer 1 is addressed through an optical network, comprising: a tail-end node; and a head-end node, comprising: a first node controller; and a line module comprising a first processor and a first non-transitory processor-readable medium storing first processor-executable instructions that when executed by the first processor cause the first processor to: receive fault information related to a fault; generate a fault packet comprising a packet header and the fault information, the packet header including first packet forwarding information identifying the first node controller as a first destination; and send the fault packet to the first node controller identified by the first packet forwarding information; and wherein the first node controller comprises first packet forwarding circuitry configured to: retrieve second packet forwarding information from a first table using at least a portion of the first packet forwarding information as a first key, the second packet forwarding information identifying the tail-end node as a second destination; update the packet header of the fault packet with the second packet forwarding information; and send the fault packet toward the tail-end node identified by the second packet forwarding information; and wherein the tail-end node comprises: an optical protection switching module comprising a first line port connected to a working path, a second line port connected to a protection path, a system port, and an optical switch coupled to the first line port to receive first optical signals from the working path and the second line port to receive second optical signals from the protection path for selectively switching optical signals from the first line port or the second line port to the system port; and a second node controller comprising second packet forwarding circuitry configured to: retrieve third packet forwarding information from a second table using at least a portion of the second packet forwarding information as a second key, the third packet forwarding information identifying the optical protection switching module as a third destination; update the packet header of the fault packet with the third packet forwarding information; and send the fault packet to the optical protection switching module identified by the third packet forwarding information; and wherein the optical protection switching module further comprises a second processor and a second non-transitory processor-readable medium storing processor-executable instructions that when executed by the second processor cause the second processor to switch the optical switch based on the fault information.

DETAILED DESCRIPTION

Further, use of the term “plurality” is meant to convey “more than one” unless expressly stated to the contrary.

As used herein, qualifiers like “substantially,” “about,” “approximately,” and combinations and variations thereof, are intended to include not only the exact amount or value that they qualify, but also some slight deviations therefrom, which may be due to manufacturing tolerances, measurement error, wear and tear, stresses exerted on various parts, and combinations thereof, for example.

The use of the term “at least one” or “one or more” will be understood to include one as well as any quantity more than one. In addition, the use of the phrase “at least one of X, V, and Z” will be understood to include X alone, V alone, and Z alone, as well as any combination of X, V, and Z.

The use of ordinal number terminology (i.e., “first”, “second”, “third”, “fourth”, etc.) is solely for the purpose of differentiating between two or more items and, unless explicitly stated otherwise, is not meant to imply any sequence or order or importance to one item over another or any order of addition.

As used herein, a digital fault or fault signal is a fault condition that is reported and may be determined after coherent detection in an optical transponder (e.g., Line card). The fault condition may include one or more of the following: Loss of Frame (LOS), based on one or more of an Out of Frame (OOF) defect, an Out of Multi-frame (OOM) defect, or a Loss of Multi-frame (LOM) defect; a Backward Defect Indication (BDI) fault, a Remote BDI (RBDI) fault, a Backward signal degrade (BSD) fault, an Alarm Indication Signal (AIS), an Open Connection Indication (OCI), and/or a remote BSD (RBSD) fault. A BDI is an indication sent upstream by a downstream node detecting LOF. This information may be carried in an SDFEC overhead.

In accordance with the present disclosure, a hardware-assisted fast relay of Layer 1 fault information from the source (i.e., the optical node where the optical link in which the fault was detected is sourced) to the destination (i.e., the optical node where the optical link in which the fault was detected is terminated) is herein described. Switching the optical signal from the working path to the protection path is preferably performed within 50 milliseconds (ms). This 50 ms switching time generally includes: (i) fault detection at the source; (ii) propagation of fault information from the source to the destination; (iii) protection switching at the destination; and (iv) signal recovery at the source. For this reason, propagation of fault information from the source to the destination is preferably performed within 10 ms.

One challenge presented by minimizing the propagation time of the fault information is that the fault information is passed between three separate communication domains or segments: (i) a source line module to a source node controller; (ii) the source node controller to a destination node controller; and (iii) the destination node controller to a destination optical protection switching module (OPSM). Where the fault source and the fault destination are housed in the same optical node, communication segment (ii) may be not applicable.

In the prior art, software-based forwarding is typically used in inter-domain packet forwarding scenarios. However, propagating the fault information within 10 ms is difficult to achieve with only software-based forwarding, especially where the source and the destination are hosted within separate optical nodes, due to queuing and thread priority or contention for each transmission of the fault information from one entity to another.

To accommodate the propagation across the communication segments, an emulated communication network, such as a virtual local area network (VLAN), is instantiated for a given flow from the source to the destination using packet forwarding information, such as a flow identifier (Flow ID), contained within packet headers of fault packets containing the fault information. The fault packets may be forwarded across the nodes of the optical network using conventional IP routing functions. Circuitry, such as a field-programmable gate array (FPGA), on a node controller may extract the Flow ID from an incoming fault packet, retrieve a new Flow ID from a lookup table, and modify the packet header of an outgoing fault packet to include the new Flow ID for routing the fault packet over the next communication segment. Thus, software-based forwarding may be avoided in the propagation of the fault packet.

Referring now toFIG.1, shown therein is a diagrammatic view of an exemplary implementation of an optical network10constructed in accordance with the present disclosure. The optical network10may include a plurality of optical nodes14a-n(hereinafter the “optical nodes14”). In the implementation shown, the optical network10includes four optical nodes14a-d, including a first optical node14a, a second optical node14b, a third optical node14c, and a fourth optical node14d; however, in other implementations, the optical network10may include more or less than four optical nodes14a-d.

The optical network10may include any type of network that uses light as a transmission medium. For example, the optical network10may include a fiber-optic based network, an optical transport network, a light-emitting diode network, a laser diode network, an infrared network, a wireless optical network, a wireless network, combinations thereof, and/or other types of optical networks.

Particular ones of the optical nodes14may be denoted as terminal nodes for an optical signal being transmitted within the optical network10. Each of the terminal nodes may either transmit or receive the optical signal being transmitted within the optical network10. The terminal nodes may include a head-end node (also referred to as a “source node”) and a tail-end node (also referred to as a “destination node”). In the implementation shown, the first optical node14a(hereinafter the “head-end node14a”) is functioning as a head-end node and the third optical node14c(hereinafter the “tail-end node14c”) is functioning as a tail-end node (the head-end node14aand the tail-end node14c, collectively the “terminal nodes14a,14c”).

As shown inFIG.1, one or more of the terminal nodes14a,14cmay be connected to one or more transponder node16(hereinafter the “transponder nodes16”), shown inFIG.1as a first transponder node16aand a second transponder node16bconnected to the head-end node14aand a third transponder node16cconnected to the tail-end node14c. The transponder nodes16may provide optical signals to the optical nodes14to which the transponder nodes16are connected.

Other ones of the optical nodes14between the terminal nodes14a,14cmay be denoted as intermediate nodes. In the implementation shown, the second optical node14b(hereinafter the “first intermediate node14b”) and the fourth optical node14d(hereinafter the “second intermediate node14d”) are functioning as intermediate nodes (the first intermediate node14band the second intermediate node14d, collectively the “intermediate nodes14b,14d”).

Each of the optical nodes14may be implemented in a variety of ways, non-exclusive examples of which including optical line terminals (OLTs), optical cross connects (OXCs), optical line amplifiers (OAs), optical add/drop multiplexer (OADMs) and/or reconfigurable optical add/drop multiplexers (ROADMs), interconnected by way of intermediate links. OLTs may be used at either end of a connection or intermediate link. OADM/ROADMs may be used to add, terminate and/or reroute wavelengths or fractions of wavelengths. Optical nodes14are further described in U.S. Pat. No. 7,995,921 titled “Banded Semiconductor Optical Amplifiers and Waveblockers”, U.S. Pat. No. 7,394,953 titled “Configurable Integrated Optical Combiners and Decombiners”, and U.S. Pat. No. 8,223,803, titled “Programmable Time Division Multiplexed Switching,” the entire contents of each of which are hereby incorporated herein by reference in its entirety.

Each of the optical nodes14may be connected to each other by optical links18(hereinafter the “optical links18a-n”). Each of the optical links18may be a fiber optic cable and may be uninterrupted (i.e., having no break in the fiber optic cable) or may have one or more optical node14disposed thereon and positioned in between each of the optical nodes14. In the implementation shown, the optical network10includes four optical links18a-d, including a first optical link18abetween the head-end node14aand the first intermediate node14b, a second optical link18bbetween the first intermediate node14band the tail-end node14c, a third optical link18cbetween the second intermediate node14dand the tail-end node14c, and a fourth optical link18dbetween the head-end node14aand the second intermediate node14d; however, in other implementations, the optical network10may include more or less than four optical links18a-d.

An optical signal being transmitted within the optical network10from the head-end node14ato the tail-end node14cmay traverse one or more paths through the optical network10, shown inFIG.1as a working path22aand a protection path22b. The working path22amay be formed between the head-end node14aand the tail-end node14cthrough the first intermediate node14band includes the first optical link18aand the second optical link18bas components thereof. The protection path22bmay be formed between the head-end node14aand the tail-end node14cthrough the second intermediate node14dand includes the third optical link18cand the fourth optical link18das components thereof.

While the working path22aand the protection path22bare described as traversable by an optical signal being transmitted from the head-end node14ato the tail-end node14c, each of the working path22aand the protection path22bmay be bidirectional; that is, each of the working path22aand the protection path22bmay be traversable by an optical signal being transmitted from the tail-end node14cto the head-end node14a.

The working path22amay be described as a default path for the optical signal to traverse; that is, the working path22amay be a data path configured to carry data traffic while there is no failure or fault signal on the working path22a. The protection path22bmay be described as a backup path for the optical signal to traverse if the optical signal is unable to traverse the working path22a; that is, the protection path22bmay be a data path configured to carry data traffic while there is a failure or fault signal on the working path22a.

If there is a failure or fault signal on the working path22a, then the working path22amay be said to have failed. As described further below, if the working path22ais failed, then data traffic may be directed from the working path22ato the protection path22b. If the failure or fault signal is resolved, then the working path22amay be said to have recovered from failure. The working path22amay be revertive or non-revertive. Revertive means that data traffic is directed from the protection path22bto the working path22aafter the working path22arecovers from failure, while non-revertive means that data traffic is not directed from the protection path22bto the working path22aafter the working path22arecovers from failure.

In some implementations, a user may interact with a computer system26(e.g., via a user device (not shown)) that may be used to communicate with one or more of the optical nodes14and the transponder nodes16via a communication network30. Each element of the computer system26may be partially or completely network-based or cloud-based and may or may not be located in a single physical location. In some implementations, the communication network30is a Layer 3 communication network.

As further described below, in some implementations, the computer system26may comprise a processor42and a memory50having a data store58that may store data such as network element version information, firmware version information, sensor data, system data, metrics, logs, tracing, and the like in a raw format as well as transformed data that may be used for tasks such as reporting, visualization, analytics, signal routing, power loading operations and/or coordination, etc. The data store58may include structured data from relational databases, semi-structured data, unstructured data, time-series data, and binary data. The data store58may be a database, a remote accessible storage, or a distributed filesystem. In some implementations, the data store58may be a component of an enterprise network.

In some implementations, the computer system26is connected to one or more of the optical nodes14and the transponder nodes16via the communication network30. In this way, the computer system26may communicate with the optical nodes14and the transponder nodes16and may, via the communication network30, transmit to or receive data from the optical nodes14and the transponder nodes16. In other implementations, the computer system26may be integrated into each of the optical nodes14and the transponder nodes16and/or may communicate with one or more pluggable card within the optical nodes14and the transponder nodes16. In some implementations, the computer system26may be a remote network element.

The communication network30may permit bi-directional communication of information and/or data between the computer system26, the optical nodes14, and/or the transponder nodes16. The communication network30may interface with the computer system26, the optical nodes14, and/or the transponder nodes16in a variety of ways. For example, in some implementations, the communication network30may interface by optical and/or electronic interfaces, and/or may use a plurality of network topographies and/or protocols including, but not limited to, Ethernet, TCP/IP, circuit switched path, combinations thereof, and/or the like. The communication network30may utilize a variety of network protocols to permit bi-directional interface and/or communication of data and/or information between the computer system26, the optical nodes14, and/or the transponder nodes16.

The communication network30may be almost any type of network. For example, in some implementations, the communication network30may be a version of an Internet network (e.g., exist in a TCP/IP-based network). In one implementation, the communication network30is the Internet. It should be noted, however, that the communication network30may be almost any type of network and may be implemented as the World Wide Web (or Internet), a local area network (LAN), a wide area network (WAN), a metropolitan network, a wireless network, a cellular network, a Bluetooth network, a Global System for Mobile Communications (GSM) network, a code division multiple access (CDMA) network, a 3G network, a 4G network, an LTE network, a 5G network, a satellite network, a radio network, an optical network, a cable network, a public switched telephone network, an Ethernet network, combinations thereof, and/or the like.

If the communication network30is the Internet, a primary user interface of the computer system26may be delivered through a series of web pages or private internal web pages of a company or corporation, which may be written in hypertext markup language, JavaScript, or the like, and accessible by the user. It should be noted that the primary user interface of the computer system26may be another type of interface including, but not limited to, a Windows-based application, a tablet-based application, a mobile web interface, a VR-based application, an application running on a mobile device, and/or the like. In one implementation, the communication network30may be connected to the user device (not shown), the computer system26, the optical nodes14, and the transponder nodes16.

The number of devices and/or networks illustrated inFIG.1is provided for explanatory purposes. In practice, there may be additional devices and/or networks, fewer devices and/or networks, different devices and/or networks, or differently arranged devices and/or networks than are shown inFIG.1. Furthermore, two or more of the devices illustrated inFIG.1may be implemented within a single device, or a single device illustrated inFIG.1may be implemented as multiple, distributed devices. Additionally, or alternatively, one or more of the devices of the optical network10may perform one or more functions described as being performed by another one or more of the devices of the optical network10. Devices of the computer system26may interconnect via wired connections, wireless connections, or a combination thereof. For example, in one embodiment, the user device and the computer system26may be integrated into the same device; that is, the user device may perform functions and/or processes described as being performed by the computer system26, described below in more detail.

Referring now toFIG.2, shown therein is a diagrammatic view of an exemplary implementation of a computer system26constructed in accordance with the present disclosure. In some implementations, the computer system26may include, but is not limited to, implementations as a personal computer, a cellular telephone, a smart phone, a network-capable television set, a tablet, a laptop computer, a desktop computer, a network-capable handheld device, a server, a digital video recorder, a wearable network-capable device, a virtual reality/augmented reality device, and/or the like.

The computer system26may include one or more input device34(hereinafter the “input device34”), one or more output device38(hereinafter the “output device38”), one or more processor42(hereinafter the “processor42”), one or more communication device46(hereinafter the “communication device46”) capable of interfacing with the communication network30, one or more non-transitory processor-readable medium50(hereinafter the “memory50”) storing processor-executable code and/or one or more software application54including, for example, a web browser capable of accessing a website and/or communicating information and/or data over a wireless or wired network (e.g., the communication network30) and/or the like, and a data store58. The input device34, the output device38, the processor42, the communication device46, and the memory50may be connected via a path62such as a data bus that permits communication among the components of the computer system26.

The input device34may be capable of receiving information input from the user, another computer, and/or the processor42, and transmitting such information to other components of the computer system26and/or the communication network30. The input device34may include, but is not limited to, implementation as a keyboard, a touchscreen, a mouse, a trackball, a microphone, a camera, a fingerprint reader, an infrared port, a slide-out keyboard, a flip-out keyboard, a cell phone, a PDA, a remote control, a fax machine, a wearable communication device, a network interface, combinations thereof, and/or the like, for example.

The output device38may be capable of outputting information in a form perceivable by the user, another computer system, and/or the processor42. For example, implementations of the output device38may include, but are not limited to, a computer monitor, a screen, a touchscreen, a speaker, a website, a television set, a smart phone, a PDA, a cell phone, a fax machine, a printer, a laptop computer, a haptic feedback generator, a network interface, combinations thereof, and the like, for example. It is to be understood that in some exemplary embodiments, the input device34and the output device38may be implemented as a single device, such as, for example, a touchscreen of a computer, a tablet, or a smartphone. It is to be further understood that as used herein the term “user” is not limited to a human being, and may comprise a computer, a server, a website, a processor, a network interface, a user terminal, a virtual computer, combinations thereof, and/or the like, for example.

In some implementations, the processor42may comprise one or more processor42working together, or independently, to read and/or execute processor executable code and/or data, such as stored in the memory50. The processor42may be capable of creating, manipulating, retrieving, altering, and/or storing data structures into the memory50. Each element of the computer system26may be partially or completely network-based or cloud-based, and may or may not be located in a single physical location.

Exemplary implementations of the processor42may include, but are not limited to, a digital signal processor (DSP), a central processing unit (CPU), a field programmable gate array (FPGA), a microprocessor, a multi-core processor, an application specific integrated circuit (ASIC), combinations, thereof, and/or the like, for example. The processor42may be capable of communicating with the memory50via the path62(e.g., data bus). The processor42may be capable of communicating with the input device34and/or the output device38.

The processor42may be further capable of interfacing and/or communicating with the optical nodes14and the transponder nodes16via the communication network30using the communication device46. For example, the processor42may be capable of communicating via the communication network30by exchanging signals (e.g., analog, digital, optical, and/or the like) via one or more ports (e.g., physical or virtual ports) using a network protocol (e.g., TCP/IP) to provide information to the optical network10(i.e., the optical nodes14and the transponder nodes16) and receive information from the optical network10(i.e., the optical nodes14and the transponder nodes16).

The memory50may store a software application54that, when executed by the processor42, causes the computer system26to perform an action such as communicate with, or control, one or more component of the computer system26, the optical network10(e.g., the optical nodes14and the transponder nodes16), and/or the communication network30.

In some implementations, the memory50may be located in the same physical location as the computer system26, and/or one or more memory50may be located remotely from the computer system26. For example, the memory50may be located remotely from the computer system26and communicate with the processor42via the communication network30. Additionally, when more than one memory50is used, a first memory may be located in the same physical location as the processor42, and additional memory may be located in a location physically remote from the processor42. Additionally, the memory50may be implemented as a “cloud” non-transitory processor-readable storage memory (i.e., one or more of the memory50may be partially or completely based on or accessed using the communication network30).

In some implementations, the data store58may be a time-series database, a vector database, a relational database, or a non-relational database. Examples of such databases include DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, mySQL, PostgreSQL, MongoDB, Apache Cassandra, InfluxDB, Prometheus, Redis, Elasticsearch, TimescaleDB, and/or the like. It should be understood that these examples have been provided for the purposes of illustration only and should not be construed as limiting the presently disclosed inventive concepts. The data store58may be centralized or distributed across multiple systems.

Referring now toFIGS.3A-3B, shown therein are diagrammatic views of exemplary implementations of a terminal node14econstructed in accordance with the present disclosure. The terminal node14emay be an implementation of one of the terminal nodes14a,14cor the transponder nodes16. The terminal node14egenerally comprises one or more chassis64, such as chassis64shown inFIG.3Aor a first chassis64aand a second chassis64bshown inFIG.3B, containing one or more controller, such as a node controller66ashown inFIGS.3A and3Band a shelf controller66bshown inFIG.3B, for example, and one or more field-replaceable unit (FRU)70a-n(hereinafter the “FRUs70”), such as a line module70a(shown inFIG.4A) and an OPSM70b(shown inFIG.4B), for example.

As shown inFIGS.3A-3B, the node controller66amay comprise one or more processor78a(hereinafter the “node controller processor78a”), one or more non-transitory processor-readable medium82a(hereinafter the “node controller memory82a”), a network switch86a(hereinafter the “node controller network switch86a”), and packet forwarding circuitry, shown inFIGS.3A-3Bas field-programmable gate array90a(hereinafter the “node controller FPGA90a”). While the node controller processor78ais shown as being separate from the node controller FPGA90a, in some implementations, the node controller processor78amay be integrated into the node controller FPGA90a. The node controller processor78a, the node controller memory82a, the network switch86a, and the node controller FPGA90amay be connected via a path102asuch as a data bus that permits communication among the components of the node controller66a.

The network switch86amay comprise one or more of a first interface, shown as Nodal Control and Timing (NCT) interface94a(hereinafter the “node controller NCT interface94a”), a second interface, shown as FRU interface96a(hereinafter the “node controller FRU interface96a”) and a third interface, shown as auxiliary (AUX) interface98a(hereinafter the “node controller AUX interface98a”).

As further shown inFIG.3B, the shelf controller66bmay comprise one or more processor78b(hereinafter the “shelf controller processor78b”) (the node controller processor78aand the shelf controller processor78b, collectively the “controller processors78”), one or more non-transitory processor-readable medium82b(hereinafter the “shelf controller memory82b”) (the node controller memory82aand the shelf controller memory82b, collectively the “controller memories82”), a network switch86b(hereinafter the “shelf controller network switch86b”) (the node controller network switch86aand the shelf controller network switch86b, collectively the “controller network switches86”), and packet forwarding circuitry, shown inFIG.3Bas field-programmable gate array90b(hereinafter the “shelf controller FPGA90b”) (the node controller FPGA90aand the shelf controller FPGA90b, collectively the “controller FPGAs90”). While the shelf controller processor78bis shown as being separate from the shelf controller FPGA90b, in some implementations, the shelf controller processor78bmay be integrated into the shelf controller FPGA90b. The shelf controller processor78b, the shelf controller memory82b, the shelf controller network switch86b, and the shelf controller FPGA90bmay be connected via a path102bsuch as a data bus that permits communication among the components of the shelf controller66b.

The shelf controller network switch86bmay comprise one or more of a first interface, shown as NCT interface94b(hereinafter the “shelf controller NCT interface94b”) (the node controller NCT interface94aand the shelf controller NCT interface94b, collectively the “NCT interfaces94”), a second interface, shown as FRU interface96b(hereinafter the “shelf controller FRU interface96b”) (the node controller FRU interface96aand the shelf controller FRU interface96b, collectively the “FRU interfaces96”), and a third interface, shown as auxiliary (AUX) interface98b(hereinafter the “shelf controller AUX interface98b”) (the node controller AUX interface98aand the shelf controller AUX interface98b, collectively the “AUX interfaces98”).

As described in further detail below, the controller network switches86may be configured to communicate using communication networks, such as the communication network30shown inFIG.1, the first intra-node communication network144a(shown inFIG.5A), or the second intra-node communication network144b(shown inFIG.5A), via one or more of the NCT interfaces94, the FRU interfaces96, and the AUX interfaces98. In some implementations, the controller network switches86may be Layer 2/Layer 3 network switches.

As shown inFIG.3B, the NCT interfaces94may be configured to communicate with the NCT interfaces94of other controller modules66, such as when the terminal node14eis provided with both the node controller66aand the shelf controller66b. Further, where the terminal node14eis provided with more than one shelf controller66b, the shelf controller NCT interface94bof a first shelf controller66bmay communicate with the node controller NCT interface94aof the node controller66aand/or the shelf controller NCT interface94bof a second shelf controller66b, for example. As further shown inFIGS.3A-3B, the FRU interfaces96may be configured to communicate with one or more controller module interface100a-n, such as a line module controller module interface100a(hereinafter the “line module CM interface100a”) (shown inFIG.4A) and an OPSM controller module interface100b(hereinafter the “OPSM CM interface100b”) (shown inFIG.4B) (collectively the “CM interfaces100”). As further shown inFIGS.3A-3B, the AUX interfaces98may be configured to communicate with the AUX interfaces98of other optical nodes14and/or other transponder nodes16in the optical network10via the communication network30.

One or more of the controller memories82may store processor-executable instructions and/or one or more software application104(hereinafter the “controller application104”) and a data store106, for example. The controller application104when executed by the controller processors78may cause the controller processors78to perform one or more of the methods300(shown inFIG.7A),400(shown inFIG.7B) (or steps thereof) described herein.

In some implementations, the data store106may be a time-series database, a vector database, a relational database, or a non-relational database. Examples of such databases include DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, mySQL, PostgreSQL, MongoDB, Apache Cassandra, InfluxDB, Prometheus, Redis, Elasticsearch, TimescaleDB, and/or the like. It should be understood that these examples have been provided for the purposes of illustration only and should not be construed as limiting the presently disclosed inventive concepts. The data store106may be centralized or distributed across multiple systems.

Referring now toFIG.4A, shown therein is a diagrammatic view of an exemplary implementation of a line module70aconstructed in accordance with the present disclosure. As shown inFIG.4A, the line module70amay comprise one or more processor108a(hereinafter the “line module processor108a”), one or more non-transitory processor-readable medium110a(hereinafter the “line module memory110a”), and a network switch112a(hereinafter the “line module network switch112a”). The line module network switch112amay comprise an interface, shown inFIG.4Aas the line module CM interface100a. In some implementations, the line module network switch112ais a Layer 2 network switch; in other implementations, the line module network switch112ais a Layer 2/Layer 3 network switch.

As described in further detail below, the line module network switch112amay be configured to communicate using communication networks, such as the first intra-node communication network144a(shown inFIG.5A) or the second intra-node communication network144b(shown inFIG.5A), via the line module CM interface100a, for example. The line module processor108a, the line module memory110a, and the line module network switch112amay be connected via a path116asuch as a data bus that permits communication among the components of the line module70a.

The line module memory110amay store processor-executable instructions and/or one or more software application118(hereinafter the “line module software application118”) and a data store120, for example. The line module software application118when executed by the line module processor108amay cause the line module processor108ato perform one or more of the methods300(shown inFIG.7A),400(shown inFIG.7B) (or steps thereof) described herein.

In some implementations, the data store120may be a time-series database, a vector database, a relational database, or a non-relational database. Examples of such databases include DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, mySQL, PostgreSQL, MongoDB, Apache Cassandra, InfluxDB, Prometheus, Redis, Elasticsearch, TimescaleDB, and/or the like. It should be understood that these examples have been provided for the purposes of illustration only and should not be construed as limiting the presently disclosed inventive concepts. The data store120may be centralized or distributed across multiple systems.

As further shown inFIG.4A, the line module70amay further comprise a coherent transceiver122which may include circuitry such as a coherent receiver, a coherent transmitter, combinations thereof, and/or the like. As described herein, the coherent transceiver122may be configured to detect a fault in one of the working path22aand the protection path22band to send fault information156(shown inFIG.6A) related to the fault to the line module processor108a.

Referring now toFIG.4B, shown therein is a diagrammatic view of an exemplary implementation of an OPSM70bconstructed in accordance with the present disclosure. As shown inFIG.4B, the OPSM70bmay comprise one or more processor108b(hereinafter the “OPSM processor108b”) (the line module processor108aand the OPSM processor108b, collectively the “module processors108”), one or more non-transitory processor-readable medium110b(hereinafter the “OPSM memory110b”) (the line module memory110aand the OPSM memory110b, collectively the “module memories110”), a network switch112b(hereinafter the “OPSM network switch112b”) (the line module network switch112aand the OPSM network switch112b, collectively the “module network switches112”), an optical switch124, a first line port126a(hereinafter the “working line port126a”), a second line port126b(hereinafter the “protection line port126b”), and a system port128.

The OPSM network switch114bmay comprise an interface, shown inFIG.4Bas the OPSM CM interface100b. In some implementations, the OPSM network switch114bis a Layer 2 network switch.

As described in further detail below, the OPSM network switch112bmay be configured to communicate using communication networks, such as the first intra-node communication network144a(shown inFIG.5A) or the second intra-node communication network144b(shown inFIG.5A), via the OPSM CM interface100b, for example. The OPSM processor108b, the OPSM memory110b, the OPSM network switch112b, and the optical switch124may be connected via a path116bsuch as a data bus that permits communication among the components of the OPSM70b.

The OPSM memory110bmay store processor-executable instructions and/or one or more software application132(hereinafter the “OPSM software application132”) and a data store136, for example. The OPSM software application132when executed by the OPSM processor108bmay cause the OPSM processor108bto perform one or more of the methods300(shown inFIG.7A),400(shown inFIG.7B) (or steps thereof) described herein.

In some implementations, the data store136may be a time-series database, a vector database, a relational database, or a non-relational database. Examples of such databases include DB2®, Microsoft® Access, Microsoft® SQL Server, Oracle®, mySQL, PostgreSQL, MongoDB, Apache Cassandra, InfluxDB, Prometheus, Redis, Elasticsearch, TimescaleDB, and/or the like. It should be understood that these examples have been provided for the purposes of illustration only and should not be construed as limiting the presently disclosed inventive concepts. The data store136may be centralized or distributed across multiple systems.

The working line port126amay be in optical communication with a first optical link18e, which may be a component of a working path22cof the optical network10, such that working line port126amay transmit and receive first optical signals on the working path22c. The protection line port126bmay be in optical communication with a second optical link18f, which may be a component of a protection path22dof the optical network10, such that the protection line port126bmay transmit and receive second optical signals on the protection path22d. The optical switch124may be coupled to the working line port126ato transmit and receive the first optical signals from the working path22cand the protection line port126bto transmit and receive the second optical signals from the protection path22dfor selectively switching the optical signals (i.e., the first optical signals or the second optical signals) from the working line port126aand the protection line port126bto the system port128.

In some implementations, one or more of the controller processors78and the module processors108may comprise one or more processor working together, or independently, to read and/or execute processor executable code and/or data, such as stored in the controller memories82and the module memories110, respectively. The controller processors78and the module processors108may be capable of creating, manipulating, retrieving, altering, and/or storing data structures into the controller memories82and the module memories110, respectively. Exemplary implementations of the controller processors78and the module processors108may include, but are not limited to, a digital signal processor (DSP), a central processing unit (CPU), an FPGA, a microprocessor, a multi-core processor, an application specific integrated circuit (ASIC), a real-time processing unit (RPU), combinations thereof, and/or the like, for example.

The controller processors78and the module processors108may be further capable of interfacing and/or communicating via the communication network30, for example, using the controller network switches86and the module network switches112, respectively. For example, the controller processors78and the module processors108may be capable of communicating via the communication network30, for example, by exchanging signals (e.g., analog, digital, optical, and/or the like) via one or more interfaces (e.g., the AUX interfaces98or the controller interfaces100) using a network protocol (e.g., TCP/IP) to communicate information.

In some implementations, the controller memories82and the module memories110may be located in the same physical location as the controller modules66and the FRUs70, respectively, and/or one or more of the controller memories82and the module memories110may be located remotely from the controller modules66and the FRUs70, respectively. For example, one or more of the controller memories82and the module memories110may be located remotely from the controller modules66and the FRUs70, respectively, and communicate with the controller processors78and the module processors108, respectively, via the first intra-node communication network144a(shown inFIG.5A) or the second intra-node communication network144b(shown inFIG.5A), for example. Additionally, when more than one memory is used for one or more of the controller memories82and the module memories110, a first memory may be located in the same physical location as the controller processors78and the module processors108, and additional memory may be located in a location physically remote from the controller processors78and the module processors108. Additionally, one or more of the controller memories82and the module memories110may be implemented as a “cloud” non-transitory processor-readable medium (i.e., one or more of the controller memories82and the module memories110may be partially or completely based on or accessed using the first intra-node communication network144a(shown inFIG.5A) or the second intra-node communication network144b(shown inFIG.5A), for example).

Referring now toFIG.5A, shown therein are a diagrammatic view of an exemplary implementation of the optical network10comprising a head-end node14fand a tail-end node14g. Each of the head-end node14fand the tail-end node14gmay be an implementation of one of the terminal nodes14a,14cor the transponder nodes16shown inFIG.1. The head-end node14fis shown as comprising a first node controller66a-1and a line module70a, while the tail-end node14gis shown as comprising a second node controller66a-2and an OPSM70b. However, one or more of the head-end node14fand the tail-end node14gmay further comprise one or more shelf controller66b, as described above. Further, the head-end node14fmay further comprise an additional OPSM70band the tail-end node14gmay further comprise an additional line module70a. Finally, while only the head-end node14fand the tail-end node14gare shown, it should be understood that the optical network10may further comprise additional nodes14not shown inFIG.5A.

The first node controller66a-1comprises a first node controller processor78a-1, a first node controller memory82a-1storing a first controller application104-1and a first data store106-1, a first node controller FPGA90a-1, and a first network switch86a-1comprising a first node controller NCT interface94a-1, a first node controller CM interface96a-1, and a first node controller AUX interface98a-1.

The second node controller66a-2comprises a second node controller processor78a-2, a second node controller memory82a-2storing a second controller application104-2and a second data store106-2, a second node controller FPGA90a-2, and a second network switch86a-2comprising a second node controller NCT interface94a-2, a second node controller CM interface96a-2, and a second node controller AUX interface98a-2.

As shown inFIG.5A, a fast path140comprising a plurality of fast path segments140a-nmay be formed between the line module70aof the head-end node14fand the OPSM70bof the tail-end node14g. The fast path140is described herein using the elements of the optical network10shown inFIG.5A; it should be noted, however, that the fast path140may be formed using other network elements.

The fast path140may extend from: (i) the line module70aof the head-end node14fto the first node controller66a-1of the head-end node14f(via a first fast path segment140a); (ii) the first node controller66a-1to the second node controller66a-2of the tail-end node14g(via a second fast path segment140b); and (iii) the second node controller66a-2to the OPSM70bof the tail-end node14g(via a third fast path segment140c).

The fast path140may utilize hardware elements such as the first node controller FPGA90a-1and the second node controller FPGA90a-2to automatically forward packets through the optical network10from the source (i.e., the line module70ain this implementation) to the destination (i.e., the OPSM70bin this implementation) without using software-based forwarding techniques that are typically used in these types of inter-domain packet forwarding scenarios.

A plurality of flow identifiers (Flow IDs)192(shown inFIG.6B) may be allocated for each of the fast path segments140a-n. The Flow IDs192may be used by the first node controller FPGA90a-1and the second node controller FPGA90a-2to identify a particular fast path segment140a-cand update a packet header152(shown inFIG.6A) of a fault packet148(shown inFIG.6A) accordingly. In some implementations, the Flow IDs192are 8 bits (i.e., 1 byte) in length. In other implementations, the Flow IDs192are 16 bits (i.e., 2 bytes) in length. However, it should be understood that the Flow IDs192may have a length other than 8 or 16 bits.

Each of the fast path segments140a-nmay utilize a separate communication network for the transmission of fault packets148. For example, the second fast path segment140bmay utilize the communication network30shown inFIG.1. Further, the first fast path segment140aand the third fast path segment140cmay utilize a first intra-node communication network144aand a second intra-node communication network144b, respectively. In some implementations, the first intra-node communication network144a, the communication network30, and the second intra-node communication network144bare a first virtual local area network (VLAN), a second VLAN, and a third VLAN, respectively. In such implementations, each of the VLANs may have a unique VLAN identifier. In some implementations, the first intra-node communication network144ais a Layer 2 communication network. In other implementations, the first intra-node communication network144ais a Layer 3 communication network. In some implementations, the second intra-node communication network144bis a Layer 2 communication network.

Referring now toFIG.5B, shown therein are a diagrammatic view of an exemplary implementation of the optical network10comprising a hybrid node14hcomprising both the line module70aand the OPSM70b. The hybrid node14hmay be an implementation of one of the terminal nodes14a,14cor the transponder nodes16shown inFIG.1. While only the hybrid node14his shown, it should be understood that the optical network10may further comprise additional nodes14not shown inFIG.5B.

As shown inFIG.5B, the fast path140may be formed between the line module70aand the OPSM70bof the hybrid node14h. Accordingly, the fast path140may extend from: (i) the line module70ato the node controller66a(via the first fast path segment140a); and (ii) the node controller66ato the OPSM70b(via the third fast path segment140c). In some implementations, the first fast path segment140autilizes the first intra-node communication network144aand the third fast path segment140cutilizes the second intra-node communication network144b.

Referring now toFIG.6A, shown therein is a diagrammatic view of an exemplary implementation of a fault packet148constructed in accordance with the present disclosure. As shown inFIG.6A, the fault packet148generally comprises a packet header152and fault information156related to a fault detected by the coherent transceiver122. In some implementations, the fault packet148further comprises a source node identifier160, a Hash-based Message Authentication Code (HMAC)164, and an Ethernet Frame Check Sequence (FCS)168. The packet header152may comprise an Ethernet header172, an IP header176, and a SHIM header180. In some implementations, the total length of the fault packet148is less than 1,500 bytes. In some implementations, the packet header152includes a sequence number and a sequence reset time encoded into the packet header152by the line module processor108a.

The sequence number may be a positive integer that is incremented sequentially up from a minimum integer (e.g., a 1-byte integer) to a maximum integer (e.g., a 4-byte integer) as new fault packets152are generated. The line module70amay store a last used sequence number in the data store120in the line module memory110a. When the sequence number reaches the maximum integer, the line module processor108amay be programmed to cause the sequence number to reset to the minimum integer when the next fault packet152is generated. The sequence number may also be reset to the minimum integer in other scenarios such as when the line module70areboots, the first node controller66a-1reboots, or there is a reconfiguration of the line module70a, for instance. The sequence reset time is a timestamp of when the sequence number was last reset to the minimum integer.

The Ethernet header172generally includes a Source MAC Address, a Destination MAC Address, and a VLAN identifier. In some implementations, the Ethernet header172is 18 bytes in length. The IP header176may be one of an IPv4 header176a(shown inFIG.6C) and an IPv6 header176b(shown inFIG.6D). In some implementations, the IPv4 header176ais 20 bytes in length and the IPv6 header176bis 40 bytes in length. In some implementations, the SHIM header180is 4 bytes in length. Further, in some implementations, the source node identifier160is 20 bytes in length, the fault information156is 77 bytes in length, the HMAC164is 64 bytes in length, and the FCS168is 4 bytes in length.

Referring now toFIG.6B, shown therein is a diagrammatic view of an exemplary implementation of the SHIM header180constructed in accordance with the present disclosure. As shown inFIG.6B, the SHIM header180may include a header type184, a reserved portion188, and a Flow ID192. In some implementations where the SHIM header180is 4 bytes in length, the header type184is 8 bits (i.e., 1 byte) in length, the reserved portion188is 8 bits (i.e., 1 byte) in length, and the Flow ID192is 16 bits (i.e., 2 bytes) in length. However, in some such implementations, only a lower 8 bits (i.e., 1 byte) of the Flow ID192is used, and the upper 8 bits (i.e., 1 byte) is set to 0x00. For the purposes of the present disclosure, the header type184of the SHIM header180may be set to 0x00.

Referring now toFIG.6C, shown therein is a diagrammatic view of an exemplary implementation of the IPv4 header176aconstructed in accordance with the present disclosure. As shown inFIG.6C, the IPv4 header176amay include an IP version196, a header length200, a Type of Service (TOS)204, a total length208, an identification212, a reserved portion216, a Don't Fragment (DF) flag220, a More Fragments (MF) flag224, a fragment offset228, a Time to Live (TTL)232, a protocol236, a header checksum240, a Source IP Address244, and a Destination IP Address248. In some implementations, the IP version196is 4 bits in length, the header length200is 4 bits in length, the TOS204is 8 bits (i.e., 1 byte) in length, the total length208is 16 bits (i.e., 2 bytes) in length, the identification212is 16 bits (i.e., 2 bytes) in length, the reserved portion216is 1 bit in length and is set to 0x0, the DF flag220is 1 bit in length, the MF flag224is 1 bit in length, the fragment offset228may be 13 bits in length, the TTL232is 8 bits (i.e., 1 byte) in length, the protocol236is 8 bits (i.e., 1 byte) in length, and the header checksum240is 16 bits (i.e., 2 bytes) in length. In some implementations, the Source IP Address244of the IPv4 header176ais 32 bits (i.e., 4 bytes) in length and the Destination IP Address248of the IPv4 header176ais 32 bits (i.e., 4 bytes) in length. In some implementations, the protocol236is set as241(i.e., 0xF1).

Referring now toFIG.6D, shown therein is a diagrammatic view of an exemplary implementation of the IPv6 header176bconstructed in accordance with the present disclosure. As shown inFIG.6D, the IPv6 header176bmay include the IP version196, a traffic class252, a flow label256, a payload length260, a next header264, a hop limit268, the Source IP Address244, and the Destination IP Address248. In some implementations, the IP version196is 4 bits in length, the traffic class252is 8 bits (i.e., 1 byte) in length, the flow label256is 20 bits in length, the payload length260is 16 bits (i.e., 2 bytes) in length, the next header264is 8 bits (i.e., 1 byte) in length, and the hop limit268is 8 bits (i.e., 1 byte) in length. In some implementations, the Source IP Address244of the IPv6 header176bis 128 bits (i.e., 16 bytes) in length and the Destination IP Address248of the IPv6 header176bis 128 bits (i.e., 16 bytes) in length.

Referring now toFIG.7A, shown therein is a diagrammatic view of an exemplary method300illustrating how the fault packet148is generated, forwarded, and processed using the fast path140between the head-end node14f, the tail-end node14g, and one or more intermediate node14n(hereinafter the “intermediate node14n”) disposed therebetween. The intermediate node14nmay be constructed similarly to the head-end node14for the tail-end node14gand generally comprises an intermediate node controller66a-N and an intermediate network switch (not shown).

Initially, the head-end node14fand the tail-end node14gmay exchange a secret key to be matched against a hash code sent by the head-end node14fto the tail-end node14gfor HMAC164validation.

In step304, the line module70amay store first packet forwarding information in the data store120. The first packet forwarding information may identify the first node controller66a-1as a first destination for a fault packet148on the fast path140. In some implementations, the first packet forwarding information includes a first Flow ID192.

In step308, the second node controller66a-2of the tail-end node14gmay send second packet forwarding information to the second network switch86a-2and over the communication network30. The second packet forwarding information may identify the second node controller66a-2as a second destination for the fault packet148on the fast path140. In some implementations, the second packet forwarding information includes the second Flow ID192. As described in further detail below, the second packet forwarding information may include: (i) a public (i.e., reachable over the communication network30) IP address of the tail-end node14g(ii) a private (i.e., internal to the optical network10) IP address of the OPSM70bof the tail-end node14g; (iii) information indicative of an encapsulation protocol to be used, such as Generic Routing Encapsulation (GRE) or Simple IP (SIP), for example; and (iv) a second Flow ID192, for example.

In step312, the intermediate node controller66a-N may receive the second packet forwarding information at the intermediate network switch (not shown).

In step316, the intermediate node controller66a-N may send the second packet forwarding information to the intermediate network switch (not shown) and over the communication network30to the first node controller66a-1.

In step320, the first node controller66a-1may receive the second packet forwarding information at the first network switch86a-1. In some implementations where the intermediate node14nis not disposed between the head-end node14fand the tail-end node14g, the second packet forwarding information may be sent by the second node controller66a-2and received directly by the first node controller66a-1.

In step324a, the first node controller66a-1may configure the first node controller FPGA90a-1so that a first lookup table (LUT) includes in a first LUT entry a first key-value pair having the second packet forwarding information as a first value and at least a portion of the first packet forwarding information (e.g., the first Flow ID192) as a first key.

The construction of an LUT entry including packet forwarding information (e.g., the second packet forwarding information or the third packet forwarding information to be described below) is illustrated below in Table 1. In some implementations, the LUT comprises 256 LUT entries. In some implementations, the size of each of the one or more LUT entry is 52 bytes.

In step324b, the second node controller66a-2may configure the second node controller FPGA90a-2so that a second LUT includes in a second LUT entry a second key-value pair having third packet forwarding information as a second value and at least a portion of the second packet forwarding information (e.g., the second Flow ID192) as a second key. The third packet forwarding information may identify the OPSM70bas a third destination for the fault packet148on the fast path140.

In step328, the line module70amay receive fault information156from, for example, the coherent transceiver122. In response, the line module70amay generate a fault packet148comprising a packet header152and the fault information156. The packet header152may include the first packet forwarding information, which may include the first Flow ID192.

In step328, the Ethernet header172of the packet header152may be initially set as follows: the Source MAC Address may be set as the MAC Address of the line module70a; the Destination MAC Address may be set as the MAC Address of the first node controller FPGA90a-1; and the VLAN identifier may be set as the VLAN identifier of the first intra-node communication network144a. In implementations where the head-end node14fincludes the shelf controller66b, the Destination MAC Address may be set as the MAC Address of the default gateway of the shelf controller network switch86b. Further, the 802.1q priority may be set to 0xE.

In step328, the IP header176of the packet header152may be the IPv4 header176afor transmission over the first intra-node communication network144a, and the IPv4 header176aof the packet header152may be initially set as follows: The Source IP Address244may be set as the IP address of the line module70a; the Destination IP Address248may be set as the IP address of the first node controller FPGA90a-1; the TTL232may be set as 2 (i.e., 0x02); and the TOS204may be set as the highest precedence or priority (i.e., 0xE0 or 0x07). The HMAC164may be generated for the fault information156using a hash function such as a Secure Hash Algorithm512(SHA-512), thereby producing a hash code which is 64 bytes in length.

In step332, the line module70amay send the fault packet148to the line module CM interface100aand over the first intra-node communication network144ato the first node controller66a-1identified by the first packet forwarding information.

In step336, the first node controller66a-1may receive the fault packet148at the first network switch86a-1and forward the fault packet148to the first node controller FPGA90a-1. In some implementations, one or more of the first network switch86a-1and the first node controller FPGA90a-1may be configured to drop the fault packet148if the first node controller66a-1is in a standby mode. Further, if the Flow ID192has a length is greater than a currently supported Flow ID192length supported by the first node controller FPGA90a-1, the first node controller FPGA90a-1may discard the fault packet148.

In step340, the first node controller FPGA90a-1may retrieve the second packet forwarding information from the first LUT using at least a portion of the first packet forwarding information (i.e., the first Flow ID192) as the first key. In some implementations, the first node controller FPGA90a-1may extract the first Flow ID192from the SHIM header180of the fault packet148, look up the first Flow ID192to determine a pointer to the first LUT entry.

Further, the first node controller FPGA90a-1may update the packet header152of the fault packet148with the second packet forwarding information. The IP header176of the updated packet header152may be either of the IPv4 header176aand the IPv6 header176bfor transmission over the communication network30. In implementations where the updated packet header152includes the IPv4 header176a, the first node controller FPGA90a-1may recalculate the header checksum240and the FCS168and insert the recalculated header checksum240into the IPv4 header176aof the updated packet header152and the recalculated FCS168into the Ethernet header172of the updated packet header152.

The construction of the Ethernet header172in the updated packet header152, such as in step340and step360to be described below, is illustrated below in Table 2.

Accordingly, in step340, the Ethernet header172in the updated packet header152may be set as follows: the Source MAC Address may be set as the MAC Address of the first node controller66a-1; the Destination MAC Address may be set as the MAC Address of the intermediate node controller66a-N (or the second node controller66a-2if the intermediate node14nis not disposed between the head-end node14fand the tail-end node14g); and the VLAN identifier may be set as the VLAN identifier of the first network switch86a-1.

Where the IPv4 header176ais used for transmission over the communication network30, the construction of the updated IPv4 header176a, such as in step340and step360to be described below, is illustrated below in Table 3.

Accordingly, where the IPv4 header176ais used for transmission over the communication network30, in step340, the IPv4 header176aof the updated packet header152may be set as follows: the IP version196may be set as 4 (i.e., 0x04); the Source IP Address244may be set as the IP address of the first network switch86a-1; the Destination IP Address248may be set as the IP address of the second network switch86a-2; and the TTL232may be set as the number of nodes14in the optical network10minus one (i.e., the number of hops).

Where the IPv6 header176bis used for transmission over the communication network30, the construction of the IPv6 header176bto replace the IPv4 header176aof the fault packet148, such as in step340, is illustrated below in Table 4.

Accordingly, where the IPv6 header176bis used for transmission over the communication network30, in step340, the IPv6 header176bof the updated packet header152may be set as follows: the IP version196may be set as 6 (i.e., 0x06); the Source IP Address244may be set as the IP address of the first network switch86a-1; the Destination IP Address248may be set as the IP address of the second network switch86a-2; and the hop limit268may be set as the number of nodes14in the optical network10minus one (i.e., the number of hops in the optical network10).

The construction of the SHIM header180in the updated packet header152, such as in step340and step360to be described below, is illustrated below in Table 5.

Accordingly, in step340, the Flow ID192of the updated packet header152may be set as the Flow ID192of the tail-end node14g.

In step344, the first node controller66a-1may send the fault packet148to the first network switch86a-1and over the communication network30to the intermediate node controller66a-N (i.e., toward the tail-end node14gidentified by the second packet forwarding information).

In step348, the intermediate node controller66a-N may receive the fault packet148at the intermediate network switch (not shown). Quality of Service (QoS) handling at the intermediate node14nmay be based on packet filtering rules that match the protocol236(i.e., filtering out packets that do not have the protocol236set to 241 or 0xF1). Further, in some implementations, an ingress policer may protect against packet rate or burst anomalies.

In step352, the intermediate node controller66a-N may forward the fault packet148to the intermediate network switch (not shown) and over the communication network30to the second node controller66a-2.

In step356, the second node controller66a-2may receive the fault packet148at the second network switch86a-2and forward the fault packet148to the second node controller FPGA90a-2. In some implementations where the intermediate node14nis not disposed between the head-end node14fand the tail-end node14g, the fault packet148may be sent by the first node controller66a-1and received directly by the second node controller66a-2. Further, if the Flow ID192has a length is greater than a currently supported Flow ID192length supported by the first node controller FPGA90a-1, the first node controller FPGA90a-1may discard the fault packet148.

In step360, the second node controller FPGA90a-2may retrieve the third packet forwarding information from the second LUT using at least a portion of the second packet forwarding information (i.e., the second Flow ID192) as the second key. Further, the second node controller FPGA90a-2may update the packet header152of the fault packet148with the third packet forwarding information. The IP header176of the updated packet header152may be the IPv4 header176afor transmission over the second intra-node communication network144b.

Further, in step360, the Ethernet header172in the updated packet header152may be set as follows: the Source MAC Address may be set as the MAC Address of the second node controller66a-2; the Destination MAC Address may be set as the MAC Address of the OPSM70b; and the VLAN identifier may be set as the VLAN identifier of the second network switch86a-2.

Where the IPv6 header176bis used for transmission over the communication network30, the construction of the IPv4 header176ato replace the IPv6 header176bof the fault packet148, such as in step360, is illustrated below in Table 6.

Accordingly, where the IPv6 header176bis used for transmission over the communication network30, in step360, the IPv4 header176aof the updated packet header152may be set as follows: the IP version196may be set as 4 (i.e., 0x04); the Source IP Address244may be set as the IP address of the second node controller66a-2; the Destination IP Address248may be set as the IP address of the OPSM70b; and the TTL232may be set as 1 (i.e., 0x01).

In step364, the second node controller66a-2may send the fault packet148to the second network switch86a-2and over the second intra-node communication network144bto the OPSM70bidentified by the third packet forwarding information.

In step368, the OPSM70bmay receive the fault packet148at the OPSM CM interface100b. The OPSM70bmay generate a hash code against the fault information156using the secret key exchanged between the head-end node14fand the tail-end node14gand determine whether the generated hash code matches the received hash code in the packet header152of the fault packet148. If the generated hash code does not match the received hash code, then the fault packet148may be dropped.

In step368, the OPSM70bmay determine if the fault information156contained in the fault packet148is new fault information156by comparing the sequence number and the sequence reset time in the packet header152to a stored sequence number and a stored sequence reset time stored in the OPSM memory110b. If the sequence number in the packet header152is greater than the stored sequence number and the sequence reset time in the packet header152is equal to the stored sequence reset time, the fault information156is determined to be new fault information156. If the fault information156is determined to be new fault information156, the OPSM processor108bmay be programmed to replace the stored sequence number with the sequence number in the packet header152and the stored sequence reset time with the sequence reset time in the packet header152. In some embodiments, the stored sequence number and the stored sequence reset time may be stored in the OPSM data store136in the OPSM memory110b.

In step372, the OPSM70bmay switch the optical switch124based at least in part on the fault information156.

Referring now toFIG.7B, shown therein is a diagrammatic view of an exemplary method400illustrating how the fault packet148is generated, forwarded, and processed using the fast path140within the hybrid node14h.

In step404, the line module70amay store first packet forwarding information in the data store120. The first packet forwarding information may identify the node controller66aas a first destination for a fault packet148on the fast path140. In some implementations, the first packet forwarding information includes a first Flow ID192.

In step408, the node controller66amay configure the node controller FPGA90aso that an LUT includes in an LUT entry a key-value pair having the second packet forwarding information as a first value and at least a portion of the first packet forwarding information (e.g., the first Flow ID192) as a key.

In step412, the line module70amay receive fault information156from, for example, the coherent transceiver122. In response, the line module70amay generate a fault packet148comprising a packet header152and the fault information156. The packet header152may include the first packet forwarding information, which may include the first Flow ID192. The IP header176of the packet header152may be the IPv4 header176afor transmission over the first intra-node communication network144a.

The Ethernet header172of the packet header152may be initially set as follows: the Source MAC Address may be set as the MAC Address of the line module70a; the Destination MAC Address may be set as the MAC Address of the node controller FPGA90a; and the VLAN identifier may be set as the VLAN identifier of the first intra-node communication network144a. In implementations where the hybrid node14hincludes the shelf controller66b, the Destination MAC Address may be set as the MAC Address of the default gateway of the shelf controller network switch86b.

In step416, the line module70amay send the fault packet148to the line module CM interface100aand over the first intra-node communication network144ato the node controller66aidentified by the first packet forwarding information.

In step420, the node controller66amay receive the fault packet148at the network switch86aand forward the fault packet148to the node controller FPGA90a.

In step424, the node controller FPGA90amay retrieve the second packet forwarding information from the LUT using at least a portion of the first packet forwarding information (i.e., the first Flow ID192) as the key. Further, the node controller FPGA90amay update the packet header152of the fault packet148with the second packet forwarding information. The IP header176of the updated packet header152may be the IPv4 header176afor transmission over the second intra-node communication network144b. Further, the node controller FPGA90amay recalculate the header checksum240and the FCS168and insert the recalculated header checksum240into the IPv4 header176aof the updated packet header152and the recalculated FCS168into the Ethernet header172of the updated packet header152.

In step428, the node controller66amay send the fault packet148to the network switch86aand over the second intra-node communication network144bto the OPSM70bidentified by the second packet forwarding information.

In step432, the OPSM70bmay receive the fault packet148at the OPSM CM interface100b. The OPSM70bmay determine if the fault information156contained in the fault packet148is new fault information156by comparing the sequence number and the sequence reset time in the packet header152to a stored sequence number and a stored sequence reset time stored in the OPSM memory110b. If the sequence number in the packet header152is greater than the stored sequence number and the sequence reset time in the packet header152is equal to the stored sequence reset time, the fault information156is determined to be new fault information156. If the fault information156is determined to be new fault information156, the OPSM processor108bmay be programmed to replace the stored sequence number with the sequence number in the packet header152and the stored sequence reset time with the sequence reset time in the packet header152. In some embodiments, the stored sequence number and the stored sequence reset time may be stored in the OPSM data store136in the OPSM memory110b.

In step436, the OPSM70bmay switch the optical switch124based at least in part on the fault information156.

In some implementations, the Destination MAC Address stored in the LUT entries may be updated from time to time by the node controller processor78aor the network switch86abased on a change in IP routing information or an Address Resolution Protocol (ARP) cache. Accordingly, the node controller processor78aor the network switch86amay monitor for changes in the IP routing information or the ARP cache.

Non-Limiting Illustrative Embodiments of the Inventive Concept(s)

Illustrative embodiment 1. A head-end node, comprising: a node controller; and a line module comprising a processor and a non-transitory processor-readable medium storing processor-executable instructions that when executed by the processor cause the processor to: receive fault information related to a fault; generate a fault packet comprising a packet header and the fault information, the packet header including first packet forwarding information identifying the node controller as a first destination; and send the fault packet to the node controller identified by the first packet forwarding information; and wherein the node controller comprises packet forwarding circuitry configured to: retrieve second packet forwarding information from a table using at least a portion of the first packet forwarding information as a key, the second packet forwarding information identifying a tail-end node as a second destination; update the packet header of the fault packet with the second packet forwarding information; and send the fault packet toward the tail-end node identified by the second packet forwarding information.

Illustrative embodiment 2. The head-end node of illustrative embodiment 1, wherein the line module further comprises a network switch configured to communicate using a communication network, and sending the fault packet to the node controller is further defined as sending, via the network switch using the communication network, the fault packet to the node controller identified by the first packet forwarding information.

Illustrative embodiment 3. The head-end node of illustrative embodiment 2, wherein the network switch is a first network switch, the node controller comprises a second network switch configured to communicate using the communication network, and the packet forwarding circuitry is further configured to, prior to retrieving the second packet forwarding information from the table, receive, via the second network switch using the communication network, the fault packet.

Illustrative embodiment 4. The head-end node of illustrative embodiment 2, wherein the communication network is a first communication network, the network switch is a first network switch, the node controller comprises a second network switch configured to communicate using a second communication network, and sending the fault packet to the tail-end node is further defined as sending, via the second network switch using the second communication network, the fault packet toward the tail-end node identified by the second packet forwarding information.

Illustrative embodiment 5. The head-end node of illustrative embodiment 4, wherein the first communication network is a first virtual local area network, and the second communication network is a second virtual local area network.

Illustrative embodiment 6. The head-end node of illustrative embodiment 1, wherein the processor is a first processor, the non-transitory processor-readable medium is a first non-transitory processor-readable medium, the processor-executable instructions are first processor-executable instructions, and the node controller further comprises a second processor and a second non-transitory processor-readable medium storing second processor-executable instructions that when executed by the second processor cause the second processor to, prior to the first processor receiving the fault information: receive the second packet forwarding information; and configure the packet forwarding circuitry so that the table includes a key-value pair having the second packet forwarding information as a value and at least a portion of the first packet forwarding information as the key.

Illustrative embodiment 7. The head-end node of illustrative embodiment 1, wherein the processor-executable instructions when executed by the processor further cause the processor to, prior to receiving the fault information, store the first packet forwarding information.

Illustrative embodiment 8. A tail-end node, comprising: an optical protection switching module comprising a first line port connected to a working path, a second line port connected to a protection path, a system port, and an optical switch coupled to the first line port to receive first optical signals from the working path and the second line port to receive second optical signals from the protection path for selectively switching optical signals from the first line port or the second line port to the system port; and a node controller comprising packet forwarding circuitry configured to: receive a fault packet comprising a packet header and fault information related to a fault, the packet header including first packet forwarding information identifying the tail-end node as a first destination; retrieve second packet forwarding information from a table using at least a portion of the first packet forwarding information as a key, the second packet forwarding information identifying the optical protection switching module as a second destination; update the packet header of the fault packet with the second packet forwarding information; and send the fault packet to the optical protection switching module identified by the second packet forwarding information; and wherein the optical protection switching module further comprises a processor and a non-transitory processor-readable medium storing processor-executable instructions that when executed by the processor cause the processor to switch the optical switch based on the fault information.

Illustrative embodiment 9. The tail-end node of illustrative embodiment 8, wherein the node controller further comprises a network switch configured to communicate using a communication network, and receiving the fault packet is further defined as receiving, via the network switch communicating using the communication network, the fault packet comprising the packet header and the fault information related to the fault.

Illustrative embodiment 10. The tail-end node of illustrative embodiment 9, wherein the communication network is a first communication network, the network switch is further configured to communicate using a second communication network, and sending the fault packet to the optical protection switching module is further defined as sending, via the network switch using the second communication network, the fault packet to the optical protection switching module identified by the second packet forwarding information.

Illustrative embodiment 11. The tail-end node of illustrative embodiment 10, wherein the network switch is a first network switch, the optical protection switching module further comprises a second network switch configured to communicate using the second communication network, and the processor-executable instructions when executed by the processor may further cause the processor to, prior to switching the optical switch, receive, via the second network switch using the second communication network, the fault packet.

Illustrative embodiment 12. The tail-end node of illustrative embodiment 10, wherein the first communication network is a first virtual local area network, and the second communication network is a second virtual local area network.

Illustrative embodiment 13. The tail-end node of illustrative embodiment 8, wherein the processor is a first processor, the non-transitory processor-readable medium is a first non-transitory processor-readable medium, the processor-executable instructions are first processor-executable instructions, and the node controller further comprises a second processor and a second non-transitory processor-readable medium storing second processor-executable instructions that when executed by the second processor cause the second processor to, prior to the packet forwarding circuitry receiving the fault packet: send the first packet forwarding information to a head-end node; and configure the packet forwarding circuitry so that the table includes a key-value pair having the second packet forwarding information as a value and at least a portion of the first packet forwarding information as the key.

Illustrative embodiment 14. A hybrid node, comprising: a node controller; an optical protection switching module comprising a first line port connected to a working path, a second line port connected to a protection path, a system port, and an optical switch coupled to the first line port to receive first optical signals from the working path and the second line port to receive second optical signals from the protection path for selectively switching optical signals from the first line port or the second line port to the system port; and a line module comprising a first processor and a first non-transitory processor-readable medium storing first processor-executable instructions that when executed by the first processor cause the first processor to: receive fault information related to a fault; generate a fault packet comprising a packet header and the fault information, the packet header including first packet forwarding information identifying the node controller as a first destination; and send the fault packet to the node controller identified by the first packet forwarding information; wherein the node controller comprises packet forwarding circuitry configured to: retrieve second packet forwarding information from a table using at least a portion of the first packet forwarding information as a key, the second packet forwarding information identifying the optical protection switching module as a second destination; update the packet header of the fault packet with the second packet forwarding information; and send the fault packet to the optical protection switching module identified by the second packet forwarding information; and wherein the optical protection switching module further comprises a second processor and a second non-transitory processor-readable medium storing second processor-executable instructions that when executed by the second processor cause the second processor to switch the optical switch based on the fault information.

Illustrative embodiment 15. The hybrid node of illustrative embodiment 14, wherein the line module further comprises a network switch configured to communicate using a communication network, and sending the fault packet to the node controller is further defined as sending, via the network switch using the communication network, the fault packet to the node controller identified by the first packet forwarding information.

Illustrative embodiment 16. The hybrid node of illustrative embodiment 15, wherein the network switch is a first network switch, the node controller comprises a second network switch configured to communicate using the communication network, and the packet forwarding circuitry is further configured to, prior to retrieving the second packet forwarding information from the table, receive, via the second network switch using the communication network, the fault packet.

Illustrative embodiment 17. The hybrid node of illustrative embodiment 16, wherein sending the fault packet to the optical protection switching module is further defined as sending, via the second network switch using the communication network, the fault packet to the optical protection switching module identified by the second packet forwarding information.

Illustrative embodiment 18. The hybrid node of illustrative embodiment 17, wherein the optical protection switching module further comprises a third network switch configured to communicate using the communication network, and the second processor-executable instructions when executed by the second processor may further cause the second processor to, prior to switching the optical switch, receive, via the third network switch using the communication network, the fault packet.

Illustrative embodiment 19. The hybrid node of illustrative embodiment 18, wherein the communication network is a virtual local area network.

Illustrative embodiment 20. The hybrid node of illustrative embodiment 14, wherein the node controller further comprises a third processor and a third non-transitory processor-readable medium storing third processor-executable instructions that when executed by the third processor cause the third processor to, prior to the packet forwarding circuitry retrieving the second packet forwarding information, configure the packet forwarding circuitry so that the table includes a key-value pair having the second packet forwarding information as a value and at least a portion of the first packet forwarding information as the key.

Illustrative embodiment 21. The hybrid node of illustrative embodiment 14, wherein the first processor-executable instructions when executed by the first processor further cause the first processor to, prior to receiving the fault signal, store the first packet forwarding information.

Illustrative embodiment 22. An optical network, comprising: a tail-end node; and a head-end node, comprising: a first node controller; and a line module comprising a first processor and a first non-transitory processor-readable medium storing first processor-executable instructions that when executed by the first processor cause the first processor to: receive fault information related to a fault; generate a fault packet comprising a packet header and the fault information, the packet header including first packet forwarding information identifying the first node controller as a first destination; and send the fault packet to the first node controller identified by the first packet forwarding information; and wherein the first node controller comprises first packet forwarding circuitry configured to: retrieve second packet forwarding information from a first table using at least a portion of the first packet forwarding information as a first key, the second packet forwarding information identifying the tail-end node as a second destination; update the packet header of the fault packet with the second packet forwarding information; and send the fault packet toward the tail-end node identified by the second packet forwarding information; and wherein the tail-end node comprises: an optical protection switching module comprising a first line port connected to a working path, a second line port connected to a protection path, a system port, and an optical switch coupled to the first line port to receive first optical signals from the working path and the second line port to receive second optical signals from the protection path for selectively switching optical signals from the first line port or the second line port to the system port; and a second node controller comprising second packet forwarding circuitry configured to: retrieve third packet forwarding information from a second table using at least a portion of the second packet forwarding information as a second key, the third packet forwarding information identifying the optical protection switching module as a third destination; update the packet header of the fault packet with the third packet forwarding information; and send the fault packet to the optical protection switching module identified by the third packet forwarding information; and wherein the optical protection switching module further comprises a second processor and a second non-transitory processor-readable medium storing processor-executable instructions that when executed by the second processor cause the second processor to switch the optical switch based on the fault information.

Illustrative embodiment 23. The optical network of illustrative embodiment 22, wherein the line module further comprises a network switch configured to communicate using a communication network, and sending the fault packet to the first node controller is further defined as sending, via the network switch using the communication network, the fault packet to the first node controller identified by the first packet forwarding information.

Illustrative embodiment 24. The optical network of illustrative embodiment 23, wherein the network switch is a first network switch, the communication network is a first communication network, the first node controller comprises a second network switch configured to communicate using the first communication network and a second communication network, and sending the fault packet to the tail-end node is further defined as sending, via the second network switch using the second communication network, the fault packet toward the tail-end node identified by the second packet forwarding information.

Illustrative embodiment 25. The optical network of illustrative embodiment 24, wherein the second node controller further comprises a third network switch configured to communicate using a third communication network, and sending the fault packet to the optical protection switching module is further defined as sending, via the third network switch using the third communication network, the fault packet to the optical protection switching module identified by the third packet forwarding information.

Illustrative embodiment 26. The optical network of illustrative embodiment 25, wherein the first communication network is a first virtual local area network, the second communication network is a second virtual local area network, and the third communication network is a third virtual local area network.

Illustrative embodiment 27. The optical network of illustrative embodiment 22, wherein the first node controller further comprises a third processor and a third non-transitory processor-readable medium storing third processor-executable instructions that when executed by the third processor cause the third processor to, prior to receiving the fault information: configure the first packet forwarding circuitry so that the first table includes a key-value pair having the second packet forwarding information as a value and at least a portion of the first packet forwarding information as the first key.

Illustrative embodiment 28. The optical network of illustrative embodiment 27, wherein the key-value pair is a first key-value pair, the value is a first value, and the second node controller further comprises a fourth processor and a fourth non-transitory processor-readable medium storing fourth processor-executable instructions that when executed by the fourth processor cause the fourth processor to, prior to retrieving the third packet forwarding information: send the second packet forwarding information to the head-end node; and configure the second packet forwarding circuitry so that the second table includes a second key-value pair having the third packet forwarding information as a second value and at least a portion of the second packet forwarding information as the second key.

Illustrative embodiment 29. The optical network of illustrative embodiment 22, wherein the first processor-executable instructions when executed by the first processor further cause the first processor to, prior to receiving the fault information, store the first packet forwarding information.

Illustrative embodiment 30. The optical network of illustrative embodiment 22, wherein the first packet forwarding circuitry is a first field-programmable gate array (FPGA), and the second packet forwarding circuitry is a second FPGA.

The foregoing description provides illustration and description, but is not intended to be exhaustive or to limit the inventive concepts to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of the methodologies set forth in the present disclosure.

No element, act, or instruction used in the present application should be construed as critical or essential to the invention unless explicitly described as such outside of the preferred embodiment. Further, the phrase “based on” is intended to mean “based, at least in part, on” unless explicitly stated otherwise.