Preface
About three years ago, we attempted to capture the state of the art in one of the most game changing technological shifts in the networking industry since Multiprotocol Label Switching (MPLS) came onto the scene. This meant the capture, corraling, and definition for the reader of the fabled unicorn of Software Designed Networks (SDN). We continue to lobby hard for the glitter-horned unicorn because we did see it then and now as necessary technology.
This time the unicorn is called Network Function Virtualization (NFV). Unsurprisingly, many of the issues, questions, concerns and confusion around its definition and efficacy paint the same background as when we wrote on SDN. Again, have set out with the goal to clearly define first what NFV is, and then to give the reader a clear and concise survey of the technical playing field.
NFV and Service Function Chaining (SFC) concepts have advanced and progressed as a technology driven by network operators and vendors that wish to build and deploy it—with an emphasis on using components derived using open source techniques. The starting point of their ideas is the ETSI NFV framework, which we will delve into in detail. It was one of the first documented efforts by network operators and potential NFV users to specify what this new unicorn looks like. A thumbnail sketch of the cat wearing the unicorn was produced. It is not quite the unicorn we were looking for, as we will see after our in-depth investigation is complete, but we are iterating on the picture as an industry—and continue to do so. As with SDN before it, we will refine the details of the picture to the point where this thing will work—and be a true unicorn we can get on and ride.
With that image in your mind—and hopefully a chuckle—we want to point out that there is real evidence that NFV has finally emerged. We are seeing real deployments of this technology. We hope you see that in this book.
At the time of writing this book, Thomas D. Nadeau was a Distinguished Engineer and Chief Architect of Open Source at Brocade, and Ken Gray was a Senior Director at Cisco Systems. We both also have extensive experience that spans roles both with other vendors and service providers, such as BT and Bell Atlantic (now Verizon).
It is important to note that this is a vendor-independent book. We are not commissioned by our present employers to write this book or espouse their viewpoints. The opinions expressed here are our own, and only our own. In some cases, we have relied on references or examples that came from our experiences with our most recent employers in the text. In no case do we intend to promote our specific company’s wares or approaches.
This work is targeted to benefit the networking industry and not necessarily our employers, although in both of our cases we are working on these technologies as part of our day jobs.
We hope the reader finds any bias to be accidental and not distracting or overwhelming. If this can be corrected or enhanced in a subsequent revision, we will do so. We both agree that there are likely to be many updates to this text going forward given how young the technology we describe herein, and how frighteningly rapidly it continues to evolve.
We have tried our best to be inclusive of everyone that is relevant in the NFV and SFC space without being encyclopedic on the topic, and still providing enough breadth of material to cover the space.
This book was another effort on our part to define what NFV and SFC are based on our real world experiences and dialogues with customers and colleagues as well as our observation of the networking industry as a whole.
Finally, we both happily work for employers who encourage us to develop and express our own opinions. We hope the reader finds the depth and breadth of information presented herein to be interesting and informative, while at the same time evocative. We give our opinions about topics, but try to present material that describes the pros and cons of a topic in what we think is as unbiased a manner as possible. We readily acknowledge there may be divergent viewpoints—our hope is that you will be aided in forming your own opinions by exposure to our viewpoint.
We do hope you find unicorns, fairy dust, and especially lots of interesting insight and information in this book!
Assumptions
NFV is a new approach to the current world of networking, but it is still networking. As you get into this book, we are assuming a certain level of networking knowledge. You do not have to be an engineer, but knowing how networking principles work—and frankly, do not work—will aid your comprehension of the text.
This topic has its own terminology, which you will discover in the book, but the following terms should be familiar before you read the book:
The Open Systems Interconnection (OSI) model defines seven different layers of technology: physical, data link, network, transport, session, presentation, and application. This model allows network engineers and network vendors to easily discuss and apply technology to a specific OSI level. This segmentation lets engineers divide the overall problem of getting one application to talk to another into discrete parts and more manageable sections. Each level has certain attributes that describe it and each level interacts with its neighboring levels in a very well-defined manner. Knowledge of the layers above layer 7 is not mandatory, but understanding that interoperability is not always about electrons and photons will help.
These devices operate at layer 2 of the OSI model and use logical local addressing to move frames across a network. Devices in this category include Ethernet in all its variations, VLANs, aggregates, and redundant forms.
These devices operate at layer 3 of the OSI model and connect IP subnets to each other. Routers move packets across a network in a hop-by-hop fashion.
These broadcast domains connect multiple hosts together on a common infrastructure. Hosts communicate with each other using layer 2 media access control (MAC) addresses.
Hosts using IP to communicate with each other use 32-bit addresses. Humans often use a dotted decimal format to represent this address. This address notation includes a network portion and a host portion, which is normally displayed, for example, as 192.168.1.1/24.
These layer 4 protocols define methods for communicating between hosts. The Transmission Control Protocol (TCP) provides for connection-oriented communications, whereas the User Datagram Protocol (UDP) uses a connectionless paradigm. Other benefits of using TCP include flow control, windowing/buffering, and explicit acknowledgments.
Network engineers use this protocol to troubleshoot and operate a network, as it is the core protocol used (on some platforms) by the ping and traceroute programs. In addition, the Internet Control Message Protocol (ICMP) is used to signal error and other messages between hosts in an IP-based network.
A facility used to house computer systems and associated components, such as telecommunications and storage systems. It generally includes redundant or backup power supplies, redundant data communications connections, environmental controls (eg, air conditioning, fire suppression), and security devices. Large data centers are industrial scale operations using as much electricity as a small town.
MPLS is a mechanism in high-performance networks that directs data from one network node to the next based on short path labels rather than long network addresses, avoiding complex lookups in a routing table. The labels identify virtual links (paths) between distant nodes rather than endpoints. MPLS can encapsulate packets of various network protocols. MPLS supports a range of access technologies.
An interface that conceptualizes the lower-level details (eg, data or functions) used by, or in, the component. It is used to interface with higher-level layers using the southbound interface of the higher-level component(s). In any architectural overview, the northbound interface is normally drawn at the top of the component it is defined in, hence the name northbound interface. Examples of a northbound interface are JSON or Thrift.
An interface that conceptualizes the opposite of a northbound interface. The southbound interface is normally drawn at the bottom of an architectural diagram. Examples of southbound interfaces include I2RS, NETCONF, or a command-line interface.
SDN encompasses a number of key concepts including a logically centralized data plane that is externalized from a data plane. The control plane may or may not exists as part of an externalized SDN Controller. Rapid and application-friendly Application Programming Interfaces (APIs) also are often part of the equation as they play a critical role in extending and interacting with the externalized control planes, as well as traditional ones.
The arrangement of the various elements (links, nodes, interfaces, hosts, etc.) of a computer network. Essentially, it is the topological structure of a network, and may be depicted physically or logically. Physical topology refers to the placement of the network’s various components, including device location and cable installation, while logical topology shows how data flows within a network, regardless of its physical design. Distances between nodes, physical interconnections, transmission rates, and/or signal types may differ between two networks, yet their topologies may be identical.
A specification of how some software components should interact with each other. In practice, an API is usually a library that includes specification for variables, routines, object classes, and data structures. An API specification can take many forms, including an international standard (eg, POSIX), vendor documentation (eg, the JunOS SDK), or the libraries of a programming language.
What Is in This Book?
This text introduces and frames the conversation this book engages in around the concepts of NFV, where they came from, and why they are important to discuss.
Chapter 1, Network Function Virtualization
In this chapter, we define what NFV is in our view. We also take the time to discuss what its key components are and more importantly, are not.
Chapter 2, Service Creation and Service Function Chaining
Here we define what goes into defining a service today and the need for change that is inspiring NFV. We discuss the components that are needed to define the salient components of a service, as well as discuss the pitfalls of some definitions. We discuss the concepts of service paths, and how services can be defined as composites of other subservices, as well as how these components can be chained together.
Chapter 3, ETSI NFV ISG
In this chapter, we consider the contribution of the ETSI NFV ISG group’s work (with focus on the charter period ending in December 2014—which we will refer to as Phase 1—and an update on its later phase) as it pertains to NFV and the potential future of the ISG. The main focus of this work is around decoupling service software from network hardware, creating flexible deployments and dynamic operations—the stated benefits of NFV in their architecture framework.
Chapter 4, IETF Related Standards: NETMOD, NETCONF, SFC and SPRING
This chapter introduces the notion of other relevant and useful standards efforts going on in the industry. In particular, we focus here on the Internet Engineering Task Force’s (IETF’s) efforts in this space, both failed and current. Here we define and describe what the NETMOD, NETCONF, SFC, and SPRING working groups are up to and why it matters to NFV and SFC technology.
Chapter 5, The NFV Infrastructure Management
In this and the succeeding chapters we will look a little bit more closely at the major building blocks of the ETSI-prescribed NFV architecture. Here we revisit the high-level architecture framework we described in Chapter 3. We begin with a discussion of the NFV-I functional area as it relates to management and control of the virtualized compute, storage and network components that together realize all virtualized functions on a given hardware platform—the VIM. We do this within the context of various open source projects such as OpenStack, and OpenDaylight. We introduce the concept of PaaS versus IaaS approaches to NFV and begin to ask questions about the ETSI architecture.
Chapter 6, MANO: Management, Orchestration, OSS, and Service Assurance
In this chapter, we discuss the orchestration of services and introduce elements that are now becoming more common in both current ETSI and open source solution dialogs. We also explore the practicality of moving to NFV en masse across an existing network, which will introduce a number of its own challenges.
Chapter 7, The Virtualization Layer—Performance, Packaging, and NFV
In this chapter, we will look at the evolution of virtualization techniques and software network I/O acceleration to satisfy these application requirements. We will also look at how the constant evolution in the compute component of the (ETSI-labeled) “NFVI” might affect the current aggregated, VM-centric NFV model, our concept of SFC and the potential economic assumptions behind the NFV proposition.
Chapter 8, NFV Infrastructure—Hardware Evolution and Testing
In this chapter, we will look in detail at the architectural evolution in the Intel Architecture (IA) for NFV including the increased dependence on cache efficiency for performance of NFV on CPU cores. We also look at the strategy of hardware augmentation that is opening the market for complimentary hardware acceleration through PCIE expansion. As with the software evolution in the preceding chapter, this leads to questions about our current architecture.
Chapter 9, An NFV Future
Here we wrap things up with conclusions and opinions on the topics discussed. We consolidate the big questions around NFV from the earlier chapters and offer our opinions on a path forward.
Conventions Used in This Book
The following typographical conventions are used in this book:
Indicates new terms, URLs, email addresses, filenames, file extensions, pathnames, directories, and Unix utilities.
Indicates commands, options, switches, variables, attributes, keys, functions, types, classes, namespaces, methods, modules, properties, parameters, values, objects, events, event handlers, XML tags, HTML tags, macros, the contents of files, and the output from commands.
Shows commands and other text that should be typed literally by the user, as well as important lines of code.
Shows text that should be replaced with user-supplied values.
Using Code Examples
This book is here to help you get your job done. In general, you may use the code in this book in your own configuration and documentation. You do not need to contact us for permission unless you are reproducing a significant portion of the material. For example, deploying a network based on actual configurations from this book does not require permission. Selling or distributing a CD-ROM of examples from this book does require permission. Answering a question by citing this book and quoting example code does not require permission. Incorporating a significant amount of sample configurations or operational output from this book into your product’s documentation does require permission.
We appreciate, but do not require, attribution. An attribution usually includes the title, author, publisher, and ISBN, for example: “Network Function Virtualization” by Ken E. Gray and Thomas D. Nadeau, Copyright 2016 Ken E. Gray and Thomas D. Nadeau, 978-0-12-802119-4.
If you feel your use of code examples falls outside fair use or the permission given here, feel free to contact us at permissions@elsevier.com.
Comments and Questions
For more information about our books, courses, conferences, and news, see our website at www.store.elsevier.com
We have a web page for this book. You can access this page at:
http://networkprogrammability.net
Follow us on Twitter: