Dynamic Service Chaining with the Intel® Open Network Platform and Wind River Craig Griffin – Solutions Architect, Wind River Systems Brian Skerry – Software Architect, Intel Corporation DATS011 Agenda • Network Builders ecosystem: vAppliances • Service chaining overview & challenges • Solutions for service chaining • Wind River Demonstration Highlights • Lessons learned • Summary & Call to Action 2 Agenda • Network Builders ecosystem: vAppliances • Service chaining overview & challenges • Solutions for service chaining • Wind River Demonstration Highlights • Lessons learned • Summary & Call to Action 3 Yesterday’s Network Networking Pain Points Manual Provisioning Service Agility Efficiency 4 Next Generation Network Delivering high-performance, open standard SDN and NFV solutions for next generation networks Intel® Open Network Platform Server (Reference Architecture for NFV and SDN) Orchestrator Controller (OpenStack*) OEM App Network Builders (OpenDaylight) SP App ISV App OpenStack and OpenDaylight Optimizations Intel DPDK Accelerated vSwitch Intel® QuickAssist Technology Drivers Intel® Ethernet Switch 10 and 40 Gigabit Drivers Intel® Service Assurance Administrator (SAA) Fedora* 20, KVM Intel® Xeon® Processor E5-2600 v3 Product Family Intel ONP Server HW Ingredients Intel QuickAssist Adapter 8950 Intel ONP Server SW Ingredients Intel® Ethernet Controller XL710 Optimized and Validated Software Cloud SPs SW Commercial SDN/NFV Solutions Co-Marketing Programs Telco HW Reference Architecture TEM / OEM / OSV/ ISV 3rd Party Reference Architecture on www.01.org 5 Trials and Deployments Intel® Data Plane Development Kit (Intel® DPDK); Intel® Open Network Platform (Intel® ONP) Enterprise Key Software Defined Infrastructure Components EMS EMS EMS OSS/BSS VNF Manager OpenStack Enhancements vRouter vBNG vIPS Intel® Data Plane Development Kit (Intel® DPDK) Accelerated vSwitch Wind River Linux*/KVM NIC 6 OCPNode Node OCP Intel® ONP Server Plugin Service Orchestrator OVS DB Open Other Flow VM1 FW VM2 Intel DPDK Accelerated vSwitch Wind River Linux/KVM NIC OCPNode Node OCP Intel® ONP Server Key Software Defined Infrastructure Components EMS EMS EMS OSS/BSS • OpenStack Enhancements vRouter vBNG vIPS Intel® Data Plane Development Kit (Intel® DPDK) Accelerated vSwitch Wind River Linux*/KVM NIC 7 OCPNode Node OCP Service Function Chaining VNF Manager Intel® ONP Server Plugin Service Orchestrator OVS DB • Open Other Flow VM1 FW Ordered Graph for Network Traffic Optional Sharing of Service Information VM2 Intel DPDK Accelerated vSwitch Wind River Linux/KVM NIC OCPNode Node OCP Intel® ONP Server Agenda • Network Builders ecosystem: vAppliances • Service chaining overview & challenges • Solutions for service chaining • Wind River Demonstration Highlights • Lessons learned • Summary & Call to Action 8 Dynamic Service Chaining Challenges • Replacing dedicated physical appliances with virtual appliances introduces many technical challenges • Challenge 1: Packet Flow - Making packets go where they don’t want to • Challenge 2: L2/L3 Processing - Some appliances change headers • Challenge 3: L4-L7 Processing - Some appliances terminate flows, start new ones • Many other challenges exist! 9 Service Chaining Challenge 1: Packet Flow Platform X 10 Platform Y Service D Application Application Application Service A • Packets may need to traverse some links multiple times • Need to be able to distinguish between “before” and “after” a service Service C Application Service B Application • We need a solution that determines what the logical packet flow should be • Virtual Appliances are not in a fixed physical location Platform Z Service Chaining Challenge 1: Packet Flow Platform X 11 Platform Y Service D Application Application Application Service A • Packets may need to traverse some links multiple times • Need to be able to distinguish between “before” and “after” a service Service C Application Service B Application • We need a solution that determines what the logical packet flow should be • Virtual Appliances are not in a fixed physical location Platform Z Service Chaining Challenge 1: Packet Flow Platform X 12 Platform Y Service D Application Application Application Service A • Packets may need to traverse some links multiple times • Need to be able to distinguish between “before” and “after” a service Service C Application Service B Application • We need a solution that determines what the logical packet flow should be • Virtual Appliances are not in a fixed physical location Platform Z Service Chaining Challenge 1: Packet Flow Platform X 13 Platform Y Service D Application Application Application Service A • Packets may need to traverse some links multiple times • Need to be able to distinguish between “before” and “after” a service Service C Application Service B Application • We need a solution that determines what the logical packet flow should be • Virtual Appliances are not in a fixed physical location Platform Z Service Chaining Challenge 1: Packet Flow Platform X 14 Platform Y Service D Application Application Application Service A • Packets may need to traverse some links multiple times • Need to be able to distinguish between “before” and “after” a service Service C Application Service B Application • We need a solution that determines what the logical packet flow should be • Virtual Appliances are not in a fixed physical location Platform Z Service Chaining Challenge 1: Packet Flow Platform X 15 Platform Y Service D Application Application Application Service A • Packets may need to traverse some links multiple times • Need to be able to distinguish between “before” and “after” a service Service C Application Service B Application • We need a solution that determines what the logical packet flow should be • Virtual Appliances are not in a fixed physical location Platform Z Service Chaining Challenge 1: Packet Flow Platform X 16 Platform Y Service D Application Application Application Service A • Packets may need to traverse some links multiple times • Need to be able to distinguish between “before” and “after” a service Service C Application Service B Application • We need a solution that determines what the logical packet flow should be • Virtual Appliances are not in a fixed physical location Platform Z Service Chaining Challenge 1: Packet Flow Platform X 17 Platform Y Service D Application Application Application Service A • Packets may need to traverse some links multiple times • Need to be able to distinguish between “before” and “after” a service Service C Application Service B Application • We need a solution that determines what the logical packet flow should be • Virtual Appliances are not in a fixed physical location Platform Z Service Chaining Challenge 2: L2/L3 Processing Platform X QinQ 18 NAT Application • Control mechanisms often built upon a flow, identified via the header • For Enterprise, Network Address Translation would modify IP Application Application vBNG Application • Modifying an L2/L3 header means that the header no longer consistent in the chain • For NFV, a vBNG would modify ethertype Platform Y MPLS IP A IP B Service Chaining Challenge 3: L4 – L7 Processing Platform X Flow 1 19 v WAN Opt Application • Current proposals do not adequately address these use cases • Control mechanisms would see new flows unexpectedly Application Application vADC Application • Some services (e.g., ADC, WAN Optimizers) do processing and modifications at L4 through L7 • These can terminate flows and initiate new ones Platform Y Flow 2 Flow 3 Flow 4 Other Service Chaining Challenges and Issues • Orchestration issues - Placement of services based on locality (physically and logically) - Placement of services based on platform capabilities • Controller / Data Path Issues - Stateful services need to follow the same path in both directions - How to pass meta-data? Do it as part of header, or pass through external mechanisms? - How to optimize service chains (avoid tromboning), and modify them once a given service is not longer needed? • Service Issues - How to approach high availability? Redundancy at the Service Function level or the Service Chain level? - Abstraction of Policy for operational networks 20 Agenda • Network Builders ecosystem: vAppliances • Service chaining overview & challenges • Solutions for service chaining • Wind River Demonstration Highlights • Lessons learned • Summary & Call to Action 21 Potential Solutions Controller Coordinates Service Segments Use of a Dedicated Service Chain Header • Many POCs have used interim solutions • A service chain header can indicate what service path to use - For example, use of TOS bits, VLAN headers • For some deployments, use of tunnelling solutions would suffice - VXLAN, VXLAN-GPE, NVGRE • Need to be aware of the potential complexity involved, especially as number of potential tuples increases Outer L2/L3/L4/Tunnel 22 Service Header - Controller can then make use of this to determine the optimal path • Various solutions under considerations by Internet Engineering Task Force (IETF) • Two current proposals, being merged into one Inner L2 or L2/L3 Payload Internet Engineering Task Force (IETF) Service Function Chaining SFC Aware Service Function SFC Unaware Service Function SFC Proxy Service Forwarder Service Classifier Network Forwarder Network Services Header Service Chain Header NSH Base Header Service Path / Index SCH Base Header Service Path / Index Network Context Optional TLV Metadata Service Context Optional TLV Metadata 23 SFC: Service Function Chaining Use of Deep Packet Inspection SDN Controller Load Balancer Virtual Appliance • Providing DPI to the SDN controller would allow it to make more intelligent decisions for the flow - Would allow bypass of unnecessary virtual appliances - For example, after DPI it might be determined that a flow does not need to go through the firmware • Need to ensure “cut-through” happens without causing issues in packet ordering if this is done dynamically • This control could be done locally in the case of co-located VMs / DPI 24 DPI Flow Table Virtual Switch Tenant Virtual Machine Firewall Virtual Appliance Flow Table Virtual Switch Use of Deep Packet Inspection SDN Controller Load Balancer Virtual Appliance • Providing DPI to the SDN controller would allow it to make more intelligent decisions for the flow - Would allow bypass of unnecessary virtual appliances - For example, after DPI it might be determined that a flow does not need to go through the firmware • Need to ensure “cut-through” happens without causing issues in packet ordering if this is done dynamically • This control could be done locally in the case of co-located VMs / DPI 25 DPI Flow Table Virtual Switch Tenant Virtual Machine Firewall Virtual Appliance Flow Table Virtual Switch Use of Deep Packet Inspection SDN Controller Load Balancer Virtual Appliance • Providing DPI to the SDN controller would allow it to make more intelligent decisions for the flow - Would allow bypass of unnecessary virtual appliances - For example, after DPI it might be determined that a flow does not need to go through the firmware • Need to ensure “cut-through” happens without causing issues in packet ordering if this is done dynamically • This control could be done locally in the case of co-located VMs / DPI 26 DPI Flow Table Virtual Switch Tenant Virtual Machine Firewall Virtual Appliance Flow Table Virtual Switch Use of Deep Packet Inspection SDN Controller Load Balancer Virtual Appliance • Providing DPI to the SDN controller would allow it to make more intelligent decisions for the flow - Would allow bypass of unnecessary virtual appliances - For example, after DPI it might be determined that a flow does not need to go through the firmware • Need to ensure “cut-through” happens without causing issues in packet ordering if this is done dynamically • This control could be done locally in the case of co-located VMs / DPI 27 DPI Flow Table Virtual Switch Tenant Virtual Machine Firewall Virtual Appliance Flow Table Virtual Switch Use of Deep Packet Inspection SDN Controller Load Balancer Virtual Appliance • Providing DPI to the SDN controller would allow it to make more intelligent decisions for the flow - Would allow bypass of unnecessary virtual appliances - For example, after DPI it might be determined that a flow does not need to go through the firmware • Need to ensure “cut-through” happens without causing issues in packet ordering if this is done dynamically • This control could be done locally in the case of co-located VMs / DPI 28 DPI Flow Table Virtual Switch Tenant Virtual Machine Firewall Virtual Appliance Flow Table Virtual Switch Agenda • Network Builders ecosystem: vAppliances • Service chaining overview & challenges • Solutions for service chaining • Wind River Demonstration Highlights • Lessons learned • Summary & Call to Action 29 Dynamic Service Chaining Demo Setup Intel® Data Plane Development 30 Kit (Intel® DPDK) Dynamic Service Chaining Demo Setup Open Network Platform for Servers Foundation Intel® Data Plane Development 31 Kit (Intel® DPDK) Dynamic Service Chaining Demo Setup VPN GW Appliance w/ QAT Intel® Data Plane Development 32 Kit (Intel® DPDK) Dynamic Service Chaining Demo Setup Router Appliance Intel® Data Plane Development 33 Kit (Intel® DPDK) Dynamic Service Chaining Demo Setup IPS (Bump in the Wire) Appliance Appliance Management Intel® Data Plane Development 34 Kit (Intel® DPDK) Dynamic Service Chaining Demo Setup WAN Optimizers (Bump in the Wire+) Appliance Intel® Data Plane Development 35 Kit (Intel® DPDK) Dynamic Service Chaining Demo Setup Deep Packet Inspection Intel® Data Plane Development 36 Kit (Intel® DPDK) Dynamic Service Chaining Demo Setup OpenStack* and ODL, KVM, & Service Chain Awareness Intel® Data Plane Development 37 Kit (Intel® DPDK) Dynamic Service Chaining Demo Setup Intel® Data Plane Development 38 Kit (Intel® DPDK) Appliance Migration Demo GUI Alternate Flows based on DPI (reroute, mark) Targeted Traffic – DPI, WAN Opt, IPS OpenStack Initial 39 No Traffic OpenStack*/OpenDaylight Networking View Open Daylight with Service Chain Orchestration/Controller have views but service chain awareness and orchestration makes the chain work 40 Traffic Flow Migration Service Chain flows same before and after migration Service Chain After Migration Migration Control 41 Traffic Flow Management and Monitoring Brocade* vRouter GUI Brocade vRouter McAfee SMC McAfee NFGW/SMC Riverbed* Virtual Steelhead GUI 42 Riverbed Virtual Steelhead Showcase 1. 2. 3. 4. 43 Flow table definition and updates in OpenDaylight GUI of vAppliances Migration using OpenStack* Custom traffic flows before and after migration 44 Agenda • Network Builders ecosystem: vAppliances • Service chaining overview & challenges • Solutions for service chaining • Wind River Demonstration Highlights • Lessons learned • Summary & Call to Action 45 Lessons Learned • Interoperability management challenge - OpenStack* versions - Linux* distributions - Intel® Architecture hardware dependencies • Insertion of L4-7 proxies is particularly “interesting” • Variety of vAppliance VNF and Intel® Data Plane Development Kit adoption • Need to settle on one set of standards, including headers • Controller and Orchestrator need to become Service Chain “aware” - 46 Need to adopt policies on how meeting SLAs are monitored/enforced Agenda • Network Builders ecosystem: vAppliances • Service chaining overview & challenges • Solutions for service chaining • Wind River Demonstration Highlights • Lessons learned • Summary & Call to Action 47 Summary and Call to action 48 • Intel and Wind River are delivering open standard NFV solutions to address networking pain points • Dynamic service chaining delivers critical capabilities for data center SDI • Based on commercial open source/community software from Wind River • The virtual appliance community needs to embrace a standards based approach, and the IETF is defining the options • Opportunity to tie-in Network Builders ecosystem into POCs • Download the Intel® Open Network Platform (Intel® ONP) for Servers Reference Architecture for NFV and SDN at www.01.org and join the community and contribute to the reference architecture and associated Intel® Architecture (IA) NFV and SDN open source projects • Virtual Network Functions need to leverage IA silicon and software ingredients to meet performance needs Additional Sources of Information • A PDF of this presentation is available from our Technical Session Catalog: www.intel.com/idfsessionsSF. This URL is also printed on the top of Session Agenda Pages in the Pocket Guide. • See the Wind River Systems Service Chaining Demo in the Network Builders Pavilion in Booth 907 • Additional info in the IETF Service Function Chaining Work Group – https://datatracker.ietf.org/wg/sfc/documents/ • Service Function Chaining in Open Daylight https://wiki.opendaylight.org/view/Service_Function_Chaining:Main • Service Function Chaining in OpenStack* https://wiki.openstack.org/wiki/Neutron/VirtualResourceForServiceChaining • Research Directions in Network Service Chaining http://ieeexplore.ieee.org/stamp/stamp.jsp?arnumber=6702549 • Extending SDN to Handle Dynamic Middlebox Actions via FlowTags http://www.contrib.andrew.cmu.edu/~sfayazba/flowtags_ons14.pdf 49 Legal Disclaimer INFORMATION IN THIS DOCUMENT IS PROVIDED IN CONNECTION WITH INTEL PRODUCTS. NO LICENSE, EXPRESS OR IMPLIED, BY ESTOPPEL OR OTHERWISE, TO ANY INTELLECTUAL PROPERTY RIGHTS IS GRANTED BY THIS DOCUMENT. EXCEPT AS PROVIDED IN INTEL'S TERMS AND CONDITIONS OF SALE FOR SUCH PRODUCTS, INTEL ASSUMES NO LIABILITY WHATSOEVER AND INTEL DISCLAIMS ANY EXPRESS OR IMPLIED WARRANTY, RELATING TO SALE AND/OR USE OF INTEL PRODUCTS INCLUDING LIABILITY OR WARRANTIES RELATING TO FITNESS FOR A PARTICULAR PURPOSE, MERCHANTABILITY, OR INFRINGEMENT OF ANY PATENT, COPYRIGHT OR OTHER INTELLECTUAL PROPERTY RIGHT. A "Mission Critical Application" is any application in which failure of the Intel Product could result, directly or indirectly, in personal injury or death. SHOULD YOU PURCHASE OR USE INTEL'S PRODUCTS FOR ANY SUCH MISSION CRITICAL APPLICATION, YOU SHALL INDEMNIFY AND HOLD INTEL AND ITS SUBSIDIARIES, SUBCONTRACTORS AND AFFILIATES, AND THE DIRECTORS, OFFICERS, AND EMPLOYEES OF EACH, HARMLESS AGAINST ALL CLAIMS COSTS, DAMAGES, AND EXPENSES AND REASONABLE ATTORNEYS' FEES ARISING OUT OF, DIRECTLY OR INDIRECTLY, ANY CLAIM OF PRODUCT LIABILITY, PERSONAL INJURY, OR DEATH ARISING IN ANY WAY OUT OF SUCH MISSION CRITICAL APPLICATION, WHETHER OR NOT INTEL OR ITS SUBCONTRACTOR WAS NEGLIGENT IN THE DESIGN, MANUFACTURE, OR WARNING OF THE INTEL PRODUCT OR ANY OF ITS PARTS. Intel may make changes to specifications and product descriptions at any time, without notice. Designers must not rely on the absence or characteristics of any features or instructions marked "reserved" or "undefined". Intel reserves these for future definition and shall have no responsibility whatsoever for conflicts or incompatibilities arising from future changes to them. The information here is subject to change without notice. Do not finalize a design with this information. The products described in this document may contain design defects or errors known as errata which may cause the product to deviate from published specifications. Current characterized errata are available on request. Contact your local Intel sales office or your distributor to obtain the latest specifications and before placing your product order. Copies of documents which have an order number and are referenced in this document, or other Intel literature, may be obtained by calling 1-800-548-4725, or go to: http://www.intel.com/design/literature.htm Intel, Xeon, Look Inside and the Intel logo are trademarks of Intel Corporation in the United States and other countries. *Other names and brands may be claimed as the property of others. Copyright ©2014 Intel Corporation. 50 Risk Factors The above statements and any others in this document that refer to plans and expectations for the second quarter, the year and the future are forwardlooking statements that involve a number of risks and uncertainties. Words such as “anticipates,” “expects,” “intends,” “plans,” “believes,” “seeks,” “estimates,” “may,” “will,” “should” and their variations identify forward-looking statements. Statements that refer to or are based on projections, uncertain events or assumptions also identify forward-looking statements. Many factors could affect Intel’s actual results, and variances from Intel’s current expectations regarding such factors could cause actual results to differ materially from those expressed in these forward-looking statements. Intel presently considers the following to be important factors that could cause actual results to differ materially from the company’s expectations. Demand for Intel's products is highly variable and, in recent years, Intel has experienced declining orders in the traditional PC market segment. Demand could be different from Intel's expectations due to factors including changes in business and economic conditions; consumer confidence or income levels; customer acceptance of Intel’s and competitors’ products; competitive and pricing pressures, including actions taken by competitors; supply constraints and other disruptions affecting customers; changes in customer order patterns including order cancellations; and changes in the level of inventory at customers. Intel operates in highly competitive industries and its operations have high costs that are either fixed or difficult to reduce in the short term. Intel's gross margin percentage could vary significantly from expectations based on capacity utilization; variations in inventory valuation, including variations related to the timing of qualifying products for sale; changes in revenue levels; segment product mix; the timing and execution of the manufacturing ramp and associated costs; excess or obsolete inventory; changes in unit costs; defects or disruptions in the supply of materials or resources; and product manufacturing quality/yields. Variations in gross margin may also be caused by the timing of Intel product introductions and related expenses, including marketing expenses, and Intel's ability to respond quickly to technological developments and to introduce new products or incorporate new features into existing products, which may result in restructuring and asset impairment charges. Intel's results could be affected by adverse economic, social, political and physical/infrastructure conditions in countries where Intel, its customers or its suppliers operate, including military conflict and other security risks, natural disasters, infrastructure disruptions, health concerns and fluctuations in currency exchange rates. Intel’s results could be affected by the timing of closing of acquisitions, divestitures and other significant transactions. Intel's results could be affected by adverse effects associated with product defects and errata (deviations from published specifications), and by litigation or regulatory matters involving intellectual property, stockholder, consumer, antitrust, disclosure and other issues, such as the litigation and regulatory matters described in Intel's SEC filings. An unfavorable ruling could include monetary damages or an injunction prohibiting Intel from manufacturing or selling one or more products, precluding particular business practices, impacting Intel’s ability to design its products, or requiring other remedies such as compulsory licensing of intellectual property. A detailed discussion of these and other factors that could affect Intel’s results is included in Intel’s SEC filings, including the company’s most recent reports on Form 10-Q, Form 10-K and earnings release. Rev. 4/15/14 51
© Copyright 2024 ExpyDoc
