A Web Service- and ForCES-based Programmable Router Architecture

1. A Web Service- and ForCES-based Programmable Router Architecture Evangelos Haleplidis1, Robert Haas2, Spyros Denazis13, Odysseas Koufopavlou1 1University of Patras, ECE Department, Patras, Greece, 2IBM Research, Zurich Research Laboratory, Rόschlikon, Switzerland, 3Hitachi Sophia Antipolis Lab, France,Spyros.Denazis@hitachi-eu.com Seventh Annual International Working Conference on Active and Programmable Networks November 21-23 2005 IWAN 2005

2. Outline • The Need for Open APIs • ForCES • Concept • Description • FlexiNET • Architecture • FlexiNET & ForCES • ForCEG • ForCES Scope • Concept • ForCEG & FlexiNET • Architecture • Use Case • Evaluation – Conclusion – Future Work IWAN 2005

3. The Need for Open APIs “a programmable network is distinguished from any other networking environment by the fact that it can be programmed from a minimal set of APIs from which one can ideally compose an infinite spectrum of higher level services”1. 1Andrew Campbell, Herman De Meer, Michael Kounavis, Kazuho Miki, John Vicente, and Daniel Villela, “A Survey of Programmable Networks”, ACM SIGCOMM Computer Communications, 1999. IWAN 2005

4. ForCES Concept • Network division: Forwarding, Control, and Management plane • Separation: • Increased scalability • Allows the planes to evolve independently. • Focus: Communication and Model for separating control-plane functionality (e.g. routing protocols) from data-forwarding-plane per-packet activities (e.g. packet forwarding). IWAN 2005

5. LFB LFB LFB LFB LFB LFB ForCES Description • Control Elements (CEs). • Forwarding Elements (FEs). • Logical Function Blocks (LFBs). • Encapsulating fine-grained, forwarding plane, operations • Responsible of a specific task. • Static Topology • Dynamic Topology FE CE IWAN 2005

6. FlexiNET Architecture • Define and implement a scalable and modular network architecture incorporating adequate network elements offering cross-connect control, switching/routing control, and advanced services management/access functions at the network access points that currently only support connectivity between user terminals and network core infrastructures. • FlexiNET Node Instances: • FUAN • FWAN • DGWN • FLAS IWAN 2005

7. FlexiNET Architecture (con.) IWAN 2005

8. FlexiNET & ForCES • FlexiNET separates control and data functionalities. • Dynamically deployed new services require additional programmability functions. • User specific network customization. IWAN 2005

9. ForCES & FlexiNET • Dynamically Deploy CEs in any PC. • User Specific Router Configuration. • Solution: ForCES CE CE FE IWAN 2005

10. ForCES Scope • Only modelling of the forwarding plane is within the scope of the ForCES working group. • FEs can only be controlled by a single active CE, hence different services that require state changes in LFBs belonging to the same FE have to go over the same CE. IWAN 2005

11. ForCEG Concept • Further separate the functionalities of the control point into the Main Control Programs (MCPs), which execute control-plane services, and a ForCES CE Gateway (ForCEG), which implements, among other things, the CE side of the ForCES protocol IWAN 2005

12. ForCEG Concept (con.) • Conceal ForCEs Model Details • Multiple MCPs to FEs • FE Easy Discovery • Generic API • Solution: Web Services Software Module Software Module Software Module API API API ForCEG ForCES FE ForCES IWAN 2005

13. ForCEG & FlexiNET • Dynamically Deploy MCPs in any PC. • User Specific Router Configuration. • Solution: ForCEG CE MCP CE MCP ForCEG FE IWAN 2005

14. ForCEG Concept (con.) CE Main Control Program Target ForCEG Firewall QoS-related Routing Correlation between high-layer function & LFB’s FE ForCES FE Start/Termination Point LFB LFB LFB … Underlying Hardware IWAN 2005

15. ForCEG Concept (con.) • Translates configuration commands from a Generic Web Service API into ForCES packets. • Extend ForCES protocol. • Conceal ForCES model from high-level functions. • Provide connections of multiple Contol Elements into a Forwarding Element. • Advertise APIs through a UDDI registry. • Detect and prevent conflicts between different MCPs. IWAN 2005

16. Main Control Program Main Control Program Main Control Program ForCEG Architecture Subscribed Events &Pending Responses Web Services Server Message Parser Command Control Logic Web Service Interface Current FE & LFB State ForCES CE Start/Termination Point ForCES Translator ForCES ForCES FE Start/Termination Point IWAN 2005

17. Translator CCL UDDI Registry AAA Proxy ForCEG Use Case MCP FCSTP Parser Web Service ForCEG Register Web Service Locate ForCEG ForCEG WSDL URL & Operations Configuration Message XML file Request Confirmation Check current state. Check message for conflicts. CFLS Returns Response XML file Check FE State Create ForCES Message ForCES Message ForCES Message Acknowledgement from FE IWAN 2005

18. Evaluation • ForCEG will be evaluated against: • Performance. • Versatility. • Ease of use. • Measurements: • Delay between the Web Service Call and the sending of the ForCES packet. • Overhead incurred by the architecture as a service executes. IWAN 2005

19. Conclusion • Motivation: To create a Generic Web Service API to provide access to ForCES APIs. • Heterogeneous: Need a middleware architecture approach which provides a Generic Service API and translates it into a low-level API. • Contribution: Our approach extends the ForCES protocol and addresses the issues of multiple CEs to FE. IWAN 2005

20. Future Work • Dynamic Mapping in an automated way. • Integration of other control protocols such as Netconf may extend the versatility of the ForCEG. • Dynamically addition of user specific mappings. IWAN 2005

21. Questions? IWAN 2005