In our previous newsletter, we outlined three separate use cases for the deployment of bare-metal switches: in a campus network, in a data centre, and on the edge of a metro Ethernet network. The latter considers a migration to a minimal white-box configuration for the customer gateway complemented by a virtualised edge-routing application running on an OpenFlow switch in a central carrier-aggregation node. We have since developed a concrete business model for this case which evaluates several different timing scenarios and calculates the capex, opex and payback potential of each relative to a Do Nothing scenario.
Figure 1: Customer-migration scenarios and associated financial outputs
The methodology was first published at the STEM User Group Meeting on 07 October and demonstrates how even the most nebulous technical opportunity can be de-mystified on a suitably flexible platform if you take time to invest in the story first.
1. The context
Consider a communications service-provider (CSP) which connects multiple enterprise customers via 1GE or 10GE rings in a metro area network. Currently the network interface device (NID) is a managed edge router configured to present various services to the customer such as virtual private circuits and public Internet. High capex and dedicated engineer time are required to connect a new customer.
Figure 2: Migration to network virtualisation in a metro area network
The present conventional routers are expensive to buy and to maintain. Their typically over-featured capability may be replaced with a bare-metal switch with the minimum required SDN feature-set (as ‘dumb’ as possible, and potentially avoiding the necessity for on-site patching).
The same services can be delivered on virtual circuits from a carrier aggregation node running an OpenFlow virtual routing app for each customer. This results in an economy of scale (compared to distributed intelligence and processing) and offers the potential for orchestration in a central office compared to managing multiple remote devices.
2. The approach with STEM
We are looking specifically at changes in the metro network between provider-edge and managed customer-edge routers. We will focus on the difference between various migration scenarios and a Do nothing base-case, so it is not necessary to model the remaining network and business elements.
Figure 3: Modelling scope from provider edge to customer edge
Our modelling approach as shown below focuses mainly on a Managed data service for enterprise customers and its connection to the network. The initial NID is a Conventional managed router which interfaces to a Provider edge router on the final spur to the customer. In the various migration scenarios, the NID is replaced with a minimal White-box switch configuration which connects to a virtualised edge-routing application running on an OpenFlow switch in a more central carrier-aggregation node.
In addition to the simple capex and opex comparison of these elements, the model also considers the effort associated with configuring the new SDN solution, alongside an annual maintenance re-configuration budget on either technology, where a defining assumption of the new technology is that it should be both easier and more convenient to control. Finally, the model assumes a modest take-up of SDN services such as liquid bandwidth or dynamic VPNs for those enterprises which have been migrated and an associated increase in revenue and traffic.
Figure 4: Network migration, configuration effort and incremental SDN services in STEM
2.1 Services – demand and revenue
We assume a type of generic enterprise, each served by one connection, for which there is an addressable market of 500 enterprises in the area considered:
- the main Managed data service has an s-curve penetration, and traffic per connection grows from 0.5 Gbit/s to 2 Gbit/s over the ten-year results-window evaluated
- the additional SDN services also have a (lesser) s-curve penetration assumption and require 10% additional bandwidth compared to ‘normal traffic’.
Tariffs are not central to the business case, but are a useful reference to show the discount effect for a Beta test scenario and to measure the effect of additional revenues for services supported by SDN:
-
Managed data has a USD 500 connection tariff and USD 9000 rental tariff (p.a.), with a discount of 25% for beta testers (rental only)
- additional SDN services are positioned at 5% of ‘normal tariff’ = USD 450 rental tariff.
2.2 Hardware – cost and capacities
The costs for this case will already vary enormously in practice, and it is likely that the market disruption envisaged will lead to further volatility. Nevertheless, you have to start somewhere and the assumptions we have used so far are shown below.
| Conventional solution |
SDN/OpenFlow solution |
Managed router at customer site:
- able to handle one enterprise
- MPLS, QOS, VPN, 5Gbit/s
- capital cost ~ USD 20,000
|
White box at customer site:
- able to handle one enterprise
- MPLS, QOS, OpenFlow
- capital cost ~ USD 7000
|
|
Provider edge-router chassis:
|
OpenFlow router chassis:
|
|
Provider edge-router cards:
|
OpenFlow router cards:
|
Figure 5: Hardware capacity and cost assumptions
Figure 6: Capex and depreciation compared between convention and migration scenarios
2.3 Controlled transition between technical architectures
The migration between these two solutions is managed by the built-in Function construct in STEM. This is a general purpose tool for modelling such transitions which differentiates between:
- the selection of technology for new customers, and
- the separate migration of existing customers (typically more constrained).
STEM effortlessly handles such details, enabling you to focus on ‘the big picture’.
Figure 7: Alternative migration scenarios for transition to SDN
2.4 Operational tasks and corresponding effort and cost
In order to capture the operational benefits of the migration to SDN, we consider configuration changes in the network, such as populating routing tables:
- each new device at a customer site requires configuration (and also on replacement)
- each existing Managed data customer requires an average of two re-configurations per year for new applications, VPNs, and so on
- additional SDN services require a configuration (although many may be done by customers themselves in practice).
In order to convert each of these tasks into measured effort, we make the controversial and certainly volatile assumption that a conventional network configuration takes 4 hours, compared to 0.25 hours in the SDN/OpenFlow network. At USD 50,000 p.a. for a network Engineer, the impact of these assumptions will be significant, even if the emphasis is on ‘getting more done’ rather than ‘having fewer engineers’. A sceptic will query the implicit 16x productivity gain and might argue that it will take time for the industry to achieve these results in practice.
As you will see below, the model can be readily extended to examine a wide range of what-ifs, according to the factors which are perceived as the most relevant or potentially advantageous and/or risky to your organisation.
Figure 8: Configuration tasks (in number) and corresponding effort and cost
3. Key results and scenarios
The whole point of this exercise is to evaluate the business case for a potential migration and we model a number of alternative futures which would enable a carrier to determine not just whether the economics work, but also how best to approach the change:
- Do nothing: if it ain’t broke, don’t fix it (and risk annoying customers)
-
Test site: deploy new solution at an internal test site for one year, and then flat roll-out to customers over next two years (pain with slow gain)
-
Beta test: offer 1-year discount to 10% of customers to try out new solution before roll-out to the other 90% (solve problems sooner)
-
Phased introduction: minimal lab test period then S-curve roll-out (hire extra customer service agents and take it on the chin).
Figure 9: Comparing the economic performance of different migration scenarios for transition to SDN
At the recent STEM User Group Meeting, we also considered a range of uncertainties where you might want to add some kind of best/worst case analysis, such as:
- later start for transition
- slower take-up
- revised cost assumptions as market re-balances
- longer configuration time for SDN due to teething troubles and lack of experience in first two years
- ‘win some’ if you implement SDN
- ‘lose some’ if you don’t
- differing physical characteristics of production hardware
- possible governance requirements for ‘dual source’ leads to higher cost
- currency fluctuations.
Figure 10: Adding new scenario cases to the SDN model
The STEM platform provides a flexible and responsive environment for exploring such what-ifs. The last thing you need to worry about is whether your model will run!
4. Next steps
The model presented here is only an indication of the more specific and detailed analysis we would deliver in a commercial context, but it illustrates a quantitative approach which has been absent from much of the SDN collateral we have seen in the public domain to date. It demonstrates how a coherent business-case can be explored, even when there are many unknowns, which is of course the time when you most need a model! The very process of thinking through the drivers and possibilities helps you to rationalise the technical, regulatory and economic uncertainties.
The STEM modelling platform will help you model very specific intended scenario-outcomes with precision. We offer to work with you to navigate the business and technical opportunity of SDN – are you ready?
STOP PRESS
This methodology will be demonstrated live in the Tools session at CTTE 2015 in Munich on 10 November 2015.