Transcript A Web Service- and ForCES-based Programmable

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,[email protected]
Seventh Annual International Working Conference on
Active and Programmable Networks
November 21-23 2005
IWAN 2005
1
Outline


The Need for Open APIs
ForCES



FlexiNET



Architecture
FlexiNET & ForCES
ForCEG






Concept
Description
ForCES Scope
Concept
ForCEG & FlexiNET
Architecture
Use Case
Evaluation – Conclusion – Future Work
IWAN 2005
2
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
3
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
4
ForCES Description

Control Elements (CEs).

Forwarding Elements (FEs).

Logical Function Blocks (LFBs).




Encapsulating
fine-grained,
operations
Responsible of a specific task.
Static Topology
Dynamic Topology
CE
forwarding
FE
LFB
LFB
LFB
LFB
LFB
IWAN 2005
plane,
LFB
5
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
6
FlexiNET Architecture (con.)
IWAN 2005
7
FlexiNET & ForCES

FlexiNET
separates
functionalities.

Dynamically deployed new services require
additional programmability functions.

User specific network customization.
IWAN 2005
control
and
data
8
ForCES & FlexiNET



Dynamically Deploy CEs in any PC.
User Specific Router Configuration.
CE
Solution: ForCES
CE
FE
IWAN 2005
9
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
10
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
11
ForCEG Concept (con.)




Conceal ForCEs Model Details
Multiple MCPs to FEs
FE Easy Discovery Software Software
Module
Module
Generic API
API

API
Software
Module
API
Solution: Web Services
ForCEG
ForCES
ForCES
FE
IWAN 2005
12
ForCEG & FlexiNET



Dynamically Deploy MCPs in any PC.
User Specific Router Configuration.
Solution: ForCEG
MCP
CE
MCP
CE
ForCEG
FE
IWAN 2005
13
ForCEG Concept (con.)
Main Control Program
CE
ForCEG
Firewall QoS-related Routing
ForCES FE
Start/Termination Point
FE
LFB
LFB
…
LFB
Target
Correlation
between
high-layer
function &
LFB’s
Underlying Hardware
IWAN 2005
14
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
15
ForCEG Architecture
MainControl
ControlProgram
Program
Main
Main
Control Program
Web
Services
Server
ForCES CE
Start/Termination
Point
Subscribed
Events &
Pending
Responses
Message
Parser
ForCES
Translator
Command
Control
Logic
Current
FE & LFB
State
Web Service
Interface
ForCES
ForCES FE
Start/Termination
Point
IWAN 2005
16
ForCEG Use Case
FCSTP
Translator
CCL
MCP
Parser
Web Service
ForCEG
AAA Proxy
UDDI Registry
Register Web Service
Locate ForCEG
XML file
Configuration
Message
ForCEG WSDL
URL & Operations
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
17
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
18
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
19
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
20
Questions?
IWAN 2005
21