 Continuing with various more frameworks and projects which are coming from different telecom consortia. Let's continue. Here we are going to look at some more. This time since we are looking at some more advanced frameworks and projects we are going to look at the requirements a little bit differently from the classical network function virtualization requirements and this would lead us to some interesting insights into how these requirements were understood and how the particular frameworks evolved. So the first one actually is open network operating system or onus. This is a highly evolved variant of the SDN controller. It provides features beyond classical SDN controllers for carrier grade requirement. Carrier is a telecommunication parlance or a telecommunication specific definition which says that in order to accommodate a very large number of users with some assured service level some cautious arrangements or trust mechanisms have to be ensured. So if SDNs have to provide trust or reliability or an assurance mechanism to the users then their bandwidth demands have to be considered meticulously. Then the content distribution mechanism which would be beyond the bounds of a LAN, a MAN or even one particular network administrator it could be on the other side of a single cloud or altogether to a different cloud. Then new business streams such as in business to business or business to consumer or consumer to consumer in e-commerce or M-commerce some new network infrastructure or architecture has to be commissioned. So this was the requirement that led to the evolution of the open flow into altogether a network operating system level framework. So onus actually is now there to take care of everything including the management monitoring that is measurements and the programming of the network devices as such which would definitely involve virtualizing the resources isolating the resources in case of a failure then secured access for different customers with the security varied security credentials and abstracting away the details of the underlying hardware by making it more vendor neutral. This is actually how the journey has been made from the open flow controller to the network operating system on the left hand side you can see from the open flow controller to the STN controller to the STN framework and to an entirely network based operating system. On the right hand side we can see that onus actually is abstracting the underlying legacy equipment or the white box networking devices which are very new which are known as the forwarding elements and is providing seamless access to the network functions as a service. We know different kinds of cloud services but they're similar to that so we have the apps which are using this. This is the evolution for massive requirements which are of carrier grade. The onus architecture itself isn't much different from what we've seen earlier for other frameworks. We have the APIs or the API layer connected through the northbound interface. This time since we're talking about really big stuff so we have the policy enforcement and conflict resolution across multiple networks and their devices and then we have the distributed protocols which are implemented at the core. Now since we are talking about the carrier grade services, scalability, availability, performance and persistence are now serious issues that onus has to handle. At the southbound where the devices are more visible to onus itself so discovery, observation, programming and configuration are the requirements at the service abstraction layer then essentially the data plane entities are more or less the same. Now we are also going to look at the most common term known as rest APIs or restful APIs. What is that? How does that relate to the implementation of network functions using various architectures? We know that APIs are essentially the appellates or the interface through which a user interacts with the particular underlying system or the underneath layers. An API which conforms to the design principles of representational state transfer. It's again a terminology which is specific to an architecture requirement like client server, pipeline and model view controller etc. So something similar to that. So we have some architecture principles which are going to be ensured while implementing web services. So these include having a consistent interface or uniform interface for multiple users, the coupling or decoupling between client and server so that having a single server and multiple clients and having a client access to multiple servers can be realized smoothly. Then the statelessness of the client credentials with the server and the ease with which a server can move or migrate from one client to the other without having to carry the backlog or the burden of a client forever. Then cashability means that in particularly networked environments, the internet connectivity could be flaky. So if there's a requirement for some buffering, it has to be provisioned. Then layered system architecture means the underlying complexities of the network, the topology, the lower layer protocols has to be invisible from the API. And then the code execution on different platforms, for instance, the client end, the server end has to be only on a need to do basis. Otherwise, having a monolithic one time deployment could lead to redundancy as well as probably something known as system becoming stale or obsolete with time. Let's look at very simple simplified diagram of how REST APIs actually become useful because they provide abstraction. Any website could be accessed by any client using the RESTful APIs as long as these principles are adhered to any API is a RESTful API. Now, the northbound implementation of the APIs, as long as it is in agreement with REST serves the job. So on the right hand side, we have the northbound APIs, which interact between the application layer and the SDN controller, it's perfectly fine for as long as the RESTful conditions are met. Then we have another framework known as Rio. This Rio framework is an yet another initiative, but it is component based. Having components allows the microservices architecture to be to be implemented. Again, it is not much different from the earlier frameworks except for the way the microservices or the components are provisioned. So some more details could be found at this URL. Let's look at the Rio implementation, which is broadly speaking, not much different from the earlier frameworks. We have the SDN apps, and then we have the Rio SDN framework, which interacts with the southbound open virtual switch environment using OpenFlow. And that actually is pretty much all that we would like to know at the very basic level. The resources are primarily the same book, software defined networking with OpenStack by Patrick Publishing. Then we have the IBM URL from where I got some insight into REST APIs and an interesting read on REST API design for SDN northbound APIs. So this this is another nice paper.