One of the exciting aspects of 5G mobile architecture is network slicing. A network slice is a dynamically-created logical end-to-end network with an optimized topology to serve a specific purpose — a service class or a customer. A mobile network operator will be able to slice the network resources (routers and links) along with compute and storage resources (for running NFVs and cloud apps) and allocate them to a service. Though the technology is being spearheaded by the cellular telecommunications-focused 3rd Generation Partnership Project (3GPP), network slicing is likely to find application in fixed networks as well. The 3GPP has not ratified the network slicing definition yet; this is expected to happen by September of 2018. Hence, everything you hear and read, including this blog post, may not be accurate by the time the specification is ratified.
Two appealing features of network slicing are orchestration and isolated performance guarantees. An orchestrator can slice a network, along with compute and storage resources, and run a service in that slice. Isolated performance guarantees ensure one slice cannot interfere with the performance of another slice. Achieving this for a high number of slices will be a challenge. Hence, at least initially, implementations will be in the low tens of slices. One slice of the network may provide mission-critical services (such as emergency response), another slice might serve traditional cellular users, a third slice might be allocated for Internet of Things devices, and perhaps a fourth slice might be for an MVNO (Mobile Virtual Network Operator) customer, and so on.
User equipment will be able to connect up to eight slices of the network simultaneously to access various services. These slices can be managed and operated independently of each other using an orchestrator that configures the network, compute and storage resources to each slice’s needs.
This sounds very much like a cloud application with its virtual network overlay. The difference is in the isolated performance guarantees. These performance guarantees come in two flavors — hard and soft guarantees. Providing hard performance guarantees would have been easy with yesteryear’s TDM based networks. However, IP/MPLS networks prevailed because statistical multiplexing in packet switching allows oversubscription of traffic without hurting performance, as well as having superior resiliency characteristics under node and link failures.
To guarantee any kind of performance, IP/MPLS network architecture relies on differentiated services bits in the packets, a packet forwarding discipline on routers, as well as a policer at the edge of the network to make sure traffic is in-profile (e.g. a high priority service is not injecting more than its negotiated rate). Expedited Forwarding policy together with edge-policing is possibly the most promising solution for hard performance guarantees. However, edge-policing implies no over-subscription of traffic. This may be the only option for mission-critical services where a timely response with hard guarantees is necessary.
For a real-world potential application of slicing, consider a European Packet Design customer in the electric power delivery business. This network manages a national power delivery grid, connecting power suppliers and consumers by turning on and off various “switches” in the grid. The company effectively runs a market with the price of electric power fluctuating with supply and demand. Not surprisingly, it is a highly secure facility with military personnel protecting it from potential terrorist attacks.
When there is a power transmission network outage, perhaps due to severe weather, a new source of power must be found immediately to avoid city black-outs. If no alternative source is found, they can cut power to a steel plant, per prior agreement, and redirect it to the cities. The decision making and power switching must all happen within 600 milliseconds to avoid black-outs. Today, this customer operates its own network as it is mission critical. With the right set of performance guarantees, they may be able to switch to using a network slice. This would bring a new revenue source to the network operator and cost savings to the customer — a win-win situation.
Though a formal definition is not yet in place, we expect the soft performance guarantees will be more compatible with statistical packet multiplexing and allow a certain level of over-subscription. It may be possible to do this with more relaxed edge-policers. Over-subscription provides better economics for network operators as most services/slices will not operate at their peak rates all the time, and definitely not at the same time across multiple slices.
Regarding the optimum topology for network slices, Layer 2 and Layer 3 VPNs are the best contenders. It doesn’t appear that new networking protocols will be necessary to deliver network slicing. Indeed, the 3GPP liaison at the July 2017 IETF meeting in Prague explicitly stated that no new work is being requested at that time. This, of course, does not prevent engineers from making advances to ease the deployment, monitoring, discovery and management of network slices easier. VPN+, a proposal that extends Layer 3 VPNs for 5G network slicing, is very interesting and we are closely monitoring it. As a matter of fact, the Packet Design Explorer Suite SDN Path Provisioning App, working with an orchestrator from one of our partners (see Packet Design partners with Ciena BluePlanet and NEC/Netcracker) can provision VPN+ services with segment routed low delay paths between dynamically-created Layer 3 VPN VRFs.
So, why do we need analytics? To run a network with hard, soft, and best-effort guarantees, network operators will need to monitor the topology, traffic, and performance of each of the slices as well as the aggregate underlay network. For example, if the capacity of a slice is exceeded, how does the network operator know if and by how much the capacity can be increased without impacting other slices? To answer this, the operator needs to understand the slice’s topology, paths, and traffic volumes in each forwarding class, delay/loss/jitter characteristics, and what other slices are sharing the same underlay resources as well as their utilization levels. Perhaps, the only way to satisfy this request is to re-route some of the slice’s paths in parts of the underlay where there is capacity.
Of course, the Explorer Suite has all this intelligence and the Path Provisioning App can set these paths automatically while making sure mission-critical slices do not leave the “safe/sovereign” network boundaries in the IP/MPLS and underlying optical topologies. To do all this, standards efforts for Network Slicing Management and Orchestration (MANO) are underway and we expect the Explorer Suite will fit right in.
Another very important challenge will be in brown field deployments. It is easy to imagine a green field deployment where every service is in some slice on the network. But today’s networks are already carrying traffic with various classes-of-service and associated forwarding policy and edge-policers. How do you add a slice to a brown field network? The answer is very carefully. Of course, by using the topology/traffic/performance intelligence found in the Explorer Suite, it may be possible to size the legacy demand in the network, migrate it to a “legacy” slice, and add other slices on top of it.
Network slicing is exciting and can enable new revenue streams for service providers. Analytics will play a key role in creating and managing these slices. So, the questions is… Are you and your network ready for slicing?