Patent 8018880

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

Active provider: Google · gemini-2.5-flash

Derivative works

Defensive disclosure: derivative variations of each claim designed to render future incremental improvements obvious or non-novel.

✓ Generated

Defensive Disclosure: US Patent 8,018,880 Derivative Works

This document provides technical disclosures of derivative works based on US Patent 8,018,880, "Layer 2 virtual private network over PBB-TE/PBT and seamless interworking with VPLS." The objective is to define prior art that addresses potential incremental improvements by competitors, rendering such future developments obvious or non-novel to a Person Having Ordinary Skill in the Art (PHOSITA). The disclosures focus on expanding the scope of the original claims across various axes, including material substitution, operational parameter expansion, cross-domain application, integration with emerging technologies, and inverse/failure modes.

Derivatives for Independent Claims 1, 14, and 26 (PBB-MPLS Interworking)

These derivatives build upon the core elements of the patent, particularly the L2VPN system comprising a PBB network with PBT/PBB-TE trunks, VSIs provisioned by an external control plane, and novel split horizon rules at the interworking VSI connecting the PBB network to an MPLS network (VPLS).

Derivative 1.1: Material & Component Substitution - Software-Defined VSI over OTN Backbone

Enabling Description:
A L2VPN system and method for interconnecting a Provider Backbone Bridge (PBB) network with a Multi-Protocol Label Switching (MPLS) network, where the Virtual Switch Instance (VSI) is implemented as a software-defined network function (SDN-VSI) running on commodity x86 hardware. The SDN-VSI utilizes an extended Berkeley Packet Filter (eBPF) framework within the operating system kernel to perform MAC address learning, filtering, and forwarding, including the specified split horizon rules. The plurality of provider backbone trunks, conventionally PBT/PBB-TE Ethernet, are substituted with Optical Transport Network (OTN) virtual concatenated links (e.g., ODUk.n-LSPs) operating at 100Gbps or 400Gbps, employing Ethernet over OTN (EoOTN) encapsulation (e.g., GFP-F). The external control plane provisions these OTN paths and programs the eBPF-based SDN-VSIs via standard network configuration protocols like NETCONF/YANG or gRPC-based interfaces, maintaining the logical PBT trunk abstraction over the physical OTN transport.

graph TD
    subgraph PBB Network (Software-Defined)
        CE1[Customer Edge 1] -->|Ethernet Frame| SDN-VSI-PBB1(SDN VSI - PBB Site 1)
        SDN-VSI-PBB1 -->|eBPF Forwarding, Learning| OTN_VCAT1(OTN VCAT Link 1)
        OTN_VCAT1 <--> OTN_VCAT2(OTN VCAT Link 2)
        SDN-VSI-PBB2(SDN VSI - PBB Site 2) -->|eBPF Forwarding, Learning| CE2[Customer Edge 2]
    end

    subgraph MPLS Network (VPLS)
        PE_MPLS1(MPLS PE 1) -- PW1(Pseudowire 1) --> PE_MPLS2(MPLS PE 2)
        PE_MPLS1 -->|MPLS LSP| CE_MPLS1[Customer Edge MPLS 1]
    end

    subgraph Interworking Site
        SDN-VSI-IW(SDN VSI - Interworking)
        SDN-VSI-IW -- PBB_SI_OTN(PBB Service Instance over OTN) <--> OTN_VCAT2
        SDN-VSI-IW -- PW_MPLS(Pseudowire over MPLS) <--> PE_MPLS1
        SDN-VSI-IW -- Customer_IF(Customer Bound Interface) <--> CE_Local[Local Customer Edge]
    end

    subgraph External Control Plane
        AI_OPTIMIZER(AI/ML Optimizer)
        SDN_CONTROLLER(SDN Controller)
        SDN_CONTROLLER -- NETCONF/gRPC --> SDN-VSI-PBB1
        SDN_CONTROLLER -- NETCONF/gRPC --> SDN-VSI-PBB2
        SDN_CONTROLLER -- NETCONF/gRPC --> SDN-VSI-IW
        SDN_CONTROLLER -- WDM_CONTROLLER(WDM/OTN Controller)
        WDM_CONTROLLER -- OpenConfig --> OTN_VCAT1
        WDM_CONTROLLER -- OpenConfig --> OTN_VCAT2
    end

    SDN_CONTROLLER -- Monitors & Controls --> AI_OPTIMIZER
    OTN_VCAT1 -- EoOTN Encapsulation --> SDN-VSI-PBB1
    OTN_VCAT2 -- EoOTN Encapsulation --> SDN-VSI-PBB2

    style SDN-VSI-PBB1 fill:#f9f,stroke:#333,stroke-width:2px
    style SDN-VSI-PBB2 fill:#f9f,stroke:#333,stroke-width:2px
    style SDN-VSI-IW fill:#f9f,stroke:#333,stroke-width:2px
    style SDN_CONTROLLER fill:#ccf,stroke:#333,stroke-width:2px
    style WDM_CONTROLLER fill:#ccf,stroke:#333,stroke-width:2px
    style AI_OPTIMIZER fill:#afa,stroke:#333,stroke-width:2px

Derivative 1.2: Operational Parameter Expansion - Terabit L2VPN with Deterministic Networking

Enabling Description:
A L2VPN system operating at a terabit-scale, designed for ultra-low latency and deterministic forwarding, suitable for high-frequency trading (HFT) or industrial control applications. The PBB network utilizes PBB-TE trunks provisioned to carry traffic at a minimum rate of 1Tbps per trunk and supporting millions of concurrent Service Instances. The interworking VSI between the PBB and MPLS network is implemented with dedicated hardware acceleration (e.g., specialized ASICs or multiple high-performance FPGAs with direct memory access) to process frames at line rate with sub-microsecond latency. The external control plane includes a Time-Sensitive Networking (TSN) scheduler that pre-allocates bandwidth and time slots on PBT trunks and MPLS Pseudowires, ensuring jitter-free transmission. The split horizon rules are enforced by hardware logic within the VSI, providing deterministic packet drop or forwarding decisions within picoseconds, even under peak load. The system is provisioned for geographically dispersed sites spanning thousands of kilometers, requiring precise clock synchronization (e.g., PTP IEEE 1588v2) across all network elements to maintain determinism.

graph LR
    subgraph PBB Network (Terabit-Scale)
        A(PBB Edge Node - HFT Client) -->|1Tbps PBT Trunk| B(PBB Core Node)
        B -->|1Tbps PBT Trunk| C(PBB Core Node)
        C -->|1Tbps PBT Trunk| D(PBB Edge Node)
    end

    subgraph MPLS Network (Terabit-Scale VPLS)
        E(MPLS PE - Exchange) --|1Tbps Pseudowire| F(MPLS PE - Data Center)
    end

    subgraph Interworking VSI (Hardware Accelerated)
        IW_VSI(HW-Accelerated VSI)
    end

    subgraph External Control Plane (TSN Enabled)
        ECC(External Central Controller)
        TSN_SCHEDULER(TSN Scheduler)
    end

    D -- High-Speed Interface (e.g., PCIe Gen5) --> IW_VSI
    IW_VSI -- High-Speed Interface --> E

    ECC -- Provisions PBT Trunks, VSIs --> A, B, C, D
    ECC -- Programs HW-Accelerated VSI, Split Horizon --> IW_VSI
    ECC -- Provisions MPLS LSPs, Pseudowires --> E, F
    ECC -- Orchestrates Time Slots & Bandwidth --> TSN_SCHEDULER
    TSN_SCHEDULER -- Time-Sync & Schedules --> B, C, D, IW_VSI, E, F

    style IW_VSI fill:#fcf,stroke:#333,stroke-width:2px
    style ECC fill:#ccf,stroke:#333,stroke-width:2px
    style TSN_SCHEDULER fill:#afa,stroke:#333,stroke-width:2px

Derivative 1.3: Cross-Domain Application - Smart Grid SCADA/DMS Integration

Enabling Description:
A L2VPN system adapted for secure and reliable communication in Smart Grid infrastructure, specifically for Supervisory Control and Data Acquisition (SCADA) and Distribution Management System (DMS) applications. The PBB network segments represent substations, remote terminal units (RTUs), and Distributed Energy Resources (DERs) in a metro or regional grid. PBT/PBB-TE trunks connect these operational technology (OT) sites, carrying IEC 61850 GOOSE messages, SCADA telemetry, and control commands. The MPLS network (VPLS) forms the wide-area backbone connecting geographically dispersed control centers and enterprise IT systems. The interworking VSI enforces split horizon rules to strictly separate OT and IT traffic. For instance, GOOSE messages from a Service Instance (PBB) are forwarded to specific Pseudowires (MPLS) for control center processing but never back to another OT Service Instance that could create a malicious loop within the substation network. Frames from the IT network (Pseudowires) are only forwarded to designated OT Service Instances and relevant customer interfaces, preventing unauthorized access or lateral movement. The external control plane manages the provisioning of L2VPNs, ensuring adherence to critical infrastructure protection (CIP) standards for cybersecurity and real-time operational requirements.

graph TD
    subgraph SCADA/DMS L2VPN
        SC(Substation Controller) --- RTU(Remote Terminal Unit)
        SC --- DER(Distributed Energy Resource)
        RTU --- PBB_SW1(PBB Switch 1)
        DER --- PBB_SW1
        PBB_SW1 -- PBT_TRUNK(PBT Trunk) --> PBB_SW2(PBB Switch 2)
    end

    subgraph Interworking Gateway
        IW_VSI_SG(Interworking VSI)
    end

    subgraph MPLS WAN
        CC(Control Center) -- PW_CC(Pseudowire to Control Center) --> MPLS_PE_CC(MPLS PE)
        ENT(Enterprise IT) -- PW_ENT(Pseudowire to Enterprise IT) --> MPLS_PE_ENT(MPLS PE)
        MPLS_PE_CC -- VPLS_CORE(VPLS Core) --> MPLS_PE_ENT
    end

    PBB_SW2 -- PBB_IF_SG(PBB Interface) --> IW_VSI_SG
    IW_VSI_SG -- MPLS_IF_SG(MPLS Interface) --> MPLS_PE_CC

    subgraph External Control Plane (CIP-Compliant)
        SG_CPM(Smart Grid Control Plane Manager)
    end

    SG_CPM -- Provisions L2VPNs, Split Horizon --> PBB_SW1, PBB_SW2, IW_VSI_SG
    SG_CPM -- Configures MPLS PWs --> MPLS_PE_CC, MPLS_PE_ENT

    style IW_VSI_SG fill:#fcf,stroke:#333,stroke-width:2px
    style SG_CPM fill:#ccf,stroke:#333,stroke-width:2px

Derivative 1.4: Integration with Emerging Tech - AI-Optimized & IoT-Monitored L2VPN

Enabling Description:
A L2VPN system where the external control plane is enhanced with Artificial Intelligence (AI) and Machine Learning (ML) for dynamic optimization and IoT sensor integration for real-time monitoring. IoT sensors (e.g., MEMS accelerometers, optical power monitors, temperature sensors) are embedded in PBB network devices and PBT fiber infrastructure, collecting telemetry such as link latency, packet loss, fiber strain, and ambient temperature. This real-time data feeds into an AI/ML engine within the external control plane. The AI/ML engine dynamically calculates optimal PBT trunk routes, tunes VSI buffer allocations, and adapts split horizon rule thresholds (e.g., for broadcast storm prevention) based on predicted traffic fluctuations, network health, and detected anomalies. For example, if IoT data indicates an aging fiber segment, the AI might proactively reroute critical L2VPNs via alternative PBT trunks or adjust split horizon rules to rate-limit certain traffic types on the affected segment, minimizing service impact. The control plane implements closed-loop automation, where AI-generated policies are automatically translated into configuration commands (e.g., via NETCONF) for network elements.

graph TD
    subgraph PBB Network
        PBB_Node1[PBB Edge Node 1] --- PBT_Link1(PBT Trunk 1)
        PBT_Link1 --- PBB_Node2[PBB Core Node]
        PBB_Node2 --- PBT_Link2(PBT Trunk 2)
        PBT_Link2 --- PBB_Node3[PBB Edge Node 3]
    end

    subgraph MPLS Network
        MPLS_PE1[MPLS PE 1] --- PW1(Pseudowire 1)
        PW1 --- MPLS_PE2[MPLS PE 2]
    end

    subgraph Interworking
        IW_VSI_AI(Interworking VSI)
    end

    subgraph IoT Telemetry
        IoT_Sensor1(Link Latency Sensor) --- PBT_Link1
        IoT_Sensor2(Fiber Strain Sensor) --- PBT_Link2
        IoT_Sensor3(Device Health Monitor) --- PBB_Node2
    end

    subgraph External Control Plane
        AI_ML_ENGINE(AI/ML Engine)
        SDN_CONTROLLER_AI(SDN Controller)
        DB(Telemetry Database)
    end

    PBB_Node3 --- IW_VSI_AI
    IW_VSI_AI --- MPLS_PE1

    IoT_Sensor1 -->|Real-time Data| DB
    IoT_Sensor2 -->|Real-time Data| DB
    IoT_Sensor3 -->|Real-time Data| DB

    DB -->|Input Data| AI_ML_ENGINE
    AI_ML_ENGINE -->|Optimized Policies| SDN_CONTROLLER_AI
    SDN_CONTROLLER_AI -->|Provisioning & Config| PBB_Node1, PBB_Node2, PBB_Node3, MPLS_PE1, IW_VSI_AI

    style AI_ML_ENGINE fill:#afa,stroke:#333,stroke-width:2px
    style SDN_CONTROLLER_AI fill:#ccf,stroke:#333,stroke-width:2px
    style IW_VSI_AI fill:#fcf,stroke:#333,stroke-width:2px

Derivative 1.5: The "Inverse" or Failure Mode - Graceful Degradation & Emergency L2VPN

Enabling Description:
A L2VPN system designed for "graceful degradation" and "emergency L2VPN" operation during critical network failures or disaster scenarios. Upon detection of a major failure event (e.g., loss of multiple PBT trunks, VSI hardware malfunction, or network-wide congestion exceeding predefined thresholds), the external control plane initiates a pre-programmed emergency response. This involves reconfiguring the interworking VSI and associated PBB/MPLS elements into a limited-functionality mode. In this mode, non-essential Service Instances (e.g., bulk data transfer, recreational internet access) are either dropped, severely rate-limited, or re-routed onto best-effort paths. Critical Service Instances (e.g., emergency services communication, essential SCADA traffic, disaster recovery data) are automatically prioritized, potentially gaining exclusive use of remaining PBT trunks and MPLS Pseudowires. The split horizon rules at the interworking VSI are dynamically tightened: for instance, frames from emergency Service Instances may bypass certain forwarding restrictions to ensure reachability, while all other traffic is subjected to extremely strict policies or even blocked from cross-domain forwarding. The system shifts to a low-power mode where feasible, reducing energy consumption on non-critical components.

stateDiagram-v2
    [*] --> Normal_Operation : Start
    Normal_Operation --> Fault_Detected : Network Anomaly/Failure
    Fault_Detected --> Emergency_Mode : Trigger Emergency Protocol

    state Emergency_Mode {
        Emergency_Mode --> Critical_Services_Prioritized : Allocate Resources
        Critical_Services_Prioritized --> Non_Critical_Services_Degraded : Limit Non-Essential
        Non_Critical_Services_Degraded --> Tightened_Split_Horizon : Enforce New Rules
        Tightened_Split_Horizon --> Low_Power_State : Optimize Energy
        Low_Power_State --> Monitoring_Degraded : Continue monitoring
    }

    Emergency_Mode --> Fault_Resolved : Recovery Initiated
    Fault_Resolved --> Normal_Operation : Return to Normal

    Critical_Services_Prioritized --> Critical_Traffic_Flow : Emergency L2VPN Active
    Non_Critical_Services_Degraded --> Limited_Traffic_Flow : Degraded L2VPN Active
    Tightened_Split_Horizon --> Loop_Prevention_Enhanced : Maximize Stability

    note on Fault_Detected
        Excessive latency, link down,
        high congestion, hardware fault.
    end note
    note on Critical_Services_Prioritized
        Emergency communication,
        SCADA, disaster recovery.
    end note
    note on Tightened_Split_Horizon
        Bypass for critical, strict for others.
    end note

Derivatives for Independent Claim 39 (PBB Core-Metro Interworking)

These derivatives extend the core elements of the patent, specifically the L2VPN system operating entirely within a PBB domain, employing VSIs provisioned by an external control plane, and featuring novel split horizon rules at the interworking VSI connecting a PBB core network to a PBB metro network.

Derivative 2.1: Material & Component Substitution - FPGA-Accelerated VSI with QKD Trunks

Enabling Description:
A L2VPN system where the interworking Virtual Switch Instance (VSI) between a PBB core network and a PBB metro network is implemented on a high-performance Field-Programmable Gate Array (FPGA) or a SmartNIC with embedded FPGA logic. This hardware-accelerated VSI provides line-rate packet processing and deterministic enforcement of the split horizon rules. The provider backbone trunks within both the PBB core and metro networks, as well as the inter-network trunks, are secured using Quantum Key Distribution (QKD) technology. This requires specialized optical transceivers capable of generating and distributing quantum keys, which are then used to encrypt the Ethernet frames traversing the PBT/PBB-TE trunks. The external control plane manages the provisioning of these QKD-secured PBT trunks and programs the FPGA-based VSIs, including the QKD key management and encryption parameters, via secure out-of-band channels. This ensures an unprecedented level of physical layer security for the L2VPN traffic.

classDiagram
    class ExternalControlPlane {
        +provisionQKDTrunks()
        +programFPGA_VSI()
        +manageQKDKeys()
    }
    class FPGA_VSI {
        +processFrames(frame)
        +enforceSplitHorizon()
        +handleQKD_Decryption()
    }
    class QKD_OpticalTransceiver {
        +establishQuantumChannel()
        +distributeKeys()
        +encryptPacket(packet, key)
        +decryptPacket(packet, key)
    }
    class PBB_CoreNode {
        -FPGA_VSI interworkingVSI
        -QKD_OpticalTransceiver coreTrunks[]
    }
    class PBB_MetroNode {
        -FPGA_VSI localVSI
        -QKD_OpticalTransceiver metroTrunks[]
    }

    ExternalControlPlane --> FPGA_VSI : Programs
    ExternalControlPlane --> QKD_OpticalTransceiver : Manages Keys
    FPGA_VSI <--> QKD_OpticalTransceiver : Encrypt/Decrypt Traffic
    PBB_CoreNode "1" -- "1" FPGA_VSI : Hosts
    PBB_CoreNode "1" -- "*" QKD_OpticalTransceiver : Connects
    PBB_MetroNode "1" -- "*" QKD_OpticalTransceiver : Connects
    PBB_CoreNode -- PBB Core Trunks (QKD Secured) --> PBB_MetroNode

Derivative 2.2: Operational Parameter Expansion - L2VPN for Extreme Environmental Conditions

Enabling Description:
A L2VPN system deployed for interconnecting PBB core and metro networks operating in extreme environmental conditions, such as polar research stations, deep-sea exploration vessels, or remote industrial sites with high temperatures, pressures, or electromagnetic interference. All network elements, including PBB switches, PBT/PBB-TE trunks, and VSIs, are housed in hardened enclosures (e.g., IP68 rated, thermally managed, EMI shielded). The external control plane is designed with adaptive routing algorithms that factor in real-time environmental data (e.g., ice formation on fiber, seismic activity affecting cables, satellite link degradation). It provisions highly redundant PBT trunks with diverse physical paths (e.g., terrestrial fiber, satellite links, underwater cables) and dynamically re-routes traffic based on link quality and environmental threats. The split horizon rules are adapted to account for potential transient link failures or intermittent connectivity common in such environments, potentially relaxing certain restrictions or imposing stricter rate limits on non-critical traffic during periods of environmental stress.

graph TD
    subgraph PBB Core Network (Arctic Data Center)
        Core_Node_H(Hardened Core Node) --- Satellite_Link(Satellite Backhaul)
        Core_Node_H --- Undersea_Fiber(Undersea Fiber Cable)
    end

    subgraph PBB Metro Network (Polar Research Station)
        Metro_Node_H(Hardened Metro Node) --- Satellite_Ant(Satellite Antenna)
        Metro_Node_H --- Local_Fiber(Local Hardened Fiber)
        Metro_Node_H --- IW_VSI_EH(Interworking VSI - Extreme Hdw)
    end

    subgraph External Control Plane (Environmental Adaptive)
        ECM(Environmental Control Module)
        Dynamic_Router(Dynamic Routing Engine)
        Provis_Engine(Provisioning Engine)
    end

    Core_Node_H -- PBT over Satellite --> Satellite_Ant
    Undersea_Fiber -- PBT over Fiber --> Metro_Node_H
    Metro_Node_H -- Inter-Network PBT --> IW_VSI_EH
    IW_VSI_EH -- Internal PBT --> Core_Node_H

    ECM -->|Real-time Environmental Data| Dynamic_Router
    Dynamic_Router -->|Optimal Path Selection| Provis_Engine
    Provis_Engine -->|Provisions PBT Trunks & VSIs| Core_Node_H, Metro_Node_H, IW_VSI_EH

    style Core_Node_H fill:#c0c0c0,stroke:#333,stroke-width:2px
    style Metro_Node_H fill:#c0c0c0,stroke:#333,stroke-width:2px
    style IW_VSI_EH fill:#fcf,stroke:#333,stroke-width:2px
    style ECM fill:#afa,stroke:#333,stroke-width:2px
    style Dynamic_Router fill:#ccf,stroke:#333,stroke-width:2px

Derivative 2.3: Cross-Domain Application - Defense/Tactical Communications for Battlefield L2VPN

Enabling Description:
A L2VPN system specifically designed for military and defense tactical communication networks, comprising PBB core networks for command and control centers and PBB metro networks for mobile units, forward operating bases (FOBs), and sensor arrays. PBT/PBB-TE trunks provide secure, resilient Layer 2 connectivity. The external control plane is a mission-aware SDN controller that can dynamically provision and tear down L2VPNs for specific operational missions or secure data enclaves on demand. Split horizon rules at the interworking VSIs (connecting core to metro) are critical for compartmentalizing sensitive information, preventing unauthorized lateral movement of data between different security classifications or operational groups. For example, a frame from a metro network Service Instance (e.g., reconnaissance data) is only forwarded to designated core Service Instances (e.g., intelligence analysis unit) and specific customer-bound interfaces, strictly adhering to "need-to-know" principles, and never re-forwarded to another metro Service Instance, even if physically possible, unless explicitly authorized by mission parameters.

graph TD
    subgraph PBB Core Network (Command & Control)
        C2_Center[C2 Center] --- Core_PE1(Core PE 1)
        Core_PE1 --- Core_VSI(Core VSI)
    end

    subgraph PBB Metro Network (Tactical Zone Alpha)
        FOB1[Forward Operating Base 1] --- Metro_PE_A1(Metro PE A1)
        Metro_PE_A1 --- Mobile_Unit1(Mobile Unit 1)
        Metro_PE_A1 --- Metro_VSI_A(Metro VSI Alpha)
    end

    subgraph PBB Metro Network (Tactical Zone Bravo)
        FOB2[Forward Operating Base 2] --- Metro_PE_B1(Metro PE B1)
        Metro_PE_B1 --- Sensor_Array1(Sensor Array 1)
        Metro_PE_B1 --- Metro_VSI_B(Metro VSI Bravo)
    end

    subgraph Interworking Gateway
        IW_VSI_Tac(Interworking VSI - Tactical)
    end

    subgraph External Control Plane (Mission-Aware SDN)
        Mission_SDN_Controller(Mission-Aware SDN Controller)
    end

    Core_VSI -- PBT Trunk Core --> IW_VSI_Tac
    IW_VSI_Tac -- PBT Trunk Metro A --> Metro_VSI_A
    IW_VSI_Tac -- PBT Trunk Metro B --> Metro_VSI_B

    Mission_SDN_Controller -- Provisions L2VPNs, Split Horizon Rules --> Core_PE1, Core_VSI, Metro_PE_A1, Metro_VSI_A, Metro_PE_B1, Metro_VSI_B, IW_VSI_Tac

    style IW_VSI_Tac fill:#fcf,stroke:#333,stroke-width:2px
    style Mission_SDN_Controller fill:#ccf,stroke:#333,stroke-width:2px

Derivative 2.4: Integration with Emerging Tech - AI-driven Anomaly Detection for PBB Security

Enabling Description:
A L2VPN system where the external control plane integrates an AI/ML-based anomaly detection engine to enhance the security and integrity of PBB core-metro interworking. The AI/ML engine continuously monitors VSI forwarding tables, MAC address learning patterns, PBT trunk utilization, and split horizon rule enforcement logs across both PBB core and metro networks. It establishes baselines for normal network behavior. Deviations, such as unexpected MAC address flapping across PBB segments, unusual broadcast traffic patterns violating split horizon, or unauthorized forwarding attempts, are immediately flagged as potential anomalies (e.g., misconfigurations, insider threats, or active attacks). The AI/ML engine can trigger automated responses, such as isolating the affected VSI, dynamically updating split horizon rules to block suspicious traffic, or initiating deeper forensic logging, all orchestrated by the external control plane. This proactive detection and response capability prevents network-wide loops or data exfiltration attempts.

stateDiagram-v2
    state Normal_Operation {
        Monitoring : Monitor VSI, MAC, PBT, Split Horizon Logs
        Learning : AI/ML Model Learns Baseline Behavior
    }

    state Anomaly_Detection {
        Anomaly_Detected : Deviation from Baseline Identified
        Classification : Classify Anomaly (e.g., misconfig, attack)
    }

    state Automated_Response {
        Isolation : Isolate Affected VSI/Segment
        Dynamic_Rules_Update : Adjust Split Horizon Rules
        Forensic_Logging : Initiate Detailed Logging
    }

    [*] --> Normal_Operation
    Normal_Operation --> Anomaly_Detection : Anomaly Detected
    Anomaly_Detection --> Automated_Response : Action Triggered
    Automated_Response --> Normal_Operation : Resolution / Mitigation
    Automated_Response --> Alert_Human : Escalate if necessary

    note on Anomaly_Detected
        - Unexpected MAC flapping
        - Split horizon rule violation attempts
        - Unusual traffic volume/patterns
    end note

Derivative 2.5: The "Inverse" or Failure Mode - Context-Aware Traffic Prioritization in PBB Congestion

Enabling Description:
A L2VPN system implementing a "context-aware traffic prioritization" mode during periods of PBB core or metro network congestion, partial link failures, or resource exhaustion. The external control plane, based on predefined service level agreements (SLAs) and real-time network telemetry, dynamically adjusts the forwarding behavior of interworking VSIs. Instead of strictly blocking frames via split horizon, the VSI prioritizes forwarding for critical Service Instances (e.g., VoIP, video conferencing for executives, or specific application traffic with high QoS tags) while actively de-prioritizing or dropping frames from non-critical Service Instances (e.g., bulk file transfers, general internet browsing). During such events, the external control plane might instruct the VSI to temporarily modify its split horizon rules to allow limited, rate-controlled forwarding for de-prioritized traffic in specific directions where alternative paths are unavailable, or to implement explicit congestion notification (ECN) based policies to reduce traffic. This ensures that essential business services remain operational, albeit with reduced capacity for non-critical traffic, rather than a full outage.

flowchart TD
    A[Start] --> B{Network Status?};
    B -- Normal --> C[Normal L2VPN Operation];
    B -- Congested/Degraded --> D{Prioritize Traffic};

    D --> E[Identify Critical Service Instances (CSIs)];
    D --> F[Identify Non-Critical Service Instances (NCSIs)];

    E --> G[Allocate Guaranteed Bandwidth/Priority for CSIs];
    G --> H[Enforce Standard Split Horizon for CSIs];

    F --> I[Rate-Limit/Deprioritize NCSIs];
    I --> J{Alternative Path Available?};
    J -- Yes --> K[Reroute NCSIs via Best-Effort Path];
    J -- No --> L[Adapt Split Horizon for NCSIs with ECN/Drops];

    K --> M[Forward NCSIs with Reduced QoS];
    L --> M;

    H --> O[VSI Forwards Frames per Policy];
    M --> O;
    C --> O;

    O --> P[End];

Combination Prior Art Scenarios with Open-Source Standards

These scenarios illustrate how the inventive concepts of US Patent 8,018,880 could be implemented or enhanced using existing open-source standards, thereby extending the scope of prior art.

  1. US 8,018,880 + OpenFlow/SDN:

    • Scenario: The "external control plane" (FIG. 4 of US 8,018,880) is implemented as a logically centralized, open-source Software-Defined Networking (SDN) controller, such as ONOS or OpenDaylight. The Provider Edge (PE) devices and the interworking VSIs (e.g., VSI 510 in FIG. 5, or VSI 610/630 in FIG. 6) are realized as OpenFlow-enabled switches.
    • Enabling Description: The SDN controller would use the OpenFlow protocol to program specific flow entries on the PEs and VSIs. These flow entries would explicitly define the forwarding actions based on the ingress port and frame characteristics (e.g., I-SID, VLAN ID, Pseudowire label), effectively enforcing the split horizon rules described in Claims 1 and 39. For instance, an OpenFlow rule for a frame received from a Service Instance on a PBB trunk at an interworking VSI would specify forwarding actions only to Pseudowire-bound ports or customer-bound interfaces, explicitly excluding forwarding to other Service Instance-bound ports on the PBB side. The controller would also manage the provisioning of PBT trunks by orchestrating paths across the underlying OpenFlow-managed network fabric.
    • Standard: OpenFlow Specification (e.g., v1.3 or higher) and related SDN controller platforms (e.g., ONOS, OpenDaylight).

  2. US 8,018,880 + NETCONF/YANG:

    • Scenario: The provisioning of VSIs, PBT trunks, and split horizon rules, currently described as using CLI or SNMP (FIG. 4), is standardized and automated using NETCONF (Network Configuration Protocol) and YANG (Yet Another Next Generation) data models.
    • Enabling Description: Network devices acting as PEs and VSIs in the L2VPN system support NETCONF operations over a secure transport (e.g., SSH). YANG data models are defined for configuring PBB parameters (e.g., B-MAC addresses, I-SIDs, PBT trunk endpoints), VSI instances (e.g., VSI creation, MAC learning parameters), and the specific split horizon rule sets. The external control plane interacts with network elements by sending NETCONF RPCs (Remote Procedure Calls) containing YANG-modeled configuration data. This allows for transactional, programmatic configuration, validation, and monitoring of the L2VPN, ensuring consistency and reducing manual errors.
    • Standard: IETF RFC 6241 (NETCONF), RFC 7950 (YANG 1.1).

  3. US 8,018,880 + ONF TR-512 (Open Disaggregated Transport Network):

    • Scenario: The underlying PBB network and PBT trunks are built using a disaggregated transport network architecture as defined by the Open Networking Foundation (ONF) TR-512. This involves separating the network elements into transponder, ROADM (Reconfigurable Optical Add-Drop Multiplexer), and packet-forwarding components.
    • Enabling Description: The external control plane, in this context, would act as a Transport SDN controller that orchestrates virtualized PBT trunks across the disaggregated optical and packet layers. It would configure the white box or disaggregated PBB/Ethernet switches (the "packet-forwarding components") to host the VSIs and enforce the split horizon rules. The controller uses open interfaces (e.g., OpenConfig, gRPC) to provision the optical layer for the underlying PBT paths and to configure the packet layer for L2VPN services. This allows for a more flexible, scalable, and multi-vendor PBB infrastructure while still adhering to the L2VPN and interworking principles of US 8,018,880.
    • Standard: ONF TR-512 (Open Disaggregated Transport Network Reference Design), OpenConfig, gRPC.

Generated 5/27/2026, 9:19:20 PM