Blog: Making Intent-Based Networking Work

By Sorell Slaymaker |

One of the many (ohh so many) “Holy Grails” for IP networking is the ability for an application to automatically request network resources and security. Intent-based networking (IBN) is the latest iteration, following past attempts such as RSVP, IGMP, and NSIS. At 128 Technology, it’s our belief that for IBN to work, fundamental changes need to be made to networking.

Intent-Based Networking Defined [Gartner]

  • Translation and Validation – The system takes a higher-level business policy (what) as input from end users and converts it to the necessary network configuration (how).
  • Automated Implementation – The system configures the appropriate network changes (how) across existing network infrastructure via network automation and/or orchestration.
  • Awareness of Network State – The system ingests real-time network status for systems under its administrative control, and is protocol- and transport-agnostic.
  • Assurance and Dynamic Optimization/Remediation – The system continuously validates (in real time) that the original business intent of the system is being met, and can take corrective actions (such as blocking traffic, modifying network capacity, sending notifications or alerts) when desired intent is not met.

Reasons Intent-Based Networking Will Not Work in Its Current State
Here are just a few reasons why IBN will not work unless major network changes are made:

  • Network Address Translation (NAT) Boundaries – Users and the applications they consume are on different networks a majority of the time. These networks are separated by firewalls and NAT boundaries, as well as potentially different address families (IPv4 vs. IPv6). These network boundaries interfere with end-to-end session-state awareness and controls, along with the ability to identify the traffic based on the initial source IP address.
  • Indistinct Differentiated Services Code Points (DSCP) – DSCP is a packet header value used for requesting Quality of Service treatment, such as high priority or best effort delivery. The challenge with this is that a lot of the traffic on the network looks the same, being either encrypted with TLS or video traffic. For instance, a room-based video between executives can have the same DHCP marking of AF41 just list a desktop video session between two co-workers. Moreover, as traffic crosses network boundaries, the treatment for DSCP is inconsistently enforced.
  • Access Control List (ACL) Hell – The underlying network is still comprised of many devices (routers, firewalls, load balancers, WAN optimizers), each using ACLs to control network performance and security, hop-by-hop. Because each ACL applies to devices within a contiguous address space, the same ACL may be used on thousands of routers to control the same service across many disparate networks. IBN masks the underlying network complexity with orchestration tools, but it does not solve the fundamental IP networking problem.
  • Signaling – In order for an application to request network resources and security, a signaling mechanism needs to be used prior to the application using the network. There are millions of private networks that connect to either IPv4 or IPv6 networks through stateful NATs, but none of them signal to each other.

A Solution to Help Intent-Based Networking Operate Better
The 128 Technology Networking Platform (128T) is a session-oriented router that leverages a Secure Vector Routing architecture. This enables 128T to address many of the fundamental IP networking integration challenges with IBN management solutions. The key enablers include:

  • Session-Orientation – Unlike a network flow, a network session has a unique session identifier, enabling it to pass routing and security policies through NAT boundaries and provide end-to-end network control and monitoring. Session Detail Records provide the industries best network performance and security analytics.
  • Named Services – Define all applications, services, and users on the network using words based on tenants and services. This naming scheme allows for granular network controls that are hierarchal and can be easily read by humans and machines. Address-independent routing provides location independent services and user mobility.
  • Single Software Stack – Access all network functions (routing, firewall, load balancing, WAN optimization) in a single software stack that has NETCONF and REST APIs that are easily controlled by SDN orchestration tools such as Ansible and Puppet.
  • Overlay Free – Enhance routing and security without overlays, such as IPsec and VxLAN. These overlays add a 25 percent to 40 percent overhead tax to the CPU of network devices and the associated bandwidth.
  • Signaling – 128 Technology uses metadata added to the first packet in a TCP or UDP session to signal to the network the required routing and security policies for the session.

Today’s IBN solutions work only in a single domain environment, such as a data center or a private enterprise WAN. With more users being mobile and applications in the cloud, fundamental changes need to be made to the network if IBN is going to successfully help deploy applications. And ultimately enhance network performance to accommodate today’s environment. At 128 Technology, we are changing the fundamental IP networking architecture so that it can be controlled end-to-end by intelligent applications. As we say (and can prove), we are fixing the Internet.

Contact Us

We're not around right now. But you can send us an email and we'll get back to you, asap.

Start typing and press Enter to search