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 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 scalable commodity providers that can monetize.

This is an evolving standard. Currently, the Crosswork solution only addresses the Transport-level Network Slice Management Functions (NSMF).

Solution

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 add them to a catalog. Network line operators can then 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. Currently, the Crosswork solution provides a large catalog of slice template examples and 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 provisions the corresponding domain-specific slice instance across its 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” 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.

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). They then want 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 deploy the service at the device layer. Realizing that vision involves 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.

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 effectively reflects the slice's intended purpose and includes specific, actionable terms, it can be further categorized as either a Service Level Objective (SLO) or a Service Level Expectation (SLE):

• Service Level Objective (SLO): A desired and achievable target value or range of values for the measurements obtained from observing a Service Level Indicator (SLI). For instance, an SLO may be stated 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 differs from an SLO as the customer may have limited means of ascertaining whether the SLE is being fulfilled but still enters into an agreement with the provider for a service that meets the expectation (refer to the sample SLE table below).

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 also describes the extent to which divergence from individual SLOs and SLEs can be tolerated and the 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.

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 support the slice instance, as shown in the illustration below.

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 templates, each 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 doesn’t need to know the details of what is inside the templates, just the overall intent (or SLA) for each slice template. The slice template catalog is thus a catalog of slice intents.

The fourth category – BGP-based VPNs – that make up a Cisco Transport Slice Instance is the selection of endpoints and service types (L2 or L3 forwarding). Operators define these when deploying the Cisco 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 Cisco 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:

1. Select a slice intent from the available Templates in the Slice Catalog.

2. 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.

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 wants to offer customers and is 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 prerequisites and build the slice template catalog, which lists 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 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.

In this scenario, you require a transport slice with Layer3 any-to-any connectivity across three endpoints, using the intent defined in the catalog for Mobile Broadband (eMBB). The eMBB intent will provide the highest bandwidth available path (including proper QoS marking/scheduling treatment), and some basic service assurance capabilities such as endpoint interface status and PE-CE route health. The eMBB intent will also enable you to specify:

• The highest bandwidth available path.

• Some basic service assurance capabilities.

• eBGP peer routing connectivity details to CE devices.

Assumptions and prerequisites

This scenario assumes the network has already built the required network capabilities for this intent. However, they will be briefly reviewed here for this scenario. For more detailed explanations, see the Cisco Transport Slice Automation Design Guide.

Slice service package prerequisites

The NSO slice services package uses a few optional prerequisites that need to be bootstrapped into NSO. The prerequisites required depend on the types of slices and intents required.

First, suppose you plan on using any “as-blueprint” forwarding-plane-policy-types in your template catalog. In that case, you must create an NSO sr-color resource pool so that the slicing service can dynamically assign colors to create ODN policies. This pool should then be referenced by the slicing service.

Second, if creating point-to-point L2 slice service types, the route-policy map assigned to the BGP session for the route reflector must be identified to the slicing package. This policy map will be modified by the slicing package with new policies as needed for L2 services, which is a standard approach for VPWS.

In this scenario, these items are not required since you are using neither of these functions:

resource-pools id-pool sr-color-pool
range start 1000
range end 2000
!
network-slice-services cfp-configurations color-pool-name sr-color-pool
network-slice-services global-settings parent-rr-route-policy SET_COLOR_EVPN_VPWS
!

Path forwarding prerequisites

The following settings have been preconfigured with the NSO T-SDN SR-TE CFP for the eMBB ODN path-forwarding intent with these properties:

• Use Color 100 to identify the intent.

• PCE is responsible for dynamic path computation

• The dynamic path computation will be based on the IGP metric.

On NSO, this set of properties will look like the below example. At this stage, the ODN policy has not been pushed to the devices.

admin@ncs# show running-config cisco-sr-te-cfp:sr-te odn odn-template eMBB
cisco-sr-te-cfp:sr-te odn odn-templatee eMBB
 color 100
 dynamic pce
 dynamic metric-type igp
!

QoS prerequisites

As described, you (the Slice Designer) should have a good understanding of the network's settings and device capabilities. You should have a well-designed and implemented QoS design throughout your network. For instance, for QoS treatment for high bandwidth business services, you have chosen to deploy these services with the network's existing "Class of Service 1" traffic policy (called "ingress_COS1").

The details of this policy are again provider-specific, but in this example, the policy will not examine or modify the ingress traffic's IP DSCP setting but mark all the traffic with an MPLS experimental bit (EXP) of 1 so that downstream core scheduling can provide the proper BW treatment. On egress from the provider network, you have chosen a policy called “Egress-High_BW-Apps,” which will assign 50% of the bandwidth to Class of Service 1 (COS1) marked traffic.

It is assumed these QoS policies are already deployed on all edge PE devices (they still need to be added to the customer-facing interfaces but have been built out and ready for use). However, you still need to identify that these QoS policies are available in the Slice Template catalog for Slice services. You will need to provide that mapping and identify which policies are available for either Layer 2 or Layer 3 slice services or both. Since QoS policies can be tailored specifically to Layer 3 or Layer 2 traffic (for example, matching on L3 DSCP vs L2 ToS bits), the system allows you to specify the usage. In the case of the example above, since all traffic is marked with EXP=1 regardless of DSCP or ToS, these policies apply to L2 or L3 services.

Slice service assurance settings

In this scenario, you only have basic service assurance requirements, which are based on passive state monitoring (no active probing). You will be using Crosswork Network Controller's Service Health capability and the Crosswork Network Controller system’s pre-built heuristic packages (ConfigProfiles and Rules) which define the objects to be monitored. In the scenario, you want to monitor basic device health and PE-CE route health, which are included in the basic system package. When you build the slice catalog, you can define which packages to use for L2 point-to-point, L2 multipoint, and/or L3 services.

The scenario above requires L3 services, but when you create your catalog for the eMBB intent (next step), you also need to consider future slice instances for eMBB services that are L2 service types. Thus, you can include all these pre-built system heuristic packages in the catalog entry for eMBB. Since these are all pre-built system packages, no prerequisite configurations are required. The system heuristic packages can be viewed via the CNC UI by selecting Administration> Heuristic Packages (see figure below).

Table 2. Heuristic profile and rule names for eMBB

System heuristic profile and rule names used for eMBB	Usage
Silver_L3PN_ConfigProfile system Rule-L3VPN-NM-Basic system	L3 profile-name L3 rule-name
Silver_L2PN_ConfigProfile system Rule-L2VPN-MP-Basic system	L2 multipoint profile-name L2 multipoint rule-name
Silver_L2PN_ConfigProfile system Rule-L2VPN-NM-Basic system	L2 point-to-point profile-name L2 point-to-point rule-name

In this scenario, you will update the enhanced Mobile Broadband (eMBB) slice intent, detailed in the previous scenario, to an Ultra-Reliable and Low-Latency Communications with Performance Monitoring (URLLC_PM) slice intent.

Before you deploy this update, the Slice Designer must add the URLLC_PM intent into the slice template catalog. As previously discussed, these are one-time operations and can be leveraged for all future slice instances using this intent.

Assumptions and prerequisites

This scenario assumes the network has already built out the required network capabilities for this intent. However, they will be briefly reviewed here for this scenario. For more detailed explanations, see the Cisco Transport Slice Automation Design Guide.

Path Forwarding Prerequisites

The following settings have been pre-configured with the NSO T-SDN SR-TE CFP for the URLLC ODN path-forwarding intent with these properties:

• Use Color 110 to identify the intent.

• PCE is responsible for dynamic path computation.

• The dynamic path computation will be based on Flex-Algo 128 using the latency metric.

admin@ncs# show running-config cisco-sr-te-cfp:sr-te odn odn-template URLLC
cisco-sr-te-cfp:sr-te odn odn-templatee URLLC
 color 110
 dynamic pce
 dynamic flex-algo 128
!

QoS prerequisites

As previously discussed, you (the Slice Designer) has already built various QoS policies in the network devices as a prerequisite.

For this scenario you must:

• create QoS ingress policy “ingress_COS5” which sets the MPLS EXP to 5. This is then used throughout the core network to give this traffic priority scheduling treatment.

• define the egress QoS policy “Egress-LowLatency,” which provides priority scheduling for this traffic.

• ensure to make these QoS policies available to the Slicing Service package.

Note	Only the new qos-catalog entries are displayed below.

admin@ncs# show running-config network-slice-services slo-sle-templates
qos-catalog network-slice-services slo-sle-templates qos-catalog L2 output-qos-policy
Egress-LowLatency description "Low Latency priority egress"
!
network-slice-services slo-sle-templates qos-catalog L2 input-qos-policy
ingress_COS5 description "Treat all as Priority Data"
!
network-slice-services slo-sle-templates qos-catalog L3 output-qos-policy
Egress-LowLatency description "Low Latency priority egress"
!
network-slice-services slo-sle-templates qos-catalog L3 input-qos-policy
ingress_COS5 description "High Priority/Low Latency"
!

Slice service assurance settings

In this scenario, you will have advanced service assurance requirements that include both passive state monitoring and SR-PM (active probing).

You will use Cisco Crosswork Network Controller Service Health capability and customize the Cisco Crosswork Network Controller system’s pre-built Heuristic packages (ConfigProfiles and Rules), which define the objects to be monitored and the various delay alarming thresholds.

The objective is to always take the lowest latency path, but you can also set the delay threshold that will trigger an alarm (for this example, set it at 25 minutes).

Note	Customizing the Heuristic packages is outside the scope of this example.

Table 5. Heuristic profile and rule names for URLLC_PM

Custom heuristic profile and rule names used for URLLC_PM	Usage
25ms_L3VPN_ConfigProfile custom Rule-L3VPN-NM custom	L3 profile-name L3 rule-name
25ms_L2VPN_ConfigProfile custom Rule-L2VPN-MP custom	L2 multipoint profile-name L2 multipoint rule-name
25ms_L2VPN_ConfigProfile custom Rule-L2VPN-NM custom	L2 point-to-point profile-name L2 point-to-point rule-name

In addition to the above Heuristic packages, you must also create:

• Performance Measurement profiles. These profiles will be used on the SR-TE tunnels.

• y.1731 profile for L2 point-to-point slices using the URLLC_PM intent.

The below PM profiles (used for SR-PM) and y-1731 profiles (used for L2 P2P) have been pre-created in the NSO PM service package.

admin@ncs# show running-config cisco-pm-fp:pm 
                
pm pm-profiles delay-profile sr-policy profile 2wayDelay
probe computation-interval 60
probe tx-interval    30000
probe protocol       twamp-light
probe measurement-mode one-way
advertisement periodic interval 60
advertisement periodic threshold 20
advertisement periodic minimum-change 1000
!
pm svc-profiles 2wayDelaySvc
performance-measurement delay-profile sr-policy profile 2wayDelay
!
!
            

admin@ncs# show running-config l2vpn-ntw y-1731-profile 

l2vpn-ntw y-1731-profile Profile-Delay-1
schedule interval 5
schedule duration 5
type delay
probe measurement-interval 60
delay-params statistic delay-two-way
!
delay-params statistic jitter-two-way
!
!