Network Function Virtualization (NFV) Overview
14-848:
NETWORK FUNCTION VIRTUALIZATION
LECTURE 6 * FALL 2019 * GREGORY KESDEN
KEY READING
•
The paper below is key reading for the Network Function Virtualization (NFV) portion of
today’s lecture:
•
“Network Functions Virtualization: An Introduction, Benefits, Enablers, Challenges & Call for
Action”,
SDN and OpenFlow World Congress
, ETSI, Darmstadt-Germany, October 22-24,
2012.
CONSIDER THE DEVICES THAT CAN COMPOSE A
“NETWORK”
•
Message router
•
CDN Router
•
Deep Packet Inspection (DPI)
•
Firewall
•
NAT
•
QoE Monitor
•
All sorts of specialized systems for a particular domain, e.g. Telephony or Mobile
SPECIALIZATION OF DEVICES IS A TYPE OF
PARTITIONING
•
Partitioning by type reduces utilization
•
Reduced utilization means: More devices, More energy, More people, More cost
•
Resources may be scarce, limiting scale: Energy, Money, Talent
•
Innovation forces constant re-evaluation and upgrades across multiple device types
•
Changes to fabric may be necessary to scale with growth or competitively for cost
•
But “Keeping up” distracts from innovation
BENEFITS OF ONE-DEVICE-DOES-ANYTHING
•
Higher utilization
•
Less equipment, Lower capital investment
•
Less equipment to run, Lower power bills, Fewer people to run it
•
All equipment same type
•
Greater economy of scale
•
Fewer “spares” needed
•
Less partitioning of talent, more efficient use of people, more impact from fewer people at a lower cost
•
More flexibility in fabric
•
Greater elasticity across broader set of uses
•
Greater efficiency in deployment and operation means improved product development cycle
NETWORK FUNCTION VIRTUALIZATION (NFV):
GOALS
•
Standardize hardware:
•
Have one type of “standard” network switch
•
Have one type of “standard” storage solution
•
Have one type of “standard” server solution
•
“Virtual appliances” (software) gets pushed into servers
•
These servers operate switches
•
These servers aren’t “old school” one-offs
•
These servers are virtualized and part of a “cloud”
RELATIONSHIP:
SDN VS NFV
•
Network Function Virtualization (NFV)
•
Provides a mechanism to use generic hardware to act as specialized hardware by moving the
specialization into servers, e.g. in the cloud
•
Doesn’t provide a way of mapping from requirements to solutions.
•
Software Defined Networks (SDNs)
•
Provides a mechanism to abstract away the complexity of managing a network by providing
useful abstractions for describing what is needed and a system for translating that into the
necessary configuration and deploying it to the network gear
•
Agnostic as to whether that network gear is specialized to do its job in hardware of by NFV.
SDN WITH NFV
•
Data center of clay that can rapidly be molded and remolded to meet changing needs
•
NFV lets the hardware do “anything”
•
SDN enables it possible to ask for what one wants in a way that can be delivered with
automation
CHALLENGES
•
Requires “standard” switch with “standard” interface
•
Something that serves the same purpose for NFV as OpenFlow does for SDN
•
How to define the interface, without constraining competition and innovation of the underlying
hardware?
•
How can “generic” virtual appliance “programs” take advantage of novel hardware innovations?
•
How to manage “virtual appliances”
•
Which switched get which versions and when? Upgrades? New Versions? Etc?
•
Automation is critical, so is abstraction.
•
SDNs can help here
CHALLENGES,
CONT
•
Security
•
How to trust the bits, initially?
•
How to trust the bits, over time?
•
How to trust the configuration?
•
All of the infrastructure needs to be secure
•
Stability, Resilience, and Availability
•
In theory, these should improve due to increased redundancy and interchangeability
•
But, in reality, vendor interoperability, heterogeneous versions, migrations, reinstantiations, etc.
•
In an interoperable world, what happens when “things don’t work”?
RECENT CATALYSTS
•
Improved virtualization
•
Virtual machines, virtual networks, and the management thereof
•
Movement of network switches from specialized fabric to high-performance shared-memory switches,
i.e. computers
•
Improved technology for managing virtualized environments, e.g. providing for elasticity, migration,
security, etc
•
Acceptance of OpenFlow and other open APIs in a space that was previously purely proprietary
•
Disruption of traditional telco markets by IP-based technologies, e.g. Skype, breaking markets free of
slow-moving committee and hardware design processes; specialized hardware (like ASICs); etc, in favor of
faster innovation and more agile technologies.
•
Huge economies of scale for commodity equipment
•
“Killer app” in 4G and 5G infrastructure which is exploding.
NETWORK WRAP-UP
•
5-layer stack, role of each layer
•
End-To-End Argument
•
Data center topology
•
Traffic Patterns
•
Virtual LANs
•
Transport Layer concerns: Paths and buffering
•
SDNs and NFV
5-LAYER MODEL
•
Application – Application-Specific protocols
•
Transport – Sessions/Connections, Ports, Sockets, Communication model
•
Network – Connectivity among networks, global scale hierarchical addresses, packet
switching
•
Link – Management of physical layer, ability to send messages station-to-station
•
Physical – Connectivity and signaling
END-TO-END ARGUMENT
•
Generally: Do things at the highest level possible.
•
May not need to do them at all
•
Covers a greater scope of the communication, e.g. consider encryption for privacy
•
Especially if not needed at multiple levels
•
Exceptions: Correctness, Concerns unique to lower layers
•
Error-detection, so we don’t pass up bad packets
•
But not error correction, as might not be needed, and errors can be introduced higher up
•
Unique to lower layer
•
Higher layers don’t necessarily know how to do good error correction for some challenging environments,
e.g. satellites or infrared, etc.
DATA CENTER TOPOLOGY
•
Venerable 3-Tier
•
Can be dual homed
•
Single paths, less bandwidth higher up (where often needed the most)
•
Fat-Trees
•
Stick with k-port switch
•
Ensures multiple paths
•
Still needs a plan to use them, e.g. MPTCP or PORTland, etc.
•
Clos Networks
•
Like cross-bars of cross-bars.
•
Expensive.
•
Leaf-and-Spline
•
Good, if there is enough port density
LATENCY VS DATA RATE
•
Latency is delay, not slowness
•
A function of signal propagation rate, e.g. close to speed of light
•
RTT is often key metric
•
Important at continental and global scales
•
A natural problem as speed of light is limit
•
Recall bit-distance, “bandwidth-delay product”, etc
•
Bandwidth is width of pipe, data per unit time
•
A function of parallelism
•
Exploiting parallelism is a management problem
•
Generally speaking:
•
Latency is a concern for long-haul
•
Bandwidth is the concern in data centers
TRAFFIC PATTERNS
•
Ingress – Coming in
•
Incast – Concentrated upward, such as by replies to queries within time budget.
•
East-West – host-to-host
•
Tail latency – In presence of parallelism, if all or many results needed, slow replies can
hold up the rest. The greater the parallelism, the greater the window to capture a really
slow reply.
VIRTUAL LANS
•
Build one switched network
•
Configure it to support multiple LANs
•
Assign certain LANs to certain ports
•
When messages need to cross switches via a “trunk” line, tag them
•
Tag on send to identify VLAN
•
Recipient switch removes tag, IDs port(s) on same VLAN, and sends message
•
Important for every day management and security to elasticity and multi-tenancy in the
cloud.
TRANSPORT LAYER CONCERNS
•
Given multiple paths, how do we make use of them?
•
Buffering:
•
How does it improve utilization and thereby bandwidth?
•
How does it increase latency?
•
Recall DCTCP’s goal: Large buffers, but low occupancy
•
Can handle bursts, but generally manages to keep them under control
•
Recall DCTCP’s solution:
•
TCP ECN with probabilistic marking
•
Pro-active before trouble builds buffers, not reactive after
•
Slows down traffic before buffers grow large and latency builds
SOFTWARE DEFINED NETWORKS (SDN
S
)
•
Solve complexity of managing networks through abstraction
•
Present an natural, abstract, perhaps domain-specific, model of the network
•
Requirements are expressed in the natural model and translated to configuration
•
Automation then manages the deployment and maintenance of this configuration
•
Enables management of networks for clouds, etc.
NETWORK FUNCTION VIRTUALIZATION (NFV)
•
Replaces specialized network gear with standard but configurable network gear
•
Gear is configured as needed for specialized role, accepts a “virtual appliance”
•
Makes fabric flexible, agile, robust, and enables economies of scale and labor.
•
Poses security risk, risk to innovation, etc.
Network Function Virtualization (NFV) focuses on virtualizing network functions to improve efficiency and reduce costs in network infrastructure. The lecture discusses key readings, devices that compose a network, specialization of devices, benefits of one-device-does-anything approach, and the goals of NFV standardization. By standardizing hardware and pushing virtual appliances into servers, NFV aims to streamline network operations and enhance scalability.
Download Presentation
Please find below an Image/Link to download the presentation.
The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
E N D
Presentation Transcript
14-848: NETWORK FUNCTION VIRTUALIZATION LECTURE 6 * FALL 2019 * GREGORY KESDEN
KEY READING The paper below is key reading for the Network Function Virtualization (NFV) portion of today s lecture: Network Functions Virtualization: An Introduction, Benefits, Enablers, Challenges & Call for Action , SDN and OpenFlow World Congress, ETSI, Darmstadt-Germany, October 22-24, 2012.
CONSIDER THE DEVICES THAT CAN COMPOSE A NETWORK Message router CDN Router Deep Packet Inspection (DPI) Firewall NAT QoE Monitor All sorts of specialized systems for a particular domain, e.g. Telephony or Mobile
SPECIALIZATION OF DEVICES IS A TYPE OF PARTITIONING Partitioning by type reduces utilization Reduced utilization means: More devices, More energy, More people, More cost Resources may be scarce, limiting scale: Energy, Money, Talent Innovation forces constant re-evaluation and upgrades across multiple device types Changes to fabric may be necessary to scale with growth or competitively for cost But Keeping up distracts from innovation
BENEFITS OF ONE-DEVICE-DOES-ANYTHING Higher utilization Less equipment, Lower capital investment Less equipment to run, Lower power bills, Fewer people to run it All equipment same type Greater economy of scale Fewer spares needed Less partitioning of talent, more efficient use of people, more impact from fewer people at a lower cost More flexibility in fabric Greater elasticity across broader set of uses Greater efficiency in deployment and operation means improved product development cycle
NETWORK FUNCTION VIRTUALIZATION (NFV): GOALS Standardize hardware: Have one type of standard network switch Have one type of standard storage solution Have one type of standard server solution Virtual appliances (software) gets pushed into servers These servers operate switches These servers aren t old school one-offs These servers are virtualized and part of a cloud
RELATIONSHIP: SDNVS NFV Network Function Virtualization (NFV) Provides a mechanism to use generic hardware to act as specialized hardware by moving the specialization into servers, e.g. in the cloud Doesn t provide a way of mapping from requirements to solutions. Software Defined Networks (SDNs) Provides a mechanism to abstract away the complexity of managing a network by providing useful abstractions for describing what is needed and a system for translating that into the necessary configuration and deploying it to the network gear Agnostic as to whether that network gear is specialized to do its job in hardware of by NFV.
SDN WITH NFV Data center of clay that can rapidly be molded and remolded to meet changing needs NFV lets the hardware do anything SDN enables it possible to ask for what one wants in a way that can be delivered with automation
CHALLENGES Requires standard switch with standard interface Something that serves the same purpose for NFV as OpenFlow does for SDN How to define the interface, without constraining competition and innovation of the underlying hardware? How can generic virtual appliance programs take advantage of novel hardware innovations? How to manage virtual appliances Which switched get which versions and when? Upgrades? New Versions? Etc? Automation is critical, so is abstraction. SDNs can help here
CHALLENGES,CONT Security How to trust the bits, initially? How to trust the bits, over time? How to trust the configuration? All of the infrastructure needs to be secure Stability, Resilience, and Availability In theory, these should improve due to increased redundancy and interchangeability But, in reality, vendor interoperability, heterogeneous versions, migrations, reinstantiations, etc. In an interoperable world, what happens when things don t work ?
RECENT CATALYSTS Improved virtualization Virtual machines, virtual networks, and the management thereof Movement of network switches from specialized fabric to high-performance shared-memory switches, i.e. computers Improved technology for managing virtualized environments, e.g. providing for elasticity, migration, security, etc Acceptance of OpenFlow and other open APIs in a space that was previously purely proprietary Disruption of traditional telco markets by IP-based technologies, e.g. Skype, breaking markets free of slow-moving committee and hardware design processes; specialized hardware (like ASICs); etc, in favor of faster innovation and more agile technologies. Huge economies of scale for commodity equipment Killer app in 4G and 5G infrastructure which is exploding.
NETWORK WRAP-UP 5-layer stack, role of each layer End-To-End Argument Data center topology Traffic Patterns Virtual LANs Transport Layer concerns: Paths and buffering SDNs and NFV
5-LAYER MODEL Application Application-Specific protocols Transport Sessions/Connections, Ports, Sockets, Communication model Network Connectivity among networks, global scale hierarchical addresses, packet switching Link Management of physical layer, ability to send messages station-to-station Physical Connectivity and signaling
END-TO-END ARGUMENT Generally: Do things at the highest level possible. May not need to do them at all Covers a greater scope of the communication, e.g. consider encryption for privacy Especially if not needed at multiple levels Exceptions: Correctness, Concerns unique to lower layers Error-detection, so we don t pass up bad packets But not error correction, as might not be needed, and errors can be introduced higher up Unique to lower layer Higher layers don t necessarily know how to do good error correction for some challenging environments, e.g. satellites or infrared, etc.
DATA CENTER TOPOLOGY Venerable 3-Tier Can be dual homed Single paths, less bandwidth higher up (where often needed the most) Fat-Trees Stick with k-port switch Ensures multiple paths Still needs a plan to use them, e.g. MPTCP or PORTland, etc. Clos Networks Like cross-bars of cross-bars. Expensive. Leaf-and-Spline Good, if there is enough port density
LATENCY VS DATA RATE Latency is delay, not slowness A function of signal propagation rate, e.g. close to speed of light RTT is often key metric Important at continental and global scales A natural problem as speed of light is limit Recall bit-distance, bandwidth-delay product , etc Bandwidth is width of pipe, data per unit time A function of parallelism Exploiting parallelism is a management problem Generally speaking: Latency is a concern for long-haul Bandwidth is the concern in data centers
TRAFFIC PATTERNS Ingress Coming in Incast Concentrated upward, such as by replies to queries within time budget. East-West host-to-host Tail latency In presence of parallelism, if all or many results needed, slow replies can hold up the rest. The greater the parallelism, the greater the window to capture a really slow reply.
VIRTUAL LANS Build one switched network Configure it to support multiple LANs Assign certain LANs to certain ports When messages need to cross switches via a trunk line, tag them Tag on send to identify VLAN Recipient switch removes tag, IDs port(s) on same VLAN, and sends message Important for every day management and security to elasticity and multi-tenancy in the cloud.
TRANSPORT LAYER CONCERNS Given multiple paths, how do we make use of them? Buffering: How does it improve utilization and thereby bandwidth? How does it increase latency? Recall DCTCP s goal: Large buffers, but low occupancy Can handle bursts, but generally manages to keep them under control Recall DCTCP s solution: TCP ECN with probabilistic marking Pro-active before trouble builds buffers, not reactive after Slows down traffic before buffers grow large and latency builds
SOFTWARE DEFINED NETWORKS (SDNS) Solve complexity of managing networks through abstraction Present an natural, abstract, perhaps domain-specific, model of the network Requirements are expressed in the natural model and translated to configuration Automation then manages the deployment and maintenance of this configuration Enables management of networks for clouds, etc.
NETWORK FUNCTION VIRTUALIZATION (NFV) Replaces specialized network gear with standard but configurable network gear Gear is configured as needed for specialized role, accepts a virtual appliance Makes fabric flexible, agile, robust, and enables economies of scale and labor. Poses security risk, risk to innovation, etc.
