Friday, May 27, 2022
HomeHealthViews on the Way forward for SP Networking: Intent and Consequence Based...

Views on the Way forward for SP Networking: Intent and Consequence Based mostly Transport Service Automation

One lesson we may all be taught from cloud operators is that simplicity, ease of use, and “on-demand” at the moment are anticipated behaviors for any new service providing. Cloud operators constructed their companies with modular ideas and well-abstracted service interfaces utilizing widespread “black field” software program programming fundamentals, which permit their capabilities to seamlessly snap collectively whereas eliminating pointless complexity. For many people within the communication service supplier (CSP) business, these fundamental ideas nonetheless must be realized in how transport service choices are requested from the transport orchestration layer.

The community service requestor (together with northbound BSS/OSS) initiates an “intent” (or name it an “end result”) and it expects the community service to be constructed and monitored to honor that intent inside quantifiable service stage goals (SLOs) and promised service stage expectations (SLEs). The community service requestor doesn’t need to be concerned with the plethora of configuration parameters required to deploy that service on the system layer, relying as a substitute on another perform to finish that data. Embracing such a fundamental precept wouldn’t solely cut back the price of operations but additionally allow new “as-a-Service” enterprise fashions which may monetize the community for the operator.

However realizing the imaginative and prescient requires the creation of intent-based modularity for the value-added transport companies through well-abstracted and declarative service layer software programming interfaces (APIs).  These service APIs could be uncovered by an clever transport orchestration controller that acts in a declarative and outcome-based manner. Work is being executed by Cisco in community slicing and network-as-a-service (NaaS) to outline this layer of service abstraction right into a simplified – but extensible – transport companies mannequin permitting for highly effective community automation.

How we acquired right here

Networking distributors construct merchandise (routers, switches, and many others.) with an in depth set of wealthy options that we lovingly name “nerd-knobs”. From our early days constructing the primary multi-protocol router, we’ve all the time taken nice delight in our nerd-knob improvement. Our tempo of innovation hasn’t slowed down as we proceed to allow among the richest networking capabilities, together with superior options round section routing site visitors engineering (SR-TE) that can be utilized to drive specific path forwarding via the community (extra on that later). But traditionally it’s been left to the operator to mould these options collectively right into a set of worthwhile community service choices that they then promote to their finish clients. Operators additionally have to spend money on constructing the automation instruments required to help extremely scalable mass deployments and embody some elements of on-demand service instantiation. Whereas an atomic-level setting of the nerd knobs permits the operator to supply granular customization for purchasers or companies, this stage of service design creates complexity in different areas. It drives very lengthy improvement timelines, service rigidity, and northbound OSS/BSS layer integration work, particularly for multi-domain use instances.

With our work in defining service abstraction for NaaS and community slicing and the proposed slicing requirements from the Web Engineering Job Power (IETF), customers of transport companies can quickly start to assume when it comes to the service intent or end result and fewer concerning the complexity of setting characteristic knobs on the equipment required to implement the service on the system stage. Transport automation is transferring in direction of intent, end result, and declarative-based service definitions the place the service person defines the what, not the how.

Within the dialogue that follows, we’ll outline the attributes of the next-generation transport orchestrator based mostly on what we’ve realized from person necessities. Determine 1 under illustrates an instance of some great benefits of the intent-based method weaving SLOs and SLEs into the dialogue. Community slicing, an idea impressed by mobile infrastructure, is launched for instance of the place intent-based networking can add worth.

Transport Services
Determine 1. Elevated confidence with transport companies

What does success seem like?

The following-generation transport orchestrator ought to be closed loop-based and implement these steps:

  1. Help an intent-based request to instantiate a brand new transport service to satisfy particular SLEs/SLOs
  2. Map the service intent into discrete adjustments, validate proposed adjustments in opposition to out there assets and assurance, then implement (together with service assurance tooling for monitoring)
  3. Operational intelligence and repair assurance instruments monitor the well being of service and report
  4. Insights observe and sign out-of-tolerance SLO occasions
  5. Really helpful remediations/optimizations decided by AI tooling drawing on international mannequin information and operational insights
  6. Suggestions are routinely carried out or handed to a human for approval
  7. Return to monitoring mode

Determine 2 reveals an instance of intent-based provisioning automation. On the left, we see the normal transport orchestration layer that gives little or no service abstraction. The service mannequin is solely an aggregation level for community system provisioning that exposes the various ‘atomic-level’ parameters required to be set by northbound OSS/BSS layer parts. The instance reveals provisioning an L3VPN service with high quality of service (QoS) and SR-TE insurance policies, nevertheless it’s solely doable to proceed atomically. The instance requires the upper layers to compose the service, together with useful resource checks, constructing the service assurance wants, after which performing ongoing change management equivalent to updating after which deleting the service (which can require some order of operations). Service monitoring and telemetry required to do any service stage assurance (SLA) is an afterthought and constructed individually, and it’s not simply built-in into the service itself. The upper layer service orchestration would must be custom-built to combine all these parts and wouldn’t be very versatile for brand spanking new companies.

Service Intent
Determine 2. Abstracting the service intent

On the suitable aspect of Determine 2, we see a next-gen transport service orchestrator which is declarative and intent-based. The person specifies the specified end result (in YANG through a REST/NETCONF API), which is to attach a set of community endpoints, additionally known as service demarcation factors (SDPs) in an any-to-any manner and to satisfy a particular set of SLO necessities round latency and loss. The concept right here is to specific the service intent in a well-defined YANG-modeled manner immediately based mostly on the person’s connectivity and SLO/SLE wants. This transport service API is programable, on-demand, and declarative.

IETF slice framework draft definitions
Determine 3. IETF slice framework draft definitions

The brand new transport service differentiator: SLOs and SLEs

So how will operators market and differentiate their new transport service choices? Whereas posting what SLOs will be requested will definitely be part of this (requesting quantifiable bandwidth, latency, reliability, and jitter metrics), the large differentiators would be the set of SLE “catalog entries” they supply. SLEs are the place “every thing else” is outlined as a part of the service intent. What kind of SLEs can we start to contemplate? See Desk 1 under for some examples. Are you able to consider some new ones? The excellent news is that operators can flexibly outline their very own SLEs and map these to specific forwarding behaviors within the community to satisfy a market want.

SLE Offerings
Desk 1. Pattern SLE choices

Capabilities wanted within the community

The great thing about intent-based networking is that the method treats the community as a “black field” that hides detailed configuration from the person. With that stated, we nonetheless want these “nerd-knobs” on the system layer to understand the companies (although abstracted by the transport controller in a programable manner). At Cisco, we’ve developed a transport controller known as Crosswork Community Controller (CNC) which works along with an IP-based community using BGP-based VPN know-how for the overlay connectivity together with system layer QoS and SR-TE for the underlay SLOs/SLEs. We’re trying to proceed enhancing CNC to satisfy the complete future imaginative and prescient of networking intent and closed loop.

Whereas BGP VPNs (for each L2 and L3), private-line emulation (for L1), and packet-based QoS are well-known business applied sciences, we should always expound on the significance of SR-TE. SR-TE will enable for a really surgical community path forwarding functionality that’s way more scalable than earlier approaches. All of the companies proven in Desk 1 would require some side of specific path forwarding via the community. Additionally, to satisfy particular SLO goals (equivalent to BW and latency), dictating and managing particular path forwarding habits can be essential to understanding useful resource availability in opposition to useful resource commitments. Our innovation on this space consists of an in depth set of PCE and SR-TE options equivalent to versatile algorithm, automated steering, and “on-demand-next-hop” (ODN) as proven in Determine 4.

Intent-based SR-TE
Determine 4. Intent-based SR-TE with Automated Steering and ODN

With granular path management capabilities, the transport controller, which incorporates an clever path computation ingredient (PCE), can dynamically change the trail to maintain throughout the desired SLO boundaries relying on community circumstances. That is the promise of software-defined networking (SDN), however when utilizing SR-TE at scale in a service provider-class community, it’s like SDN for adults!

Given the system is intent-based, that must also imply it’s declarative. If the person wished to change from SLE No.1 to SLE No.2 (go from a “greatest effort” latency-based service to a lowest latency-based service), then that ought to be a easy change within the top-level service mannequin request. The transport controller will then decide the mandatory adjustments required to implement the brand new service intent and solely change what’s wanted on the system stage (known as a minimum-diff operation). That is NOT carried out as an entire deletion of the unique service after which adopted by a brand new service instantiation. As an alternative, it’s a modify-what’s-needed implementation. This method thus permits for on-demand adjustments which provide the cloud-like flexibility customers are searching for, together with time-of-day and reactionary-based automation.

Even the requirements our bodies are getting on board

The community slicing idea initially outlined by 3GPP TS 23.501 for 5G companies as “a logical community that gives particular community capabilities and community traits”, was the primary to mandate the service in an intent-based manner, and to request a service based mostly on particular SLOs. This method has grow to be a generic want for any community service (not simply 5G) and definitely for the transport area, most service suppliers look to the IETF for requirements definitions. The IETF is engaged on varied drafts to assist distributors and operators have widespread definitions and repair fashions for intent-based transport companies (known as IETF Community Slice Providers). These drafts embody: Framework for IETF Community Slices and IETF Community Slice Service YANG Mannequin.

IETF network slice
Determine 5. IETF community slice particulars


We envision a future the place transport community companies are requested based mostly on outcomes and intents and in a simplified and on-demand style. This doesn’t imply the transport community gadgets will lose wealthy performance – removed from it. The “nerd-knobs” will nonetheless be there! Wealthy gadgets (equivalent to VPN, QoS, and SR-TE) and PCE-level performance will nonetheless be wanted to supply the granular management required to satisfy the specified service goals and expectations, but the implementation will now be abstracted into extra consumable and user-oriented service constructions by the intent-based next-gen transport orchestrator.

This method is according to the business’s necessities on 5G community slicing and for what some are calling NaaS, which is desired by software builders. In all instances, we see no distinction in that the service is requested as an end result that meets particular goals for a enterprise function. Distributors like us are working to develop the right automation and orchestration methods for each Cisco and third-party system help to understand this way forward for networking imaginative and prescient into enhanced, on-demand, API-driven, operator-delivered transport companies.

Study extra

This is only one weblog in a bigger collection analyzing Views on the Way forward for Service Supplier Networking, so make sure you verify them out and acquire entry to further related content material.

We encourage you to be taught extra about what our improvements imply for remodeling your community by catching us this yr @CiscoLive in June, the place we’ll be internet hosting an interactive panel, IBOSPG-2001 “Future Imaginative and prescient of SP Networking”. Our panel will share our perspective on the way forward for the service supplier community. Please come be part of us and work together with our panel.

Additionally @CiscoLive, you may try our transport community slicing demo on the Crosswork Community Automation sales space within the World of Options. Different associated periods @CiscoLive embody BRKSPG-2034- Automating Operations Throughout Service Lifecycle with Cisco SDN Controller and BRKATO-3000- Superior Automation with Cisco NSO.

Be part of us for these Cisco Stay periods!

Monday, June 13:

Automating Operations Throughout Service Lifecycle with Cisco SDN Controller (BRKSPG-2034)  @  2:30pm PDT

Future Imaginative and prescient of SP Networking (IBOSPG-2001)  @  4pm PDT

Tuesday, June 14:

Superior Automation with Cisco NSO (BRKATO-3000)  @  1:45 PM PDT





Please enter your comment!
Please enter your name here

Most Popular

Recent Comments