US 8018880

US Patent 8,018,880: Layer 2 Virtual Private Network over PBB-TE/PBT and Seamless Interworking with VPLS

Title: Layer 2 virtual private network over PBB-TE/PBT and seamless interworking with VPLS

Assignee: The current assignee is K.MIZRA LLC, as of January 13, 2020. The original assignee was Brixham Solutions Ltd.

Inventors: Norival R. Figueira and Richard D. Gitlin.

Filing Date: March 25, 2008 (Application number US12/079,413).

Issue Date: September 13, 2011.

Abstract: The patent describes a Layer 2 Virtual Private Network (L2VPN) system utilizing a Provider Backbone Bridge (PBB) network. This network connects multiple sites via provider backbone trunks, specifically Provider Backbone Transport (PBT) or Provider Backbone Bridge Traffic Engineering (PBB-TE) trunks, to form the L2VPN.

Plain-Language Overview of Independent Claims:

The patent includes four independent claims covering methods, systems, and computer program products related to L2VPNs over PBB/PBT networks, particularly focusing on interworking with MPLS-based Virtual Private LAN Services (VPLS) and handling traffic between different PBB network segments.

• Independent Claim 1 (Method): This claim details a method for setting up an L2VPN. It involves connecting various sites within a PBB network using PBT or PBB-TE trunks. Virtual Switch Instances (VSIs) are provisioned for these sites using a control plane located externally to the sites. Crucially, a specific "split horizon" rule is used to manage frame forwarding at a VSI that links the PBB network to a Multi Protocol Label Switching (MPLS) network. This rule dictates:

  1. Frames arriving from a Service Instance on a PBB trunk can only be sent to Pseudowires (MPLS paths) or customer connections.
  2. Frames arriving from a Pseudowire (MPLS path) can only be sent to Service Instances on PBB trunks or customer connections.
  3. Frames arriving from a customer connection are forwarded normally by the VSI without any restrictions.

• Independent Claim 14 (System): This claim describes a system designed to implement the method of Claim 1. It comprises:

  1. A connector to link PBB network sites using PBT or PBB-TE trunks.
  2. A controller that interfaces with an external control plane to provision VSIs for the sites.
  3. A first VSI configured to apply the specific split horizon rule (as described in Claim 1) when handling frames at the interface between the PBB network and an MPLS network.

• Independent Claim 26 (Computer Program Product): This claim covers a non-transitory computer-readable storage medium containing instructions. When executed, these instructions cause a system to perform the method outlined in Claim 1, encompassing the coupling of PBB sites, external provisioning of VSIs, and the application of the defined split horizon rules for PBB-MPLS interworking.

• Independent Claim 39 (Method): This claim presents another method for interconnecting an L2VPN system within a PBB network, specifically when connecting a PBB core network to a PBB metro network. It involves:

  1. Coupling PBB network sites using PBT or PBB-TE trunks.
  2. Provisioning VSIs via an external control plane.
  3. Employing a split horizon rule at a VSI connecting the PBB core and metro networks. This rule ensures:
     • Frames from a PBB metro network Service Instance can only be forwarded to PBB core network Service Instances or customer interfaces.
     • Frames from a PBB core network Service Instance can only be forwarded to PBB metro network Service Instances or customer interfaces.
     • Frames from a customer interface are forwarded normally by the VSI without restrictions.

CAFC 2026 Docket Search:

As of April 26, 2026, a search of the CAFC 2026 dockets did not yield specific litigation records directly referencing US patent 8,018,880. General patent-related Federal Circuit activity and other patent infringement cases were found, but no authoritative information specifically linking this patent to ongoing litigation in the CAFC for 2026 was identified.

As of April 26, 2026, a search for litigation involving US patent 8,018,880 reveals the following:

Known Litigation:

• Jurisdiction: Texas Eastern District Court [cite: Current time information in United States of America., 1]
  • Case Number: 2:24-cv-00974 [cite: Current time information in United States of America., 1]
  • Status: Case filed. [cite: Current time information in United States of America., 1]

Unified Patents' portal indicates that this patent has family litigation and a US case filed in the Texas Eastern District Court, case number 2:24-cv-00974. No further details regarding plaintiffs, defendants, or specific filing dates for this particular case were immediately available through the provided search results from Unified Patents, nor were outcomes or detailed statuses for any other litigation directly referencing US patent 8,018,880. [cite: Current time information in United States of America., 1, 5] While Unified Patents tracks a vast number of patent cases, including those in District Courts, and provides search functionality for patent numbers and case details, a direct search for 8018880 on their general litigation list did not immediately yield more specific information beyond the initial "Family has litigation" flag and the Texas Eastern District Court case number.

Proceedings overview

As of May 27, 2026, there are no AIA trial proceedings on file for US Patent 8,018,880 according to the USPTO Open Data Portal. This means the patent has not been challenged through Inter Partes Review (IPR), Post-Grant Review (PGR), or Covered Business Method (CBM) review. For a defendant, this indicates the patent claims remain untested by the PTAB, which can make an IPR-based defense potentially more challenging, as there are no prior invalidation rulings to leverage.

Strategic summary

Given the absence of any AIA trial proceedings, all claims of US Patent 8,018,880 are currently UNTESTED by the PTAB. There are no canceled or sustained claims through IPR, PGR, or CBM. The estoppel landscape is entirely open, meaning a potential petitioner facing assertion of this patent would not be barred from raising any valid prior-art grounds under § 102 or § 103 that they could reasonably have raised. There is no pattern of PTAB activity to analyze, such as repeated filings by the same petitioner, aggressive appeals by the patent owner, or involvement of defensive aggregators like Unified Patents.

Recommended next steps

As there is no PTAB activity on file for US Patent 8,018,880, a defendant facing assertion of this patent today should understand that all claims are currently presumed valid as far as the PTAB is concerned. The absence of PTAB challenges for a patent that has been active since 2011 (publication date) and has related litigation [cite: Current time information in United States of America.] could indicate several things, including that the patent owner has not aggressively enforced it, or that prior art challenges have been deemed less effective than other defensive strategies. If considering an IPR, a defendant would need to conduct a thorough prior art search to identify strong grounds for invalidity under § 102 or § 103, as these are the statutory bases permitted in IPRs. The PTAB has discretion in instituting IPRs, and a strong petition with robust evidence is crucial.

Inventors

• Norival R. Figueira: Likely employed by Hammerhead Systems, Inc. at the time of filing, which was an operating company in the networking equipment sector. The inventors assigned their rights to Hammerhead Systems, Inc. shortly after the application was filed.
• Richard D. Gitlin: Likely employed by Hammerhead Systems, Inc. at the time of filing.

Unusual patterns: The inventors assigned their rights to Hammerhead Systems, Inc. on June 6-7, 2008, a few months after the March 25, 2008 filing date. Hammerhead Systems, Inc., an operating company, subsequently assigned the patent back to Brixham Solutions Ltd. in early 2010 before Hammerhead's acquisition by Nokia Siemens Networks later that year. This initial loop suggests a strategic handling of intellectual property prior to a major corporate transaction.

Original assignee

The original assignee on the application was Brixham Solutions Ltd. While originally listed, the patent's journey involved an early transfer to Hammerhead Systems, Inc., an operating company known for its HSX 6000 product in the aggregation network space. Hammerhead Systems, Inc. was acquired by Nokia Siemens Networks in 2010. Brixham Solutions Ltd. later re-acquired the patent from Hammerhead Systems, Inc. in 2010. Given its re-acquisition of the patent and subsequent transfers to entities with names characteristic of patent holding companies, Brixham Solutions Ltd. appears to have primarily functioned as a patent holding or licensing entity rather than shipping products embodying the claims directly. Its current status as an independent operating entity is unclear, as the patent has been transferred out.

Assignment timeline

• 2008-06-06 to 2008-06-07 (executed) / recorded 2008-06-17 — Reel 021112/0104

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: GITLIN, RICHARD D.; FIGUEIRA, NORIVAL R.
  • Assignee: HAMMERHEAD SYSTEMS, INC., CALIFORNIA
  • Correspondent: BLAKELY, SOKOLOFF, TAYLOR & ZAFMAN, LLP, 1279 OAKMEAD PARKWAY, SUNNYVALE, CALIFORNIA 94085-4040.
  • Context: Inventors assigned their patent rights to an operating company, likely their employer or an acquiring entity.

• 2010-01-08 (executed) / recorded 2010-01-19 — Reel 023810/0916

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: HAMMERHEAD SYSTEMS, INC., DELAWARE
  • Assignee: BRIXHAM SOLUTIONS LTD., VIRGIN ISLANDS, BRITISH
  • Correspondent: RICHARD A. LOEB, 555 Montgomery Street, Suite 1000, San Francisco, CA 94111.
  • Context: An operating company assigned patent rights back to the original applicant, potentially as part of a divestiture or re-organization before the operating company's acquisition.

• 2017-06-27 (executed) / recorded 2017-08-16 — Reel 043312/0218

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: BRIXHAM SOLUTIONS LTD.
  • Assignee: GLOBAL INNOVATION AGGREGATORS LLC., CALIFORNIA
  • Correspondent: NICK ZIMMERMAN, 10887 White Rock Rd., Ste. 200, Rancho Cordova, CA 95670. This correspondent recurs in this chain.
  • Context: Transfer from a prior patent holding entity to an entity with a name suggesting patent aggregation.

• 2019-12-24 (executed) / recorded 2020-01-13 — Reel 051579/0773

  • Conveyance: ASSIGNMENT OF ASSIGNORS INTEREST
  • Assignor: GLOBAL INNOVATION AGGREGATORS, LLC
  • Assignee: K.MIZRA LLC, CALIFORNIA
  • Correspondent: NICK ZIMMERMAN, 10887 White Rock Rd., Ste. 200, Rancho Cordova, CA 95670. This correspondent recurs in this chain.
  • Context: Transfer between entities with names suggesting patent aggregation/licensing, indicating a further sale within the assertion ecosystem.

Timeline diagram

timeline
    title Ownership of US 8018880
    2008 : Filed by Brixham Solutions Ltd
         : Inventors assigned to Hammerhead Systems
    2010 : Hammerhead assigned to Brixham
    2011 : Patent issued
    2017 : Brixham assigned to Global Innovation Aggregators
    2020 : Global Innovation Aggregators assigned to K.MIZRA LLC
    2024 : Infringement suit filed by K.MIZRA

NPE / troll-pattern signals

1. Shell-entity transfer — Present.

   • Global Innovation Aggregators LLC (assignee in Reel 043312/0218) has a name highly suggestive of a patent aggregation or licensing entity, typically a shell.
   • K.MIZRA LLC (assignee in Reel 051579/0773) is the current assignee, has a generic name, and is known to be asserting this patent in litigation. These characteristics are consistent with a shell entity.
   • Brixham Solutions Ltd. (assignee in Reel 023810/0916, assignor in Reel 043312/0218): Its re-acquisition of the patent from an operating company (Hammerhead) and subsequent transfer to other aggregation-named entities strongly suggests it acted as a patent holding/licensing entity.

2. Known asserter in the chain — Present. K.MIZRA LLC is the current assignee and has active litigation for this patent (Case 2:24-cv-00974 in Texas Eastern District Court), identifying it as an asserting entity.

3. Repeat correspondent across the chain — Present. NICK ZIMMERMAN, 10887 White Rock Rd., Ste. 200, Rancho Cordova, CA 95670, is the correspondent for the assignment to Global Innovation Aggregators LLC (Reel 043312/0218) and the subsequent assignment to K.MIZRA LLC (Reel 051579/0773). This recurrence indicates a consistent legal representative for these entities.

4. Cascading transfers — Not present. The transfers from Brixham to Global Innovation Aggregators (recorded 2017-08-16) and then to K.MIZRA LLC (recorded 2020-01-13) are separated by more than 24 months based on both executed and recorded dates.

5. Pre-litigation transfer — Not present. The assignment to K.MIZRA LLC was executed on 2019-12-24 and recorded on 2020-01-13 (Reel 051579/0773). The earliest identified litigation (2:24-cv-00974) was filed in 2024, which is not within 6 months of the transfer date.

6. Bankruptcy fire-sale — Not present. There is no indication that any of the assignors in the chain filed for bankruptcy. While Hammerhead Systems, Inc. was acquired, the patent transfer occurred before the acquisition and was not part of bankruptcy proceedings.

7. Privateering — Unclear. The patent was transferred from an operating company (Hammerhead Systems, Inc.) to Brixham Solutions Ltd. before Hammerhead's acquisition. It is not explicitly documented that Brixham, Global Innovation Aggregators, or K.MIZRA are asserting the patent on behalf of an operating company against its competitors.

8. Defensive aggregator (anti-NPE) — Not present. The chain terminates with K.MIZRA LLC, which is an asserting entity, not a defensive aggregator.

Verdict

NPE — high confidence

This verdict is supported by the presence of multiple strong signals: the patent is currently held by K.MIZRA LLC, a non-operating entity actively involved in litigation. The chain includes transfers to other shell-like entities (Global Innovation Aggregators LLC), and the same correspondent attorney, Nick Zimmerman, handled the recordings for these two most recent transfers (Reel 043312/0218 and Reel 051579/0773), indicating a consistent legal strategy associated with patent assertion.

USPTO Assignment Center Search: https://assignmentcenter.uspto.gov/

To identify the most relevant prior art for US patent 8,018,880, I will review the "Citations" section of the patent itself, as this lists the prior art that the patent examiner and applicants considered during prosecution. "Prior art" refers to existing knowledge or inventions that predate the patent application and are used to determine if an invention is new and non-obvious.

Below are the patent citations listed in US8018880B2, along with their publication/filing dates and a brief description. I will then analyze which claims they potentially anticipate under 35 U.S.C. § 102.

Most Relevant Prior Art for US Patent 8,018,880:

The patent 8,018,880 cites the following U.S. patents as prior art:

• US20040037279A1 to David Zelig

  • Publication Date: February 26, 2004
  • Description: This patent application describes a Virtual Private LAN Service using a multicast protocol. It relates to creating virtual private networks and handling multicast traffic within them.
  • Potential Anticipation (35 U.S.C. § 102): Claims 1, 14, 26, and 39 generally describe the creation of L2VPNs and the use of VSIs. While Zelig's application focuses on VPLS and multicast, the fundamental concept of establishing a Layer 2 VPN and managing traffic within it could potentially anticipate the broad idea of an L2VPN as generally described in the preamble of these claims. However, the specific PBB/PBT technology and the novel split horizon rules of 8,018,880 would likely differentiate it.

• US20040042454A1 to Attaullah Zabihi

  • Publication Date: March 4, 2004
  • Description: This patent application describes stackable virtual local area network provisioning in bridged networks, focusing on how VLANs can be provisioned in a hierarchical manner.
  • Potential Anticipation (35 U.S.C. § 102): The concept of assigning customers to separate VLANs or service instances to create L2VPNs is mentioned as a known solution in the background of 8,018,880. Zabihi's application, focusing on stackable VLAN provisioning, could be considered in relation to how service instances (which can be identified by VLAN IDs or stacked VLAN IDs) are used to differentiate customer traffic, as discussed in the description of 8,018,880. This could potentially anticipate aspects related to Service Instance identification in claims like Claim 6 (method) and Claim 19 (system).

• US20040081171A1 to Finn Norman W.

  • Publication Date: April 29, 2004
  • Description: This patent application describes a large-scale Layer 2 metropolitan area network.
  • Potential Anticipation (35 U.S.C. § 102): This reference could potentially anticipate the general concept of a large-scale L2VPN over an Ethernet network, which is a problem 8,018,880 aims to solve. However, 8,018,880 specifically addresses PBB/PBT networks and their interworking with VPLS, offering more detailed solutions for these technologies.

• US20050013297A1 to Telefonaktiebolaget Lm Ericsson (Publ)

  • Publication Date: January 20, 2005
  • Description: This patent application details arrangements for connection-oriented transport in a packet switched communications network.
  • Potential Anticipation (35 U.S.C. § 102): Given that PBT/PBB-TE trunks are connection-oriented, this reference might generally anticipate the concept of establishing connection-oriented paths for transport within a packet-switched network, as broadly mentioned in the coupling steps of claims 1, 14, 26, and 39.

• US20050044262A1 to Cisco Technology, Inc.

  • Publication Date: February 24, 2005
  • Description: This patent application focuses on a system and method for interconnecting heterogeneous Layer 2 VPN applications.
  • Potential Anticipation (35 U.S.C. § 102): This reference is highly relevant as 8,018,880 specifically addresses seamless interworking between L2VPN over PBB and VPLS (an MPLS-based L2VPN). Claim 1 and its dependent claims, as well as claims 14, 26, and 39 (if they include the MPLS interworking), could potentially be anticipated by the broad concept of interconnecting heterogeneous L2VPN applications. However, the specific "split horizon" rules and the use of PBB/PBT as the underlying transport for one of the L2VPNs, as detailed in 8,018,880, would be key distinguishing features.

• US20060029032A1 to Nortel Networks Limited

  • Publication Date: February 9, 2006
  • Description: This patent application describes a system and method for a hub and spoke virtual private network.
  • Potential Anticipation (35 U.S.C. § 102): The general concept of a VPN and its topology (hub and spoke) could broadly relate to the L2VPN services described in 8,018,880. However, 8,018,880 emphasizes a multipoint-to-multipoint service using a full mesh of PBT trunks or Service Instances.

• US20060187950A1 to Alcatel

  • Publication Date: August 24, 2006
  • Description: This patent application covers an architecture and provisioning tools for managed multicast virtual private LAN trees.
  • Potential Anticipation (35 U.S.C. § 102): Similar to Zelig (US20040037279A1), this reference could potentially anticipate aspects related to multicast forwarding in an L2VPN context, as 8,018,880 mentions supporting unicast, broadcast, and multicast forwarding. The "provisioning tools" aspect could also generally relate to the use of a control plane, though 8,018,880 specifies an external control plane.

• US20070008982A1 to Cisco Technology, Inc.

  • Publication Date: January 11, 2007
  • Description: This patent application describes redundant pseudowires between Ethernet access domains.
  • Potential Anticipation (35 U.S.C. § 102): This reference is relevant to the reliability aspects of L2VPNs. The description of 8,018,880 mentions connecting a customer location to multiple service provider sites for redundant access (FIG. 2) and discusses the slow recovery of STP-based solutions. The concept of redundant pseudowires could potentially anticipate methods of providing redundancy for L2VPN services, though the specific PBB/PBT and VPLS interworking might still be distinguishing.

• US20080101390A1 to Chunzhe Hu

  • Publication Date: May 1, 2008 (Filed: August 9, 2005)
  • Description: This patent application describes a method and system for implementing hierarchical VPLS.
  • Potential Anticipation (35 U.S.C. § 102): This is highly relevant as 8,018,880 describes its architecture as a "hierarchical L2VPN service where a L2VPN over PBB (L2VPNoPBB) is used at the metro network, while VPLS is used at the MPLS WAN (core) network" (FIG. 3). Claims 9, 10, 12, 22, 24, 34, 35, 37, 47, and 48, which specifically refer to VPLS and hierarchical L2VPNs, could be directly impacted by this prior art. Chunzhe Hu's application directly addresses hierarchical VPLS, which could anticipate the general concept of combining different L2VPN technologies in a hierarchical manner. However, the specific combination with PBB and the unique split horizon rules in 8,018,880 could be distinguishing.

• US20080172497A1 to Nortel Networks Limited

  • Publication Date: July 17, 2008 (Filed: January 17, 2007)
  • Description: This patent application describes a method and apparatus for interworking Ethernet and MPLS networks.
  • Potential Anticipation (35 U.S.C. § 102): This is also very relevant, as a core aspect of 8,018,880 is the seamless interworking between PBB (an Ethernet network) and MPLS networks (via VPLS). Claims 1, 9, 12, 14, 24, 26, 34, 37, 39, 47, and 50, which address this interworking, could be anticipated by the broad concept disclosed by Nortel. The specific mechanisms, such as the described split horizon rules for the interworking VSI, would be critical for distinguishing 8,018,880.

• US20080219268A1 to Dennison Larry R.

  • Publication Date: September 11, 2008 (Filed: March 1, 2007)
  • Description: This patent application describes a software control plane for switches and routers.
  • Potential Anticipation (35 U.S.C. § 102): This reference is directly pertinent to the "external control plane" aspect of 8,018,880. Claims 1, 14, 26, and 39 all include provisioning VSIs using an external control plane. Dennison's application describes a software control plane that is not tied to specific router hardware, which aligns with the advantages of an external control plane highlighted in 8,018,880 (e.g., eliminating hardware limitations and vendor lock-in). This reference could potentially anticipate the use of an external control plane for provisioning network elements.

• US20080247406A1 to Hammerhead Systems, Inc.

  • Publication Date: October 9, 2008 (Filed: March 26, 2007)
  • Description: This is a publication of the same patent application as 8,018,880, but published prior to the grant of 8,018,880. It has the same title: "Layer 2 virtual private network over PBB-TE/PBT and seamless interworking with VPLS".
  • Potential Anticipation (35 U.S.C. § 102): This is a continuation-in-part or related application, and as such, it would likely be considered co-pending or part of the same patent family, not typically prior art for novelty purposes under 35 U.S.C. § 102 unless specific priority dates or inventorship issues arise. However, for a complete analysis, it's important to note its existence.

• US7787478B2 to Cisco Technology, Inc.

  • Publication Date: August 31, 2010 (Filed: March 7, 2006)
  • Description: This patent describes managing traffic within and between virtual private networks when using a session border controller.
  • Potential Anticipation (35 U.S.C. § 102): While focusing on session border controllers, the broader concept of managing traffic within and between VPNs is relevant. Claims in 8,018,880 dealing with frame forwarding (e.g., split horizon rules in claims 1, 14, 26, and 39) could be broadly related to traffic management, though the specific context and mechanisms differ significantly.

• US20040170173A1 to Ping Pan

  • Publication Date: September 2, 2004
  • Description: This patent application describes a method and apparatus for transporting packet data over an optical network.
  • Potential Anticipation (35 U.S.C. § 102): This could generally anticipate the transport of packet data, which underlies L2VPNs. However, it does not specifically address PBB/PBT or the advanced L2VPN features of 8,018,880.

• US20050169270A1 to Ryoichi Mutou

  • Publication Date: August 4, 2005
  • Description: This patent application describes a router, frame forwarding method, and lower layer frame virtual forwarding system.
  • Potential Anticipation (35 U.S.C. § 102): Mutou's application could potentially anticipate aspects of frame forwarding within a virtualized networking environment, as addressed by the VSI and split horizon rules in 8,018,880.

• US20060047851A1 to Cisco Technology, Inc.

  • Publication Date: March 2, 2006
  • Description: This patent application describes a computer network with point-to-point pseudowire redundancy.
  • Potential Anticipation (35 U.S.C. § 102): Similar to US20070008982A1, this addresses redundancy using pseudowires. While 8,018,880 uses PBT trunks, the idea of robust point-to-point connections with redundancy could be generally anticipated.

• US20060245436A1 to Cisco Technology, Inc.

  • Publication Date: November 2, 2006
  • Description: This patent application describes a comprehensive model for VPLS.
  • Potential Anticipation (35 U.S.C. § 102): This is highly relevant to the VPLS portion of 8,018,880. The comprehensive VPLS model could potentially anticipate the VPLS network described in 8,018,880, especially those claims dealing with the VPLS part of the end-to-end L2VPN (e.g., claims 9, 10, 12, 22, 24, 34, 35, 37, 47, and 48). The specific interworking with PBB and the unique split horizon rules would be the distinguishing features.

• US20070086361A1 to Nortel Networks Limited

  • Publication Date: April 19, 2007 (Filed: October 5, 2005)
  • Description: This patent application describes Provider Link State Bridging.
  • Potential Anticipation (35 U.S.C. § 102): While not PBT, Provider Link State Bridging is another approach to carrier Ethernet networking. This could broadly relate to the underlying bridging technologies used in the PBB network.

• US7688756B2 to Nortel Networks Limited

  • Publication Date: March 30, 2010 (Filed: October 5, 2005)
  • Description: This patent describes Provider Link State Bridging (a granted patent from US20070086361A1).
  • Potential Anticipation (35 U.S.C. § 102): Same as above, but as a granted patent, it carries more weight. It could broadly relate to the underlying bridging technologies used in the PBB network.

• US20080212595A1 to Hammerhead Systems, Inc.

  • Publication Date: September 4, 2008 (Filed: January 25, 2007)
  • Description: This patent application describes mapping PBT and PBB-TE traffic to VPLS and other services.
  • Potential Anticipation (35 U.S.C. § 102): This is highly relevant as it explicitly discusses mapping PBT/PBB-TE traffic to VPLS. This could potentially anticipate aspects of the interworking function between L2VPN over PBB and VPLS, as described in 8,018,880, particularly in claims related to seamless interworking (e.g., claims 1, 9, 12, 14, 24, 26, 34, 37, 39, 47, and 50). The specifics of the "split horizon" rules in 8,018,880 would be a key area for differentiation.

• US20080279196A1 to Robert Friskney

  • Publication Date: November 13, 2008 (Filed: April 6, 2004)
  • Description: This patent application describes differential forwarding in address-based carrier networks.
  • Potential Anticipation (35 U.S.C. § 102): This could generally anticipate aspects of traffic forwarding and differentiation within carrier networks, but it's less specific to the PBB/PBT and VPLS interworking or the novel split horizon rules of 8,018,880.

Overall Assessment of Prior Art Relevance:

The most relevant prior art references for US patent 8,018,880 appear to be those that directly address the creation of L2VPNs, interworking between different Layer 2 technologies (especially Ethernet and MPLS), hierarchical VPN structures, and the use of control planes for provisioning. Specifically:

• US20050044262A1 (Cisco Technology, Inc.): Interconnecting heterogeneous Layer 2 VPN applications.
• US20080101390A1 (Chunzhe Hu): Hierarchical VPLS.
• US20080172497A1 (Nortel Networks Limited): Interworking Ethernet and MPLS networks.
• US20060245436A1 (Cisco Technology, Inc.): Comprehensive model for VPLS.
• US20080212595A1 (Hammerhead Systems, Inc.): Mapping PBT and PBB-TE traffic to VPLS and other services.
• US20080219268A1 (Dennison Larry R.): Software control plane for switches and routers.

These references collectively suggest that many of the individual components or broader concepts (L2VPNs, VPLS, interworking between Ethernet/MPLS, external control planes) were known in the art. The novelty of US8018880B2 largely lies in the specific combination of PBB/PBT with VPLS and, critically, the novel split horizon rules (claims 1, 14, 26, 39) that are designed to prevent loops in these specific interworking scenarios, especially at the boundaries between PBB and MPLS networks, or between PBB core and metro networks. An argument for anticipation under 35 U.S.C. § 102 would need to demonstrate that one or more of these prior art references explicitly or inherently discloses all elements of a given claim, including the specific details of the split horizon rules and their application in the described architectural context.

Obviousness Analysis of US Patent 8,018,880 under 35 U.S.C. § 103

This analysis assesses the obviousness of US patent 8,018,880 based on the provided prior art, from the perspective of a Person Having Ordinary Skill in the Art (PHOSITA) at the time of the invention (priority date March 26, 2007). A PHOSITA in this field would likely possess a Bachelor's or Master's degree in Electrical Engineering, Computer Science, or a related field, along with several years of experience (e.g., 3-5+ years) in designing, implementing, or operating carrier-grade Ethernet networks, MPLS networks, or enterprise networking solutions. Such a person would be familiar with relevant IEEE standards (e.g., 802.1ah for PBB, 802.1Qay for PBB-TE/PBT) and IETF RFCs (e.g., RFC 4761, 4762 for VPLS), network management protocols (e.g., SNMP, CLI), and fundamental bridging concepts including MAC address learning and loop prevention mechanisms like Spanning Tree Protocol (STP) and split horizon.

The patent US8018880B2 introduces methods, systems, and computer program products for creating Layer 2 Virtual Private Networks (L2VPNs) over Provider Backbone Bridge (PBB) networks using Provider Backbone Transport (PBT) or PBB Traffic Engineering (PBB-TE) trunks. Key aspects include provisioning Virtual Switch Instances (VSIs) via an external control plane and employing novel split horizon rules for: (1) interworking between PBB and Multi Protocol Label Switching (MPLS) networks (specifically VPLS), and (2) interworking between PBB core and PBB metro networks.

Argument 1: Obviousness of PBB-MPLS (VPLS) Interworking with External Control Plane and Adapted Split Horizon Rules (Claims 1, 14, 26)

Differences from Prior Art:
Claims 1, 14, and 26 describe an L2VPN over a PBB network using PBT/PBB-TE trunks, with VSIs provisioned by an external control plane. The most distinct feature is the application of specific split horizon rules at a VSI coupling the PBB network to an MPLS network (VPLS). These rules dictate frame forwarding based on the ingress interface type (Service Instance over PBT, Pseudowire over MPLS, or customer bound interface) to prevent loops.

Motivation for Combination and Obviousness:
A PHOSITA, at the time of the invention, would have been motivated to combine known networking technologies and techniques to achieve scalable and robust L2VPN services.

1. Interworking of Heterogeneous L2VPNs: The problem of interconnecting different Layer 2 VPN technologies, such as Ethernet networks and MPLS-based VPLS, was well-known. For instance, US20050044262A1 (Cisco Technology, Inc.) teaches a "system and method for interconnecting heterogeneous Layer 2 VPN applications," directly addressing the general problem of interworking. Similarly, US20080172497A1 (Nortel Networks Limited) describes a "method and apparatus for interworking Ethernet and MPLS networks." More specifically, US20080212595A1 (Hammerhead Systems, Inc.) explicitly describes "mapping PBT and PBB-TE traffic to VPLS and other services," demonstrating a direct teaching to combine these specific technologies. Given these teachings, it would have been obvious for a PHOSITA to combine PBB/PBT L2VPNs with VPLS L2VPNs to provide broader connectivity. The use of Virtual Switch Instances (VSIs), which are recognized as standard learning bridges (IEEE 802.1D and 802.1Q) and are fundamental to VPLS (IETF RFC 4762 and RFC 4761), at the interworking point would be a predictable architectural choice for bridging traffic between these two network types.

2. External Control Plane Provisioning: The use of an external control plane for provisioning network elements was also a known and desirable approach for managing network complexity and achieving scalability. US20080219268A1 (Dennison Larry R.) describes a "software control plane for switches and routers" and highlights its advantages in decoupling control logic from hardware for improved scalability and innovation. The '880 patent itself details similar benefits of an external control plane. A PHOSITA would have been motivated to apply such an external control plane to automate the provisioning of VSIs and PBT trunks in a combined PBB-VPLS environment, leveraging its known benefits for large-scale deployments.

3. Adapted Split Horizon Rules for Loop Prevention: The fundamental problem of forwarding loops in interconnected bridged networks is well-understood, and "split horizon" is a known technique to prevent such loops in L2VPNs. The '880 patent explicitly acknowledges this by stating, "A form of split horizon is also used with VPLS, as described in RFC 4762." [cite: Current time information in United States of America.] RFC 4762's split horizon rule (rule 511 in FIG. 5 of '880 patent) prevents frames from being forwarded back to another Pseudowire, thereby avoiding loops within a VPLS network.
   A PHOSITA, combining a PBB network with a VPLS network via a VSI, would immediately recognize the potential for forwarding loops at this interworking point. Motivated by the known need for loop prevention in such scenarios and the existing use of split horizon in VPLS, they would predictably adapt the split horizon principle. The claimed rules (1) "in the event a frame is received from a Service Instance over one of the plurality of provider backbone trunks, the received frame is forwarded to Pseudowires over the MPLS network and a set of customer bound interfaces" and (2) "in the event a frame is received from a Pseudowire over the MPLS network, the received frame is forwarded to a set of Service Instances over the plurality of provider backbone trunks and a set of customer bound interfaces" are direct and logical extensions of the split horizon principle. These rules prevent frames from re-entering their originating network segment (PBB frames from going back to PBB, MPLS frames from going back to MPLS) through the interworking VSI, while allowing forwarding to the other network segment and local customer interfaces. Rule (3), allowing normal VSI forwarding for frames from customer interfaces, is standard bridge behavior to reach all parts of the L2VPN. This adaptation of a known loop prevention technique to a new but analogous interworking context would be obvious to a PHOSITA.

Therefore, the combination of the teachings from US20050044262A1 (interconnecting heterogeneous L2VPNs), US20080212595A1 (mapping PBT/PBB-TE to VPLS), the established VPLS split horizon principle (RFC 4762 as acknowledged in '880), and US20080219268A1 (external control plane), would render the methods, systems, and computer program products of claims 1, 14, and 26 obvious.

Argument 2: Obviousness of PBB Core-Metro Interworking with External Control Plane and Adapted Split Horizon Rules (Claim 39)

Differences from Prior Art:
Claim 39 describes a method for interconnecting a PBB core network with a PBB metro network using a VSI. The key distinguishing feature is the application of specific split horizon rules at this interworking VSI to manage frame distribution between the core and metro segments and customer interfaces.

Motivation for Combination and Obviousness:

1. Hierarchical PBB Network Architectures: The concept of segmenting a large L2 network into hierarchical components, such as metro and core networks, is a known scaling practice in telecommunications and Ethernet networks. The patent itself implies this by describing an "end-to-end L2VPN over PBB for a customer using a PBB Core network and two PBB metro networks" (FIG. 6) and stating that "one or multiple PBB metro networks can be connected to a PBB core network." This indicates that such hierarchical PBB deployments were either existing or a natural evolution. US20040081171A1 (Finn Norman W.) describes a "large-scale Layer 2 metropolitan area network," broadly suggesting the context of large, segmented L2 networks. A PHOSITA would recognize the benefits of such segmentation for scalability and management in a PBB environment. Interconnecting these segments using VSIs, which function as learning bridges, would be a conventional approach for bridging traffic.

2. External Control Plane Provisioning: As discussed for Argument 1, the provisioning of VSIs and PBT trunks via an external control plane, as claimed in claim 39, would be obvious in light of US20080219268A1 (Dennison Larry R.), which promotes the use of such control planes for flexible and scalable network management.

3. Adapted Split Horizon Rules for Loop Prevention in PBB Core-Metro: When interconnecting two bridged PBB domains (core and metro) via a VSI, a PHOSITA would readily identify the potential for forwarding loops, similar to the interworking scenario with VPLS or any interconnected bridged network. Given the established knowledge of split horizon as a loop prevention mechanism in L2VPNs (e.g., in VPLS as per RFC 4762 and acknowledged by '880), a PHOSITA would be motivated to adapt this technique for the PBB core-metro interworking VSI.
   The claimed split horizon rules for this scenario (rule 601 in FIG. 6 of '880 patent) state: (1) "whenever a frame is received from one of a second set of Service Instances over the second plurality of provider backbone trunks of the PBB metro network, the received frame can only be forwarded to the first set of Service Instances over the first plurality of provider backbone trunks of the PBB core network and a set of customer bound interfaces;" and (2) "whenever a frame is received from one of a first set of Service Instances over the first plurality of provider backbone trunks of the PBB core network, the received frame can only be forwarded to the second set of Service Instances over the second plurality of provider backbone trunks of the PBB metro network and a set of customer bound interfaces." These rules are a direct application of the core split horizon principle: a frame arriving from a specific segment (metro or core) is prevented from being forwarded back into the same segment through the interworking VSI, while being allowed to proceed to the other segment and local customer interfaces. Rule (3), allowing normal VSI forwarding for frames from customer interfaces, is standard bridge behavior. This adaptation of a known and effective loop prevention method to a new but analogous interworking point, addressing a predictable problem, would be obvious to a PHOSITA.

Therefore, the combination of the known architectural practice of hierarchical L2 networks (as generally understood and implied by the patent figures), the standard use of VSIs as learning bridges, the well-known principles of split horizon for loop prevention in L2VPNs (RFC 4762 as acknowledged in '880), and the teachings of US20080219268A1 (external control plane), would render the method of claim 39 obvious.

US Patent 8,018,880 was filed on March 25, 2008, and issued on September 13, 2011.

Patent Term Adjustments (PTA) and Patent Term Extensions (PTE)

The patent explicitly states that it is "Active, expires 2028-08-13" and includes an entry for "Adjusted expiration" on that date. [cite: Current time information in United States of America.]

Patent Term Adjustment (PTA) is granted by the USPTO to compensate for administrative delays during patent prosecution. It adds to the typical 20-year term from the earliest claimed filing date. The specific "Adjusted expiration" date of August 13, 2028, indicates that some PTA was applied to US 8,018,880.

Patent Term Extensions (PTE) are distinct from PTA and are typically granted for delays due to premarket regulatory review, such as for pharmaceuticals. There is no information in the provided text to suggest that US 8,018,880 received a Patent Term Extension under 35 U.S.C. 156.

Continuation and Divisional Applications

The patent is listed as claiming priority to U.S. Provisional Patent Application No. 60/920,227, filed March 26, 2007, and US12/079,413, filed March 25, 2008. [cite: Current time information in United States of America.]

The USPTO Open Data Portal provides a "Continuity" section where information regarding parent and child applications can be found. A specific search of the USPTO database would be required to definitively confirm if US 8,018,880 is a continuation or divisional of other applications, or if it has led to any such applications. However, based on the provided text, the application number US12/079,413 is listed as an "Application filed by Brixham Solutions Ltd" on March 25, 2008, and US8018880B2 is the publication of this application. [cite: Current time information in United States of America.] It claims priority to the provisional application.

Related Family Members

The patent family for US8018880B2 includes: [cite: Current time information in United States of America.]

• US20080247406A1: This is a publication of the same patent application as US8018880B2. [cite: Current time information in United States of America.]
• WO2008118467A1 [cite: Current time information in United States of America.]
• EP2183887A4 [cite: Current time information in United States of America.]

These are international and European equivalents or related publications of the same invention.

Projected Expiration Date

The "Legal status" section of the patent explicitly states: "Active, expires 2028-08-13". [cite: Current time information in United States of America.] This "Adjusted expiration" date reflects the original 20-year term from the earliest effective filing date, plus any Patent Term Adjustments (PTA) accrued during prosecution.

Therefore, the projected expiration date for US Patent 8,018,880 is August 13, 2028. [cite: Current time information in United States of America.]

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.