Derivative works — US Patent 7061859

Defensive Disclosure: Derivatives of US Patent 7061859 for Prior Art Generation

Current Date: April 26, 2026

This document outlines a series of derivative works based on US Patent 7061859, "Fast protection in ring topologies," for the purpose of generating defensive prior art. These disclosures aim to render future incremental improvements in the field of bidirectional ring network fault protection obvious or non-novel by expanding on the core claims (Claims 1 and 7) across various technical axes.

Derivatives Based on Core Claims 1 & 7

The core invention of US7061859 resides in a method and device for fault protection in a bidirectional ring network. This involves:

Constructing a general mask (e.g., a bitmap) indicating reachable segments post-fault.
Constructing a specific mask (e.g., a bitmap) for a given data flow, indicating its desired path pre-fault.
Superimposing these masks (e.g., via a Boolean operation) to determine the flow's disposition (convey, steer, or stop).

The following derivatives build upon these fundamental principles.

1. Material & Component Substitution

Derivative 1.1: Quantum Processor for Mask Operations

Enabling Description: The traditional network processor described in US7061859 is replaced by a specialized quantum co-processor designed for accelerated Boolean and comparative operations on large-scale bitmasks. Qubits, acting as the fundamental units of information, are used to represent the state of network segments (reachable/unreachable, part of desired path/not part of desired path). A quantum entanglement process is employed to simultaneously compare the general and specific masks. For a network with N segments, instead of N sequential bit operations or parallel classical gate arrays, the quantum co-processor leverages superposition and quantum parallelism to execute the mask superposition (e.g., quantum AND gate equivalent for Boolean conjunction) across all segments in a single or few clock cycles, significantly reducing latency for determining data flow disposition. Quantum RAM (QRAM) is utilized for ultra-fast storage and retrieval of both general and specific masks, enabling real-time updates for rapidly changing network topologies or transient faults. This architecture is particularly suited for high-speed packet rings exceeding current Terabit-per-second capacities.

graph TD
    A[Network Segment State Detectors] --> B(Quantum Register Init)
    B --> C{Construct General Mask Qubits}
    B --> D{Construct Specific Mask Qubits}
    C --> E(Quantum Conjunction Gate)
    D --> E
    E --> F[Quantum Measurement & Result Decoding]
    F --> G{Disposition Logic (Classical CPU)}
    G --> H[Packet Forwarding/Steering/Discard]

Derivative 1.2: FPGA/ASIC Hardware Accelerated Masking Engine

Enabling Description: The mask construction and superposition logic specified in US7061859 are implemented directly into a custom hardware solution, either an Application-Specific Integrated Circuit (ASIC) or a Field-Programmable Gate Array (FPGA). This dedicated hardware module integrates directly with the Media Access Control (MAC) blocks (e.g., MAC blocks 40 and 42 in FIG. 2 of US7061859) and the network interfaces. The general mask is generated by a fault detection module that directly monitors physical layer signals (e.g., loss of light, signal-to-noise ratio degradation) or receives alarms (e.g., BFD packets) via dedicated low-latency input pins. The specific masks are pre-loaded or dynamically configured in high-speed, on-chip SRAM/eDRAM. The Boolean conjunction (AND) operation (as described in step 54 of FIG. 4) is performed by a bitwise logic array operating in nanoseconds. The output of this logic array directly feeds a hardware-implemented disposition state machine that triggers packet steering via forwarding table updates or direct MAC layer rerouting. This provides deterministic, ultra-low-latency fault protection suitable for real-time critical applications where the 50ms SONET/SDH standard is insufficient.

graph TD
    A[Network Interfaces (400GbE+)] -- Raw Segment Status --> B(Fault Detector Logic - FPGA/ASIC)
    C[Packet Classifier/Flow Manager] -- Flow Path Segments --> D(Specific Mask Generator - FPGA/ASIC)
    B -- General Mask (GM) --> E(Mask Conjunction Unit - FPGA/ASIC)
    D -- Specific Mask (SM) --> E
    E -- Combined Mask (CM) --> F(Disposition Logic - FPGA/ASIC)
    F -- Action Command --> G[Packet Forwarding Engine]
    G --> H[Output Ports]

Derivative 1.3: Optical Switch with Photonic Mask Representation

Enabling Description: In an all-optical packet switching network, the general and specific masks are not represented electronically but photonically. Each bit in a mask corresponds to a specific wavelength, time slot, or polarization state of an optical signal. For instance, the presence of light at a certain wavelength in a control pulse signifies a '1' (e.g., segment unreachable or part of path), while its absence signifies a '0'. Fault detection triggers the generation of a photonic general mask control signal. Similarly, each data flow has an associated photonic specific mask generated at the source node. Superposition is achieved using nonlinear optical gates (e.g., based on four-wave mixing or semiconductor optical amplifiers) where the interaction of the photonic general mask and specific mask control signals directly influences the routing of the data-carrying optical packets. For example, a photonic AND gate would pass light only if both general and specific mask bits are '1', indicating an overlap. The result directly controls an array of optical MEMS or thermo-optic switches to implement "convey," "steer," or "stop" dispositions without optical-electrical-optical (OEO) conversion.

graph TD
    A[Optical Fault Detector] -- Photonic General Mask --> B(Optical Logic Gate Array)
    C[Optical Flow Path Encoder] -- Photonic Specific Mask --> B
    B -- Photonic Combined Mask --> D(Optical Switch Fabric)
    E[Optical Data Flow] --> D
    D --> F[Rerouted Optical Flow]
    D --> G[Discarded Optical Flow]
    D --> H[Conveyed Optical Flow]

2. Operational Parameter Expansion

Derivative 2.1: Micro-Ring Network for On-Chip Interconnects

Enabling Description: The mask-based fault protection is scaled down and applied to very high-frequency, ultra-short-distance on-chip interconnects forming micro-ring networks within multi-core processor architectures or System-on-Chips (SoCs). Here, "nodes" are individual processing cores, cache blocks, or memory controllers, and "segments" are the nanophotonic waveguides or electrical traces connecting them. Faults can be transient (e.g., due to thermal noise, voltage fluctuations, electromigration) or permanent (e.g., manufacturing defects). The general mask, with perhaps 8-64 bits, is generated by on-chip diagnostic logic monitoring link integrity at gigahertz to terahertz frequencies. Specific masks represent the intended data paths for inter-core communication or memory access requests. The network processor, integrated directly into the NoC (Network-on-Chip) router, performs Boolean superposition at speeds commensurate with CPU clock rates (GHz), enabling packet rerouting around faulty interconnects within a few clock cycles, ensuring uninterrupted operation of high-performance computing tasks.

graph TD
    A[Core N] -- On-Chip Link Segment X --> B[NoC Router A]
    B -- On-Chip Link Segment Y --> C[Core M]
    B -- Link Health Monitor X --> D(General Mask Gen. (NoC))
    C -- Link Health Monitor Y --> D
    E[Packet Origin (Core N)] -- Desired Path --> F(Specific Mask Gen. (NoC))
    D --> G{Mask Superposition (NoC)}
    F --> G
    G -- Disposition --> H[Packet Reroute Logic (NoC)]
    H --> I[Alternative On-Chip Link Segment Z]

Derivative 2.2: Global Satellite Ring Network (LEO/MEO Constellations)

Enabling Description: The fault protection mechanism is adapted for a global communication network comprised of hundreds or thousands of Low Earth Orbit (LEO) or Medium Earth Orbit (MEO) satellites. Each satellite functions as a "node," interconnected by high-speed inter-satellite laser links (ISLs) acting as "segments," forming a dynamic, multi-layered ring topology around Earth. Faults include temporary link obstructions (e.g., atmospheric interference), satellite failures, or planned orbital maneuvers. The "general mask" is derived from global network telemetry, identifying unreachable ISLs or offline satellites, disseminated via a dedicated control plane. The "specific mask" represents high-priority data flows (e.g., intercontinental internet traffic, critical telemetry) intended for specific ground stations or other satellites. The network processor in each satellite, which is radiation-hardened and optimized for autonomous operation, performs the mask superposition. Due to the vast scale and dynamic nature, mask updates consider propagation delays across the constellation, and disposition might involve rerouting traffic to different orbital planes or directing it to available ground gateways.

graph TD
    A[LEO Satellite 1 (Node A)] -- ISL 1 (Segment 1) --> B[LEO Satellite 2 (Node B)]
    B -- ISL 2 (Segment 2) --> C[LEO Satellite 3 (Node C)]
    C -- ISL N (Segment N) --> A
    D[Global Network Control Center] -- Fault Alerts --> A
    A -- General Mask (GM) --> E{Processor A}
    A -- Specific Mask (SM) --> E
    E -- Disposition --> F[ISL Management Unit]
    F -- Reroute --> B

Derivative 2.3: Industrial Control System (ICS) Ring Network for Extreme Environments

Enabling Description: The fault protection method is implemented in robust ring networks for critical Industrial Control Systems (ICS) operating under extreme environmental conditions, such as deep-sea exploration, nuclear power generation, or high-temperature manufacturing. The network nodes are ruggedized industrial controllers or PLCs, and segments are hardened fiber optic cables or highly shielded industrial Ethernet connections. These components are designed to withstand temperatures from -50°C to +200°C, high vibration, corrosive atmospheres, and intense electromagnetic interference. Faults could be physical damage to cables, sensor failures, or controller malfunctions. The "general mask" is built from highly resilient, redundant sensor inputs and diagnostic protocols (e.g., HART, Modbus/TCP, Profinet over fiber), indicating inaccessible process areas or failed control loops. The "specific mask" delineates critical data flows (e.g., emergency shutdown commands, safety interlocks, process variable monitoring). The industrial network processor, enclosed in an explosion-proof, EMI-hardened casing, performs the mask superposition to rapidly reroute control data, ensuring operational safety and continuity in hazardous conditions.

graph TD
    A[Sensor Array 1 (Node A)] -- Hardened Segment 1 --> B[Industrial PLC (Node B)]
    B -- Hardened Segment 2 --> C[Actuator Control (Node C)]
    D[Environmental Monitors] -- Fault Detections --> B
    E[Critical Data Flow] --> B
    B -- General Mask --> F{ICS Processor}
    B -- Specific Mask --> F
    F -- Disposition --> G[Secure Routing Module]
    G --> H[Alternative Path/Emergency Stop]

3. Cross-Domain Application

Derivative 3.1: Autonomous Vehicle Swarm Communication Protection

Enabling Description: The mask-based fault protection is applied to maintain reliable communication within a dynamic swarm of autonomous vehicles (e.g., drones for aerial mapping, ground robots for logistics). Each vehicle acts as a "node," and direct vehicle-to-vehicle wireless links (e.g., mesh Wi-Fi, 5G sidelink, UWB) form transient "segments" of a communication ring. Faults include temporary link loss due to obstacle occlusion, jamming, vehicle power loss, or departure from the swarm. A vehicle's onboard communication processor constructs a "general mask" representing the current reachability of other swarm members and links. For critical swarm tasks (e.g., synchronized movement, target tracking, collaborative sensing), a "specific mask" defines the desired multi-hop communication path. Superimposing these masks allows the vehicle to rapidly decide: (1) if direct communication is possible, (2) if messages must be rerouted through intermediate vehicles to maintain swarm integrity, or (3) if a critical command or sensor data cannot reach its destination, necessitating a re-evaluation of the swarm's mission or task.

graph TD
    A[Autonomous Vehicle 1 (Node)] -- Wireless Link (Segment) --> B[Autonomous Vehicle 2 (Node)]
    B -- Wireless Link (Segment) --> C[Autonomous Vehicle 3 (Node)]
    D[Vehicle 1 Comm Processor] -- Link Status --> E(General Mask Builder)
    D -- Task Comm Path --> F(Specific Mask Builder)
    E --> G{Mask Superposition}
    F --> G
    G -- Disposition --> H[Comm Routing Module]
    H -- Reroute/Discard/Transmit --> B

Derivative 3.2: Smart City Infrastructure Monitoring and Protection

Enabling Description: This fault protection system is deployed within a smart city's critical infrastructure backbone. "Nodes" are smart utility substations, traffic management centers, public safety hubs, and environmental monitoring stations, interconnected by a redundant fiber optic ring network acting as "segments." Faults include fiber cuts (e.g., due to construction), hardware failure at a hub, or cyber-attacks disrupting specific segments. Each infrastructure hub's network processor constructs a "general mask" reflecting the operational status and reachability of critical city zones and services. A "specific mask" is generated for high-priority data flows, such as emergency service dispatch communications, real-time traffic light synchronization, or critical environmental sensor data streams. Superimposition of these masks allows the city's network to rapidly determine if an emergency communication requires rerouting through an alternative fiber path, if traffic control data needs to be temporarily rerouted via wireless backup, or if a segment failure isolates a critical service, necessitating immediate human intervention and backup power activation.

graph TD
    A[Traffic Mgmt Center (Node)] -- Fiber Segment --> B[Utility Substation (Node)]
    B -- Fiber Segment --> C[Public Safety Hub (Node)]
    D[Segment Health Monitors] -- Fault Reports --> A
    E[Emergency Data Flow] --> A
    A -- General Mask --> F{Network Processor A}
    A -- Specific Mask --> F
    F -- Disposition --> G[Infrastructure Router]
    G --> H[Reroute / Alert / Forward]

Derivative 3.3: Decentralized Energy Grid Management

Enabling Description: The mask-based protection is applied to a decentralized energy grid comprised of interconnected micro-grids, renewable energy sources (e.g., solar, wind), and battery storage units configured in a ring topology. Each generation unit, storage unit, or grid interconnection point functions as a "node," and the power lines/associated communication links are "segments." Faults can be localized power outages, generation unit failures, or communication link breakdowns. Each node's smart grid controller builds a "general mask" indicating which parts of the local grid can still supply or receive power and data. A "specific mask" represents the desired path for critical power flows (e.g., from a solar farm to a residential area, or battery discharge to a critical load). The controller superimposes these masks to determine: (1) if the desired power flow can continue, (2) if power needs to be rerouted through an alternative path (e.g., drawing from a different micro-grid or storage unit), or (3) if a critical load is isolated, requiring load shedding or emergency generator activation.

graph TD
    A[Solar Farm (Node)] -- Power Line/Comm Link --> B[Battery Storage (Node)]
    B -- Power Line/Comm Link --> C[Critical Load (Node)]
    D[Grid Sensors] -- Fault Status --> A
    E[Desired Power Flow] --> A
    A -- General Mask --> F{Grid Controller A}
    A -- Specific Mask --> F
    F -- Disposition --> G[Power Router/Switchgear]
    G --> H[Reroute Power / Shed Load / Supply]

4. Integration with Emerging Technologies

Derivative 4.1: AI-Driven Predictive Fault Masking

Enabling Description: This derivative integrates Artificial Intelligence (AI), specifically machine learning models (e.g., Long Short-Term Memory networks or Transformer models), into the network processor (44 in US7061859) or a centralized network orchestrator. IoT sensors are deployed extensively within each network segment (31-37), continuously collecting telemetry data such as optical power levels, temperature, vibration, packet error rates, and latency fluctuations. This raw sensor data is fed into the ML model, which is trained to identify subtle precursors to impending segment failures. Instead of merely reacting to a detected fault, the AI generates a "predictive general mask" indicating segments that are likely to fail within a defined future window (e.g., 500ms, 1s). This proactive mask, combined with the specific masks, enables preemptive traffic steering (step 58) or flow stopping (step 60), minimizing or entirely avoiding service interruption by rerouting data before an actual hard failure occurs. The AI also continually refines its prediction accuracy based on observed fault actualization.

graph TD
    A[IoT Sensors on Segments] --> B(Real-time Telemetry Data)
    B --> C{AI/ML Predictive Model}
    C -- Predicted Faults --> D(Proactive General Mask Generator)
    E[Packet Flows] --> F(Specific Mask Generator)
    D --> G{Mask Superposition Logic}
    F --> G
    G -- Disposition --> H[Network Processor (Reroute/Discard)]

Derivative 4.2: IoT-Enhanced Dynamic Segment Status & Blockchain Ledger

Enabling Description: Each network segment (31-37) is instrumented with an array of Internet of Things (IoT) sensors (e.g., optical transceivers reporting link quality, environmental sensors, power monitors). These IoT devices transmit their real-time operational status (e.g., link up/down, signal degradation, error count) as authenticated transactions to a distributed ledger (blockchain) maintained across the network nodes. Each node's network processor (44) consults this immutable and cryptographically verified blockchain to construct the "general mask." This ensures that the general mask accurately and securely reflects the most current and trustworthy status of each segment, moving beyond a simple binary up/down to include states like "degraded," "intermittent," or "at-risk," based on aggregated IoT data. The specific mask (52) is then superimposed (54) with this granular, blockchain-verified general mask, allowing for more intelligent disposition decisions, such as throttling traffic on degraded paths before full rerouting, or prioritizing certain flows based on service-level agreements encoded in smart contracts on the blockchain.

graph TD
    A[IoT Sensors (Segments)] --> B(Data Aggregation & Signing)
    B --> C{Blockchain Network}
    C -- Authenticated Segment Status --> D(General Mask Constructor - Node NP)
    E[Data Flows] --> F(Specific Mask Constructor - Node NP)
    D --> G{Mask Superposition Logic - Node NP}
    F --> G
    G -- Disposition --> H[Packet Forwarding/Steering/Discard]

Derivative 4.3: Blockchain-Verified Network State and Policy Enforcement

Enabling Description: The entire fault protection policy, including the definition of "general mask" construction rules, "specific mask" generation parameters for different traffic classes, the Boolean operation logic for superposition, and the thresholds for disposition decisions (convey, steer, stop), is codified as a smart contract and stored on a permissioned blockchain. Each network processor (44) retrieves these policies directly from the blockchain, ensuring that all nodes operate under an identical, tamper-proof, and auditable fault protection regime. When a node detects a fault, it publishes the raw fault event to the blockchain. Other nodes, upon receiving this, reference the blockchain-verified policy to construct their general masks. Any decision regarding data flow disposition (steps 56, 58, 60) is then logged as a transaction on the blockchain, providing an immutable audit trail of all protection actions. This architecture enhances security, ensures consistent behavior, and simplifies compliance across complex network deployments.

graph TD
    A[Network Administrator] -- Define Policy --> B(Smart Contract Deployment)
    B --> C{Blockchain (Immutable Policy & State)}
    C -- Verified Policy & Fault Events --> D(Network Processor A)
    C -- Verified Policy & Fault Events --> E(Network Processor B)
    D -- General Mask/Specific Mask --> F{Superposition Logic}
    E -- General Mask/Specific Mask --> G{Superposition Logic}
    F --> H[Disposition & Log to Blockchain]
    G --> I[Disposition & Log to Blockchain]

5. The "Inverse" or Failure Mode

Derivative 5.1: Low-Power Redundancy Mode

Enabling Description: In scenarios of critical power deficit (e.g., a remote solar-powered node operating on depleted battery reserves during extended darkness), the network processor (44) transitions into a "low-power redundancy mode." Instead of dynamically generating full-fidelity general and specific masks for all segments and flows, the system activates pre-computed, static "minimal masks" stored in non-volatile memory. These minimal masks represent only critical backbone segments and essential data flows (e.g., control plane traffic, emergency services data). The Boolean superposition is simplified, potentially using a hardware-accelerated lookup table rather than dynamic bitwise operations, to minimize CPU cycles and energy consumption. Non-essential data flows are automatically designated for discarding at step 60 to conserve bandwidth and power, ensuring the longest possible operational lifespan for the core protection function. The system maintains a "heartbeat" signal through minimal masks to communicate its degraded state to other nodes.

stateDiagram-v2
    [*] --> Normal_Operation : Power OK
    Normal_Operation --> Low_Power_Mode : Power Critical
    Low_Power_Mode --> Normal_Operation : Power Restored
    Low_Power_Mode --> Full_Shutdown : Battery Exhausted

    state Normal_Operation {
        High_Fidelity_Masks : Dynamic GM/SM Generation
        Full_Disposition : Convey/Steer/Stop
    }

    state Low_Power_Mode {
        Minimal_Masks : Pre-computed GM/SM
        Lookup_Table_Ops : Simplified Logic
        Discard_NonEssential : Default Disposition
    }

Derivative 5.2: Safe Shutdown and Data Preservation Mode

Enabling Description: Upon detection of an imminent catastrophic network failure (e.g., multiple segment failures, widespread power grid instability impacting nodes), the system enters a "safe shutdown and data preservation mode." In this mode, the mask-based logic is re-prioritized to identify and utilize any remaining reachable segments for data archival. The "general mask" constructed at step 50 will primarily highlight paths leading to designated data storage or offload facilities (e.g., cloud endpoints, local redundant storage). The "specific mask" at step 52 will focus exclusively on data flows identified as critical for integrity (e.g., transactional data, configuration backups, operational logs). The superposition (step 54) will prioritize disposition actions that enable "convey to archive" or "steer to redundant storage" for these critical flows. All non-critical data flows are immediately halted or discarded (modified step 60) to free up bandwidth and processing power for the data preservation task. This ensures maximum data integrity even in the face of widespread infrastructure collapse.

graph TD
    A[Catastrophic Fault Detected] --> B{Determine Criticality of Data Flow}
    B -- Critical Flow --> C(Specific Mask for Critical Data)
    B -- Non-Critical Flow --> D(Discard Immediately)
    E[Remaining Reachable Segments] --> F(General Mask for Archive Paths)
    C --> G{Mask Superposition}
    F --> G
    G -- Disposition --> H[Convey to Archive / Steer to Redundant Storage]
    H --> I[Network Resources]

Derivative 5.3: Limited-Functionality "Guardian" Mode

Enabling Description: Should the primary network processor (44) experience a software crash or partial hardware failure (e.g., memory corruption, CPU malfunction), the device enters a "guardian mode." In this mode, a stripped-down, isolated hardware module or a minimal firmware core takes over. This module is pre-configured with a highly simplified "general mask" logic (e.g., a binary flag indicating "ring intact" or "ring broken") and fixed "specific masks" for essential control plane messages (e.g., basic routing updates, health checks). The Boolean superposition is replaced by a hardcoded, basic logical OR operation that simply detects any major fault. The disposition mechanism is reduced to a generic "wrap-all" or "steer-all to primary backup path" action, bypassing the nuanced three-way decision. This ensures rudimentary network connectivity for diagnostic purposes or for re-establishing a stable state, sacrificing optimal resource utilization for guaranteed minimal functionality, similar to a safe boot mode in a computer system.

stateDiagram-v2
    [*] --> Primary_NP_Active : Normal Operation
    Primary_NP_Active --> Guardian_Mode : NP Fault Detected
    Guardian_Mode --> Primary_NP_Active : NP Recovered
    Guardian_Mode --> Full_Shutdown : Guardian Failure

    state Primary_NP_Active {
        Full_GM_SM : Dynamic Masking
        Optimized_Disposition : Convey/Steer/Stop
    }

    state Guardian_Mode {
        Simplified_GM : Basic Ring Status
        Fixed_SM : Essential Control Traffic
        Basic_OR_Logic : Fault Detection
        Generic_Reroute : Limited Disposition
    }

Combination Prior Art Scenarios

These scenarios combine the teachings of US7061859 with existing open-source standards, demonstrating how the patent's core concepts could be implemented or enhanced within known frameworks, thus contributing to prior art.

1. Integration with Resilient Packet Ring (RPR) (IEEE 802.17)

Enabling Description: The rapid fault protection method of US7061859, utilizing general and specific masks for flow disposition, can be integrated into a Resilient Packet Ring (RPR) network as defined by the IEEE 802.17 standard. RPR nodes inherently support bidirectional traffic and fast protection mechanisms (e.g., wrapping, steering). Instead of RPR's default protection, the network processor (as in Claim 7 of US7061859) within an RPR node is enhanced. Upon receiving a fault notification (e.g., from an RPR topology advertisement or a failure indication), the node constructs the general mask indicating unreachable RPR segments. For each RPR data flow (e.g., based on RPR's Class of Service or MAC address ranges), a specific mask representing its configured RPR path is maintained. The network processor then superimposes these masks (Claim 1) to determine the disposition of the RPR packet flow. This allows for a more granular, flow-specific protection decision beyond the typical ring-wide RPR wrap/steer, potentially enabling different protection strategies for different traffic classes within the same RPR ring, thereby optimizing bandwidth utilization and recovery time.

2. MPLS-TP (RFC 6374) with Mask-Based Protection

Enabling Description: The mask-based fault protection of US7061859 can be combined with Multiprotocol Label Switching - Transport Profile (MPLS-TP) networks, specifically within a ring topology as described by IETF RFC 6374 and related ITU-T G.8131 standards for protection switching. In an MPLS-TP ring, a "node" (e.g., a Label Edge Router or Label Switching Router) implements the processor of Claim 7. When an Operations, Administration, and Maintenance (OAM) message (e.g., Continuity Check or Lock Request) indicates a fault along an MPLS-TP segment (e.g., a link failure affecting a Label Switched Path, LSP), the network processor constructs a general mask identifying the unreachable segments. For each active MPLS-TP LSP (representing a "data flow"), a specific mask is generated, detailing the segments traversed by that LSP. The network processor superimposes these masks (Claim 1) using a Boolean operation to determine the LSP's disposition: (1) convey over its current primary path if unaffected, (2) steer the LSP traffic onto a pre-provisioned or dynamically calculated protection LSP (alternative path) if the primary path overlaps with the fault, or (3) stop conveying (e.g., discard or buffer) the LSP if the destination becomes unreachable via any path. This enables rapid, flow-aware protection switching for MPLS-TP services.

3. Ethernet Ring Protection Switching (ERPS) / ITU-T G.8032 with Mask-Based Decisions

Enabling Description: The method of fault protection described in US7061859 can be integrated into an Ethernet Ring Protection Switching (ERPS) network, which is standardized by ITU-T G.8032. In an ERPS ring, the network nodes (e.g., Ethernet switches) incorporate the communication device of Claim 7. Upon detection of a fault, such as a link failure reported via Ring APS (R-APS) messages, an ERPS node constructs a general mask representing the unreachable segments in the Ethernet ring. For specific Ethernet data flows (e.g., identified by VLAN ID, MAC address, or specific service instances), a specific mask is built, indicating the segments over which the flow is normally conveyed. The ERPS node's network processor then superimposes these general and specific masks (Claim 1) using a Boolean conjunction. The resulting combined mask informs the ERPS node's decision for the data flow's disposition: (1) convey the flow on its primary path, (2) steer the flow by activating a different segment of the ring (e.g., unblocking a Ring Protection Link, RPL, and rerouting through the opposite direction) or using a pre-established alternative Ethernet path, or (3) stop conveying the flow if the destination is completely isolated. This enhances standard ERPS by adding granular, flow-specific decision-making to the ring-wide protection actions.