[ PPT ] presentation


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

[ PPT ] presentation

  1. 1. Network Services in the Next- Generation Internet Tilman Wolf Department of Electrical and Computer Engineering University of Massachusetts Amherst Department of Electrical and Computer Engineering
  2. 2. Need for Clean-Slate Network Architecture  Limitations of current architecture Access router: - Access concentration Core router: - Multiprotocol label switching - QoS aware routing (cable, DSL, wireless) • Fixed TCP/IP stack - Network address translation - Policy-based QoS - Monitoring - Monitoring and billing • Hardware implementation of forwarding - Firewall • Extensions are “hacks” − Firewalls, intrusion detection systems, network address translation `  Need for new network architecture End system: Edge router: - Packet classification - QoS (DiffServ) Server: - Content-based • Support for more heterogeneity - IP security - monitoring and billing switching - TCP termination - Firewall - SSL termination − End systems: cell phones, PDAs, RFID tags, sensors - IP security − Routers: wireless infrastructure, ad-hoc networks • Support for new networking paradigms − Data access: content distribution, content addressable networks − Protocols: multipath routing, network coding Tilman Wolf 2
  3. 3. Network Virtualization  Virtualization of router system parallel • Common hardware (“substrate”) “protocol stacks” • Coexistence of multiple virtual networks • Specialized networks deployed as separate ` substrate router protocol stacks (“slices”) `  Programmability in data plane • Deployment of new protocols through software  Questions • How to deploy new functionality in empty slice? − Per-connection functionality and network-wide functionality • How to manage processing resources in substrate? Tilman Wolf 3
  4. 4. Outline  Introduction  Network Services • Architecture • Routing with network services  Packet processing systems • Runtime management  Conclusions Tilman Wolf 4
  5. 5. Flexibility vs. Manageability  Customization in network architecture Application trans- coding caching IDS • What is the right level of flexibility? flow SSL Transportreliability  Two extremes control privacy QoS • ASIC implementation of IP router Network anycast schedu- ling multi- cast − All packets are handled the same way − No flexibility • Active networks − Packet processing can be programmed caching multi- cast reliability − Too much flexibility – very difficult to manage flow  Our approach: balanced combination trans- coding anycast control SSL privacy • Set of well-defined protocol processing QoS features (“network services”) IDS schedu- ling − E.g., reliability, security, scheduling, … • Custom combination of services provides flexibility Network services Tilman Wolf 5
  6. 6. Network Service Architecture  New communication abstraction • Custom Service-Enabled Network composition of functions along End- System End- System end-to-end path • expressed as Connection Request sequence of End- Service Service End- “network services” System 1 2 System  Benefits • End-system application can choose most suitable features • Network can control placement of services • Programmable routers implement network services Tilman Wolf 6
  7. 7. Related Work  Protocol stack composition on end-system (“vertical”) • Configurable protocol stacks [Bhatti & Schlichting, SIGCOMM 1995] • Configurable protocol heaps [Braden, Faber & Handley, CCR 2003] • NCSU SILO project [Dutta et al., ICC 2007]  Custom network processing (“horizontal”) • Active networks [Tennenhouse & Wetherall, SIGCOMM 1996] • Modular routers: Click [Kohler et al., TOCS 2000] • Programmable routers and network processors  Substrate systems • Router virtualization: VINI (Princeton), SPP (Washington University) • Forwarding substrate: OpenFlow (Stanford), PoMO (Univ. of Kentucky)  Our focus: abstractions for horizontal composition Tilman Wolf 7
  8. 8. Network Service Architecture  Hierarchical inter-network and intra-network design • Autonomous System abstraction • Match with administrative boundaries of Internet Service- Enabled  Control plane Control plane Service Controller Network Service Controller • Connection End- End- setup System System Service Service Service • Routing Data plane Node Node Node Service algorithm Service Node Service Service  Data plane Node Node Node • Forwarding • Packet processing Tilman Wolf 8
  9. 9. Connection Setup  Interface to applications End- System Service Controller Service Node 1 Service Node 2 • API similar to Berkeley sockets connection t • Service specification determines request sequence of requested services mapping service  Example: setup service *:*>>compression(LZ)>> setup setup decompression(LZ)>> ack resource ... allocation • Connection to port 80 connection setup • Compression (Lempel Ziv) on path ack ack data  Options transmission • Parameters necessary for service (e.g., service data LZ) processing transmission • Constraints service placement (e.g., service sending LAN, receiving LAN) processing ... Tilman Wolf 9
  10. 10. Multiparty Interests  Connection setup can be influenced by multiple parties: • Sender (connection to destination) • Receiver (e.g., use of proxy) • Network service provider (e.g., monitoring)  Explicit addition of services *:*>>monitoring>>proxy>> *:*>> *:*>>monitoring>>*.* Network *:*>>proxy>> service provider Sender Receiver Tilman Wolf 10
  11. 11. Service Routing Problem  Interesting problem at connection setup • Determine path and select nodes to perform service • How can a node decide best path? − Better to perform service locally? − Better to defer to downstream node? − Which direction to route connection?  Assumption: single cost metric • Otherwise NP complete  Centralized solution ? ? • Global view necessary s ? t • Limited scalability ?  Distributed solution • Dynamic programming Tilman Wolf 11
  12. 12. Distributed Service Matrix Routing  Similar to Distance Vector routing • Each neighbor announces cost of best path to each destination • Each node adds cost to neighbor and picks best router (Bellman-Ford) no service  Distributed Service Matrix Routing (DSMR) services • Expand vector to include service: “service matrix” − Periodic service matrix exchange − Service matrices stabilize eventually - S1 S2 S1S2 S2S1 ... • Each node can determine best path v1 3 6 9 11 10 ... − Handle service locally OR destinations v2 4 7 5 15 13 ... − Send to neighbor with ... ... ... ... ... ... ... lowest cost • Challenge: each service combination requires columns in matrix − Exponential growth of matrix with number of services Tilman Wolf 12
  13. 13. Approximate DSMR no service  Use information from single service only services • Matrix lists node where service is performed  Routing of multiple services - S1 S2 ... • Allocate best node for last service v1 3 6,v3 9,v4 ... • Find best path for v2 4 7,v5 5,v4 ... S2 destinations second-to-last S1 ... ... ... ... ... service to S3 that node S2 • Repeat for S1 S3 all services s t  Upper bound Least-cost path for services sequence on path Least-cost path for one service (given by service matrix) Approximate least-cost path (and upper-bound) Tilman Wolf 13
  14. 14. Prototype Implementation  Emulab prototype • 12 Autonomous Systems • 60 nodes  Service routing • Centralized within AS • Approximate DSMR between ASs  149,760 connections • All possible source- destination pairs • All possible service combinations Tilman Wolf 14
  15. 15. Evaluation of DSMR  Correctness • 6 of 149,760 connections failed  Convergence time • Service matrices converge • Time increases with network size  Approximate DSMR • Works well for small number of services • Inefficiency grows with number of service path length of approximation over optimal route Tilman Wolf 15
  16. 16. Evaluation of DSMR  Connection setup time with Distributed Service Routing Protocol (DSRP) • Compared to TCP • Setup time less than 2× longer  Evaluation summary • Routing with service constraints can be solved efficiently • Distributed algorithm is scalable when using approximation Tilman Wolf 16
  17. 17. Example Scenario: IPTV Distribution  Heterogeneous receivers present challenge with live IPTV • Current solution: overlay with transcoding on end-systems Network HDTV display HDTV Source (1080p) (1080p) 1080p to 1080p to H.263 H.261 Video transcoding Low quality display (H.261) Low quality display (H.263) Tilman Wolf 17
  18. 18. Example Scenario: IPTV Distribution  Transcoding in network when using network service Network HDTV display HDTV Source (1080p) (1080p) 1080p to 1080p H.263 to H.261 Low quality display (H.261) Low quality display (H.263) Tilman Wolf 18
  19. 19. Example Scenario: IPTV Distribution  Prototype implementation • Emulab simulation  Service request • *:*>>monitor(bandwidth) >>multicast(, videotranscode(1080p,H.264) >>monitor(bandwidth) >> >>*:5000  Also prototyped on real router system • Cisco ISR with AXP • Single core processor insufficient  How to design a good packet processing system? Tilman Wolf 19
  20. 20. Outline  Introduction  Network Services • Architecture • Routing with network services  Packet processing systems • Runtime management  Conclusions Tilman Wolf 20
  21. 21. Programmable Router  Flexibility through programmability • General-purpose processing capability in data path • Packet processing in software  High-performance Router processing hardware packets Port Port • E.g., network processors  Scalability through high Switching Port Fabric level of parallelism Network Interface Network Processor Processing Processing Network Engine Engine Port Interconnect Port services on Processing Processing packet Engine Engine processor I/O Tilman Wolf 21
  22. 22. Programming of Packet Processors  Programming is challenging • Distribution of processing onto multiple processors − Run-to-completion model often not feasible • Limited instruction store on embedded packet processors • Contention for shared data structures • System components on MPSoC are tightly coupled • Simple code, but repetitiveness amplifies small problems  Typical solution: offline optimization • Simulation to identify performance bottlenecks • Manual adjustment − Code, thread and processor allocation, memory management • Repeat  Offline optimization cannot handle dynamic environment • Change in network traffic, network services, slice allocation, etc. Tilman Wolf 22
  23. 23. Runtime System for Packet Processors Offline programming Runtime Possible data-path Update of profiling and configuration management network services information Click configuration Graph of Task mapping schedulable Implementation Click elements of Click elements Installation of Click configuration on packet processing hardware User  Adaptation of task allocation Click Processor Click Processor Packets core core to processing resources • Runtime profiling to obtains Click Hardware usage statistics accelerator Processor core • Task mapping to adapt to Heterogeneous multi-core current requirements packet processing system  Current focus: processing (not memory) Tilman Wolf 23
  24. 24. Workload Representation  Granularity of representation PollDevice(eth0) is important StrideSwitch(1, 1) • Too coarse: not easily distributed • Too fine-grained: scalability problem  Good balance: Unqueue Unqueue Click modular Classifier(...) Classifier(...) router • Directly To eth1 Queue ARPResponder(...) To eth1 Queue ARPResponder(...) translatable To eth1 Queue To eth1 Queue into imple- Tee(5) Unqueue Tee(5) Unqueue mentation To eth1 Queue Strip(14) To eth1 Queue Strip(14) Unqueue Unqueue Unqueue Unqueue CheckIPHeader Unqueue Unqueue Unqueue Unqueue CheckIP Tilman Wolf 24 EtherEncap(...) EtherEncap(...) EtherEncap(...) EtherEncap(...) EtherEncap(...) EtherEncap(...) EtherEncap(...) EtherEncap(...)
  25. 25. Task Mapping Problem  Which Click element (“task”) should run on which processor?  Challenges tt 2 33 t21 • Different task “sizes” t41 1 tT-21 (in terms of processing t1 ... tT1 requirements) tT-11 t61 t81 • Different task utilization t5t3 t 55 t71 • Communication cost of inter-processor transfers task mapping ... ...  Leads to packing problem • Computationally hard to solve ... ... ... ...  Our approach M threads • Simplify problem by creating interconnect N processors tasks of equal size packet processing system Tilman Wolf 25
  26. 26. Task Replication  Profiling provides runtime information • Task utilization • Task processing time ti-1 ti ti+1  Compute: “work” per task task replication • work = (utilization) × (processing time)  Replicate tasks with highest work ti-11 ti1 ti+11 • Replication reduces utilization • Reduced utilization reduces work ti2 ti+12  Benefits or replication • Task work more balanced ti3 − Simplifies mapping problem • Larger number of tasks − Allows scaling to large number of processors Tilman Wolf 26
  27. 27. Task Replication  Example: Click configuration with 23 tasks • IP forwarding and IPSec as network services 155 difference 13.5 difference Tilman Wolf 27
  28. 28. Task Mapping  Simple greedy algorithm • Co-locate tasks with maximum utilization edges • When processor “full” then switch to next  Runtime adaptation • Update profiling information • Update replication • Update mapping • Update NP configuration Tilman Wolf 28
  29. 29. System Evaluation  Our runtime system vs. SMP Click on 4-core Xeon • For various scenarios we observe up to 1.32x higher throughput Tilman Wolf 29
  30. 30. What’s Next?  Trends continue • Trend towards more programmability in networks • Trend toward more embedded cores per chip • Trends towards system usability − Cisco QuantumFlow (40 cores, 4 threads) programmable in ANSI-C  Question: homogeneous or heterogeneous MPSoC? • Homogeneity simplifies slow path processing general- purpose programmability packet processor • Hardware accelerators processing perform better • How to find balance in system implementation fast path processing specialized ? hardware next-generation Internet? t Internet today next-generation architecture Internet architecture Tilman Wolf 30
  31. 31. What’s Next?  Question: is there a better packet processor design? • High overhead for managing instruction memory 32 local data memory instruction 32 32 packet processing context service 1 / in data in/out / / flow 17 flow 9 service • Hardware support for context service 5 8 / addr[7..0] processor addr[11..0] addr[17..12] 6 / 12 address / 6 / service 1 shifter /8 /8 management service 2 address shifter addr[15..8] addr[19..18] PKT_DONE /2 service 5 packet memory • Processor core sees simple DEC 10 packet / (flow 17) 12 / STATE_EN 32 FLOW_EN / instruction and memory ServiceTag[7..0] 8 24 / / packet (flow 9) FlowTag[23..0] address space data[31..0] addr[19..0] 32 18 / /  Question: correct service 32/ PKT_IN[31..0] 32/ PKT_OUT[31..0] composition semantics? • How can service specifications be verified or composed automatically? • Can enumeration of all service properties be avoided? Tilman Wolf 31
  32. 32. Outline  Introduction  Network Services • Architecture • Routing with network services  Packet processing systems • Runtime management  Conclusions Tilman Wolf 32
  33. 33. Conclusions  Next-generation Internet needs to meet many demands • Flexibility is key to avoid ossification  Network services implement new features • Routing with services is important control-plane problem • Distributed Service Matrix Routing provide effective solution  Programmable routers provide packet processing platform • Runtime system for network processors necessary for adaptation • Mapping of processing tasks to hardware resources  Exciting time for networking research • New network architecture and applications • “Clean slate” designs allow for creative contributions Tilman Wolf 33
  34. 34. Acknowledgements  Graduate students • Xin Huang • Sivakumar Ganapathy • Shashank Shanbhag • Qiang Wu  Sponsors • National Science Foundation • Intel Research Council Tilman Wolf 34
  35. 35. wolf@ecs.umass.edu http://www.ecs.umass.edu/ece/wolf/ Tilman Wolf 35
  36. 36. Publications  Network service architecture • Tilman Wolf, “Service-centric end-to-end abstractions in next-generation networks,” in Proc. of Fifteenth IEEE International Conference on Computer Communications and Networks (ICCCN), Arlington, VA, Oct. 2006, pp. 79-86. • Sivakumar Ganapathy and Tilman Wolf, “Design of a network service architecture,” in Proc. of Sixteenth IEEE International Conference on Computer Communications and Networks (ICCCN), Honolulu, HI, Aug. 2007. • Xin Huang, Sivakumar Ganapathy, and Tilman Wolf, “A scalable distributed routing protocol for networks with data- path services,” in Proc. of 16th IEEE International Conference on Network Protocols (ICNP), Orlando, FL, Oct. 2008. • Shashank Shanbhag and Tilman Wolf, “Implementation of end-to-end abstractions in a network service architecture,” In Proc. of Fourth Conference on emerging Networking EXperiments and Technologies (CoNEXT), Madrid, Spain, Dec. 2008.  Runtime management of packet processors • Tilman Wolf, Ning Weng, and Chia-Hui Tai, "Run-time support for multi-core packet processing systems,"IEEE Network, vol. 21, no. 4, pp. 29-37, July 2007. • Qiang Wu and Tilman Wolf, “Dynamic workload profiling and task allocation in packet processing Systems,” in Proc. of IEEE Workshop on High Performance Switching and Routing (HPSR), Shanghai, China, May 2008. • Xin Huang and Tilman Wolf, "Evaluating dynamic task mapping in network processor runtime systems," IEEE Transactions on Parallel and Distributed Systems, vol. 19, no. 8, pp. 1086–1098, Aug. 2008. • Qiang Wu and Tilman Wolf, “On runtime management in multi-core packet processing systems,” in Proc. of ACM/IEEE Symposium on Architectures for Networking and Communication Systems (ANCS), San Jose, CA, Nov. 2008. • Qiang Wu and Tilman Wolf, “Runtime resource allocation in multi-core packet processing systems,” in Proc. of IEEE Workshop on High Performance Switching and Routing (HPSR), Paris, France, June 2009.  Service processor design • Qiang Wu and Tilman Wolf, “Design of a network service processing platform for data path customization,” In Proc. of The Second ACM SIGCOMM Workshop on Programmable Routers for Extensible Services of TOmorrow (PRESTO), Barcelona, Spain, August 2009.  Verification of service composition • Shashank Shanbhag, Xin Huang, Santosh Proddatoori, and Tilman Wolf, “Automated service composition in next- generation networks,” in Proc. of The International Workshop on Next Generation Network Architecture (NGNA), Montreal, Canada, June 2009. Tilman Wolf 36