Welcome to FaaS
| Table of Contents|
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.