The purpose of this ONOS talk is to convey the rationale behind our approach to a few architectural pillars，
Which in my view make ONOS unique, and which make it an excellent platform for developing SDN solutions,
Not just for service providers, but also for data center and campus network operators.
Specifically, it is its distributed core which provides high availability, scalability, and performance,
Its northbound and southbound abstractions and models that give applications the ability to configure and control the network without becoming dependent on device specifics,
And last but not least, its distributed applications platform that allows users and developers to dynamically extend the base capabilities.
These areas are pivotal as they bring tremendous business value and are what sets ONOS apart.
In order to attain the high availability, scalability, and performance, required for deployments in service provider and other mission-critical networks,
ONOS is built as a physically distributed system, as a cluster of separate nodes.
Of course, there are many different ways clustered solutions can be constructed;
We chose to build it as a symmetric cluster where all nodes are software-wise identical to each other.
Not only this yields many attractive properties not the least of which is simplicity of deployment, but it also fits well with the other desirable characteristics that we wanted the platform to have.
Namely, it helps the applications and the platform itself to be able to access the state in a logically centralized manner and with complete location transparency, meaning without regard where in a cluster the data resides.
The symmetric nature of the ONOS cluster also fits naturally with the desired dynamic scale-out model,
Which allows users to dynamically adjust ONOS cluster size depending on changing workloads and the scale of their control domain.
ONOS takes a multi-faceted approach to tracking network state.
In deciding what kind of distributed treatment to apply, we consider the nature of the state, which is of course primarily determined by the source of its mutation and its access patterns.
Without going into details, we could roughly generalize that nearly all edicts on north–to-south state is treated in strongly consistent manner,
Whereas all sensory and telemetry information or south-to-north state is treated in an eventually consistent manner.
Our own firsthand experience tells us that applying the same treatment uniformly results in significant drawbacks, barrier to achieving high performance certainly being a principle one.
Therefore, rather than viewing the distributed core as a monolithic database of all key values store and then picking a technology such as Cassandra or MongoDB and then building the system around it,
ONOS instead views the core as a collection of data structures.
So the core is built around a number of high-level store abstractions, each tailored for its data and each completely insulating the choice of distributed technology from the rest of the system.
This allows the stores to evolve and improve independently of each other and of the rest of the system.
It should be pointed out that ONOS benefited from this design decision immediately.
With the store implementations being nicely encapsulated, they have evolved significantly since the first release, and today nearly all of them are based on some combination of these distributed primitives.
Since the abstractions exposed by these primitives resemble the familiar collections and comprehensive primitives available in Java and other programming languages, this further helps the developers who are likely to already be familiar with such constructs.
It should also be noted that all ONOS distributed primitives and in fact all ONOS clustering, are implemented at top of a single messaging substrate.
This not only simplifies the deployment, it also improves the system security.
Development of the distributed primitives help to further contain the complexities of distributed algorithms and consequently result in drastic simplifications of the various network state stores.
This move not only benefited the core stores, but it also allowed ONOS applications and extensions to easily construct their own.
In our view, it is not sufficient for the platform alone to have the characteristics of high availability, scalability, and performance.
Applications have to have them too in order for the whole solution to have those characteristics.
This in fact was one of our primary motivators for this approach.
Its benefits are clearly visible in the simplicity and ease with which many of ONOS applications were able to provide distributed stores for tracking and safeguarding their own state.
I should add that we work with Amazon, Microsoft, and Google to learn from them.
In other words, we sought practical advice from those leading the world in distributed systems.
Another key differentiator for ONOS is its approach towards abstracting the environment to the south, and the network centric abstractions and models provided to applications to the north.
It allows ONOS to support many legacy interfaces and protocols with ease and it gives it the elasticity to adapt to the evolving data plane programming models, like P4, without causing applications to be rewritten.
Clearly, standard control and configuration protocols and models are extremely important to us, and we use them in ONOS whenever possible.
In our view, the value of models standard or otherwise, lies in their ubiquity and we certainly want to help them gain that.
However, we do not want to rely on them solely.
Why? Because the viability of the platform should not be predicated on a success, meaning a widespread adoption of such models
Similarly, standard protocols are also important to us, but we do recognize that ultimately, they are secondary to what is really important, and that is the kind of configuration and control that can be conducted with a device.
ONOS should be able to interact with devices regardless of whether they use NETCONF, OpenFlow, a P4-based program, or some custom RPC.
In ONOS, we consider configuration as important as control, if not more.
Really, the distinction between the two is often drawn rather arbitrarily.
So for ONOS, abstractions for both control and configuration are extremely crucial.
We assert that applications should not be at the whim of device protocol and device model details. 我们认为应用不应该受限于设备所使用的协议和模型的细节
Which is why Black Bird, our second release, introduced the driver subsystem intended to support abstracting various facets of device interactions, including configuration.
Because not all devices support the same aspects of control or configuration, ONOS takes a faceted approach to offering device configuration abstractions.
This enables applications to engage in selected configuration activities to each device, but without exposing them to the specific details of the models or protocols to which those activities are conducted.
So, ONOS certainly allows applications to engage in such southbound and implicitly device centric interactions.
After all, this is how we allow applications to program devices supporting multi-table pipelines yet without exposing applications to the pipeline structures themselves.
However, we recognize that there are tremendous benefits to enabling northbound applications to interact in a network-centric manner as much as impossible.
And to that effect, we are investing in services such as our intents subsystem.
Not only this raises the level of language that applications need to speak, it also provides the platform with added degrees of freedom to resolve what might otherwise be conflicting requests.
This is one of the reasons why ONOS deliberately separates the southbound device-centric interactions apart from the northbound interactions which are mostly network-centric.
This extends to our use of the YANG modeling language.
On the southbound, we use it to assist in creating device drivers for various aspects of control and configuration via NETCONF.
In this way, the nuances of the different models exposed by various devices are abstracted away from applications.
And on the northbound, we are starting to use it as a means for external applications to interact with ONOS network-centric services.
In this way, applications that are aware of various network service models, such as L3VPN, can interact with ONOS on their own terms.
Using this same northbound mechanism, service providers can then create and offer customized network-centric services for their customers using YANG or TOSCA as a service definition language.
To facilitate this, we are developing a tool chain for processing YANG models and also an application capable of composing services by mapping their definitions onto northbound services of the ONOS platform and its many applications.
This combined approach offers ONOS applications the necessary model extensibility, and at the same time allows applications written for existing devices to work equally well for the new devices.
While the ONOS platform itself contains many useful capabilities, one of its key strength is its dynamic extensibility and modularity.
It is clear from engagements with our partners and community in general that while there are often shared interests in certain use cases, there are also many diverse uses for which the community wants to create ONOS based solutions.
Therefore, it is important to keep the ONOS core as lean and as minimal as possible, and instead allow functionality to be added or enabled on as needed basis.
This is where ONOS own platform applications come in by effectively acting as ONOS core extensions.
Users can selectively activate the functionality that is applicable for their environments.
This includes high-level functionality such as integrations with external systems such as OpenStack, or various traffic steering applications such as segment routing.
But it also includes low-level functionality such as drivers or protocol providers required to interact with specific environments.
ONOS extensions seamlessly augment the functionality of the base system at all layers within,
Whether it is new southbound drivers and protocol providers, or whether it is a new distributed core component for tracking new type of state or a northbound service for accessing that state.
This extensibility also applies to the ONOS REST API, command line interface and the graphical user interface.
Our goal was to enable applications to extend these surfaces so that the new functionality completely blends in and from the user's point of view become structurally indistinguishable from the base platform.
This is why ONOS developer tool kit provides tools and starter code that make it very easy for developers to get started with developing their ONOS-based applications.
It should also be fairly obvious that this extensibility presents tremendous business opportunities for vendors and system integrators by allowing them to build their own differentiating value at top of the commodity ONOS platform.
I hope that through the course of the talk, I manage to convey the merits of the approach that ONOS takes with regard to constructing its highly available, scalable and high performance distributed core.
I hope that I helped you see that it is equally important to do so in a manner that it enables applications to be developed with those same attributes in order to allow robust solutions to be built.
I also hope that it became clear that the approach to abstractions for network control and configuration is one which is the most sensible in the long run, as it allows ONOS platform and applications to transcend the gradual evolution of devices and the various controller configuration protocols.
The rapid growth of the ONOS community, the influx of proposals for new features and diverse use cases, the rate at which new functionality is being developed for the ONOS platform and the number of global ONOS deployments all attest to the value of its extensibility and usability.
We see a tremendous exuberance in energy building behind this project, which I personally, find very exciting.
While we as a community have done a lot of good work in the last year and a half, there is still a vast field of opportunities for the project ahead.
I strongly encourage everyone to learn more about ONOS and use cases it enables, and to come and join the rapidly growing ONOS project community.
Have a great day, and thank you for listening.
原文发布于微信公众号 - SDNLAB（SDNLAB）