A routing hub

Abstract

A routing hub for connecting airport infrastructure to a combination of public and private hosted services is provided, the routing hub comprising: a set of input connections including at least one MPLS input connection and one non-MPLS input connection; a set of output connections including at least one MPLS output connection and one non-MPLS output connection; and a plurality of aggregation routers arranged between the set of input connections and set of output connections, the aggregation routers arranged to maintain network traffic segregation or provide network traffic aggregation between MPLS and non- MPLS connections based on a set of rules. A system comprising a plurality of the routing hubs and a fabric network connecting the routing hubs is also provided, wherein each routing hub is located at a different location and is configured to operate as a point of presence for a predetermined region associated with the routing hub. A method of providing network connectivity using the routing hub is also disclosed, including receiving data via MPLS and non-MPLS input connections, processing the data at aggregation routers, and transmitting the processed data via MPLS and non-MPLS output connections. A method of providing network connectivity using the system is also disclosed, including receiving traffic at one of the routing hubs, processing the traffic at aggregation routers based on the rules, and forwarding processed traffic via the fabric network to other routing hubs.

Description

[0001] A ROUTING HUB

[0002] BACKGROUND OF THE INVENTION

[0003] This application relates to a routing hub and method of operating a routing hub within a network of routing hubs.

[0004] In the aviation industry, multiple network entities, such as airport infrastructures, airlines, and related service providers, must exchange data to support their operations. However, significant incompatibilities often exist between their network systems. These incompatibilities commonly necessitate additional network infrastructure or the replacement of existing facilities to enable data transfer between entities employing different data transport technologies. Such variations typically arise due to subsector-specific preferences, regional differences, or varying levels of modernisation, including reliance on or tolerance of legacy network protocols and devices. Furthermore, even within a single network entity, different network elements may use distinct data transport technologies.

[0005] One approach to addressing these challenges involves implementing multiple network connectivity solutions, such as multiprotocol label switching (MPLS), software-defined wide area network (SD-WAN), internet, cross-connects, and cloud provider interchange, to connect various locations, including airports and off-airport sites, to IT systems and services hosted in public or private clouds, datacentres, or co-location facilities. However, current solutions face several limitations. For example, access to hosted solutions, such as Infrastructure as a Service (laaS), often requires an MPLS connection for each entity, even when sufficient internet connectivity is already in place.

[0006] Furthermore, as internet connectivity becomes increasingly reliable, there is a growing shift towards public cloud adoption. However, there remains a need to provide both public and private network connectivity for critical operations from airports and off-airport locations. Also, there is growing demand for reducing the reliance on MPLS and transitioning to internet-only or hybrid network solutions while maintaining access to services in both public and private networks.

[0007] Accordingly, there is a need for a solution that minimises the need for additional infrastructure, simplifies the interconnection model, supports migration to public or privatecloud ecosystems, minimises restrictions imposed by service providers, and accelerates network and application deployment times.

[0008] SUMMARY OF THE INVENTION

[0009] The invention is defined in the independent claims to which reference should now be directed. Advantageous features are set out in the dependent claims.

[0010] In a first aspect, the present disclosure relates to a routing hub for connecting airport infrastructure to a combination of public and private hosted services, comprising: a set of input connections including at least one MPLS input connection and one non-MPLS input connection; a set of output connections including at least one MPLS output connection and one non-MPLS output connection; and a plurality of aggregation routers arranged between the set of input connections and set of output connections, the aggregation routers arranged to maintain network traffic segregation or provide network traffic aggregation between MPLS and non-MPLS connections based on a set of rules.

[0011] Optionally, the set of rules may include at least one rule that causes the aggregation routers to aggregate multiple MPLS inputs to fewer MPLS outputs.

[0012] Optionally, the set of rules may include at least one rule that causes the aggregation routers to aggregate one or more MPLS inputs to a higher number of MPLS outputs.

[0013] Optionally, the set of rules may include at least one rule that causes the aggregation routers to aggregate one or more MPLS inputs to one or more non-MPLS outputs.

[0014] Optionally, the set of rules may include at least one rule that causes the aggregation routers to aggregate one or more non-MPLS inputs to one or more MPLS outputs.

[0015] Optionally, the set of rules may include at least one rule that causes the aggregation routers to aggregate one or more non-MPLS inputs of a first type to one or more non-MPLS outputs of a second type.Optionally, the non-MPLS connections may transport data by using one or more of: software-defined wide area network, direct internet, internet via a virtual private network, SD-WAN, Internet, cross-connects, and cloud provider interchange.

[0016] Optionally, the airport infrastructure may include a departure control system.

[0017] Optionally, the departure control system may be provided via traditional third-party hosting.

[0018] Optionally, the airport infrastructure may be located at airport premises.

[0019] Optionally, the airport infrastructure may be located at a location remote from airport premises, and the airport infrastructure is configured to communicate with the airport premises via a communication network.

[0020] In a second aspect, the present disclosure relates to a system comprising a plurality of the routing hubs and a fabric network connecting the routing hubs, wherein each routing hub is located at a different location and is configured to operate as a point of presence for a predetermined region associated with the routing hub.

[0021] Optionally, the predetermined region may be determined based on geographical distance to the routing hub or one or more known network conditions, including latency.

[0022] Optionally, the system may further comprise one or more sub-routing hubs located at a location remote from the plurality of routing hubs, and each of the one or more sub-routing hubs is configured to communicate with at least one of the plurality of routing hubs.

[0023] In a third aspect, the present disclosure relates to a method of providing network connectivity using a routing hub, the method comprising receiving data via a set of input connections including at least one MPLS input connection and at least one non-MPLS input connection; processing the data at a plurality of aggregation routers arranged between the set of input connections and a set of output connections; and transmitting the processed data via the set of output connections including at least one MPLS output connection and at least one non-MPLS output connection, wherein the aggregation routers maintain network traffic segregation or provide network traffic aggregation between MPLS and non-MPLS connections based on a set of rules.In a fourth aspect, the present disclosure relates to a method of providing network connectivity using a system comprising a plurality of routing hubs and a fabric network connecting the routing hubs, each routing hub being located at a different location and configured to operate as a point of presence for a predetermined region associated with the routing hub, the method comprising receiving, at one of the routing hubs, traffic via at least one MPLS input connection and at least one non-MPLS input connection; processing the traffic at aggregation routers of that routing hub based on a set of rules that maintain network traffic segregation or provide network traffic aggregation between MPLS and non-MPLS connections; and forwarding at least part of the processed traffic via the fabric network to one or more other routing hubs for delivery to public or private hosted services.

[0024] BRIEF DESCRIPTION OF THE DRAWINGS

[0025] Embodiments of the invention will now be described, by way of example only, and with reference to the accompanying drawings, in which:

[0026] Figure 1 is a schematic representation of a routing hub and its associated network connections, according to an embodiment;

[0027] Figure 2 is a schematic representation of regional edge network connections at an airport, according to an embodiment;

[0028] Figure 3 is a schematic representation of a system comprising multiple routing hubs distributed at multiple locations, according to an embodiment;

[0029] Figure 4A is a schematic representation of a high-level physical infrastructure design of an example regional global Point of Presence, according to an embodiment;

[0030] Figure 4B is a schematic representation of an example distributed regional global Point of Presence implemented across multiple data centres, according to an embodiment;

[0031] Figure 5 is a schematic representation of a system comprising routing hubs and mini routing hubs distributed across multiple geographic locations, according to an embodiment;Figure 6A is a schematic representation of SD-WAN inbound customer access traffic flows, according to an embodiment;

[0032] Figure 6B is a schematic representation of third-party vendor or co-location customer traffic flows, according to an embodiment;

[0033] Figure 6C is a schematic representation of IPSec VPN internet access customer flows, according to an embodiment;

[0034] Figure 6D is a schematic representation of Cloud Exchange fabric access customer flows, according to an embodiment; and

[0035] Figure 6E is a schematic representation of OBS MPLS customer flows, according to an embodiment.

[0036] DETAILED DESCRIPTION

[0037] Figure 1 illustrates an example of a routing hub 100 and its associated network connections, according to an embodiment. The example shown in Figure 1 is provided in the form of a multi-tenant solution in an example use case for the aviation industry, connecting airports and off-airport locations to the routing hub 100 (“Connectivity Hub”) and transporting them to other hosting locations. However, it will be appreciated that, in other embodiments, the routing hub 100 may be implemented in alternative forms and may also be used in industries outside the aviation sector.

[0038] As shown in the example of Figure 1, the routing hub 100 may connect airport infrastructure at airport premises to a combination of public and private hosted services. Alternatively, the routing hub 100 may connect airport infrastructure located at a location remote from airport premises. In such cases, the airport infrastructure is configured to communicate with the airport premises via a communication network.

[0039] The routing hub 100 comprises a set of input connections, including at least one Multiprotocol Label Switching (MPLS) input connection and at least one non-MPLS input connection. The at least one MPLS input connection is configured to transport data to therouting hub 100 using MPLS. The at least one non-MPLS input connection is configured to transport data to the routing hub 100 using a network transport technology other than MPLS. The routing hub 100 also comprises a set of output connections, including at least one MPLS output connection and one non-MPLS output connection. The at least one MPLS output connection is configured to transport data from the routing hub 100 using MPLS. The at least one non-MPLS output connection is configured to transport data from the routing hub 100 using a network transport technology other than MPLS.

[0040] While the terms “input connection” and “output connection” are used herein, this does not necessarily imply that separate connections must be provided for input and output. Thus, it will be appreciated that, in some embodiments, a single connection may be utilised to perform both input and output functions.

[0041] Furthermore, the term “non-MPLS” as used herein may include, but is not limited to, software-defined wide area network (SD-WAN), internet (including direct internet and internet via a virtual private network (VPN)), and other equivalent data transport technologies, as illustrated in Figure 1.

[0042] The routing hub 100 includes a plurality of aggregation routers arranged between the set of input connections and set of output connections. The aggregation routers are configured to maintain network traffic segregation or provide network traffic aggregation between MPLS and non-MPLS connections based on a set of rules.

[0043] For example, in a scenario where data is received from multiple network entities that utilise MPLS for data transport and needs to be transmitted to another entity that also uses MPLS for data transport, the routing hub 100 may receive the data from the multiple network entities via MPLS input connections for aggregation. The aggregated data may then be sent to the receiving entity via an MPLS output connection. It will be appreciated that the aggregated data may also be transmitted to more than one receiving network entity, such as in cases where multiple MPLS inputs correspond to fewer MPLS outputs.

[0044] Multiple inputs or outputs referred to herein do not necessarily correspond to multiple physical input or output connections. Thus, it will be appreciated that a single physical connection may be utilised to accommodate multiple inputs and / or outputs.The routing hub 100 may also be utilised to aggregate data transported using MPLS by receiving data from one or more MPLS input connections and transmitting it to one or more other network entities using non-MPLS data transport technology via non-MPLS output connections. Similarly, the routing hub 100 may also aggregate data transported using non-MPLS transport technology by receiving data from one or more non-MPLS input connections and transmitting it to one or more other network entities using MPLS via MPLS output connections.

[0045] In the aviation industry, where multiple network entities (e.g. airport infrastructures, airlines, and related service providers such as car rental companies or hotels) are required to exchange data for their operations, there are often significant incompatibilities between their network systems. These incompatibilities frequently necessitate the implementation of additional network facilities or the replacement of existing infrastructure to enable data transfer between entities utilising different data transport technologies. Such variations typically arise from the preferences of specific subsectors, regional differences, or varying levels of modernisation (e.g. differing degrees of reliance or tolerance on legacy network protocols and devices). Furthermore, even within a single network entity, different network elements may employ distinct data transport technologies. Accordingly, the capability of the routing hub 100 to aggregate both MPLS and non-MPLS inputs and outputs may be particularly advantageous in the aviation industry, as well as in similar network environments involving multiple entities with a number of data transport technologies.

[0046] Similarly, the routing hub 100 may also accommodate the aggregation of data from one or more non-MPLS inputs of one type to one or more non-MPLS outputs of another type.

[0047] As illustrated in Figure 1, the routing hub 100 may be provided in the form of, or may form a part of a multi-tenant solution that provides a shared set of infrastructure components. The components may be modular by design, and may optionally comprise SD-WAN gateway or router, firewalls, intrusion detection system (IDS), intrusion prevention system (IPS), network switching for layer 2 and layer 3 functionality, and / or MPLS gateways or routers.

[0048] The aggregation routers of the routing hub 100 may utilise the concept of virtual routing forwarding (VRF) tables to maintain network traffic segregation where required and to provide network aggregation based on the source and destination network traffic profiles from other components of the network. The aggregation routers may control how traffic issent to the final destination, for example, using IPv4 / IPv6 routing tables, which may be towards the internet, MPLS, private or public clouds, or to a network entity (e.g. customers, third parties, or providers) physically connected in the same location or region.

[0049] The aggregation routers may function as the demarcation point between public and private clouds, and pass network traffic across shared or dedicated physical network links. The aggregation routers may also be configured to connect multiple routing hubs 100 together using MPLS or private network.

[0050] When connecting to the MPLS gateways or routers, the traffic can maintain network segregation or be aggregated depending on the requirement. Quality of service can also be maintained or applied accordingly.

[0051] The SD-WAN gateways or routers may be multi-tenant in nature and may serve as the demarcation point between the SD-WAN customer overlays and non-SD-WAN networks, facilitating the transfer of traffic between these environments. Therefore, the inclusion of SD-WAN gateways or routers in the routing hub 100 eliminates the need to deploy additional SD-WAN Customer Premises Equipment (CPE) to extend the overlay.

[0052] The routing hub 100 may optionally be connected to or include one or more firewalls for securing network traffic from and to the internet. Such firewalls may be application aware and make decisions based on application, user and content. The firewalls may be connected to, or incorporate, an IDS and / or IPS to protect against evasive tactics, monitor and analyse traffic behaviour, and respond appropriately.

[0053] One of the primary use cases of the firewalls is to have the ability to encrypt and decrypt IPSec traffic via the internet but also via another medium if required. Once traffic enters the firewalls, it may be then securely passed to the aggregation routers to route towards the final destination.

[0054] The firewalls may also be used to provide internet access to on-premise locations that may not have internet connectivity locally (e.g. SD-WAN or MPLS). Thus, a regional hub may provide a distributed internet feed from the firewalls to the aggregation routers for onward distribution.Network switching may be employed to interconnect the various network components and can optionally aggregate physical links to enhance bandwidth and resiliency. The network switches will primarily utilise Layer 2 features, delegating routing tasks to the aggregation routers. However, if necessary, the switching layer may also incorporate Layer 3 capabilities.

[0055] For connectivity directly to customers’ physical networks that are located in the same building or region (e.g. within a co-location facility), the switches may terminate the connection and forward the traffic to the aggregation routers.

[0056] The network switches may be used to connect multiple routing hubs 100 together using a co-location physical network as an alternative to using MPLS provider for this purpose.

[0057] MPLS gateways / routers are traditionally employed for private wide area network (WAN) connectivity across domestic and international locations. They form a key component in the network design, enabling access to and from on-premise locations while ensuring guaranteed network bandwidth.

[0058] MPLS may also utilise virtual routing and forwarding (VRF) instances to segregate or aggregate network traffic, typically under the control of a service provider or telecommunications provider. The aggregation routers may determine how traffic is received from or sent to the MPLS gateways / routers.

[0059] Figure 3 illustrates a distributed network system 300, comprising multiple airports, each equipped with or connected to a routing hub (global PoP 100) that includes regional edge hosting 150 or is otherwise connected to an associated edge hosting component. The system employs a Global PoP (Point of Presence) architecture to facilitate connectivity between airports and across regions.

[0060] As shown in Figure 3, the system may be designed to include one or more PoPs 100 per region. The total number of PoPs 100 in the system 300 or per region may be determined by network traffic profiles or demands. For example, in regions with higher demands, requiring low latency, and / or adherence to data sovereignty requirements, more than one physical PoPs 100 may be deployed. Each PoP 100 may be configured to facilitate connectivity within the region and enables interconnectivity between regions usingtechnologies supporting both local and inter-PoP connections (e.g. a cloud exchange fabric, such as Equinix Fabric). Such inter-PoP connections may extend globally as illustrated in Figure 3.

[0061] The system 300 may utilise gateway-to-gateway communication. For example, the system may use SD-WAN gateway-to-gateway communication to optimise routing across SD-WAN-enabled segments, while ensuring compatibility with other transport technologies such as internet and MPLS networks. Connectivity may be further supported through colocation provider networks and interconnection solutions (e.g. services provided by data centre and interconnection operators, such as Equinix, Megaport, and Sify).

[0062] Optionally, in conjunction with the full global PoPs 100, the system 300 may include one or more mini PoPs as cost-effective, streamlined alternative of the full global PoPs. The mini PoPs may be configured to function as mini landing zones and may be deployed at strategic locations to address specific operational needs. Such mini PoPs may be designed with reduced equipment, lowering implementation costs while enabling the system to bring a cloud presence closer to customers in geographically distributed locations. Thus, this helps to address latency concerns within the network and provides an alternative to implementing a full global PoP 100 at every location, thereby offering scalability and flexibility. Such mini PoPs are particularly useful in scenarios where low latency requirements must be met without the complexity of deploying a full PoP 100.

[0063] Therefore, the system 300 may connect the main landing zones formed by global PoPs 100, providing efficient inter-regional communication and a global network infrastructure.

[0064] The system 300 may be deployed using a regional global PoP model. For example, one or more physical routing hubs (e.g. PoPs) 100 may be deployed per region as shown in Figure 4A. Optionally, such regional routing hubs may be deployed using a distributed model, such as a split-data centre model. For example, a distributed regional global PoP (GPoP) may be implemented in forms of two split data centres 450-1, 450-2 in the same region or in two geographically close regions (e.g. in the same city or in two neighbouring cities), as shown in Figure 4B.

[0065] Such a distributed regional model is particularly advantageous in scenarios involving constraints (e.g. infrastructure-related or financial constraints) that make the establishmentof a full regional GPoP across multiple data centres difficult. For instance, the example shown in Figure 4B includes two data centres 450-1 and 450-2 that are in communication with each other. However, in this example, only the first data centre 450-1 B is connected to an SD-WAN component 450-1A, while the second data centre 450-2 lacks a direct connection to the SD-WAN component 450-1A. In such configurations, communication between the SD-WAN 450-1A and the second data centre 450-2 is facilitated via the first data centre 450-1 B.

[0066] This approach effectively eliminates the need for additional data centres (i.e. the second data centre 450-2 and any subsequent data centres) to be configured as full regional GPoPs in the same manner as the first data centre 450-1.

[0067] It will be appreciated that, in other embodiments, a distributed regional GPoP model may be deployed without any full regional GPoP. In such cases, GPoPs with partial functionalities may intercommunicate to collectively provide the complete functionalities of a full regional GPoP.

[0068] It should also be appreciated that the distributed model is not limited to the use of two data centres, 450-1 and 450-2, but may be extended to a greater number of data centres across multiple regions.

[0069] In the context of the distributed GPoP model, the intercommunication between partial GPoPs may involve a combination of direct physical links and virtualised connections, depending on factors such as geographic separation and network traffic profiles. This flexibility in interconnection methods may allow for cost-effective scalability and adaptability to varying regional demands.

[0070] Figure 4A illustrates a high-level physical infrastructure design of an exemplary standard regional global Point of Presence (GPoP). The GPoP infrastructure may comprise the following main hardware components, as illustrated in Figure 4A:

[0071] Network Switches (e.g. access and aggregation switches, such as switches of the Cisco Catalyst 9200 and 9300 series in the example of Figure 4A): These switches may be deployed at the access and aggregation layers. They may enable high-speed data transmission and provide resilience through advanced stacking capabilities and redundancy features.

[0072] Routers (e.g. core routers, such as routers of the Cisco 8500 series in the example of Figure 4A): At the core of the GPoP may be routers that direct and manage traffic flow throughout the network, ensuring seamless interconnectivity across different network segments.

[0073] VPN firewalls (e.g. VPN firewall appliances, such as Fortigate VPN firewalls in the example of Figure 4A): Firewalls may be used to secure VPN connections. These firewalls may provide robust protection for data as it traverses the network.

[0074] Internet firewalls (e.g. perimeter internet firewalls, such as Palo Alto internet firewalls in the example of Figure 4A): Firewalls may also be used at the network perimeter to secure internet access points.

[0075] In some embodiments, the selection of hardware components for a GPoP may be influenced by factors such as expected data throughput, redundancy requirements, and compatibility with existing infrastructure. For example, the use of modular switch and router platforms may facilitate upgrades or reconfiguration of the GPoP without significant disruptions to network operations.

[0076] The GPoP may be functionally structured into core connectivity, customer connectivity and access aggregation layers, and security perimeter layers. The core connectivity layer may include routers (such as Cisco 8500 series routers in the example of Figure 4A), which provide routing and switching capabilities, including Network Address Translation (NAT) and inter-GPoP connectivity over high-speed, resilient links.

[0077] The customer connectivity and access aggregation layer may utilise network switches (such as Cisco Catalyst 9200 for 1G internet access and Cisco Catalyst 9300 for 10G private and hosting access in the example of Figure 4A) to provide connectivity options for diverse customer needs.The security perimeter layer may be established using aforementioned firewalls (such as Palo Alto firewalls for securing internet access ingress and egress and Fortigate firewalls for VPN connectivity in the example of Figure 4A).

[0078] The functional layers of the GPoP may optionally operate independently, allowing for maintenance or upgrades in one layer without affecting the others. For instance, software updates to security perimeter devices may be performed without interrupting core connectivity or customer access. This layered approach may improve manageability and fault isolation within the GPoP.

[0079] The GPoP may be designed to support various data transport mechanisms, including MPLS, SD-WAN, and internet VPN, creating a versatile connectivity fabric that links onpremises infrastructure with cloud services. For example, the GPoP platform may facilitate co-location interconnections, offering secure, software-defined WAN gateways, MPLS network gateways, and aggregation gateways that integrate SITA's hub network and services. The GPoP platform may also facilitate a shared cloud environment, enabling access to public and private cloud resources. This cloud integration may allow for the hosting of platform services and infrastructure, providing a seamless and scalable service model. Additionally, the GPoP platform may support cross-connect capabilities, allowing for direct connections to customers, third-party partners, and public cloud providers, thereby enhancing connectivity options.

[0080] In addition to providing diverse transport mechanisms, the GPoP may incorporate data traffic optimisation techniques such as data load balancing and traffic shaping to manage data flows efficiently. For example, traffic destined for public cloud services may be prioritised differently from traffic intended for private data centres based on predefined policies.

[0081] The locations for the main Global PoPs 100 may be determined by considering factors such as regional network demand, connectivity requirements, and their contribution to the overall global infrastructure. For example, prospective locations for the main Global PoPs 100 and the corresponding justifications are as follows:

[0082] - Amsterdam, Netherlands: Selected to address network traffic demand in Western Europe and to enhance connectivity across the region.Frankfurt, Germany: Positioned to manage high traffic volumes in Central Europe and to support compliance with data sovereignty requirements.

[0083] Singapore: Deployed to serve as a key connectivity hub in Southeast Asia, addressing both regional and intercontinental traffic.

[0084] India: Two locations (Mumbai and Chennai) to support network demand across the Indian subcontinent and facilitate connectivity to neighbouring regions.

[0085] United States: Two locations (East Coast - Washington and West Coast - San Francisco) to optimise traffic management and connectivity across North America and transatlantic routes.

[0086] The deployment of GPoPs may additionally be dependent on regulatory requirements, such as data residency laws or mandated peering arrangements with local network operators.

[0087] The example of Figure 4A illustrates an exemplary design for a GPoP at a single PoP location. However, it will be appreciated that, in other embodiments, a subset of these components may be deployed as part of or in the form of one or more Mini GPoPs, which will be discussed below in detail.

[0088] As shown in Figure 5, in addition to the routing hub 100 (Main GPoPs), the system 300 may comprise one or more mini routing hubs 500 (e.g. Mini Point of Presence (MiniPoP)) in addition to one or more full routing hubs 100 to enable efficient and strategic expansion of the system 300. In some embodiments, the mini routing hubs 500 may operate as subrouting hubs within the system 300, communicating with one or more routing hubs 100 as described in claim 14. Mini-PoPs 500 may function as additional nodes or services intended to enhance the network's reach and strengthen regional service availability. Such Mini-PoPs 500 may, optionally, be provided in the form of the partial GPoPs 450-2 discussed above with reference to Figure 4B. The locations for the Mini-PoPs 500 may be determined by considering factors such as regional network demand, connectivity requirements, and their strategic contribution to the global infrastructure. For example, prospective locations for Mini-PoPs 500 and the corresponding justifications are as follows:Brazil: Serving as a pivotal connectivity node in South America, a Mini-PoP 500 in this location is intended to address the continent's connectivity requirements, with a focus on resilience and the provision of localised content delivery.

[0089] South Africa: This location is strategically selected to provide substantial services across the African continent, which is essential for ensuring regional access and comprehensive data solutions.

[0090] - Australia (Sydney): With the objective of solidifying presence in Oceania, this Mini- PoP 500 is expected to provide optimised network routes and services tailored to the Asia-Pacific corridor.

[0091] Qatar: Positioned as a nexus in the Middle East, a Mini-PoP 500 in this location is projected to play a significant role in enhancing regional connectivity and facilitating communication between Europe, Asia, and Africa.

[0092] In some scenarios, the Mini-PoPs 500 may be deployed via local service providers to leverage existing infrastructure and reduce deployment time. This may enable the system 300 to expand its coverage rapidly without the need for extensive investment in new physical infrastructure.

[0093] The Mini-PoPs 500 may be configured to function primarily as regional nodes. Although they may be designed with lower bandwidth and resilience profiles compared to the main Global PoPs 100, they can, in conjunction with the main Global PoPs 100, provide improved network security and operational efficiency at the system 300 level. These Mini-PoPs 500 may include a reduced amount of hardware, utilising virtualised rather than physical hardware. The use of virtualised hardware in Mini-PoPs 500 may also allow for flexible resource allocation based on real-time traffic patterns. For example, bandwidth and processing power may be dynamically adjusted to accommodate peak usage times, ensuring efficient utilisation of available resources.

[0094] Thus, the system 300 may be expanded in a modular manner to meet requirements such as geographic positioning, the objective of reducing network latency, enhancing customer experience, and delivering localised services in a cost-effective manner relative to the more extensive Global PoP configurations. The inter-region links required to connect the routinghubs 100 and mini-routing hubs 500 may be provided using a low latency fabric network, such as the Equinix low latency fabric network. Furthermore, the established system 300 may be evaluated based on traffic patterns locally and / or globally for consideration of further improvement and / or expansion of the system.

[0095] Such a modular deployment model may also facilitate phased deployment, allowing new mini-PoPs 500 to be integrated incrementally based on emerging traffic demands and infrastructural constraints.

[0096] In addition, the system 300 may leverage hyperscaler and public cloud networks to extend reachability, in conjunction with infrastructure and interconnection providers (e.g. providers such as Equinix and Megaport). These networks may be strategically integrated into public cloud exchange points of presence through multiple multicloud providers. This approach may enable seamless connectivity across diverse cloud environments, facilitating optimised traffic management and improved accessibility for end-users. By incorporating hyperscaler and public cloud networks, the system 300 can enhance its flexibility, scalability, and ability to deliver consistent performance across various regions.

[0097] The integration of hyperscaler and public cloud networks may also allow the system 300 to benefit from advanced capabilities such as automated scaling, traffic analytics, and distributed security functions. These capabilities may contribute to maintaining high performance and reliability standards across geographically dispersed regions.

[0098] As discussed above, the routing hubs 100 and / or the system 300 comprising one or more routing hubs 100 may address different connectivity and operational requirements across multiple environments, including SD-WAN, MPLS, public and private clouds, and interregion communication. The following are examples of use cases illustrating the flexibility and capabilities of the routing hub 100 which may form a part of the system 300. In the context of the below use cases, the ability of the routing hub 100 to manage both MPLS and non-MPLS traffic types provides cost-effective solutions for enabling communication between legacy and modern network infrastructures.

[0099] Use Case 1: SD-WAN Inbound Customer Access Traffic Flows

[0100] SD-WAN customer access to the routing hub 100 in conjunction with system 300 may be facilitated either via the MPLS overlay network or the internet overlay network, as illustratedin Figure 6A. Upon reaching the SD-WAN gateway within the routing hub 100 (e.g. GPoP), customers may access or consume a range of services available through system 300. The available destination services may include:

[0101] Internet: Direct access to public internet resources;

[0102] Public / private cloud: Connectivity to cloud services hosted on public or private infrastructure;

[0103] MPLS products of the network operator (e.g. MPLS services provided by an operator such as SITA OBS);

[0104] Hyperscaler network services (e.g. services offered via a hyperscaler networking platform such as Alkira); and / or

[0105] Other GPoP Resources (inter-GPoP): Connectivity to other GPoPs via the routing hub 100 to support inter-region communication and resource sharing.

[0106] As exemplified in this use case, the routing hub 100, as part of system 300, may be used to manage diverse traffic types efficiently while maintaining optimised routing and security.

[0107] Use Case 2: 3rd Party Vendor / COLO Customer Traffic Flow

[0108] The routing hub 100 may be used to support traffic flows for third-party vendors or data colocation (COLO) customers as part of system 300, as illustrated in Figure 6B. These connections may utilise available GPoP services such as:

[0109] Internet: Public internet access for external communications;

[0110] Public / private cloud: Secure connections to cloud services hosted either publicly or privately;

[0111] SD-WAN Access: Utilisation of SD-WAN overlay networks for dynamic traffic routing and management; and / or

[0112] Other GPoP Resources (inter-GPoP backhaul): Access to resources hosted on other GPoPs via the routing hub 100 to facilitate inter-region backhaul connections.

[0113] As exemplified in this use case, this configuration may enable third-party vendors to integrate seamlessly with the routing hub 100 as part of system 300 without significant modifications to their existing network setups.

[0114] Use Case 3: IPSec VPN Internet Access Customer FlowsAs shown in Figure 6C, the routing hub 100 may facilitate secure internet access for customers using IPSec VPN. In this scenario, VPN connections may terminate on VPN firewalls (e.g. Fortigate VPN firewalls) integrated with the routing hub 100, with a dedicated virtual domain (VDOM) instance provisioned for each VPN customer. This setup allows VPN customers to securely access system 300 resources through the routing hub 100, enabling them to consume GPoP resources with the same security and efficiency as other local or private access subscribers.

[0115] The use of dedicated VDOM instances enhances security by isolating traffic between different VPN customers, thereby providing improved data protection.

[0116] Use Case 4: Cloud Exchange Fabric Access Customer Flows

[0117] The routing hub 100 may also support a global networking platform (e.g. a cloud exchange fabric, such as ECX Fabric) customers, as illustrated in Figure 6D. In this configuration, customers may connect to:

[0118] Internet: For public-facing applications and services;

[0119] Public / private cloud: For scalable cloud services, including hybrid cloud models; MPLS products of the network operator (e.g. MPLS services provided by an operator such as SITA OBS) for leveraging existing MPLS infrastructure; and / or Other GPoP Resources (inter-GPoP backhaul): For enhanced inter-region connectivity and resource access via the routing hub 100.

[0120] The use of a global networking platform may allow customers to benefit from low-latency interconnections and optimised traffic paths, thereby improving the overall performance of their network services through the routing hub 100.

[0121] Use Case 5: OBS MPLS Customer Flows

[0122] As illustrated in Figure 6E, the routing hub 100 may be configured to provide access to GPoP resources for legacy MPLS-connected customers. In this model, end devices connecting to the routing hub 100 may implement their own security solutions or mechanisms, consistent with current OBS implementations. Therefore, existing MPLSbased networks may be integrated without necessitating significant changes to security protocols or infrastructure.Thus, the routing hub 100 may be used to support both legacy MPLS and modern SD-WAN overlay networks in diverse networking environments.

[0123] The use cases discussed above illustrate the adaptability of the routing hub 100 within the system 300 to various networking scenarios, including hybrid cloud, multi-cloud, SD-WAN, and legacy MPLS environments. The modular and flexible design of the routing hub 100 enables it to provide secure, reliable, and scalable connectivity across multiple regions and diverse network architectures.

Claims

CLAIMS1. A routing hub for connecting airport infrastructure to a combination of public and private hosted services, comprising:a set of input connections including at least one MPLS input connection and one non-MPLS input connection;a set of output connections including at least one MPLS output connection and one non-MPLS output connection; anda plurality of aggregation routers arranged between the set of input connections and set of output connections, the aggregation routers arranged to maintain network traffic segregation or provide network traffic aggregation between MPLS and non-MPLS connections based on a set of rules.

2. A routing hub according to claim 1, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate multiple MPLS inputs to fewer MPLS outputs.

3. A routing hub according to claim 1 or 2, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate one or more MPLS inputs to a higher number of MPLS outputs.

4. A routing hub according to any of the preceding claims, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate one or more MPLS inputs to one or more non-MPLS outputs.

5. A routing hub according to any of the preceding claims, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate one or more non-MPLS inputs to one or more MPLS outputs.

6. A routing hub according to any of the preceding claims, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate one or more non-MPLS inputs of a first type to one or more non-MPLS outputs of a second type.

7. A routing hub according to any of the preceding claims, wherein the non-MPLS connections transport data by using one or more of: software-defined wide area network,direct internet, internet via a virtual private network, SD-WAN, internet, cross-connects, and cloud provider interchange.

8. A routing hub according to any of the preceding claims, wherein the airport infrastructure includes a departure control system.

9. A routing hub according to claim 8, wherein the departure control system is provided via traditional third-party hosting.

10. A routing hub according to any of the preceding claims, wherein the airport infrastructure is located at airport premises.

11. A routing hub according to any of claims 1 to 9, wherein the airport infrastructure is located at a location remote from airport premises, and the airport infrastructure is configured to communicate with the airport premises via a communication network.

12. A system comprising a plurality of the routing hubs according to any of the preceding claims and a fabric network connecting the routing hubs, wherein each routing hub is located at a different location and is configured to operate as a point of presence for a predetermined region associated with the routing hub.

13. The system according to claim 12, wherein the predetermined region is determined based on geographical distance to the routing hub or one or more known network conditions, including latency.

14. The system according to claim 12 or 13, wherein the system further comprises one or more sub-routing hubs located at a location remote from the plurality of routing hubs, and each of the one or more sub-routing hubs is configured to communicate with at least one of the plurality of routing hubs.

15. A method of providing network connectivity using a routing hub, the method comprising:receiving data via a set of input connections including at least one MPLS input connection and at least one non-MPLS input connection;processing the data at a plurality of aggregation routers arranged between the set of input connections and a set of output connections; andtransmitting the processed data via the set of output connections including at least one MPLS output connection and at least one non-MPLS output connection, wherein the aggregation routers maintain network traffic segregation or provide network traffic aggregation between MPLS and non-MPLS connections based on a set of rules.

16. The method according to claim 15, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate multiple MPLS inputs to fewer MPLS outputs.

17. The method according to claim 15 or 16, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate one or more MPLS inputs to a higher number of MPLS outputs.

18. The method according to any of claims 15 to 17, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate one or more MPLS inputs to one or more non-MPLS outputs.

19. The method according to any of claims 15 to 18, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate one or more non-MPLS inputs to one or more MPLS outputs.

20. The method according to any of claims 15 to 19, wherein the set of rules includes at least one rule that causes the aggregation routers to aggregate one or more non-MPLS inputs of a first type to one or more non-MPLS outputs of a second type.

21. The method according to any of claims 15 to 20, wherein the non-MPLS connections transport data by using one or more of: software-defined wide area network, direct internet, internet via a virtual private network, SD-WAN, Internet, cross-connects, and cloud provider interchange.

22. The method according to any of claims 15 to 21, wherein the airport infrastructure includes a departure control system.

23. The method according to claim 22, wherein the departure control system is provided via traditional third-party hosting.

24. The method according to any of claims 15 to 23, wherein the airport infrastructure is located at airport premises.

25. The method according to any of claims 15 to 23, wherein the airport infrastructure is located at a location remote from airport premises, and the airport infrastructure communicates with the airport premises via a communication network.

26. A method of providing network connectivity using a system comprising a plurality of routing hubs and a fabric network connecting the routing hubs, each routing hub being located at a different location and configured to operate as a point of presence for a predetermined region associated with the routing hub, the method comprising:receiving, at one of the routing hubs, traffic via at least one MPLS input connection and at least one non-MPLS input connection;processing the traffic at aggregation routers of that routing hub based on a set of rules that maintain network traffic segregation or provide network traffic aggregation between MPLS and non-MPLS connections; andforwarding at least part of the processed traffic via the fabric network to one or more other routing hubs for delivery to public or private hosted services.

27. The method according to claim 26, wherein the predetermined region is determined based on geographical distance to the routing hub or one or more known network conditions, including latency.

28. The method according to claim 26 or 27, wherein the system further comprises one or more sub-routing hubs located at a location remote from the plurality of routing hubs, and each of the one or more sub-routing hubs communicates with at least one of the plurality of routing hubs.

Images