Heavy reading sdn_metro_networks

White Paper
Software-Defined Metro Networks:
Virtualizing the Network &
Services Edge
Prepared by
Stan Hubbard
Senior Analyst, Heavy Reading
www.heavyreading.com
on behalf of
www.calient.net www.cyaninc.com
www.overturenetworks.com
December 2012

HEAVY READING | DECEMBER 2012 | WHITE PAPER | SOFTWARE-DEFINED METRO NETWORKS 2
Executive Summary
The communications industry is entering an exciting new era with the emergence
of software-defined networking (SDN). Over the past year, we have seen dramati-
cally increased carrier interest in applying SDN architectural concepts and
marrying SDN, carrier Ethernet 2.0 and packet-optical technologies to unleash the
capabilities of the network in unprecedented ways to support cloud and other
next-generation business, residential and mobile services.
A growing number of major service providers worldwide – including AT&T, BT,
CenturyLink, China Mobile, Colt, DT, Level 3, KDDI, KT, NTT, Orange, Telecom Italia,
Telefónica, Verizon and others – have embraced SDN and are promoting SDN
standards, evaluating SDN solutions, beginning early SDN trials and/or deploying
SDN technologies. Many of these operators are focused on driving development
of carrier-specific, SDN-related initiatives within industry organizations like the Open
Networking Foundation (ONF), MEF, IETF, ITU-T Study Group 13 and ETSI's new
Network Functions Virtualization (NFV) Forum.
Despite the buzz of activity, we remain in the very early days of what some are
describing as an "SDN revolution." Heavy Reading survey data and other industry
feedback suggests that the vast majority of carrier professionals tracking the SDN
trend are still just getting up to speed on definitions, benefits and implementation
challenges. While many of these individuals have expressed optimism about the
longer-term impact of SDN on carrier business models, they are looking for practi-
cal ways that they can be begin now to transition toward an SDN architecture.
This white paper is designed to shed light on how operators can take advantage
of emerging SDN solutions to build and operate more efficient and service-friendly
metro networks today while putting in place a software-driven infrastructure that
will enable them to support a vast array of innovative and differentiating services
and applications in the future. We will provide an overview of SDN concepts,
examine important near-term and longer-term drivers of carrier interest in SDN,
discuss key issues for operators to consider as they begin their SDN journey, and
explore opportunities for virtualizing both the photonic transport layer and the
carrier Ethernet services edge. We also will share examples of how SDN virtualiza-
tion can be implemented today and will provide examples of potential SDN-
enabled service options available in the future.
This white paper complements a recent webinar on the same topic hosted by
Light Reading and Heavy Reading, An archive of the webinar involving Cyan,
CALIENT Technologies, Overture Networks and Sidera Networks can be found
here: Metro SDNs – Virtualizing the Network & Services Edge.

SDN Concepts
Perhaps contrary to popular opinion, many of the modern concepts associated
with SDN are not new. A number of carriers and other industry players have been
working on various aspects of software-driven data networks within their own
companies or within the IETF for multiple years. They just did not put an SDN-like
framework around their work until recently.
What is new, however, is the excitement generated over the past 18 months
about open standards-based solutions, extensive programmability, network
virtualization and network-based application-awareness. A growing number of
service provider professionals and their suppliers are intrigued by the prospect that
SDN could fundamentally transform how carrier networks are built and operated
and how services are created, customized, delivered, monitored and monetized.
In our view, SDN is an open, application-aware architectural concept that
encompasses programmability of multiple network layers – including manage-
ment, network services, control, forwarding and transport planes – as well as
network virtualization in order to:
• Optimize the use of network resources by seeking to utilize the lowest-cost
function possible
• Increase network agility
• Unleash service innovation
• Accelerate service time-to-market
• Extract business intelligence
• Enable dynamic, service-driven virtual networks
• Deliver better economics for the overall network
With SDN, applications can request and manipulate services provided by the
network, and the network exposes network state to the applications.
Figure 1: SDN – Open, Network Virtualization, Programmability at Multiple Layers
Source: Heavy Reading analyst perspective, drawing upon various carrier & vendor views

An important aspect of SDN emphasized by the Open Networking Foundation –
and embodied in the OpenFlow standard – is the ability to decouple network
control from forwarding and make it directly programmable. As explained by a
groundbreaking April 2012 ONF white paper, "This migration of control, formerly
tightly bound in individual network devices, into accessible computing devices
enables the underlying infrastructure to be abstracted for applications and
network services, which can treat the network as a logical or virtual entity…
Network intelligence is (logically) centralized in software-based controllers, which
maintain a global view of the network. As a result, the network appears to the
applications and policy engines as a single, logical switch."
SDN thus gives operators the option to take network intelligence out of the router
and put it into a server. What is left in the network element is a simplified packet-
forwarding engine with a table lookup mechanism on where to route or switch.
The controlling server communicates in a vendor-independent way with SDN-
enabled switches or routers via OpenFlow or other standards-based protocols. This
vendor-independence is one of the key tenets of SDN, and it helps service
providers to avoid being locked-in to a particular vendor's proprietary hardware &
software solution bundle.
Another important goal of this approach is to ride the performance/price im-
provement wave of the server market by leveraging the benefits of Moore's law
associated with CPU capacity and storage. This stands in contrast to a traditional
approach that would require expensive and extensive router card and software
upgrades to take advantage of advances in capacity and storage.

A Longer-Term SDN Goal – NaaS
One of the exciting opportunities envisioned for SDN is to enable operators to offer
the network as a service (NaaS) – the ability to support multiple virtual customer
networks running over a single shared physical infrastructure. Here, we are talking
about transforming carrier networks in a similar way to what is happening in data
centers – where dedicated resources are being converted into virtual resources
that enable a cloud-based environment with self-service and usage-based billing.
NaaS is a reasonable destination for a communications industry that generally is
evolving toward a utility model. Dozens of senior service provider experts surveyed
by Heavy Reading in late 2011 agreed that a utility model is beginning to emerge
in which (a) Ethernet serves as the unifying layer to virtualize access to the net-
work, (b) large data centers sit at the heart of the cloud ecosystem and play the
role of power generation plants in the network and (c) high-capacity Ethernet
and wavelength services function as transmission lines interconnecting large and
small data centers.
SDN has the potential to accelerate the transition to a utility model and make the
model smarter by opening up new ways to unlock the value of the physical
network. With SDN's open interfaces and software tools now added into the mix,
we can envision an almost unlimited array of customized services and applications
delivered over a dynamic, programmable, high-performance virtualized infra-
structure. This could include applications that are orchestrated end-to-end across
data centers and multiple physical networks. With SDN, operators should be able
to truly maximize their return on investment in their network assets by evolving the
network into a more agile entity that supports "everything-as-a-service" – including
the network itself.

What's Driving Carrier Interest in SDN Today?
Many service providers are intrigued by the longer term game-changing potential
of SDN, but what is really driving their interest at the moment are practical con-
cerns related to how they run their business. Service providers face particularly
daunting strategic challenges when it comes to controlling costs in building,
scaling and operating metro networks, introducing new and innovative service
types in a timely manner, reducing the time it takes to provision and activate
services, and efficiently managing services once they are up and running.
Since the mid 1990s, carriers have been under constant pressure to scale capacity
on their networks to keep up with explosive residential, business and mobile traffic
demands. At the same time, they have struggled to contain network costs while
driving services to more locations and orchestrating the delivery of new content
into the metro environment. Operators generally have not been very effective in
controlling costs despite advances in fundamentally transforming technologies like
DWDM and carrier Ethernet that have delivered dramatic performance/price
improvements over the past 15 years.
In the view of many SDN proponents, current networks have grown too complex,
static and vendor-dependent to be able to effectively address either the cost
challenges or the dynamic service and application requirements of today's metro
environment. The architecture of most of the network equipment deployed today
is vertically integrated and based on proprietary technology. The routing architec-
ture, for example, uses specialized hardware to support certain network functions
and protocols, and the hardware is tightly integrated with a specialized control
plane and specialized features. While this approach gives vendors opportunities to
differentiate their platforms, it tends to limit the overall pace of industry innovation
because the introduction of new capabilities and support for new services is
dependent on vendor product cycles.
Network cost in the metro environment essentially is a function of the legacy
architecture, which typically consists of multiple closed equipment groups – i.e.,
service edge routers, carrier Ethernet switch/routers, SONET/SDH MSPPs and DWDM
systems – that are difficult to manage in an efficient manner (see Figure 2). The
groups are often treated as individual network silos, with separate element
management (EMS), network management (NMS) and service management
systems (SMS) associated with each silo.
With the legacy architecture, it can take months to introduce new service types
not only because of the need for extensive switch/router upgrades to enable a
new service but also because of required changes to provisioning systems (EMS
and NMS) and billing systems. Meanwhile, even when fiber is available at a
customer site, it can take days to weeks to turn-up services due to the involvement
of multiple EMS and NMS systems, inventory discrepancies, internal coordination
and other business process factors.
SDN is drawing the attention of major operators worldwide because they see the
potential to break free from these and other constraints tied to the legacy
architecture. SDN offers a new way of thinking more comprehensively about the
components of the network and a new way of orchestrating the behavior of these
components that should help control capital and operational costs, speed service
innovation, accelerate service delivery, support more customized services and
applications, and yield additional business benefits as well.

Figure 2: Legacy Network Architecture
Source: Cyan

Software-Defined Metro Considerations
Below, we highlight some of the practical issues for operators to consider as they
begin transitioning their metro networks to an SDN architecture that ultimately
should be capable of supporting everything as a service. We believe it is im-
portant to think holistically about creating a dynamic network infrastructure that is
treated as a single programmable entity and leverages SDN, CE 2.0 and packet-
optical technologies.
Network Functions Virtualization
One of the most important industry developments that has the potential to
dramatically impact the networking landscape and reshape how networks are
built in coming years is the growing interest of major service providers – including
AT&T, BT, China Mobile, Colt, Deutsche Telekom, Orange, KDDI, Telefónica, Verizon
and others – in virtualizing as many network functions as possible.
As explained in the recently published Network Functions Virtualisation white
paper, these operators ultimately want to leverage standardized IT virtualization
technology to consolidate different types of network equipment onto standard-
ized high volume servers, switches and storage platforms located in data centers,
network nodes or end-user sites. The carriers believe virtualization is necessary to
make progress in reducing network costs, speeding service time-to-market,
fostering service and application innovation by enabling development ecosys-
tems, and addressing other important business and technology challenges.
While carrier experts have noted that network functions can be virtualized outside
the context of an SDN architecture, we believe it is important to include network
virtualization in any discussion of the transition to SDN.
Logically Centralized Control Option
Emerging SDN-enabled platforms promise to give operators the flexibility to select
the degree to which network functions are centralized in a logical controller or
distributed in network elements.
For the last decade, the control plane debate has been dominated by distributed
control associated with MPLS and GMPLS. With this approach, control plane
agents within each network element talk to each other and coordinate amongst
themselves regarding network resources. The problem is this does not scale well
because each element has to track information from every other element. This
also requires consistency in the protocols used. Innovation is hindered because
operators cannot change the protocol in any of the nodes without changing it in
all of the nodes.
SDN offers the potential to remove barriers to innovation and to scale in a more
cost-effective manner by moving the control plane out of switches and routers
and logically centralizing the control function in an elastic compute structure that
maintains a global view of the network and can expand independently of the
underlying network hardware. A logically centralized controller permits operators
to gain vendor-independent control over the network while maintaining a
consistent policy and management framework. Operations are simplified by
enabling a network administrator to programmatically configure a network
abstraction rather than manually configure each individual network device.

The key takeaway here is that various network equipment providers are focused
on providing options that will enable either a radical shift to logically centralized
control (i.e., using OpenFlow-enabled switches only) or a more evolutionary
transition that introduces logically centralized control in certain parts of the
network (i.e., using SDN-enabled platforms that support the new OpenFlow
protocol as well as current generation networking technologies).
Open Environment With APIs
Operators should expect that their SDN architecture will be able to take ad-
vantage of an open environment with both northbound and southbound APIs in
place of closed, proprietary systems. The extensive use of standardized APIs at
numerous network touch points promises to enable operators to introduce more
dynamic solutions that can leverage real-time information on the network topolo-
gy, understand the capabilities of end devices, adjust application behavior in
response to usage, bill with greater granularity and deliver a more personalized
customer experience. Meanwhile, the network should be able to leverage
application interaction to do such things as fine-tune bandwidth to meet certain
application requirements.
Multi-Layer Management, Visualization & Modeling
While much of the initial discussion of SDN has centered on what it means for Layer
2/3 switches and routers, the architectural approach needs to be extended to
include Layer 1 technologies like TDM, OTN, DWDM and optical switching as well
for comprehensive network and service management, network visualization,
network modeling and service orchestration purposes.
Based on discussions with multiple operators and other information, we believe a
multi-layer management system with a rich set of OAM capabilities is needed to
support a smart utility model with predictable, reliable, on-demand services and
applications for a diverse set of residential, business and mobile users. Here, we are
talking about a management system that provides traditional FCAPS functionality
(fault, configuration, accounting, performance and security management) as well
as multi-vendor and multi-technology support to simplify network operations,
accelerate service activation and provide end-to-end visibility and control over
how services and circuits are routed and groomed.
SDN software tools are available that can help operators visualize all the elements
in different network layers and understand how the elements interact. The tools
can be used to enhance customer support and to train personnel on the inner
workings of the network. Also, virtualized views based on customers, services,
markets, regions or other factors can be used to support operational procedures.
New modeling tools also are available to facilitate the design of carrier networks
and predict performance on an end-to-end basis. Such a tool can be used, for
example, to design a virtual topology of each network layer to supporting groom-
ing and multiplexing. Or perhaps an operator could look throughout all the layers
of a network to ensure redundancy at every level in support of a premium service.
Service Orchestration Across Technologies, Layers, & Domains
Once operators have logically centralized control, open APIs, comprehensive
service management and visualization/modeling tools, they can then think about

orchestrating services and applications across multiple technologies, network
layers and network domains. The idea here is for applications to have access to all
of the information about the network and service performance capabilities that
they need to know. Armed with this information, applications can coordinate
across all of the Layer 1-3 technologies and network domains in order to make the
most efficient use of network resources and to ensure the appropriate resources
are devoted to meet certain performance requirements.
Orchestration has potentially far-reaching implications because it can enable
carriers to get the best economics by grooming higher layer constructs into lower
cost, higher capacity tunnels. Stated another way, orchestration may allow
operators to no longer be held hostage to Layer 3 router economics and, instead,
may finally open up the possibility of fully leveraging the performance/price
advantages of Layer 1 photonic and Layer 2 carrier Ethernet technologies.
Cyan's Blue Planet SDN system, illustrated in Figure 3, is the type of software
orchestration solution that we believe will be warmly received in the market as
operators embark on their SDN journey.
Formally announced in November 2012, Blue Planet is an open architecture
platform that allows Cyan and third-party applications to interrogate and control
the underlying network architecture. It is designed to work with a wide range of
OpenFlow-enabled devices as well as devices that are not SDN-enabled. Blue
Planet already is being used by NTT Communications to increase network efficien-
cy and to facilitate more rapid Ethernet service delivery, according to the carrier's
Vice President of Engineering.
Figure 3: Snapshot of Cyan’s Blue Planet SDN System
Source: Cyan

Figure 3: Snapshot of Cyan’s Blue Planet SDN System (Continued)
SYSTEM ELEMENTS DESCRIPTION
SDN Orchestration
Platform
This service orchestration platform includes an operating system, a hypervisor, a
messaging system, middleware, and a Web portal – all of which run in a distributed
computing environment. It also includes APIs for application development as well as
network services such as databases, inventory and asset management, topology
management, and security.
SDN Applications
The SDN platform supports a variety of Cyan applications and incorporates an appli-
cation development environment to facilitate the creation of third-party applications.
Cyan’s applications fall into three groups that are aligned with the service life cycle: 1)
planning applications that enable the designing and planning of multi-layer and multi-
vendor networks; 2) service performance and SLA monitoring applications that provide
real-time and historic information on the performance of individual services; and 3)
operations applications that include FCAPS functions and other innovations designed
to simplify operations and management. Many of the Cyan applications employ the
company’s 3-D visualization capability.
Element Adapters
Cyan provides element adapters that enable the SDN platform to control the compa-
ny’s packet optical platforms as well as Layer 1-3 devices from 20+ other network
equipment suppliers.
Source: Cyan

Virtualizing the Photonic Layer
The convergence of SDN and next-generation photonic platforms makes it
possible for carriers to dynamically reconfigure the optical network to support
high-capacity data flows with guaranteed low-latency for on-demand applica-
tions and NaaS requirements. In this section, we discuss what it takes to virtualize
the photonic layer and share examples of how this can be implemented today.
Why Virtualize the Photonic Layer?
The continued rapid growth in traffic demands on networks, combined with
dynamically changing traffic patterns associated with mobile data, video and
cloud services, can lead to situations in which metro networks become overload-
ed, latency increases and application performance suffers. Up to now, operators
have had little choice but to spend scarce capital on over-designing the network
for a worst-case scenario in order to ensure that the proper amount of bandwidth
is available and that service quality is maintained. This leads to poor utilization of
network resources with a certain amount of stranded capacity that yields no
direct revenue benefit. This is not profitably sustainable especially at a time like
today when traffic demands continue to increase while revenue growth remains
fairly anemic for a number of services.
Operators obviously would prefer a more efficient approach to get the most out
of their network investment. They are not only looking for a bandwidth-on-demand
capability that allows them to direct network capacity where it is needed, when it
is needed. They also are looking for guaranteed performance-on-demand to
support the various latency, jitter, packet loss and availability requirements of a
diverse set of real-time and non-real-time applications. The photonic layer is the
foundation for all other virtual services that ride above it, and the ability to
partition and dynamically reassign resources should start here.
Virtualizing With Optical Circuit Switching + SDN
Traditional solutions fall short when it comes to readily reconfiguring optical
networks. While suitable for short, bursty traffic, they generally are not designed to
handle the switching of large data flows in an economic manner, nor are they
designed to deliver the low latency performance required by many applications.
However, optical circuit switches (OCS) like those offered by CALIENT Technologies
can support massive data flow switching with low latency. Built with 3D MEMs
technology, these platforms require no optical-electronic-optical conversion and
can switch in 25 milliseconds. They are designed to support switching up to 100
Gbit/s and beyond without an equipment upgrade.
We discussed earlier that one of the goals of the SDN architecture is to utilize the
lowest-cost function possible. Optical circuit switching takes us a step in that
direction by leveraging the performance/price advantage of photonic technolo-
gy, but we still need a way to have coordinated control over both the optical
circuit switches and the packet switches/routers deployed in a converged
network. This is where SDN steps in.
Both the SDN management plane and the SDN control plane have roles to play in
dynamically reconfiguring the optical network. The management plane analyzes
flows within the network in coordination with the photonic and routing control
planes, creates new topologies and related configurations based on operational

needs, and propagates the configuration to the respective control planes for
execution. The SDN control planes then orchestrate topology-related changes. A
photonic engine handles changes across the optical switches, and a routing/
switching engine deals with changes across routers/switches. Both the photonic
and routing/switching engines maintain the status of execution of each step in the
configuration flow and communicate this status to the management plane.
Are combined OCS + SDN solutions available today? In November 2012, CALIENT
introduced a new OpenFlow API that – when combined with an OpenFlow
controller – allows the company's S320 optical circuit switches to reconfigure
networks to optimize high-capacity data flows. Connections can be changed at
the instruction of the OpenFlow controller based on time of day, real-time applica-
tion requirements or predictive algorithms. The OpenFlow API on the S320 is
available for interoperability testing, as of December 2012.
Example 1 – Maximizing Cloud Performance
Let's look at an example of where it makes sense in the metro setting to virtualize
the photonic layer. Here, we have an operator that is looking to maximize the
performance of cloud services by improving the way capacity is managed
among data centers. A couple of SDN-enabled capabilities that are applicable
include rapid service provisioning & reconfiguration and dynamic network
optimization, which permits the carrier to deal effectively with fluctuating traffic.
Figure 4 illustrates multiple data centers interconnected over a metro fiber
network. The connections most likely would be implemented as wavelengths on a
fiber ring. Based on the time of day or a particular event, we see a need for
additional capacity between datacenters 3 and 4. An SDN controller responds to
this need by ordering the OCS to reallocate capacity from other nodes to support
the short term demand. This type of reallocation of capacity – which would have
been largely impossible prior to SDN – could take place multiple times in a single
day in an application-driven network environment.
Figure 4: Maximizing Cloud Performance by Virtualizing the Photonic Layer
Source: CALIENT Technologies

Example 2 – Minnesota Telecom Evolving Toward SDN Architecture
Cyan and CALIENT are currently involved in an SDN-related network evolution
project launched in mid 2012 by Minnesota Telecom's Northeast Services Cooper-
ative (NESC). The operator has deployed an integrated solution consisting of
Cyan's Blue Planet SDN platform, Planet Operate network management applica-
tions and Z77 packet-optical transport platform, as well as CALIENT's S320 photonic
switch. This solution is being used to deliver a variety of broadband services for
enterprise, government and residential customers over a 915-fiber-mile network.
The initial phase of the project has focused on centralized management, provi-
sioning and testing for all nodes in the network. Having a single multi-layer man-
agement system for both the packet-optical and photonic switching platforms
enables the operator to avoid contention – that is, having two different flows of
traffic trying to use the same wavelength at a given node.
In a later phase, Minnesota Telecom plans to utilize software-defined customer
control that, among other things, will permit bandwidth levels to be changed on
the fly.
Figure 5: Minnesota Telecom – Multi-Layer Management
Sources: CALIENT Technologies & Cyan

Virtualizing the Carrier Ethernet Services Edge
Virtualization of the carrier Ethernet services edge has the potential to help
operators become operationally more efficient, speed service deployment,
ensure a consistent end-user experience and create dynamic service offerings for
the cloud era. In this section, we explore some of the key steps operators can take
to virtualize the edge and share an example of how virtualization is being used to
accelerate service turn-up.
Why Virtualize the Carrier Ethernet Services Edge?
Operators face a multitude of challenges that negatively impact their ability to
generate a profit from the traditional edge service delivery architecture. These
include:
• Lack of consistency & scalability. Carriers typically deploy a variety of
point solutions from multiple vendors, which can make it difficult to inte-
grate these products into back-office systems, maintain consistent service
offerings or roll out new features across platforms and across the edge
network.
• Slow service velocity. The current complexity of the network edge, com-
bined with the typical process of manually provisioning circuits on access
devices, also makes it difficult to quickly deploy new services and effi-
ciently manage moves, adds and changes.
• Revenue de-coupled from bandwidth demand. Customer demand for
more bandwidth does not necessarily translate into additional revenue. In
fact, it is not uncommon to see customers shift to an Ethernet service with
the expectation that they will get much more bandwidth for the same
price that they were paying for a lower speed legacy TDM circuit. The
operator can be left facing potentially higher operating costs at the edge
without an increase in the average revenue per user (ARPU).
In addition to the profitability challenges, many carriers also are on the hook to
ensure highly reliable access in an increasingly on-demand cloud services envi-
ronment.
How Virtualization Addresses Service Edge Challenges
SDN-enabled virtualization promises to help address cost and service-related
challenges in numerous ways. Among other things, virtualization provides opera-
tors the ability to:
• Abstract service creation and management and thereby create a more
dynamic service deployment environment.
• Simplify IT and back office integration by masking or hiding some of the
complexity of specific network elements and access technologies.
• Leverage the flexibility of OAM-rich multiple access options to deliver a
consistent service offering with performance guarantees to all customer
locations.
• Better integrate multi-vendor or third-party demarcation platforms, which
can help control operational costs.

• Accelerate time-to-service by opening the northbound control plane in-
terface.
• Accelerate service turn-up via increased automation.
There are three basic types of platforms that work as a "system" to virtualize the
services edge. These include a service orchestration/management platform, a
service aggregation switch (what Overture calls a service exchange switch) and
service nodes (i.e., NIDs or demarcation devices).
Example – Rapid Service Turn-Up With Virtualization
Let's take a moment here to explore how virtualization can help accelerate
service velocity.
Today, zero touch provisioning solutions are available from Overture and a small
number of other suppliers that reportedly can help operators save as much as 15%
to 20% on operational costs by eliminating unnecessary truck rolls and streamlining
the service provisioning and activation process. With zero touch provisioning, the
service orchestration platform can discover a service node, store the node's
configuration, pre-provision the node for service turn-up and periodically down-
load software updates in order to upgrade the edge network.
Going forward with SDN-enabled virtualization, operators should be able to do
network-wide flow-through provisioning from the metro core to the enterprise
customer site (see Figure 6). In this scenario, following the installation of a service
node, the service aggregation platform engages in a short series of communica-
tions back and with the node to ensure that it is properly configured and the
service is commissioned. An operator could then use SDN/OpenFlow commands
to orchestrate dynamic service creation and EVC moves, adds and changes.
Figure 6: SDN-Enabled Virtualization & Network Wide Flow-Through Provisioning
Source: Overture Networks

Looking Ahead: SDN-Enabled Service Options
The convergence of carrier Ethernet, SDN and the cloud promises to make
networks operationally more efficient, flexible and scalable and to unleash faster
service innovation. We are just at the beginning of what is shaping up to be an
extraordinary paradigm shift in the way networks are built, operated and utilized.
We have highlighted some practical applications enabled by emerging SDN
solutions and also discussed a longer term vision in which operators can utilize an
SDN architecture to provide the network itself as a service. But we have only
begun to explore what the future could bring.
The following are several additional examples of emerging service options
enabled by the transition toward an SDN metro architecture and extensive use of
service OAM, service orchestration, centralized control, network programmability
and virtualization of network resources.
• Increasingly sophisticated real-time capacity management. During an
Ethernet Expo Americas keynote in November 2012, tw telecom's SVP for
Business Development & Strategy Mike Rouleau shared an outlook for real-
time capacity management that involves an evolution from: 1) manual
control today to 2) threshold management and eventually to 3) API-driven
management. Earlier this year, tw telecom introduced the capability for
customers to manually double or triple their capacity in real time via a
Web service portal. In the future, the operator expects to have the ability
to adjust bandwidth based on utilization triggers, events or scheduled ca-
pacity changes. Eventually, tw telecom envisions being able to use APIs to
automatically drive bandwidth-on-demand, with applications signaling to
the network to turn bandwidth up or down on the fly, thereby eliminating
the need for dedicated overlay networks with stranded capacity.
• API-driven performance-on-demand. We could also envision API-driven
performance-on-demand, in which the network dynamically ensures not
only that the appropriate capacity is available for a given application,
but also that a guaranteed level of performance is delivered. Here we are
talking about using service orchestration and logically centralized control
to choose the best paths in the network to meet SLA targets for latency,
jitter, packet loss and availability, then dynamically allocating the neces-
sary resources along those paths to make sure those targets are met.
• Private cloud services. In mid 2012, NTT Communications became the first
operator in the world to introduce an enterprise cloud service that utilizes
an SDN/OpenFlow infrastructure. Doug Junkins, the CTO of NTT Americas,
recently shared that the operator already has deployed OpenFlow-
enabled switches in its data centers in Hong Kong and Tokyo and is on
track to have switches deployed in the U.S. and Europe as well by the end
of 2012. NTT Communications is tying the orchestration of its customer por-
tal and cloud controllers into an OpenFlow controller to completely au-
tomate the SDN network and enable customers to quickly spin up and
spin down virtual machines. The service will enable customers to have
precise control of server resources as well as network resources – such as a
virtual firewall, virtual load balancer and virtualized networks. An online
portal also permits customers to monitor usage of server and network re-
sources and change settings on a real-time basis.

Heavy reading sdn_metro_networks

More Related Content

What's hot (19)

Similar to Heavy reading sdn_metro_networks (20)

Recently uploaded (20)

Heavy reading sdn_metro_networks