Overview
Objective
Simplify Transport Service provisioning by focusing on the service's SLA intents (the "what" instead of the "how"). This implies a service-oriented view, leveraging the concepts of software-defined networking (SDN).
Challenge
Service providers face ever-growing demands from end users for highly customized, flexible network services with very different, sometimes contradictory, service level requirements: support for highly mobile smart cars, ultralow-latency AR and mobile gaming applications, secure machine-to-machine communication in logistics and manufacturing, and so on. Modern software-defined network (SDN) traffic engineering technologists have responded with a host of innovative protocols and features that offer many ways to engineer network traffic to meet these special needs. Crosswork support for these approaches, such as SR-TE services, Tree-SID and Local Congestion Mitigation, are featured elsewhere in this Guide.
The advent of 5G mobile networking has accelerated this trend, resulting in a new approach to network architecture: network slicing. This still-emerging standard enables network engineers to slice the 5G network's bandwidth into tranches that prioritize some services over others, instead of treating it as a single, monolithic network. The network engineer can design each network slice around the needs and intents of its users, allocating speed, latency, throughput and other resources to each slice as required. CNC delivers a rich and customizable tool set to make deploying these slices easier. When combined with Service Health, it provides the added ability to easily monitor the health of these services. The provider organization can then offer the slice itself as a service, helping to broaden the range of service offerings.
But how to make these services easy to provision? The design and coding of the sophisticated traffic engineering services that underlie network slicing require the skills of experienced network architects and deep knowledge of each provider's existing network infrastructure. Without some form of automation that allows line operators to instantiate the designed slices quickly and easily, network slices might remain a type of custom configuration, achievable only for a small set of important users, instead of a scalable commodity providers can monetize.
This is an evolving standard. At present, the Crosswork solution addresses the Transport-level Network Slice Management Functions (NSMF) only.
Solution
Cisco Crosswork Network Controller offers direct support for network slicing at the OSI transport layer. Using this solution, network engineering experts can design slices around customer intents and then add them to a catalog. Network line operators can then simply pick the slice intent that best meets the customer's needs, specify the slice endpoints, and (where needed) set any custom constraints or options built into the chosen slice.
This is Cisco's initial offering in the network slicing arena, chosen because of our company's strengths at the transport layer. At present, the Crosswork solution provides a large catalog of slice template examples and an extensive customization for each template. This document offers a scenario that you can follow to create and (optionally) monitor a network slice.
How Does Transport Slicing Work?
It's important at the outset to understand the difference between 5G network slicing and generalized transport slicing. When operational, a 5G network slice is an end-to-end solution crossing multiple sub-domains. The 5G network authority 3rd Generation Partnership Project (3GPP) refers to each end-to-end network slice operating on the network as the Network Slice Instance (NSI). Each NSI is a unique entity, provisioned in the network with a set of Service Level Requirements chosen from a set of pre-created Network Slice Templates (NST).
All NSIs must be orchestrated by a controller called the Network Slice Management Function (NSFM). The NSMF in turn communicates with sub-domain controllers, referred to as Network Slice Subnet Management Functions (NSSMF). Each NSSMF in turn provisions the corresponding domain-specific slice instance across its own sub-domain boundaries (called a Network Slice Subnet Instance or NSSI). For the Transport domain, the IETF has defined the NSSI as an “IETF Network Slice” in order to differentiate slices in the transport domain from slices bridging other domains. The space occupied by transport slicing in this hierarchy is shown in the illustration below, where the CNC solution will provide the NSSMF functionality for the Transport domain. It is important to highlight that Cisco's Transport Slicing solution can be used independently from 5G use cases, as it's a generic solution for implementing any transport service based on intents.
![Defining Transport Slicing Scope](/c/dam/en/us/td/i/400001-500000/470001-480000/479001-480000/479417.jpg)
Simplification and ease of use are key principles in transport slicing. The operator wants to start very simply, by requesting from a controller a service based on a desired service intent or outcome (such as supplying low latency to an AR application). He then wants the controller to build the service.
The controller must also monitor the built service to ensure it honors the operator's intent. Above all, the operator wants to avoid exposure to the many configuration parameters required to actually deploy the service at the device layer. Realizing that vision requires the creation of intent-based modularity for value-added transport services supporting the slice, using well-abstracted and declarative service-layer APIs. These service APIs must be maintained and exposed by a controller that can act in a declarative and outcome-based way, as shown in the following figure.
![Abstracting Service Intents/Outcomes](/c/dam/en/us/td/i/400001-500000/470001-480000/479001-480000/479418.jpg)
Monitoring the slice's fidelity to the intent involves a Service Level Agreement (SLA) between the customer and the slice provider. To ensure that this SLA both captures the slice intent and has concrete, actionable terms, it can be further defined as either an SLO or SLE:
-
Service Level Objective (SLO): A desired, achievable target value or range of values for the measurements returned by observation of a Service Level Indicator (SLI). For example, an SLO may be expressed as "SLI <= target", or "lower bound <= SLI <= upper bound".
-
Service Level Expectation (SLE): The expression of an unmeasurable service-related request that a customer makes of the provider. An SLE is distinct from an SLO because the customer may have little or no way of determining whether the SLE is being met, but will still contract with the provider for a service that meets the expectation (see the following table of sample SLEs).
SLE |
Description |
---|---|
Encrypted Link Services | Traffic must transit encrypted links only. |
Disjoint Path Services | The network has multiple forwarding planes with no common nodes or links. |
High speed links only | Traffic must transit high-speed links only. Links offering speeds greater than or equal to 100Gbps are typical for "elephant flows". |
Lowest Latency | Always take the lowest latency path. No SLO would be specified in this case. |
Regional Avoidance | Do not use nodes or links in specific regions or countries. |
Trusted Nodes | Only use trusted nodes ("trusted" meaning verified and not in the common carrier space). |
L4-L7 Services | Redirect to “in-line” L4-L7 service on traffic (typically used for security services). |
Reliable Links | Use only transit links that have optical protection and L1 diversity. |
“Circuit-Style” Services | Provide L1 circuit-like connectivity. |
Gaming Services | Use network segments optimized for network gamers (low latency, high bandwidth) |
Connected Car | Use network segments optimized for network-connected cars (low latency, close proximity) |
Cloud Provider-Specific | Connect me to the secure “walled garden” for a cloud provider (such as AWS or Azure). |
The SLA therefore sets key goals and measures to be applied for a given connectivity construct between a sending endpoint and the set of receiving endpoints. It may also describe the extent to which divergence from individual SLOs and SLEs can be tolerated, and specific consequences for violating these SLOs and SLEs.
What Makes Up a Cisco Transport Slice?
To build and deploy these highly abstract intents, Crosswork Network Controller must translate them into actual device configurations. Governing bodies like the IETF and 3GPP leave these decisions to vendors. Cisco can leverage a complete toolkit, built over many years of innovation, as shown in the following figure.
![Cisco's Transport Slicing Toolkit](/c/dam/en/us/td/i/400001-500000/470001-480000/479001-480000/479419.jpg)
For a Cisco Transport Slice Instance, we categorize the features in the preceding illustration as follows: Service Assurance, Path Forwarding, QOS (PHB), and BGP-based EVPN. The configurations in these categories are what support the slice instance, as shown in the illustration below.
![](/c/dam/en/us/td/i/400001-500000/480001-490000/480001-481000/480717.jpg)
The first three of these features (shown in red) are defined in the slice template catalog (this catalog is equivalent to what 3GPP calls the NSST). The slice catalog contains slice templates, each of which is defined once by a slice designer. Slice templates are just blueprints and are not instantiated in the network in any way. Slice instances are the instantiated services after they are deployed in the network. The end-user really doesn’t need to know the details of what is inside the templates, just what the overall intent (or SLA) is for each slice template. The slice template catalog is thus a catalog of slice intents.
The fourth category – BGP-based VPNs – that makes up a Cisco Transport Slice Instance is the selection of endpoints and service types (L2 or L3 forwarding). Operators define these when deploying the Transport Slice Instance.
The benefit of this approach is to fully abstract the underlying configuration details of the various machinery components required to realize a Transport Slice Instance (aka the IETF Network Slice, or, in 3GPP parlance, the Network Subnet Slice Instance or NSSI).
To deploy a new slice instance, the operator executes the following steps:
-
Select a Slice Intent from the available Templates in the Slice Catalog.
-
Select slice endpoints and connectivity details, which drive the VPN configuration. Once committed, Crosswork Network Controller will then provision:
-
The forwarding plane policy details which drive the segment routing traffic engineering (SR-TE) configurations and BGP prefix coloring for ODN/AS.
-
The QoS profile details,which drive the ingress marking (for PHB treatment) and the egress scheduling.
-
The SLA details, which will drive the needed Service Assurance configurations.
-
The BGP based VPN connectivity requirements to provide endpoint connectivity.
-
The following illustration provides more detail on the parts of the slice template that automate slice instantiation.
![What is automated when deploying a slice instance](/c/dam/en/us/td/i/400001-500000/470001-480000/479001-480000/479421.jpg)
Transport Slice High Level Workflow
Transport slicing in Crosswork Network Controller is designed around two main user personas:
Slice Designer: The Designer understands the service requirements the provider organization want to offer to customer and is very familiar with the provider network’s underlying capabilities. This person has authorization to do one-time setup operations within the network and has a networking engineering background. They will set up the needed network pre-requisites and then build the slice template catalog, which offers a listing of available slice service offerings for network operators.
Slice Requestor: The Requestor requests new slice instances using the intent-based and simplified CNC user interface. They pick their desired slice type from the pre-built slice catalog, select their endpoints and transport options, and then click submit.
Cisco's objective in the Cisco Crosswork Network Controller Transport Slice solution is to make the user experience as simple as possible for the Requestor. This is the only slice deployment operation driving network service provisioning, and as it must be done constantly for a large SP network, it is a major contributor to provider OPEX. The Slice template catalog creation is done once by highly skilled designer personnel. While the design step is not automated, this approach leverages those skilled resources in a way that maximizes their value to the provider organization at a scale that cannot be realized if the designer must instantiate every slice by hand. The catalog creation requires a good understanding of the network and its capabilities, and requires pre-requisite configurations as shown in the figure below. Slice Designers must be familiar with all the pre-requisite configuration types listed in the illustration for this approach to work.
![Role of the Slice Designer and Requestor](/c/dam/en/us/td/i/400001-500000/470001-480000/479001-480000/479422.jpg)