In previous posts in this series I discussed the following design principles used in Tail-f’s SDN technology: logically centralized implementation of network services, data structure representations of service and network states, and data models describing these data structures.
In this post I will discuss how network services can be implemented by mapping service operations to configuration state changes in the network.
Let’s use a VPN service as an example. The definition of this service is a YANG data model describing the service from a network operator’s point of view: it describes the parameters that an operator need to specify to create a VPN instance. These parameters might include a VPN identifier, a route distinguisher, and a list of access links that ties the PE (Provider Edge) routers together with the corresponding CE (Customer Edge) routers. Each access link is made up of a PE router and an interface on that router, a CE router and an interface on that router, and subnet to be associated with the link.
Based on this service definition, VPN instances can be created, modified, re-deployed and deleted. To implement a VPN service we thus need to implement create, modify, re-deploy and delete operations that map these service-level operations into the corresponding configuration changes in the network. For example, adding a leg to a VPN service might involve VRF, BGP, policy map, and interface configuration on a PE router, and BGP and interface configuration a CE router.
We do this mapping in two steps. First we map the create/modify/re-deploy/delete operation on the service instance (a data structure in the controller) into an abstract network configuration change-set (another data structure in the controller).
In the second step we map the network configuration change-set into device-specific command sequences that are deployed into the affected devices in the network. These command sequences might be CLI commands, NETCONF operations, requests to RESTful interfaces, SNMP SET operations, or some other operations supported by the devices in the network.
Note that the first step in the mapping is data structure mapping that does not require distributed programming The second step, however, involves writing data to the network of devices. The NCS controller carries out both steps within an atomic transaction implemented using a two-phase commit protocol (error recovery in the network can be horrendously complex to manage without such transactional guarantees):
Of course, most interfaces on network devices do not support transactions (NETCONF is an exception). In the last 5 minutes of this presentation I describe how a controller can implement transactions toward a device with a non-transactional CLI: