Documente Academic
Documente Profesional
Documente Cultură
by Abel Tong
and Kevin Wade
NFV and SDN Guide for Carriers and Service Providers
Published by
Ciena
7035 Ridge Rd.
Hanover, MD 21076
No part of this publication may be reproduced, stored in a retrieval system or transmitted in any form
or by any means, electronic, mechanical, photocopying, recording, scanning or otherwise, without the
prior written permission of Ciena Corporation. For information regarding permission, write to: Ciena
Experts Books 7035 Ridge Rd Hanover, MD 21076.
Ciena, BluePlanet, and the Ciena and BluePlanet logos are registered trademarks of Ciena Corporation
in the U.S. and other countries. Third party trademarks mentioned are the property of their respective
owners and do not imply endorsement.
Publisher’s Acknowledgments
We’re proud of this book; please send us your comments at expertbooks@ciena.com
Some of the people who helped bring this book to market include the following:
Additional Contributors:
Earl Follis
Britt Marshall
Mina Paik
Editor:
Elisa Rodero
Essentials
4
Executive Summary
Service providers’ sense of urgency to use Software-Defined Networking (SDN) and
Network Functions Virtualization (NFV) is being driven by the demand for dynamic
services and customer control. The drive to virtualize the network is different from
other transformational initiatives in the past, as the impetus for change is based
on end-user demands rather than technological advancements by networking
vendors. Service providers are always looking for ways to cut Operating Expenses
(OPEX) and Capital Expenses (CAPEX) while delivering networking solutions that
support their ever-changing business goals. A perfect storm of new technological
capabilities—increasing demands imposed on networks due to cloud computing
and big data, growing market acceptance for network virtualization, and the avail-
ability of NFV and SDN products—sets the stage for an explosion in demand for
SDN and NFV by service providers around the world.
NFV and SDN represent a revolutionary way of configuring, deploying, and main-
taining networks that provides a compelling business case for service providers to
fundamentally change the way they implement customer-facing network services,
functions, and capabilities. SDN decouples the data plane from the management
plane, enabling network orchestration, control, and management in a way that is not
possible using traditional networking hardware and software solutions. NFV, mean-
while, promises to virtualize network services, decoupling software from proprietary
hardware. This allows network operators to quickly configure and deploy new net-
work services using a policy-based management paradigm running on commodity
hardware. Both technologies support highly agile networking, elastic provisioning,
reduced time-to-revenue for new services, and frictionless customer turn-ups.
Collectively, NFV and SDN present service providers with an opportunity to imple-
ment a more customer-centric network infrastructure, where the network easi-
ly—and, in some cases, automatically—adapts to dynamic customer needs and
requirements. By delivering programmability, network agility, and simplified network
management based on open concepts and standards, NFV and SDN help custom-
ers transition to software-defined networks based on commodity hardware and
open software to lower costs and avoid vendor lock-in.
5
Roadmap for this Book
This NFV and SDN essentials guide will give readers a concise overview of the archi-
tectural concepts of NFV and SDN. It will also discuss market drivers and the value
propositions for NFV and SDN, including how NFV and SDN can increase a compa-
ny’s revenue while reducing costs. This guide will outline the foundational building
blocks of NFV and SDN, and, lastly, discuss the future of NFV and SDN from Ciena’s
perspective. This document also includes a glossary of general networking terms
and acronyms for reference.
NFV gives service providers and operators the opportunity to lower their network
infrastructure costs while speeding up the configuration and deployment of new
network services. This new, more flexible, software-based network service envi-
ronment allows service providers and operators to quickly spin up new network
6
services as needed for specific situations and customers, shortening the process
from the weeks or months to days or even minutes. This business agility creates a
significant competitive advantage because it allows network operators to pursue
new markets and opportunities that were not economically viable using traditional
networking hardware and software, and do so much more quickly.
What Is NFV?
NFV can reduce or eliminate application-specific, proprietary hardware from the
network infrastructure. Instead of requiring a network operator to deploy new
hardware components for each new service or application, the NFV model provides
the same functionality using virtual appliances running on commodity x86 servers.
Conceptually, an operator can deploy a virtual appliance on demand and upgrade its
functionality through software updates over time. Figure 1 presents a comparison of
the classic network model versus the new network model.
Figure 1. Classic network model features hardware-based appliances and components, while
the new virtual network model utilizes virtual appliances and components. (Image source:
ETSI) Traditional physical networks incorporate specialized hardware that offers one physical
node per role, manual installation processes per site, and static, hard-to-scale operations.
Meanwhile, virtualized networks are software based. Multiple roles may run on the same hardware
components. Virtual networks enable remote operation and management. They are dynamic and
easy to scale, based on operational requirements.
7
Firewalls, Provider-Edge (PE) routers, Deep Packet Inspection (DPI), and encryption
are a few examples where currently an operator typically deploys separate hardware,
often from different vendors. Each hardware element faces its own obsolescence
cycle, requires its own certification activities, and needs to be managed, often in
unique ways. Managing these multiple vendors and functions is complicated and
fundamentally too expensive to scale and support. Worse, the ability to quickly turn
up new applications is difficult to impossible for most service providers.
8
Further, as functionality evolves or standards change—for example, in encryption or
virtualized security—updates are made through software remotely, without physical-
ly touching any hardware.
9
Figure 2. A selection of vendors that develop and market VNFs
The VNF ecosystem includes a wide variety of components from multiple vendors.
A few examples of VNFs include vRouter functionality, security and encryption,
load-balancing, virtual Set-Top Boxes (vSTB), WAN optimization, and performance
monitoring. Once selected, the VNFs are controlled and operated through what
ETSI has defined as the Management and Orchestration (MANO) function. MANO
includes the distribution of VNFs across hosts, orchestration of VNF functionality,
and management of a VNF’s lifecycle. Figure 2 shows a selection of vendors offering
VNFs and virtual appliances.
NFV MANO consists of three functional areas that accomplish all tasks related
to the lifecycle of a VNF: NFV Orchestrator (NFVO), VNF Manager (VNFM), and
Virtualized Infrastructure Manager (VIM). The NFV orchestrator brings on new
network services and VNFs and provides global resource management, validation,
and authorization of VNF infrastructure resource requests. VNFM controls specific
VNF instances, coordinating infrastructure resource requests between the VNF
instance and related network element management systems. The VIM controls
and manages NFV infrastructure, which includes compute, storage, and network
resources.
Operators have multiple options in terms of the servers used for hosting VNFs,
NFVO, and VIM, and their physical locations. Depending on service provider options
and enterprise strategies, servers could be virtual resources located in a cloud data
center, a central office, a dedicated pod, or the customer’s premises.
10
SDN Basics
SDN has rightfully garnered much recognition over the last few years as the tech-
nology has rapidly progressed from conceptual architecture to standards-based
products and capabilities. SDN is a disruptive technology that continues to mature
as new products are introduced into the market. And the momentum behind SDN
continues to grow as users create new and innovative applications that combine
SDN with NFV.
What Is SDN?
SDN is a network architecture based on the concept of separating management
and control of a network from its physical hardware. This logical separation enables
network behavior to be programmed by a diverse set of applications and services
using open APIs. By opening up traditionally closed networks, SDN allows service
providers to control networks and devices in a consistent manner, regardless of the
underlying hardware or networking technology (for example, Carrier Ethernet (CE),
IP/MPLS, or SONET/SDH). By driving standards for the programmatic interfaces,
SDN applies unified management and control to these formerly disparate networks.
11
but in reality, end-user demand is also pushing companies to adopt SDN. Mobile
computing, Bring-Your-Own-Device (BYOD), and hybrid cloud architectures can
drastically shift network traffic characteristics. Conventional networking archi-
tectures cannot easily adapt to these ever-changing requirements, while SDN is
specifically designed to handle these types of dynamic, demanding network envi-
ronments.
SDN Tenets
SDN improves network control and reduces the cost of a network while increasing
agility by leveraging four key attributes:
12
where open APIs support a wide range of applications, including cloud
orchestration, OSS/BSS, SaaS, and business-critical networked apps; from
below, where intelligent software controls hardware from multiple vendors
through open programmatic interfaces; and from within, where intelligent
network services and applications can run in a common SDN software envi-
ronment.
A key advantage of SDN is the ability for network operators to build applications and
programmatically control their networks though SDN-enabled APIs. SDN enables
applications that are not just network-aware, but can intelligently monitor network
conditions and automatically adapt the network configuration as needed. Thus, SDN
enables agility for the delivery of dynamic and on-demand services like bandwidth
on demand. SDN also facilitates network automation, which reduces operational
costs for deployment, management, and operations. The cost savings realized
through SDN-based automation both increase profits and reduce costs while
achieving the ultimate benefit of improved agility.
Another benefit of SDN is the ability to establish policies for managing networks,
service-levels, and applications, rather than explicitly managing network configu-
rations for physical resources. Network policy management is made possible in an
SDN environment because the SDN controller collects global knowledge of the net-
work. That global knowledge allows SDN controllers to map policy settings across
13
the network and into the appropriate configuration of each network device. This
capability enables SDN operators to leverage policies to manage networks from a
services perspective—such as users and applications—as compared to the phys-
ical resource-based approach used by legacy network architectures. Policy-based
automation frees up network administrators from mundane activities so they can
concentrate on more important activities like troubleshooting complex network
issues or network planning.
SDN automation also has the potential to help service providers find and retain
qualified network administrators. By automating operations, network complexity is
reduced and network managers can manage a greater number of devices with few-
er errors and greater productivity. Changes take far less time, and resources may
be utilized more efficiently than in the past. In the IT space, server administrators
have leveraged virtualization and automation to the extent that the typical server
administrator can effectively manage multiple thousands of servers. SDN will give
network administrators that same sort of leverage, to manage many hundreds or
thousands of network devices, rather than dozens. SDN exponentially expands the
scope and reach of network operations personnel, reducing CAPEX and OPEX in
the process.
These building blocks combine to create a solid foundation for virtualized networks
to offer robust, automated, agile services to service providers, operators, and enter-
prises. Figure 4 shows the three layers of the virtualized network model: the Orches-
tration Layer, the Control Layer, and the Infrastructure Layer.
14
Figure 4.
Orchestration Layer
With the transition to virtualized networks, the Orchestration Layer provides the crit-
ical function of abstracting services from the underlying infrastructure components,
including physical and virtual networks. The abstraction, combined with open APIs
enable service providers to create, deploy and manage services across multiple
network domains, and automate their lifecycles – a process which we refer to as
‘multi domain service orchestration’. In addition to interfacing with the Control and
Infrastructure Layers, the Orchestration Layer also leverages open interfaces and
APIs to communicate with traditional OSS and BSS systems to integrate with back-
end service management processes, such as service assurance, alarm monitoring,
order management, and billing.
The decoupling of network services from the actual underlying network and their
elements through a common abstraction layer reduces the need for custom coding
across different network and management siloes. With the right service orches-
tration solution, Service Providers benefit from their ability to add, configure and
provision new devices and services flexibly and in realtime, to meet the require-
ments of today’s on-demand services -- even in the most complex, heterogeneous
environments.
Control Layer
The Control Layer is focused on controlling and managing individual physical and
virtual domains, providing the programmability and intelligence to manage and
control traffic flows within that environment. The Control Layer includes platforms
such as underlay and overlay SDN controllers, cloud or VIM platforms, and NFV
orchestrators that control and configure network resources. The Control Layer also
15
features standards-based interfaces to the north and south that tie the Orchestra-
tion Layer to underlying network functions, and open interfaces to the east and west
that support scaling of the virtual network.
Key requirements for the Control Layer include an approach and framework that
leverage open standards to ensure interoperability with other hardware and soft-
ware. Another key requirement for the Control Layer is the support of legacy
network protocols such as CLI, TL1, and SNMP, in addition to newer protocols and
interfaces such as REST APIs, OpenFlow, and Netconf/YANG.
Infrastructure Layer
The Infrastructure Layer includes the physical and virtual appliances and devices
that comprise the network layer in a virtualized network. The Infrastructure Layer
is where the processing and forwarding of data occurs. In a multi-domain environ-
ment, these network components can include both virtual networking and legacy
network gear that has been integrated into the Infrastructure Layer. The Infrastruc-
ture Layer also provides intelligent forwarding, switching, and routing protocols that
can be reconfigured at any time without requiring the network to be brought down
for maintenance. As network intelligence moves from network devices such as
proprietary routers and switches to the Control Layer, network hardware becomes
a commodity component, driving down hardware costs, while SDN automation
increases the agility of configuring and maintaining the network. The Infrastructure
Layer communicates with the Control Layer using legacy network protocols such
as CLI, TL1, and SNMP in addition to newer protocols and interfaces such as REST
APIs, OpenFlow, and Netconf/YANG.
16
Figure 5. Automation, optimization, and monetization are key competitive advantages of SDN.
Automation improves operational efficiency while reducing the time to market for
new network services. Optimization conserves network resources while improving
the quality of network services. Monetization leverages intelligent pricing models
and the ability for mass customization to generate new revenue for operators. This
book examines the competitive advantages service providers can expect to derive
from NFV and SDN as crucial contributors to their ongoing success.
17
Figure 6. An Infonetics Research survey highlighting what service providers are looking for in NFV
and SDN
The agility offered by SDN and NFV is a huge competitive advantage that can
increase revenue by delivering to customers what the competition cannot, faster
than ever before. Increased agility alone makes a strong case for SDN adoption
among operators. Fortunately for operators and customers, SDN has even more
benefits.
18
Operational efficiencies: NFV and SDN promote operational efficiencies by auto-
mating routine network maintenance tasks, network provisioning, and troubleshoot-
ing. Automating network optimization, as described above, is an excellent example
of how operational efficiencies inherent in SDN can streamline routine network
management.
Refocusing on growth via SDN and NFV automation: As SDN and NFV work to
streamline operations, software will take over more of the day-to-day management
of SDN networks. As a result, existing network personnel can spend less time mon-
itoring and maintaining services and more time creating services and generating
revenue. This shift in utilization improves the efficiency of the business and allows
for budgetary reallocation to generate more profit.
Openness of SDN platforms: Clearly, operators have long bristled under the
restrictive environment offered by proprietary network vendors, being forced to
wait months or years for coveted features and capabilities to finally make it into a
released product. Proprietary hardware also tends to be expensive, and once an
operator commits to one networking vendor, it gets harder to consider other man-
ufacturers’ equipment due to the real possibility of compatibility and interoperability
issues. SDN assists with interoperability issues by using a robust set of standards
that migrates the majority of network intelligence from a dedicated, closed-architec-
ture network device to standard hardware and software available from a multitude of
OEMs.
Summary
The value proposition for SDN and NFV combines the competitive advantages of
programmability, the technical advantages of centralized intelligence, the finan-
cial benefits of automation, and the increased agility that helps service providers
and operators to attract new customers. SDN and NFV represent a profound shift
in the focus and control of networking technology, from proprietary vendors to
standards-based OEMs, creating hardware that works seamlessly with hardware
from other OEMs. A cursory inspection of SDN and NFV features makes it clear that
these specifications have been developed with operators, rather than networking
vendors, in mind. This stark difference from earlier network standards efforts is
exactly why SDN and NFV are not considered just an evolutionary step, but rather
a revolutionary leap forward for service providers. NFV plus SDN puts operators,
service providers, and enterprises in the network driver’s seat, with features and
capabilities designed to make operators more agile, competitive, and profitable.
19
Open Source Projects and Standards for NFV and SDN
The specific paths to market for SDN and NFV have been molded and guided by
standards bodies and industry consortia. The SDN specification is being developed
by the Open Networking Foundation (ONF) standards organization, while NFV is
being formed and molded by the European Telecommunications Standards Institute
NFV Industry Specification Group (ETSI NFV ISG). Both SDN and NFV specifications
are considered to be frameworks for networking vendors who want their devices
and software to interoperate with other standards-compliant vendors, while indi-
vidual vendors are free to deviate from the specs as needed to differentiate their
products, offer capabilities beyond the specs, or ensure compatibility with legacy
network gear.
The ETSI NFV ISG includes networking software vendors, service providers, network
operators, national technology organizations from numerous countries, academic
and research institutions, and related user groups. The ETSI NFV ISG management
philosophy is based on open standards, and uses a consensus model for devel-
opment and definition decisions related to NFV. In this sense, the ETSI NFV ISG is
more of an industry cooperation model than a traditional standards organization
that might tend to be less transparent about the negotiations and compromises
that form the standard. Many NFV vendors and customers are currently leveraging
widely-used NFV APIs that are not part of the NFV specification, yet are critical to
the success of NFV. In this sense, standards are definitely important, but the goal is
a working NFV network architecture that goes beyond the functions and capabilities
of the “official” NFV spec. The ETSI NFV ISG recently announced a collaboration
with the Metro Ethernet Networking (MEF) standards body to integrate NFV as the
network services architecture for Carrier Ethernet 2.0, a developing standard for
carrier-scale Ethernet.
What has evolved into the SDN specification is actually a combination of work by
industry consortia and standards bodies such as the Open Networking Founda-
tion (ONF). Though the ONF has been instrumental in organizing the effort behind
formation of the SDN specification, parallel work by various industry groups has also
added momentum and vital market input to the network virtualization movement.
Evidence of collaboration of the many industry bodies includes the “An Industry Ini-
tiative for Third Generation Network and Services” whitepaper published in Novem-
ber 2016, authored by MEF, ON.Lab, ONOS, OPEN-O, OpenDaylight, ONF, OPNFV,
and TM Forum. This paper describes a vision for the transformation of network
20
connectivity services and the networks used to deliver them, based on network-as-
a-service (NaaS) principles which make the network appear to the user as the user’s
own virtual network with bump-in-the-wire value-add services. The end goal is a
Third Network that combines the on-demand agility and ubiquity of the Internet with
the performance and security assurances of today’s business grade networks.
SDN and NFV are changing the role of standards organizations and industry groups
in open source projects and specifications. Compared to past standardization
efforts that seem to emphasize the standard itself, SDN and NFV are much more
focused on implementation and operational capabilities and agility, not just the
underlying paper standards. In other words, the specifications for SDN and NFV are
based much more on practical considerations and less on the theoretical applica-
tions that might be part of a standards organization’s definition efforts.
21
center network; this requires comprehensive security, as the data now traverses
outside the corporate LAN. Proprietary, purpose-built hardware appliances sup-
port this new architecture today, but utilizing SDN and NFV is a much more flexible,
cost-effective solution in this use case.
To mitigate these cloud migration challenges, a network built on SDN and NFV can
address each of these concerns in a programmable, flexible, high-performance
corporate network. Using NFV, network functions such as firewalls, virtual routing to
and from the cloud, NAT, antivirus, Distributed Denial-of-Service (DDOS) protection,
and WAN optimization can all be virtualized. Similarly, SDN capabilities can be used
to orchestrate overall network operations and cloud connectivity across the sites.
SDN and NFV can also combine to provide the requisite security capabilities needed
to keep Personally Identifiable Information (PII) and other mission-critical corporate
data safe and secure.
In this use case, Ciena’s Blue Planet provides three critical capabilities to enterprises
migrating to the cloud using SDN and NFV:
1. SDN orchestration of networking across the WAN and to/from the cloud
3. The software and support that tie together this cloud-enabled network with
multiple company data centers and remote locations
With networks built on dedicated hardware, operators must maintain a sizable fleet
of expensive trucks and personnel with deep technical expertise to keep their
networks running smoothly. The overhead for operators using traditional network
22
hardware and architectures is immense. SDN provides a programmable, open inter-
face that can orchestrate software-defined devices, as well as legacy network gear
in most cases. Rather than physically installing new gear, SDN allows for download-
ing and provisioning of network services as needed. This ability to automate and
remotely administer far-flung physical networks reduces the need for hands-on
maintenance of network components, thus reducing the need for truck rolls.
In addition to automation capabilities, SDN and NFV also lower costs through better
end-to-end monitoring and better software tools for visualization and trouble-
shooting. These operational efficiencies allow operators to pursue customers in
market segments that were previously too small or unprofitable to make it worth
their while. Lower operational and management costs benefit the operator’s bottom
line, increasing profit potential and cash flow. As a result of lower costs, operators
that previously concentrated on serving larger businesses might now be able to
compete effectively for revenue from smaller businesses. Prior to the advancement
of SDN and NFV, these lower-tier customers were likely ignored by operators due
to the thin margins in that market segment. Lowering network costs now makes
those lower-margin customers a viable market for operators looking to expand their
customer base.
The case for cost efficiencies due to the use of SDN and NFV provides two distinct
benefits for operators:
23
Use Case 3: Service Providers and Transform Their Businesses
The third use case highlights how large-scale connectivity companies, enterprises,
and service providers can leverage SDN and NFV to transform their business mod-
els by lowering costs and pursuing new customers and market opportunities. One
high-performance connectivity provider has traditionally competed in the enter-
prise and service provider data center interconnect market. This provider installed
an SDN-enabled WAN and secured direct connections to various cloud partners
such as Amazon Web Services, Windows Azure, and Google Cloud. By lowering
costs and streamlining the process for provisioning and managing their WAN cloud
interconnects, this provider can now resell their cloud-direct access to enterprises
that could not otherwise afford or justify a direct connection to a cloud provider. By
offering these enterprises the opportunity to enjoy the performance advantages of
being direct-connected to their cloud(s) of choice, this provider has opened up vast
new markets for its connectivity services.
24
Nothing breeds success like success, so the more companies that successfully
make the transition to SDN and NFV, the more their competition will be motivated to
consider adopting SDN and NFV as well. Thanks to the compelling business case
for SDN and NFV, competition will likely be a strong motivator for the widespread
adoption of SDN and NFV. The pro-adoption argument includes greater agility and
control of the network, opportunities for revenue uplift, streamlining of network
operations, and differentiation of service offerings. SDN and NFV are disruptive
technologies in the network market, as evidenced by the large number of network-
ing startups and networking OEMs rethinking how to transform their product lines to
thrive in a virtualized network world.
That said, some challenges remain for SDN and NFV, including the inevitable
learning curve required to master this new approach to networking. There are also
preliminary discussions about integrating SDN into optical domains instead of only
supporting packet domains, as it currently does. Also, as SDN and NFV mature as
technologies, the end-to-end orchestration of these new technologies—including
integration with legacy networking technologies during the early phases of most
SDN implementations—will continue to be a challenge. Recognizing that orches-
tration is the glue that binds together SDN and NFV in large-scale networks, Ciena
is preparing a follow-up book entitled The Ciena Essentials Guide to Orchestration.
This will give readers an overview of orchestration, from design to implementation
and maintenance, as they continue their SDN and NFV educational journey with
Ciena and Blue Planet.
25
Glossary
Controller
A logically centralized component of software providing network management (and
network control) functionality. For example, a controller establishes the policies
and rules regarding packet forwarding and configures the network infrastructure to
perform the forwarding.
Domain
A networking component with centralized management. A domain can be as small
as a single network function or device or as broad as an entire network.
OpenFlow
A communications protocol for programmatically controlling the forwarding plane
of a network switch or router. OpenFlow assumes a separation of the control plane
from the data plane and directs packet flow through pattern-match/action com-
mands.
Orchestrator
A software component used to provide end-to-end control across a network. An
orchestrator is generally considered to provide higher-level perspective than a con-
troller. For example, it may provide end-to-end service abstraction, where a control-
ler might focus on packet forwarding and control.
Pod
A self-contained unit that includes compute and storage. NFV pod refers to an inde-
pendent x86-based component dedicated to running VNFs.
Python
A widely used, high-level, general-purpose, interpreted, dynamic programming
language that provides constructs intended to facilitate readability and enable clear
programs on both small and large scales.
Resource
Any entity that provides a well-defined set of network functionalities that can be
modeled and controlled through an API. A resource may be an individual device or
network function, or an entire network or network domain.
26
Acronyms
API Application Programming Interface
An API expresses a software component in terms of its inputs, outputs, and opera-
tions for programmatically manipulating and controlling a software component.
BP Blue Planet
Blue Planet is a Ciena software platform purpose-built for network virtualization,
orchestration, and management.
CE Carrier Ethernet
CE represents a standard set of Ethernet services that have come into being over
the past 10+ years. The standard covers point-to-point and multipoint Ethernet
connectivity services. Today, the global CE market exceeds $50 billion.
27
CORD Central Office Re-architected as a Data Center
CORD represents a different way of building central offices that leverages open
source and white box technologies in favor of specialized and vendor proprietary
devices. CORD combines these open building blocks with SDN and NFV to bring
economies with the scale and agility of the cloud to service providers. CORD began
as a proof of concept sponsored by ON.Lab and AT&T. Now, companies like Ciena
are helping to bring CORD into production.
DC Data Center
A DC is a facility used to house computer systems and associated components. It
includes servers, storage, networking, power, air conditioning, and security.
28
IP Internet Protocol
IP is the principal communications protocol in the Internet protocol suite for carrying
datagrams across a network.
NE Network Element
NEs are individual networking devices being managed.
29
ONF Open Networking Foundation
ONF is an organization aimed at improving networking through SDN, the OpenFlow
protocol, and related technologies.
30
PNF Physical Network Function
A PNF is a physical appliance or hardware device that provides network functions.
PS Professional Services
PS are consulting services provided by a vendor to customize or fine-tune an appli-
cation or installation to suit a particular customer’s needs.
RA Resource Adapter
An RA adapts between the internal data model and an external system or resource.
31
its message format and relies on application layer protocols, most notably Hyper-
text Transfer Protocol (HTTP) or Simple Mail Transfer Protocol (SMTP) for message
negotiation and transmission.
32
33
Abel Tong
Senior Director, Solutions Marketing,
Blue Planet
Abel Tong is Senior Director of Solutions Marketing for Ciena’s Blue Planet
software solutions. He is responsible for helping to transform networks through
the application of Software Defined Networking (SDN) and Network Function
Virtualization (NFV), to deliver value and create new services, and to simplify
network operations for Ciena’s customers.
Abel is also a long-time contributor to the MEF. Abel leads MEF’s Project UNITE,
an industry wide collaborative initiative bringing standards development
organizations together to create the building blocks for Lifecycle Service
Orchestration and Third Network. Abel is also a member of Open Cloud Connect
(OCC), Open Daylight and the Open Networking Foundation (ONF).
34
Kevin Wade
Product Marketing Team Leader,
Ciena Blue Planet
Kevin Wade is Senior Director of Product Marketing for Ciena’s Blue Planet
software portfolio. In this role, Kevin is responsible for leading the Blue Planet
product marketing team, as well as for driving the creation of programs to drive
market awareness and market share for Ciena’s industry-leading SDN/NFV
orchestration, analytics and management software solutions.
Kevin has more than 20 years of experience in the networking industry with
successful start-ups and public companies, targeting both the service provider
and enterprise markets. Kevin joined Ciena through the Cyan acquisition, where
he was responsible for the company’s product marketing and field marketing
activities.
Before joining Cyan in 2012, Kevin was Sr. Director of Product Marketing with
Force10 Networks (now Dell Force10) and also held product marketing positions
with Ascend (now part of Nokia) and Cabletron (now Extreme Networks).
35
“According to our global service provider surveys, essentially
every network operator is now planning to invest in SDN and
NFV for three main reasons: (1) operators seek greater service
agility, along with accelerated time-to-revenue; (2) they want a
clear, unobstructed view of their global services across multiple
network domains; and (3) they also need to automate as much
as possible. This book provides an excellent foundation for
anyone who needs to get up to speed quickly on SDN and NFV.”
Michael Howard, Senior Research Director and Advisor,
Carrier Networks for IHS Markit (Infonetics)
Ciena may make changes at any time to the products or specifications contained herein without notice. Ciena and the
Ciena Logo are trademarks or registered trademarks of Ciena Corporation in the U.S. and other countries. Third-party
trademarks are the property of their respective owners and do not imply a partnership between Ciena and any other
company. Copyright © 2017 Ciena® Corporation. All rights reserved.