SDN and NFV Era
SDN and NFV Era
Introduction to the E2 Controller
06.28.17

Introduction

To handle increasing requirements, networking has layered capability on top of capability for decades in an incremental pursuit of improvement. The result has been that networks have scaled in terms of doing what they need to do, but they have done so at the expense of complexity. Put more simply, networks have gotten better while networking has gotten worse.

 

This is largely what spawned the SDN movement. The recognition that management and control needed to be simplified led architects to seek out abstraction. Of course, by abstracting configuration, operators lose some of the pinpoint control. But in giving up control, they gain the ability to scale operationally.

 

Abstraction was initially about using centralized controllers as API brokers. Controllers basically were responsible for translating policy constructs into vendor-specific configuration. As that control model has evolved, it has led to the rise of intent-based networking.

 

Intent-based networking is predicated on the idea that operators should specify what needs to happen without necessarily explicitly declaring how it is to happen. More directly, operators need to describe behaviors and constraints in a way that avoids needing to translate that into explicit configuration.

 

The combination of controllers and intent-based models are the next generation in management in control, particularly in service-driven networks where behavior is complex and requires distributed coordination.

 

Intent-Based Networking

What is intent?  Intent-based models declare “what” to do but not “how” to do it.  For example, an operator may want to create a connectivity service.  They do not describe route-targets, route-distinguishers, BGP address-families nor specific packet encapsulations.  Rather they declare that a p2p connectivity service should be created between two service points.  In turn, the SDN Controller, E2, transforms that declaration into service-, device- and technology-specific semantics and propagates them to network devices.

 

Picture1.png

 

Intent can also be thought of as the single source of truth that describes the intended state of an infrastructure. In its essence, intent represents business rules, users, applications, policies, inventory, constraints, capabilities, and design elements, and it is highly variable in nature across different networking scenarios. Without a single source of truth, you can spend most of your time developing middleware that simply synchronizes all the truth that is otherwise distributed, leaving little time for actually caring for existing services or architecting new ones.

 

As an example, today, many systems measure compliance based on configuration verification. This means that configurations essentially become the source of the truth. While they certainly are a source of truth, the biggest problem is that it is very difficult, if not impossible, to determine the intent of those configurations within a complex system. To be specific, a bug in a device’s software may expose vulnerabilities even in the presence of a perfectly compliant configuration.

Intent moves operators away from managing configuration. Here are some basic tenets of intent:

 

  • Intent is stable: It doesn’t change as a result of a link going down, changing router vendors, upgrading software, or any other change to the infrastructure. This property frees applications from the underlying network details.
  • Intent is non-specific: Intent is not specific to protocols, vendor operating systems, media types, or packet formats. Because it is abstracted from changes to the infrastructure, intent-based networking eliminates the impact of changes to the intent.
  • Intent is common: The interface is designed to allow different services, developed independently, to express their resource requirements in a common language.
  • Intent scales out, not up: It doesn’t change when you go from one network controller domain with a million ports to a thousand network controllers with a thousand ports each.
  • Intent provides context: When different systems push low-level rules, there is always a risk of conflicting changes to the system state. Attempts to examine these rules (of the form “match this header and perform this action”) and resolve such issues have been unsuccessful because at this low level of abstraction, it is impossible to decode the overall intent of the services pushing the rules.

By implementing an intent-based interface on E2 it will deliver the benefits described above and, in turn, pave the way for simpler yet more optimized solutions.

 

E2 Concept

E2 is an SDN Controller that instantiates network service instances across nodes of a network, whether physical or virtual. Continuous streams of telemetry data from each network device assist the engine in placing service instances.  E2 leverages intent-based service models to describe the resulting network service instances.

 

Picture2.png

Intent: a high-level description of a network service request. Such requests will result in a decision on where it [service instance] should be placed, based on request type, available resources and network status.

 

The intent is then transferred to the network elements using a combination of configuration and control APIs exposed by the network devices. The engine receives a wide variety of real-time telemetry data streamed from the network devices, including network topology, network utilization, link and path latency, flow data, routing information, and application and user metrics. These telemetry streams are utilized to make intelligent placement decisions to ensure optimal utilization of network and nodes. The system also provides lifecycle event orchestration for workflow customization.

 

E2 is not another network management system. An NMS typically does not make decisions! E2 will make decisions by optimizing the placement of services, leveraging control and telemetry data exposed by modern network elements.  E2 offers a unique combination of intent-based service abstraction, network resource orchestration and optimization along with advanced analytics to automate the process of translating a service request into a service instance configured and active on the most optimal resource.  Tasks such as service placement, service assurance, service maintenance and resource optimization and even capacity planning when it comes to service capabilities, will no longer require human or manual intervention but will be automated, leveraging advanced analytics.

 

Contrail

Contrail Controller, an SDN controller from Juniper Networks, is currently deployed by vendors to orchestrate the creation of virtual networks in data centers. E2 is being built on top of the Contrail platform to orchestrate service provider networking. Some of the unique functionalities E2 provides include:

 

  • Service Abstraction
  • Vendor neutral
  • Multi-vendor support

By abstracting services, Contrail allows SDN to function as a compiler by translating abstract, high-level workflows to low-level configuration. This is achieved primarily through the data models, which essentially leverages SDN as a compiler. The data model allows applications to express their intent in a declarative rather than an imperative manner, the fundamental aspect of E2 architecture. The data manipulated by the application also stays within Contrail, which makes the application virtually stateless.  The consequence of this design is E2 applications are freed from the complexities of high availability, scale and peering.

 

Picture3.png

 

The configuration node of E2 is responsible for transforming any change in high-level service data model to a corresponding set of changes in the low-level technology data model. This is conceptually similar to a Just In Time(JIT) compiler

 

The Contrail data model is vendor neutral, and it has multi-vendor support to interact with network devices like Juniper, Alcatel, Cisco etc. It works by first translating the low-level data model to a meta tree (an intermediate representation format) and then rendering to vendor-specific configuration.

 

Picture4.png

 

Use-cases

Edge and Aggregation

Today, most of the SPs want the ability to do network service automation. Access Edge and Aggregation SPs manage the most complex services, residential, mobile, internal OSS, business edge customers etc. and automation becomes a crucial part of their business success. One use case is they need to backhaul customer circuits to the edge service layer based on the network resources and the live state of the network.

 

Picture5.png

 

E2 addresses the problem by enabling:

  • Intent-based service creation from vendor input, and
  • Service placement from intent, taking into account the telemetry for live network state

A few other SP requirements are:

  • Ability to bring down network nodes to maintenance without services running on those nodes being impacted
  • Ability to deploy a new network node to the network for capacity and redirect services seamlessly
  • Ability to move services across different network nodes in the network, intelligently

Routing and Traffic Engineering

The most fundamental aspect of the routing and traffic engineering use cases within the E2 space is the manipulation of routing policy as a result of the analysis of telemetry data.  Whether the policy manipulation is meant to influence traffic engineering or exit/ingress peer engineering or security is somewhat irrelevant. By collecting and analyzing flow-based telemetry, one can describe how to change routing policy to maintain optimal forwarding in small FIB routers or load-balance egress or ingress traffic across a set of peers, for example.  Furthermore, through the correlation of multiple BGP address families, it is possible to validate several different kinds of data-plane and control-plane synchronization faults without injecting synthetic probes into a network.

 

Picture6.png

 

Another important routing-specific use case is leveraging “BGP as an API” in the network.  BGP is a powerful protocol for routing state distribution, but, at times, BGP best-path computation can result in unanticipated results.  The route-server and RPD API extensions to Junos, combined with E2, enables client-specific RIB modification to become a reality.

 

Picture7.png

 

Last but not least, almost every VPN/service scenario in modern networks warrants the dissemination of routing state, via BGP, in the form of a specific BGP address family. Through its intent-based models, E2 orchestrates client-specific configuration, which is complex in and of itself.  But also optimizes the optimal placement and resource utilization of virtual entities, such as route reflectors, used for scalable propagation of the VPN/service specific reachability information.

 

Picture8.png

 

Intent-based control is the only means by which operators will be able to thrive in an era that is simultaneously more demanding on its services and requires that operations be both cost-efficient and fast. But intent models will be hyper-contextual, meaning they need to developed not just for use cases but also specific deployments. Juniper has built out an intent-based framework that allows for these models to be developed and used, in combination with real-time data being streamed from the infrastructure.

 

Authors

Colby Barth, cbarth@juniper.net

Babu Singarayan, bsingarayan@juniper.net

Nitin Kumar, kumarn@juniper.net

 

06.28.17
h-zaker@netone.co.jp

Hi cbarth,

 

Nice post Smiley Happy

I understand the whole picture of Intent based controlling. 

 

Is there any product going to be release from Juniper?

If yes, I am very egar to take a look at this product.

 

Regards,

Hadi

Top Kudoed Authors