Skip to end of banner
Go to start of banner

FaaS

Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Welcome to FaaS

Introduction

In general, FaaS project aims to create a common abstraction layer on top of a physical network, so northbound API or services can be easier to be mapped onto the physical network as concrete device configuration. The common abstraction layer models the physical network as a topology that consists of abstracted node - fabrics. Each fabric is abstraction of a portion of the physical network usually within the same control plane and uses similar data path technique, such as VXLAN or VLAN. Every fabric offers a set of unified services as well as primitive constructs to create and manage a logical network life cycle according to users’ requirement.

Using FaaS to deploy network services

  • decouples user network services from vendor and technology specific implementation, avoid vendor locked in.
  • enable service deploy and control automation, massively reduce OPEX as well as CAPEX.
  • improve service deployment agility.

If you think of a computer as a network, FaaS provides a set of system calls for network applications. Those system calls has two layers. One layer is called driver layer which abstracts vendor/technology specific technique, which is realized on top of a specific fabric object. The second layer is built on top of the whole network which consists of a topology of fabrics. The second layer provides neutron like user level logical network abstractions. With those two layers' abstraction, the controller can be extended to support more devices and technology while keeps users' services transparent to the change.

Moreover, applications built on top of FaaS is using high level primitives to program the network. To make an analogy, using FaaS to build applications is like a using C lib other than assembly to program a machine.

We also realize that the FaaS will evolve as underneath technology evolves just like system calls are extended as OS evolves. FaaS has to evolve in a backward compatible fashion.

Project Information

Project Facts

Project Creation Date:  August 6, 2015
Lifecycle State: Incubation
Type: App
Primary Contact: Xingjun Chu <xingjun.chu@huawei.com>
Project Lead:  Xingjun Chu <xingjun.chu@huawei.com>
Committers:  
IRC: freenode.net@opendaylight-faas
Mailing List:  faas-dev@lists.opendaylight.org
Archives: unspecified
Meetings: See Community Meetings 
Repository:  Repository 
Jenkins: Jenkins 
Gerrit Patches: Gerrit
Open Bugs: Bugzilla

Documentation

Getting Started for Users

Getting Started for Developers

Requirements


Test and Integration Plan

https://wiki.opendaylight.org/view/FaaS:SystemTestPlan

Release Planning

ReleaseRelease PlanRelease NotesRelease ReviewInstallation GuideUser GuideDeveloper GuideOperations GuideHow-To's/TutorialsFeature TreeFeature Tests
BerylliumRelease PlanRelease NotesRelease Review-------
BoronRelease PlanRelease NotesRelease Review-------
CarbonRelease PlanRelease NotesRelease Review-------
NitrogenRelease PlanRelease NotesRelease Review-------
OxygenRelease PlanRelease NotesRelease Review-------
SNAPSHOT----User GuideDeveloper GuideOperations GuideHow-To's/Tutorials-System Test Plan

Release Notes

  • No labels