Intent-Based Networking (IBN) is an approach to network management that shifts the focus from manually configuring individual devices to specifying desired outcomes or business objectives, referred to as "intents". == Description == Rather than relying on low-level commands to configure the network, administrators define these high-level intents, and the network dynamically adjusts itself to meet these requirements. IBN simplifies the management of complex networks by ensuring that the network infrastructure aligns with the desired operational goals. For example, an implementer can explicitly state a network purpose with a policy such as "Allow hosts A and B to communicate with X bandwidth capacity" without the need to understand the detailed mechanisms of the underlying devices (e.g. switches), topology or routing configurations. == Architecture == Advances in Natural Language Understanding (NLU) systems, along with neural network-based algorithms like BERT, RoBERTa, GLUE, and ERNIE, have enabled the conversion of user queries into structured representations that can be processed by automated services. This capability is crucial for managing the increasing complexity of network services. Intent-Based Networking (IBN) leverages these advancements to simplify network management by abstracting network services, reducing operational complexity, and lowering costs. A proposed three-layered architecture integrates intent-based automation into network management systems. In the business layer, intents are based on Key Performance Indicators (KPIs) and Service Level Agreements (SLAs), reflecting business objectives. The intent layer evaluates and re-plans actions dynamically, where a Knowledge module abstracts and reasons about intents, while an Agent interfaces with network objects to execute actions. The data layer observes network objects, updates topology information, and interacts with the Knowledge and Agent modules to ensure accurate and timely responses to network changes. At the bottom, the network layer contains the physical infrastructure, transforming network data into a usable format for the intent layer to act upon.
Second-order co-occurrence pointwise mutual information
In computational linguistics, second-order co-occurrence pointwise mutual information (SOC-PMI) is a method used to measure semantic similarity, or how close in meaning two words are. The method does not require the two words to appear together in a text. Instead, it works by analyzing the "neighbor" words that typically appear alongside each of the two target words in a large body of text (corpus). If the two target words frequently share the same neighbors, they are considered semantically similar. For example, the words "cemetery" and "graveyard" may not appear in the same sentence often, but they both frequently appear near words like "buried," "dead," and "funeral." SOC-PMI uses this shared context to determine that they have a similar meaning. The method is called "second-order" because it doesn't look at the direct co-occurrence of the target words (which would be first-order), but at the co-occurrence of their neighbors (a second level of association). The strength of these associations is quantified using pointwise mutual information (PMI). == History == The method builds on earlier work like the PMI-IR algorithm, which used the AltaVista search engine to calculate word association probabilities. The key advantage of a second-order approach like SOC-PMI is its ability to measure similarity between words that do not co-occur often, or at all. The British National Corpus (BNC) has been used as a source for word frequencies and contexts for this method. == Methodology == The SOC-PMI algorithm measures the similarity between two words, w 1 {\displaystyle w_{1}} and w 2 {\displaystyle w_{2}} , in several steps. === Step 1: Score neighboring words with PMI === First, for each target word ( w 1 {\displaystyle w_{1}} and w 2 {\displaystyle w_{2}} ), the algorithm identifies its "neighbor" words within a certain text window (e.g., within 5 words to the left or right) across a large corpus. The strength of the association between a target word t i {\displaystyle t_{i}} and its neighbor w {\displaystyle w} is calculated using pointwise mutual information (PMI). A higher PMI value means the two words appear together more often than would be expected by chance. The PMI between a target word t i {\displaystyle t_{i}} and a neighbor word w {\displaystyle w} is calculated as: f pmi ( t i , w ) = log 2 f b ( t i , w ) × m f t ( t i ) f t ( w ) {\displaystyle f^{\text{pmi}}(t_{i},w)=\log _{2}{\frac {f^{b}(t_{i},w)\times m}{f^{t}(t_{i})f^{t}(w)}}} where: f b ( t i , w ) {\displaystyle f^{b}(t_{i},w)} is the number of times t i {\displaystyle t_{i}} and w {\displaystyle w} appear together in the context window. f t ( t i ) {\displaystyle f^{t}(t_{i})} is the total number of times t i {\displaystyle t_{i}} appears in the corpus. f t ( w ) {\displaystyle f^{t}(w)} is the total number of times w {\displaystyle w} appears in the corpus. m {\displaystyle m} is the total number of tokens (words) in the corpus. === Step 2: Create a semantic 'signature' for each word === For each target word ( w 1 {\displaystyle w_{1}} and w 2 {\displaystyle w_{2}} ), the algorithm creates a list of its most significant neighbors. This is done by taking the top β {\displaystyle \beta } neighbor words, sorted in descending order by their PMI score with the target word. This list of top neighbors, X w {\displaystyle X^{w}} , acts as a semantic "signature" for the word w {\displaystyle w} . X w = { X i w } {\displaystyle X^{w}=\{X_{i}^{w}\}} , for i = 1 , 2 , … , β {\displaystyle i=1,2,\ldots ,\beta } The size of this list, β {\displaystyle \beta } , is a parameter of the method. === Step 3: Compare the signatures === The algorithm then compares the signatures of w 1 {\displaystyle w_{1}} and w 2 {\displaystyle w_{2}} . It looks for words that are present in both signatures. The similarity of w 1 {\displaystyle w_{1}} to w 2 {\displaystyle w_{2}} is calculated by summing the PMI scores of w 2 {\displaystyle w_{2}} with every word in w 1 {\displaystyle w_{1}} 's signature list. The β {\displaystyle \beta } -PMI summation function defines this score. The score for w 1 {\displaystyle w_{1}} with respect to w 2 {\displaystyle w_{2}} is: f ( w 1 , w 2 , β ) = ∑ i = 1 β ( f pmi ( X i w 1 , w 2 ) ) γ {\displaystyle f(w_{1},w_{2},\beta )=\sum _{i=1}^{\beta }(f^{\text{pmi}}(X_{i}^{w_{1}},w_{2}))^{\gamma }} This sum only includes terms where the PMI value is positive. The exponent γ {\displaystyle \gamma } (with a value > 1) is used to give more weight to neighbors that are more strongly associated with w 2 {\displaystyle w_{2}} . This calculation is done in both directions: The similarity of w 1 {\displaystyle w_{1}} with respect to w 2 {\displaystyle w_{2}} : f ( w 1 , w 2 , β 1 ) = ∑ i = 1 β 1 ( f pmi ( X i w 1 , w 2 ) ) γ {\displaystyle f(w_{1},w_{2},\beta _{1})=\sum _{i=1}^{\beta _{1}}(f^{\text{pmi}}(X_{i}^{w_{1}},w_{2}))^{\gamma }} The similarity of w 2 {\displaystyle w_{2}} with respect to w 1 {\displaystyle w_{1}} : f ( w 2 , w 1 , β 2 ) = ∑ i = 1 β 2 ( f pmi ( X i w 2 , w 1 ) ) γ {\displaystyle f(w_{2},w_{1},\beta _{2})=\sum _{i=1}^{\beta _{2}}(f^{\text{pmi}}(X_{i}^{w_{2}},w_{1}))^{\gamma }} === Step 4: Calculate final similarity score === Finally, the total semantic similarity is the average of the two scores from the previous step. S i m ( w 1 , w 2 ) = f ( w 1 , w 2 , β 1 ) β 1 + f ( w 2 , w 1 , β 2 ) β 2 {\displaystyle \mathrm {Sim} (w_{1},w_{2})={\frac {f(w_{1},w_{2},\beta _{1})}{\beta _{1}}}+{\frac {f(w_{2},w_{1},\beta _{2})}{\beta _{2}}}} This score can be normalized to fall between 0 and 1. For example, using this method, the words cemetery and graveyard achieve a high similarity score of 0.986 (with specific parameter settings).
Honeywell JetWave
Honeywell's JetWave is a piece of satellite communications hardware produced by Honeywell that enables global in-flight internet connectivity. Its connectivity is provided using Inmarsat’s GX Aviation network. The JetWave platform is used in business and general aviation, as well as defense and commercial airline users. == History == In 2012, Honeywell announced it would provide Inmarsat with the hardware for its GX Ka-band in-flight connectivity network. The Ka-band (pronounced either "kay-ay band" or "ka band") is a portion of the microwave part of the electromagnetic spectrum defined as frequencies in the range 27.5 to 31 gigahertz (GHz). In satellite communications, the Ka-band allows higher bandwidth communication. In 2017, after five years and more than 180 flight hours and testing, JetWave was launched as part of GX Aviation with Lufthansa Group. Honeywell’s JetWave was the exclusive terminal hardware option for the Inmarsat GX Aviation network; however, the exclusivity clause in that contract has expired. In July 2019, the United States Air Force selected Honeywell’s JetWave satcom system for 70 of its C-17 Globemaster III cargo planes. In December 2019, it was reported that six AirAsia aircraft had been fitted with Inmarsat’s GX Aviation Ka-band connectivity system and is slated to be implemented fleetwide across AirAsia’s Airbus A320 and A330 models in 2020, requiring installation of JetWave atop AirAsia’s fuselages. Today, Honeywell’s JetWave hardware is installed on over 1,000 aircraft worldwide. In August 2021, the Civil Aviation Administration of China approved a validation of Honeywell’s MCS-8420 JetWave satellite connectivity system for Airbus 320 aircraft. In December 2021, Honeywell, SES, and Hughes Network Systems demonstrated multi-orbit high-speed airborne connectivity for military customers using Honeywell’s JetWave MCX terminal with a Hughes HM-series modem, and SES satellites in both medium Earth orbit (MEO) and geostationary orbit (GEO). The tests achieved full duplex data rates of more than 40 megabits per second via a number of SES' (GEO) satellites including GovSat-1, and the high-throughput, low-latency O3b MEO satellite constellation, with connections moving between GEO/MEO links in under 30 sec. == Uses == === Commercial aviation === Honeywell’s JetWave enables air transport and regional aircraft to connect to Inmarsat’s GX Aviation network. The multichannel satellite (MSC) JetWave terminals share the same antenna controller, modem and router hardware with the business market, but have an MCS-8200 fuselage-mounted antenna. === Business aviation === Honeywell’s JetWave hardware allows users to connect to Inmarsat’s Jet ConneX, a business aviation broadband connectivity offering to provide Wi-Fi for connected devices. JetWave offers a tail-mount antenna for business jets. === Defense === Honeywell’s JetWave satellite communications system for defense allows users to connect to the Inmarsat GX network, offering global coverage for military airborne operators, including over water, over nontraditional flight paths and in remote areas. JetWave and the Inmarsat GX network enable mission-critical applications like real-time weather; videoconferencing; large file transfers; encryption capabilities; in-flight briefings; intelligence, surveillance, and reconnaissance video; and secure communications. JetWave is configurable for a variety of military platforms and offers antennas for large and small airframes.
W3C Device Description Working Group
The W3C Device Description Working Group (DDWG), operating as part of the World Wide Web Consortium (W3C) Mobile Web Initiative (MWI), was chartered to "foster the provision and access to device descriptions that can be used in support of Web-enabled applications that provide an appropriate user experience on mobile devices." Mobile devices exhibit the greatest diversity of capabilities, and therefore present the greatest challenge to content adaptation technologies. The group published several documents, including a list of requirements for an interface to a Device Description Repository (DDR) and a standard interface meeting those requirements. The group was rechartered in 2006 to work in public towards the development of the Application Programming Interface (API) for a DDR. Early in 2007, the group launched a wiki and a blog to add to the public mailing list. The group subsequently published a formal vocabulary of core device properties, and an API called the DDR Simple API, which became a W3C Recommendation in December 2008. The group closed at the end of 2008, but with the intention of maintaining the Web pages, blog and wiki through W3C volunteer effort. == Publications == The DDWG published several W3C Working Group Notes and one W3C Recommendation. A W3C WG Note that articulates what the W3C and other organizations are doing or have already done with regard to device information. This document suggests an environment in which these technologies work together to meet the goals of content adaptation. The completed document was published on 31 October 2007. A W3C WG Note describing the ecosystem surrounding creation, maintenance and use of device descriptions. The completed document was published on 31 October 2007. A W3C WG Note describing a set of requirements for a reference repository of device descriptions. The completed document was published on 17 December 2007. A W3C WG Note describing a process to manage contributions to an initial core vocabulary, identification of key device properties, a formal initial core vocabulary and the identification of a maintainer for the core vocabulary. The details were contained in the Working Group Note describing the DDWG Core Vocabulary published on 14 April 2008. A W3C WG Note defining useful grouping and structure patterns in device descriptions. The Device Description Structures document was published as a Working Draft on 5 December 2008. The intention is that this document will be future input to other W3C groups. A W3C Recommendation defining a language-neutral programming interface to a Device Description Repository. The DDR Simple API was published on 5 December 2008. There is the possibility of future publications on the DDWG wiki describing implementations of the API in various languages, including Java, IDL, WSDL, C# etc. Much of the DDWG's material was developed in public via the DDWG Wiki and through their public mailing lists.
GPU switching
GPU switching is a mechanism used on computers with multiple graphic controllers. This mechanism allows the user to either maximize the graphic performance or prolong battery life by switching between the graphic cards. It is mostly used on gaming laptops which usually have an integrated graphic device and a discrete video card. == Basic components == Most computers using this feature contain integrated graphics processors and dedicated graphics cards that applies to the following categories. === Integrated graphics === Also known as: Integrated graphics, shared graphics solutions, integrated graphics processors (IGP) or unified memory architecture (UMA). This kind of graphics processors usually have much fewer processing units and share the same memory with the CPU. Sometimes the graphics processors are integrated onto a motherboard. It is commonly known as: on-board graphics. A motherboard with on-board graphics processors doesn't require a discrete graphics card or a CPU with graphics processors to operate. === Dedicated graphics cards === Also known as: discrete graphics cards. Unlike integrated graphics, dedicated graphics cards have much more processing units and have its own RAM with much higher memory bandwidth. In some cases, a dedicated graphics chip can be integrated onto the motherboards, B150-GP104 for example. Regardless of the fact that the graphics chip is integrated, it is still counted as a dedicated graphics cards system because the graphics chip is integrated with its own memory. == Theory == Most Personal Computers have a motherboard that uses a Southbridge and Northbridge structure. === Northbridge control === The Northbridge is one of the core logic chipset that handles communications between the CPU, GPU, RAM and the Southbridge. The discrete graphics card is usually installed onto the graphics card slot such as PCI-Express and the integrated graphics is integrated onto the CPU itself or occasionally onto the Northbridge. The Northbridge is the most responsible for switching between GPUs. The way how it works usually has the following process (refer to the Figure 1. on the right): The Northbridge receives input from Southbridge through the internal bus. The Northbridge signals to CPU through the Front-side bus. The CPU runs the task assignment application (usually the graphics card driver) to determine which GPU core to use. The CPU passes down the command to the Northbridge. The Northbridge passes down the command to the according GPU core. The GPU core processes the command and returns the rendered data back to the Northbridge. The Northbridge sends the rendered data back to Southbridge. === Southbridge control === The Southbridge is a set of integrated circuits such Intel's I/O Controller Hub (ICH). It handles all of a computer's I/O functions, such as receiving the keyboard input and outputting the data onto the screen. The way how it usually works usually has two steps: Take in the user input and pass it down to the Northbridge. (Optional) Receive the rendered data from the Northbridge and output it. The reason why the second step can be optional is that sometimes the rendered the data is outputted directly from the discrete graphics card which is located on the graphics card slot so there is no need to output the data through the Southbridge. == Main purpose == GPU switching is mostly used for saving energy by switching between graphic cards. The dedicated graphics cards consume much more power than integrated graphics but also provides higher 3D performances, which is needed for a better gaming and CAD experience. Following is a list of the TDPs of the most popular CPU with integrated graphics and dedicated graphics cards. The dedicated graphics cards exhibit much higher power consumption than the integrated graphics on both platforms. Disabling them when no heavy graphics processing is needed can significantly lower the power consumption. == Technologies == === Nvidia Optimus === Nvidia Optimus™ is a computer GPU switching technology created by Nvidia that can dynamically and seamlessly switch between two graphic cards based on running programs. === AMD Enduro === AMD Enduro™ is a collective brand developed by AMD that features many new technologies that can significantly save power. It was previously named as: PowerXpress and Dynamic Switchable Graphics (DSG). This technology implements a sophisticated system to predict the potential usage need for graphics cards and switch between graphics cards based on predicted need. This technology also introduces a new power control plan that allows the discrete graphics cards consume no energy when idling. == Manufacturers == === Integrated graphics === In personal computers, the IGP (integrated graphics processors) are mostly manufactured by Intel and AMD and are integrated onto their CPUs. They are commonly known as: Intel HD and Iris Graphics - also called HD series and Iris series AMD Accelerated Processing Unit (APU) - also formerly known as: fusion === Dedicated graphics cards === The most popular dedicated graphics cards are manufactured by AMD and Nvidia. They are commonly known as: AMD Radeon Nvidia GeForce == Drivers and OS support == Most common operating systems have built-in support for this feature. However, the users may download the updated drivers from Nvidia or AMD for better experience. === Windows support === Windows 7 has built-in support for this feature. The system automatically switches between GPUs depending on the program that's running. However, the user may switch the GPUs manually through device manager or power manager. === Linux === Modern Linux systems handle hybrid graphics in two parts: power/control for the inactive GPU, and optional render offloading for individual applications. vga_switcheroo (in the kernel since 2.6.34) coordinates power and mux control on systems with multiple GPUs. It was designed primarily for muxed designs (hardware display switch), and on muxless laptops it is typically used only for power control. A display server restart is no longer required for offloading on muxless systems. DRI PRIME (Mesa) enables per-process render offload on muxless systems: an app renders on the discrete GPU and the integrated GPU presents the result. Users can opt in via the DRI_PRIME environment variable (e.g., DRI_PRIME=1) or desktop integration. On GNOME, the switcheroo-control service exposes the discrete GPU to the shell, adding a “Launch using Discrete Graphics Card” entry to app menus on supported systems (Wayland or Xorg), which invokes render offload under the hood. With the proprietary Nvidia driver, render offload is provided as PRIME Render Offload (supported since driver 435.xx). Distributions commonly ship a helper like prime-run or desktop menu entries that set the required environment for offloading. ==== Notes and limitations (Linux) ==== On muxless systems the internal display is hard-wired to the integrated GPU; the discrete GPU cannot directly drive that panel and instead renders offscreen for composition by the iGPU. External displays connected to the dGPU may allow direct output depending on the laptop’s wiring. Power-saving behavior varies by driver and distro defaults. Some setups need explicit configuration to power down the inactive GPU when idle. Desktop integrations (e.g., GNOME's menu item) simply opt an app into offload; they do not "auto-switch" the whole session. Users can still launch apps on either GPU as needed.
BeyondCorp
BeyondCorp is an implementation of zero-trust computer security concepts creating a zero trust network. It is created by Google. == Background == It was created in response to the 2009 Operation Aurora. An open source implementation inspired by Google's research paper on an access proxy is known as "transcend". Google documented its Zero Trust journey from 2014 to 2018 through a series of articles in the journal ;login:. Google called their ZT network "BeyondCorp". Google implemented a Zero Trust architecture on a large scale, and relied on user and device credentials, regardless of location. Data was encrypted and protected from managed devices. Unmanaged devices, such as BYOD, were not given access to the BeyondCorp resources. == Design and technology == BeyondCorp utilized a zero trust security model, which is a relatively new security model that it assumes that all devices and users are potentially compromised. This is in contrast to traditional security models, which rely on firewalls and other perimeter defenses to protect sensitive data. === Trust === The corporate network grants no inherent trust, and all internal apps are accessed via the BeyondCorp system, regardless of whether the user is in a Google office or working remotely. BeyondCorp is related to Zero Trust architecture as it implements a true Zero Trust network, where all access is granted on identity, device, and authentication, based on robust underlying device and identity data sources. BeyondCorp works by using a number of security policies including authentication, authorization, and access control to ensure that only authorized users can access corporate resources. Authentication verifies the identity of the user, authorization determines whether the user has permission to access the requested resource, and access control policies restrict what the user can do with the resource. ==== Trust Inferrer ==== One of the main components in BeyondCorp's implementation is the Trust Inferrer. The Trust Inferrer is a security component (typically software) that looks at information about a user's device, like a computer or phone, to decide how much it can be trusted to access certain resources like important company documents. The Trust Inferrer checks things like the security of the device, whether it has the right software installed, and if it belongs to an authorized user. Based on all this information, the Trust Inferrer decides what the device can access and what it can't. === Security mechanisms === Unlike traditional VPNs, BeyondCorp's access policies are based on information about a device, its state, and its associated user. BeyondCorp considers both internal networks and external networks to be completely untrusted, and gates access to applications by dynamically asserting and enforcing levels, or “tiers,” of access. === Device Inventory Database === BeyondCorp utilized a Device Inventory Database and Device Identity that uniquely identifies a device through a digital certificate. Any changes to the device are recorded in the Device Inventory Database. The certificate is used to uniquely identify a device; however, additional information is required to grant access privileges to a resource. === Access Control Engine === Another important component of BeyondCorp's implementation is the Access Control Engine. Think of this as the brain of the Zero Trust architecture. The Access Control Engine is like a traffic cop standing at an intersection. Its job is to make sure that only authorized devices and users are allowed to access specific resources (like files or applications) on the network. It checks the access policy (the rules that say who can access what), the device's state (like whether it has the right software updates or security settings), and the resources being requested. Then it makes a decision on whether to grant or deny access based on all of this information. It helps ensure that only the right people and devices are allowed access to the network, which helps keep things secure. The Access Control Engine utilizes the output from the Trust Inferrer and other data that is fed into its system. == Usage == One of the first things Google did to implement a Zero Trust architecture was to capture and analyze network traffic. The purpose of analyzing the traffic was to build a baseline of what typical network traffic looked like. In doing so, BeyondCorp also discovered unusual, unexpected, and unauthorized traffic. This was very useful because it gave the BeyondCorp engineers critical information that assisted them in reengineering the system in a secure manner. Some of the benefits BeyondCorp realized by adopting a Zero Trust architecture include the ability to allow their employees to work securely from any location. It reduces the risk of data breaches since data and applications are protected and users and devices are constantly being verified. The Zero Trust architecture is scalable and can be adapted to the changing needs of the businesses and their users. Especially relevant in today's work-from-home era, BeyondCorp allows employees to access enterprise resources securely from any location, without the need for traditional VPNs.
Kimchi (software)
Kimchi is a web management tool to manage Kernel-based Virtual Machine (KVM) infrastructure. Developed with HTML5, Kimchi is developed to intuitively manage KVM guests, create storage pools, manage network interfaces (bridges, VLANs, NAT), and perform other related tasks. The name is an extended acronym for KVM infrastructure management. It is an Apache-licensed project hosted on GitHub, and incubated by oVirt.org.