New ONOS release advances support for dynamic configuration of legacy devices, enhances whitebox leaf-spine fabric solution, and offers enhanced user interface
SANTA CLARA, Calif. April 3, 2017 – ONOS Project, the ONF/ON.Lab open source software-defined networking (SDN) OS for service providers, today announces availability of a new ONOS release now in operation in several new lab & field trials and to be featured in demonstrations at this week’s Open Networking Summit.
ONOS® is broadening its ability to bring SDN and NFV agility to mission-critical networks. By adding support for ‘incremental SDN’ alongside the ‘disruptive SDN’ capabilities for which it has been long known, ONOS can now address an ever wider array of deployment scenarios.
- Disruptive SDN: Disruptive (pure-play) SDN leverages whiteboxes and relies on ONOS for real-time network control.
- Incremental SDN: Incremental (brown-field) SDN enables software defined configuration of legacy networking systems where the control plane remains embedded in the network devices (e.g. BGP or OSPF). ONOS can now import device-specific netconf/yang models, automatically manage these models in its distributed database, and dynamically sync and apply this configuration to the network. Should the network devices ever fall out of sync with the configuration intent in ONOS’ database, ONOS will automatically bring the network back to the desired state. In this way, centralized configuration can be organized, replicated, pushed and verified on the network, enabling ONOS to support ‘incremental SDN’ deployments of brown-field networking equipment alongside disruptive SDN where full control is managed by ONOS in real-time.
Additionally, ONOS now includes a number of other major enhancements such as:
- Whitebox Leaf-Spine Fabric – the flexible datacenter fabric solution offered by ONOS has been enhanced to support IPv6 routing, vLAN tagged external interfaces and AAA endpoint authentication.
- GUI v2.0 – an enhanced Web user interface is now included, improving usability on large-scale networks by providing regional topology views with drill-down, context sensitive help, and global search
“ONOS delivers important performance and scalability advancements that are needed for service providers and enterprises to advance SDN, said Bill Snow, chief development officer, ON.Lab. “New demos and POCs at ONS this week will bring to life how ONOS enables next-generation disaggregated IP/Optical transport network solutions, and how the dynamic configuration capabilities make it easy to add innovative new services, like L3VPN.”
Additional new and improved ONOS features include:
- VLAN support
- VPLS support
Whitebox Leaf-Spine Fabric
- VLAN access and trunk ports
- IPv6 dynamic routing
- Static routes (IPv4 and v6)
- DHCP relay support (IPv4 only)
- AAA support (EAPOL – 802.1x)
- Lumentum WaveReady support (TL1)
- Pipeline support for Nokia OLT
- IPv6 support
- New distributed system support – consistent document tree
- CI/CT improvements (build speed enhancements)
- High Availability (HA) enhancements
Northbound Intent Interface Enhancements
- IETF ACTN – enabling management of multiple TEs as one
- Optional Guaranteed Bandwidth Allocation
- Protection Intent Support
- Shared resource modeling
- Hashing support for ECMP traffic distribution
- Policers and bandwidth monitoring
- Scalability improvements and regionalization support
The full list of ONOS features in the latest releases can be found here.
ONOS Use Case Example – Argela
Showcasing the power and commercial readiness of this new release, ONOS Project collaborator Argela (the research and development arm of Turk Telekom) is currently using ONOS as the network operating system for its SDN and NFV-based network infrastructure. Argela has pilot ONOS deployments at three different Turkish government institutions, in addition to Turk Telekom’s intranet. The infrastructure provides extensive centralized analytics, policy management, zero touch traffic management, enhanced topology management and complete network security. ONOS is configured to allow for a multi-layer security at the user access, data, control and application layers. Argela’s ONOS deployment provides protection to a vast variety of threats such as DDoS protection, intrusion detection, malware protection and network access protection.
ONOS Activities at Open Networking Summit
Thanks to ONOS partners and collaborators, ONF is demonstrating several new ONOS field trials, use cases and commercial deployments at ONS this week.
The ONOS Mini Summit will show how organizations use ONOS to meet their business needs through technical sessions and hands-on design workshops on application development, multi-domain environments, security, system testing, global SDN deployment and service models. More details on ONF’s ONOS Mini Summit and CORD Mini Summit are available here.
ONOS will also be featured in the SDN & NFV Solutions Showcase (S3) exhibit area with live demos on Dynamic Configuration and Packet-optical solutions made possible by contributions from ONOS members Calient, Ciena, CoAdna, Fujitsu, Lumentum, NEC, NTT Communications, OpLink and Polatis.
The rapidly growing, diverse ONOS community comprises a core engineering team at ONF/ON.Lab, as well as developers from service providers, vendors, research and educational networks spanning many industries. Future ONOS releases will focus on further development of dynamic configuration with NETCONF and RESTCONF models and services, virtualization, codebase disaggregation, and extending intent-based interfaces. This work is driven by collaboration among the ONOS Brigades, smaller teams focused on specific features that will ship in upcoming versions of ONOS.
Open Networking Lab (ON.Lab) has created the leading open source platforms CORD® (Central Office Re-architected as a Datacenter) and ONOS® (Open Network Operating System (ONOS) for service providers. Founded by SDN’s inventors and leaders to foster an open source community to realize the full potential of SDN, ON.Lab brings innovative ideas from leading edge research and delivers high-quality open source platforms on which members of its ecosystem can build solutions. For further information, visit http://onlab.us/.
The Open Networking Foundation (ONF), the recognized leader and standard bearer for SDN. Launched in 2011, the ONF has successfully taken Software Defined Networking (SDN) from obscurity to the universally accepted vision for next generation networking.
The ONF is led by a board including representation from leading operators including AT&T, Google, NTT Communications, SK Telecom and Verizon. The merger of ONF and ON.Lab is expected to be complete in late 2017. For further information visit http://www.opennetworking.org/.
ON.Lab & ONOS Contact
Chief Development Officer at ON.Lab
PR Manager at The Linux Foundation
ONF Executive Director Guru Parulkar introduces Foundation’s new game-changing Open Innovation Pipeline strategy.
Last fall, ONF and ON.Lab announced an agreement to become a single organization under the ONF name. Since that time, our aligned operations teams have been hard at work framing the go-forward strategy of the new ONF, an energizing and exciting planning initiative in preparation for our formal merger at the end of 2017.
Today, we have announced the new ONF Open Innovation Pipeline – a strategy that leverages open source platforms, network device disaggregation, and software defined standards to build high value use cases and solutions and to solidify pre-established paths for taking those solutions into operator PoCs, trials and deployment. This framework is the first and only one of its kind in the networking industry and we believe that it’s a game changing in terms of how SDN and NFV will get deployed in networks. It builds on ON.Lab’s advancements with CORD® and ONOS®, two platforms which successfully brought together operators, vendors and integrators to build solutions for carrier networks by leveraging SDN, NFV and Cloud technologies via an open source approach and disaggregated network devices in the form of white boxes. It also draws from ONF’s deep relationships with the operator community.
We understand that the SDN movement initiated by the ONF successfully set the disaggregation of networking devices and control software in motion. It has also fostered the emergence of a broad range open source platforms. We now believe that the industry needs a unifying effort to build solutions out of the numerous disaggregated components. We’re recognizing a trend – one where vendors are leveraging open source to build closed proprietary solutions – and warn that this only provides marginal benefit to the broader ecosystem. The ONF’s Open Innovation Pipeline is designed to counteract this.
Why is the Open Innovation Pipeline needed?
The SDN movement, first initiated by the ONF, has successfully set in motion the disaggregation of networking devices and control software and fostered the emergence of a broad range open source platforms. A trend has emerged where vendors leverage open source to build closed proprietary solutions, providing only marginal benefit to the broader ecosystem. Complexity still challenges many operators, who find building solutions involves the need to integrate many layers of technology, product, customization and integration.
Few players have the resources to invest in building such complex solutions. Innovative offerings have difficulty making it into operator networks because the only route to market is through closed vertically integrated “stovepipe” solutions that tightly integrate together a selection of technologies in ways that result in proprietary barriers to entry.
The industry needs a unifying effort to build solutions out of the numerous disaggregated components. An open platform and clear roadmap is needed to deliver on the promise of SDN and NFV.
ONF will also help a variety of vendors accelerate how an idea or innovation gets adopted into production networks, while operators and system integrators also stand to benefit from the Open Innovation Pipeline. The pipeline allows members of all types to bring their unique innovation and value into the solution. Operators, vendors and integrators all have a role to play, and the pipeline helps integrate these contributions into consumable solutions for operators.
How will the Open Innovation Pipeline accelerate innovation into deployment?
ONF will maintain an integrated open source platform, making it easy for new innovations to focus on where they add value. Vendors and integrators can add value and introduce offerings anywhere along the innovation pipeline. Additionally, to foster interoperability ONF will focus on developing open source interworking APIs and Models by working with the broader open source community. Additionally, data plane innovation will continue to be fostered through standards development for OpenFlow and future offerings.
Want to learn more about the Open Innovation Pipeline Strategy?
We understand that you may have questions about our new strategy. If you’d like to learn more, I encourage you to read this overview of our new Open Innovation Pipeline strategy.
And, if your travels take you to Mobile World Congress in Barcelona the week of February 27, we also encourage you to visit us at the show in Hall 5, Stand 5161 to learn more about this exciting new initiative.
– Guru Parulkar, Executive Director
By Rob Jack, Huawei
Rob Jack is the Chief Solution Architect, OSS within Huawei’s Consulting & IT Services division and has held senior OSS architecture and consulting roles for over 20 years throughout Asia, Australia, Europe and the Middle East. He served as CTO for Fastwire, a specialist Inventory Management OSS solution prior to its acquisition by Huawei in 2013 and now leads research teams in Future OSS and Orchestration, helping to build Huawei’s advanced next generation Infrastructure Enabling System (IES). The TMF Catalyst project integrated ONOS as part of it’s platform, thus we have invited Rob Jack to share more details with us in this guest blog.
The TMF (tmforum.org) has long adopted a “needs-driven” approach to developing and validating the assets which it provides to the telecommunications industry. It does this primarily via its Catalyst program, whereby teams of vendors, SIs and CSPs work together to lead research on a particular business problem.
While many of the core TMF assets such as the SID Information Framework, or Business Process Framework are familiar to many in telecoms, they are perhaps associated with the development and integration of traditional OSS/BSS. More recently the TMF has been leading the OSS/BSS industry in developing new capabilities and assets towards the virtualization of networks and telecom services, with a number of programs in place towards this, including the ZOOM (Zero Touch Operations Orchestration & Management) project. ZOOM’s particular focus on SDN/NFV has tackled many challenges being driven from Telco digitization, and a number of TMF Catalyst projects are operating within ZOOM towards better defining the needs for new concepts and associated standards within this exciting field.
A Future Focused Team and Operating Model
One of those projects, termed “Future Mode of Operations: Model-Driven Service Orchestration for Hybrid Networks” is led by Huawei with participation from vendor partners including Inspur and, in first phases, IBM. The project was championed by Orange and China Mobile, who provided a business requirement of using a modern orchestration architecture to achieve on-demand scale-out of a combined physical/virtual network during peak mobile traffic scenarios: such as stadium events or similar “tidal effect” traffic peaks in the mobile core network. The scenario demanded the use of VoLTE, and associated EPC and IMS infrastructure.
Mirroring the roll-out of NFV, the team chose to develop the scenario from standard physical infrastructure to a 4G VoLTE network, including elements such as S/PGW within the EPC and S/P-CSCF within the IMS domain. In addition, an NFV MANO provided by Huawei created access to a VNF form of the S/PGW, is becoming created, onboarded and ready for scale-out on demand.
The final piece of the puzzle was provided by partnership with ONOS. Following a workshop held after a visit from the Catalyst project team to San Jose in July 2015, a team from the ONOS Project worked to provide access to Intent APIs based around the Huawei IPVPN extensions to ONOS core. This allowed the Catalyst to achieve the second element of the hybrid orchestration proof of concept – on-demand scale-out of the IPVPN core transporting the VoLTE sessions.
The team has since worked together through three iterations of the Catalyst project, with a main focus in each phase on:
- ‘Tidal Effect’ Traffic Hybrid Orchestration for VoLTE scale-out
- Policy usage in tidal effect scenarios
- Cost-based policy in multi-VAS and IoT slice orchestration
Moving to a Cost-Driven Decision
This latest iteration of the Catalyst has seen use cases from Orange and China Mobile resulting in a partnership approach to the solution as shown below:
In the mVAS scenario, ONOS is being called by a policy-based orchestration to build or scale IP-VPN based services such that any OpCo (local operating company) of an international CSP can leverage a multi-VAS service hosted at a centralized, cloudified location supporting VNF-based services.
The policy used in this scenario goes beyond the standard Event Condition Action (ECA) policies typically used today to drive many QoS based network intent rules, such as: “if Local VAS utilization goes above 80%, trigger a scale-out of VPN and use mVAS capability.” Here, the Huawei Orchestration component is using Goal and Utility Function policies – the latter can assign a cost (derived from financial metrics of CAPEX and OPEX) to first determine whether the scale-out is economical. Goal policies of ensuring overall customer experience can go hand-in-hand with the Utility Function and lower-layer ECA policies to ensure that an organization’s overall operating model can be encapsulated and automated.
Leveraging Intent with Open OSS APIs
The Intent APIs presented by ONOS represent a key advantage in ensuring that such an approach can be made to work without involving onerous software engineering or configuration to match and breakdown such goals into highly procedural API calls. Using these, the team was able to successfully and simply create orchestration across this complex hybrid domain. Further, these types of scale-out intents lent themselves well to modelling within an intent- model Service Catalog. The Service Orchestration system was able to include abstracted specifications of the types of virtual link services available within ONOS in its own Service Catalog, and associate those to the capabilities and capacities (again expressed abstractly) in physical and virtual domains to allow decision processes in orchestration to operate automatically.
Beyond the ONOS-based capabilities, the Catalyst has demonstrated API-based solutions and developed new standards assets through the collaboration for (among others):
- Multi-domain Catalog federation, including usage of TOSCA templates for NFV services
- A Dynamic Inventory, including federated and Topology API capabilities
- Usage of B2B2X APIs to support partner inter-operation for VAS or IoT services
Kicking Goals, Moving Forward
Over the first two phases the Catalyst was awarded twice by an independent panel of judges. At Dallas in 2015, the project received the “Best Adoption of Frameworx”, while in Nice earlier this year it was awarded for “Greatest Contribution to Accelerating Digital Business”.
This month, the latest phase will be demonstrated at TMF events in Dallas and Singapore, and once more the contribution from the ONOS project will be key to showing a complete model-driven service orchestration for hybrid networks.
The Catalyst team acknowledges this great contribution from ONOS, and is hopeful that this collaboration between the open source world and standards organizations like the TMF continues to improve on the increasingly rapid turnaround between standards development and proven solutions that is needed to drive the real-world, mass-scale adoption of virtualized infrastructure.
If your company is a TMF member, and you would like to learn more about the project or the Catalyst program, please feel free to contact the TMF directly through firstname.lastname@example.org or via https://www.tmforum.org/collaboration/catalyst-program/catalyst-program-benefits/
Learn about the ONOS Deployments Brigade from Luca Prete, MTS ON.Lab:
Q: Luca, please tell us a bit about yourself and role within ONOS.
A: As an SDN enthusiast, I joined ON.Lab in 2014 before the open sourcing of ONOS. I earned a bachelor’s degree in Computer Science in Milan and a Masters in Internet technologies from the University of Pisa. I’ve been involved in computer science consulting since 2005, with a particular focus on systems and networks. Since 2012, I’ve collaborated with the Italian NREN in the R&D department, researching SDN and cloud computing systems deployments. At ON.Lab, I currently lead deployment activities.
Q: Briefly summarize the Deployments Brigade’s team, scope, goals, and any notable progress to-date.
A: The goal of the Deployments Brigade is to make ONOS-based SDN deployments easy and production-ready. During our current ONOS/SDN deployments in R&E Networks around the world, we learned a basic set of features the network operators ask for, and as a brigade we want to make it available and easy to deploy.
More specifically, we’re developing a software stack on ONOS that will allow Operators to provision on-demand Layer2 VPNs and exchange L3 routes, both over a convergent packet-optical network. We’re trying to make the stack support the most recent standards and protocols used by Service Providers and Research and Educational Networks today, such as the MEF standards – for the creation of L2 VPNs (E-LINE and E-LAN), and the NSI protocol for the provisioning of resources among multiple administrative domains.
I knew network operators really wanted such a stack and features, but when we saw the number of people from the Partners and the Community asking to participate, I was really impressed and happy. The brigade currently comprises 18 active developers from Service Providers, Vendors, RENs and Academia, while the mailing list has a broader audience including Managers and Executives.
As many know, each brigade should meet for the first time within the September-October timeframe to have the opportunity to share requirements, ideas, work together, and – why not – have some fun. Having people with different backgrounds and expectations might be challenging. The initial goal was to discuss requirements, define tasks, go through the initial design phases together, and possibly start to code. Exceeding my expectations, in one week, we defined requirements and tasks, we talked about the solution design, and we coded a full working solution in answer to our first use-cases: being able to manage VLAN tags in SDN-IP and run together applications to provide on-demand Layer2 and Layer3 services (VPLS and SDN-IP). Additional code under review will enable more new features; soon VPLS will be able to associate in the same network interfaces using different VLAN IDs, as well as different tag types, such as MPLS tags, VLAN IDs, and so on. The Intent Framework will natively support bandwidth provisioning and enforcement, and the VPLS app will be able to use it, opening a completely new set of use-cases.
Q: Has the Deployments Brigade team developed any best practices, or do you have any advice to share with the other Brigades to optimize collaboration leading into the ONOS Developer Summit?
A: The work week and the preparation leading up to it was very educational.
Arriving prepared to the working week is fundamental: goals should be clear, a basic backlog should be in place and the staff of ON.Lab should be prepared to dedicate time to the team, to answer questions and work with them.
People will have different backgrounds and will already have different opinions, ideas, requirements. If things above are not well prepared, you’ll probably just add confusion to the group.
It’s fundamental to put the right balance between presentations, interactive design discussions and practical work – meaning coding. The week together is not a conference, it’s not intended for executives. It’s for developers. You don’t want to see people of your group become passive listeners, get bored with lots of presentations. It’s also important that everyone has the chance to fully express her/his ideas. This can be achieved through interactive discussions.
It is important for people to walk away from the working week at ON.Lab with some concrete work in progress. While I may have difficulties starting a coding task from scratch once back to my daily job, If I were to start a task at ON.Lab with a concrete idea of how things might be done and help from core developers, I would feel excited and fully involved looking forward to bringing the task to completion.
Lastly, the social aspect shouldn’t be forgotten. This has been at least as important as coding for the success of the project. I’ve personally noticed a huge difference between the first day of meeting and the next days. After team bonding, people were better able to comfortably interact. This was true both for external contributors and for internal people at ON.Lab.
Q: How can people get involved with the Deployments Brigade?/Any call-to-action?
A: There are many ways people can get involved. As a geographically distributed group, we use online tools, and we want to make sure they all remain up to date as much as possible.
Basic information about our brigade can be found on the ONOS Wiki at https://wiki.onosproject.org/display/ONOS/Deployment+brigade. This contains anyway the main other pointers I’m giving here, and tells you how to get involved.
Our backlog, a list of current tasks and their current progress can be found on our Agile tool platform, at https://jira.onosproject.org/secure/RapidBoard.jspa?rapidView=1&view=planning.nodetail
We also have a public mailing-list we use to talk one each other, which is public. The address is email@example.com. If you’re interested in looking at the old conversations, the archive is available at https://groups.google.com/a/onosproject.org/forum/?hl=en#!forum/brigade-deployments
I’ll close with expressing how happy and satisfied I feel when I see how much has been done by the deployments brigade, and how much is also going on. I guess this is the demonstration of the potential of such initiative, that – hopefully – will continue to produce better and better results.
In an effort to advance collaboration among the rapidly growing open source ONOS community, align on vision for the project, and concentrate efforts around developing key ONOS features that will benefit the community as a whole, five ONOS Brigade teams have formed. All are invited to participate in the ONOS Brigades.
Patrick Liu, ONOS Technical Steering Team member and lead of Huawei’s ONOS open source team, is heading up the Dynamic Configuration Brigade with collaboration from others within Huawei, Fujitsu, OpLink, and ON.Lab. Patrick is seeking additional members of the community to join the Dynamic Configuration Brigade. Learn more about their efforts below, and join the discussion on the onos-dev list.
Liu: Let me briefly introduce myself. For the past three years I have been leading an open source development team in Huawei across North America, China, and India. This team has been actively contributing to ONOS and OPNFV. For the rest of this year, I will be leading Dynamic Configuration (YANG based) project for ONOS. It will be my and my team’s top priority. We want to work with the rest of community as part of ONOS Dynamic Configuration Brigade.
This brigade is focused on a few areas of ONOS.
- On SB, our goal is to allow a network operator to automatically discover and activate devices from any vendor into its network as long as the device exposes a Yang Model. We will build a service and vendor agnostic driver into ONOS. This driver provides a mechanism for operator, integrator, vendor, etc., to quickly hook a new device to the ONOS controller through modifying the driver configuration file (.xml) rather than modifying JAVA code. This provides an agile way to enable and activate NETCONF-enabled devices.
- On NB, our goal is to allow a network operator to use service definitions in Yang and enable configuration and provisioning of devices in support of the service models. We will build a corresponding application and provide configuration interface for users to install, update, and remove configuration dynamically. We will use L3VPN as our example service to guide this development.
- In ONOS Core, we will build a Configuration Store that will store all device and service configuration models. The configuration Store will use ONOS latest distributed primitive called DocTree store leveraging ONOS clustering. This is a distributed data store, which will provide transactional operation to applications doing read/write/update/delete operations on the Configuration Store.
We are currently building a brigade team for this project. Current members are from Fujistu, Huawei, OpLink and ON.Lab. We still need more resources including 1-2 developers, 1-2 QA engineers, and 3-5 Vendor’s devices with device models ready for an exciting multi vendor demo.
To learn more, visit the Dynamic Configuration wiki page.
Interested in joining an ONOS Brigade? Please check out this recent blog post to get a quick introduction to each of the ONOS Brigades.
Authors: Raghu Gangi, Manjunatha Hethur, Mukesh Kumar and Vishvesh Deshmukh, ADARA Networks
With the announcement of ONOS Hummingbird release, Networking has taken a truly significant step forward. Software Defined Networking was conceived to address networking that had become petrified due to proprietary technologies and vendor lock-in; that model has begun to recur in Controller architectures. As evidence of this Network Control Applications are increasingly tied to specific vendors, and Controllers; these applications are often purposefully not interoperable between Controllers. This is why ONOS, a community based Open System, designed by and for the Service Provider, and consequently for their Enterprise, Residential and Mobile customers, is so inherently important.
These and other issues illustrated the need for Controller enhancements which enable multiple Network Control Applications to work on an Open System Controller Framework; ONOS, developed for and by Service Providers’ and partners to operate in the most challenging heterogeneous environments was the correct platform for such an enhanced capability.
The ADARA contribution of an Enhanced ONOS Message Queue implement support for Real Time External Events, including Topological, Link, Device, Packet events which accelerate the drive to an industry wide goal for ONOS; to achieve the greatest level of functionality in the spectrum of Open System options. These enhancements are implemented as an ONOS Application, as a key part of the ONOS code-base, and they come pre-staged as part of the ONOS distribution, and as part of an ADARA ONOS distribution and as a selectable ONOS feature.
ADARA enhancements to Rabbit MQ
The enhancements to the Rabbit Message Queue are implemented to expose the ONOS Controller to an expanding universe of current and future Networking Applications; doing so greatly enhances the utility of ONOS in a myriad of deployment models, and use cases. The gateway role served by the Message Queue between ONOS and valued added Network Applications external to the Controller facilitates rapid development by a much wider ecosystem of contributors, and is an important step in increasing ONOS dynamism in response to Real Time conditions and ONOS capabilities for Service Providers. Now Application’s such as Multi-Layer Multi-Constraint Packet Optical Performance Based Path Computation Engines, Real Time Bandwidth Calendaring Applications, Intelligent Workload Placement Engines, and Customer Portal Fully Automated Service Creation and Provisioning Engines are all possible and all within our reach. The ADARA contribution of an Enhanced ONOS Message Queue opens the ONOS System to External Networking Applications of all types by implementing support for Real Time External Events to communicate with ONOS:
ADARA Supported Events:
- Device Event
- Device Added
- Device Removed
- PORT Up
- PORT Down etc
- Link Event
- Topology Event
- Packet Event
The Message Queue is especially important in ONOS; it enables gateway like behavior for external Network Control Applications; this is a critical function as its’ role is to enable a large set of current and future Network Applications to interact with ONOS to support Use Cases for Service Providers and their Enterprise, Residential and Mobile customers. The Message Queue Framework in ONOS Hummingbird now has new features that improve interoperability, enabling many applications to interact with the Northbound protocol through message bus integration and support the industrywide move to services as network primitives.
Applications and New Real Time External Event Capabilities enabled by ADARA enhancements for ONOS Hummingbird
As Network Control Applications are increasingly tied to specific vendors and Controllers, due to their design, implementation and functionality, they recycle the issues of legacy Best Efforts networking into SDN architectures. Legacy infrastructures are typically statically configured; Controller architectures by design are intended to support dynamic configurability. In legacy networking, once a forwarding decision has been made, it cannot be revised until it expires; with SDN Controller systems, we natively alter packet flows during forwarding; this underscores the importance of Network Control Applications, the Message Queue, and the enablement of support for Real Time External Events. Controller based Networking enables dynamic routing and Traffic Engineering; previously, this was suboptimal as legacy routing protocols do not support dynamic weights or links.
By coupling support for External Events with Multi-Layer Performance Measurement, Calculation, Forwarding and Resource Allocation, we enable ONOS to expand its’ capabilities with myriad Applications with wide ranging, novel emerging functionalities. This enables Multi-Layer Multi-Path, Multi-Constraint Performance Based Path Computation Engines capable of calculating Network selection’s based on multiple constraints such as Real Time Bandwidth, Latency, Link Quality, Utilization, Spectrum, and Reach, in Multiple Networking Layers with constraints’ specific to Packet, MPLS, WDM, OTN layers. Multi-Layer dynamism with Real Time Performance Based Path Computation deployed in Central Offices enables automated creation of services, enabling Automated Circuit creation with defined constraints and service types through User Portals. Automated Real Time Bandwidth calendaring to support both planned / predictable and unpredictable bandwidth demands; enabling Real Time Service for scheduled temporal reservations for backups and gaming, along with unscheduled demands for bandwidth that are in excess of capacity, typically these services are intolerant to delays. This support for Real Time External Events supports Intelligent Workload Placements of VNFs in Central Offices and Cloud Data Centers. In these and other scenarios, the ability of a Real Time External PCE Application to react to Virtual and Physical Packet Events along with Topological, Link, Device, State, Configuration Events and Multi-Layer Performance changes would enable the Path Computation Engine and the ONOS Controller to return many more options than initially requested, with all options meeting the required constraints.
Why do we need MQ messaging?
Message queues enable asynchronous communication between the sender and receiver. Messages placed onto the queue are stored until the recipient retrieves them. Message queues have implicit or explicit limits on the size of data that may be transmitted in a single message and the number of messages that may remain outstanding on the queue.
What are the uses of MQ messaging?
In a typical implementation, a system administrator installs and configures message-queueing software (a queue manager or broker), and defines a named message queue. Or register with a message queuing service.
An application registers a software routine that “listens” for messages placed onto the queue.It may connect to the queue and transfer a message onto it. The queue-manager software stores messages until a receiver connects. The receiving application shall process the message in an appropriate manner.
There are often numerous options as to the exact semantics of message passing, including:
- Durability – Messages may be stored in memory, written to disk, or even committed to a DBMS if the need for reliability indicates a more resource-intensive solution.
- Security policies – Provides access control for application while accessing message
- Message purging policies – queues or messages are purged after the expiry time
- Message filtering – Messages queues support filtering data so that a subscriber can only see messages matching some pre-specified criteria of interest
- Delivery policies – Guarantees that a message is delivered at least once, or no more than once based on policy
- Routing policies – Defines what servers should receive a message or a queue’s messages.
- Batching policies – Defines the policy for bundling multiple messages.
- Queuing criteria – Defines when a message be considered “enqueued”? When one queue has it? Or when it has been forwarded to at least one remote queue? Or to all queues?
- Receipt notification – Provides acknowledgement when all recievers receive the messages.
- All above considerations can have substantial effects on transaction semantics, system reliability, and system efficiency.
How RabbitMQ fits into existing ONOS container
The ONOS ADARA RabbitMQ module was designed and developed to support deployment as an independent module inside ONOS container. It can be built as a separate module; it can be installed / uninstalled independently from ONOS container without any impact on a running ONOS instance.
These and future enhancements will position ONOS to leverage new capabilities at an accelerating pace from industry-wide contributions to support Service Providers and their Enterprise and Residential Customers. ONOS has commenced writing a very exciting new chapter in Networking.
We had the chance to sit down with Huawei’s Bill Ren, ONOS Board Member, VP of Huawei fixed network industry & ecosystem development, to discuss the progress of the ONOS® Project this past year.
Dedicated to building a Better Connected World, Huawei Technologies Co. Ltd., is a founding member of the open source ONOS community and a leading global information and communications technology solutions provider. Through open collaboration, Huawei has established a comprehensive ICT portfolio of end-to-end solutions in telecom and enterprise networks, devices and cloud computing.
Here are the insights he had to share:
Tell us about yourselves and your participation in the ONOS Project.
Ren: This is my first year as an ONOS board member for Huawei, a founding ONOS member that has contributed to various areas of the ONOS Project including, technical code committing, architectural defining, community supporting, market promotion, training and ecosystem development.
Early this year I was appointed as VP of industry and ecosystem development in charge of SDN open source and ecosystem development. I’m pleased to sit on the ONOS Board representing Huawei. In my past 17 years with Huawei, I have been working on many real network deployment projects in Europe and Asia and have had the chance to talk with many tier 1/2 operator customers. I hope my experience will bring benefits to my new position and also to ONOS project.
Before coming to this role, I started as an EMS/OSS developer, architect and product manager. I have worked as a product management director in charge of Huawei fixed network SingleOSS strategy and product management for many years. Then I served as director of solution management for two years mainly focused on SDN solutions.
What do you think about ONOS progress so far?
Ren: We’re pleased to see that ONOS continues to issue new releases on a quarterly basis. Each release successfully delivers new features and prioritizes the top use cases, such as SDN-WAN, SDN-IP, Transport Network, and VPN. This is an excellent cadence for releases, and Huawei has enjoyed being involved in many of them, including the most recent release of Hummingbird.
The ONOS Project is exceptional. It has a fully dedicated group of engineers collaborating and contributing to the project. The project will continue to grow and succeed as new companies join the initiative and contribute to the ONOS code.
We have also seen tremendous growth in just the past year, both on the partner side and with more than 50 collaborators actively contributing to the development of ONOS. We look forward to the continued build out of the Ambassador program, which is creating new avenues in localized time zones for training, contributor recruitment and collaborative best practice sharing.
How is Huawei incorporating ONOS into its products and solutions?
Ren: Huawei just launched the first full-scenario Agile Controller 3.0 (AC 3.0) in the industry at HUAWEI CONNECT 2016, based on ONOS. We recently contributed a blog about AC 3.0. Click here to read more about it.
Tell us about the process for contributing to the ONOS code?
Ren: First of all, I believe we need a common open source SDN controller platform to move the whole industry ahead. I believe ONOS is the right platform for the whole industry for collaborating and building commercial solutions. Huawei has hundreds developers working on SDN controller and Huawei have many marketing managers working face-to-face with our customers, collecting requirements from real projects, which will drive our product development. We generate many codes every day. I have a small SDN open source developer team contributing ONOS code. This team is led by Patrick Liu. Basically, code comes from our commercial product team and is adapted to the ONOS style. We carefully define which part should be contributed to the industry common platform and which part should remain proprietary for vendor differentiation. At the current stage, we see there is a lot of space for contributing to move ONOS as a full scenario controller platform.
Huawei recently hosted an ONOS bootcamp in Beijing. How did it go?
Ren: Huawei, together with ONOS Project and a few other partners, hosted two ONOS camps in China this year.
ONOS Boot Camp, OPIC and SDN/NFV Alliance Summit in Beijing, China
We hosted the first boot camp in April in Beijing, co-located with China SDN/NFV congress.
In April 2016, experts from around the world gathered to discuss how to further develop the SDN/NFV industry in China at the China SDN/NFV Conference 2016 and Huawei hosted the World’s First ONOS Boot Camp and Hackathon in Beijing, China.
During the event, ONOS provided training for more than 40 personnel from major carriers and research institutes in China. The camp was designed to help the group overcome SDN/NFV challenges and evolve carrier networks.
The boot camp also featured a “hackathon” for students to build ONOS-based applications. The students who passed the certification exam and successfully developed the application were awarded ONOS Association Certification. Hackathon group winners were also awarded various prizes.
Leaders from ONOS, SDN/NFV Industry Alliance, and operators all attended the opening ceremony of the boot camp. Huawei was a strong supporter of the event, in addition to the more than 40 participants from three operators, research institutions and universities who attended the event.
ONOS at Huawei Connect in Shanghai, China
On Aug. 30, together with ONOS, SDN/NFV Huawei hosted the second ONOS camp. Fifty people from carriers, startups, institutes and universities attended this boot camp. Thirtyfive of the attendees successfully passed the ONOS certification exam and earned their proof. This boot camp is also supported by SDN/NFV Industry Alliance and SDNLAB.
On Sept. 1, Huawei hosted the First ONOS Asia Mini-Summit. In total, the summit hosted 11 speakers from China and Korea. Experts from China Unicom and China Telecom shared their ONOS experience on the carrier network. Speakers from Beijing University of Posts and Telecommunications, Future Network Innovation Institute and Korea Institute of Science and Technology Information also shared about ONOS deployment in R&E networks. Huawei shared AC 3.0 SDN controller architect best practices. I also shared my thinking and outlook on the SDN open source community.
What’s next for Huawei and ONOS?
Ren: Huawei has launched our ONOS-based AC 3.0 controller, which is just the beginning. We will move on to enhance our products and test and trial our solutions in field networks. Meanwhile, Huawei will go on to bring new experience and knowledge to the ONOS community, contribute more codes, and work closely with the ONOS core team to enhance the ONOS platform, including the performance benchmarking test. As I said before, we need a mature and common open source SDN controller platform and we will go on working for it.
On Sept. 1, 2016 at Huawei Connect 2016, Huawei launched the networking industry’s first ONOS-based full-scenario Agile Controller 3.0 with a media round table event. The room was packed with attendees from a total of 20 representing media, including: CWW, CCTime, Communications Weekly, PPTN, Packet Pushers, SDxCentral, Light Reading, among others.
The event was hosted by Liu Shaowei, President of Huawei Enterprise Networking Product Line; Huang He, General Manager of Huawei SDN Controller Domains; and, Bill Xudong Ren, ONOS Board Member, VP of Huawei, Fixed Network Industry & Ecosystem Development.
The Agile Controller 3.0 (AC 3.0) focuses on four business scenarios (enterprise campus, data center network, WAN, and IoT) and provides capabilities such as on-demand network resource pool reservation, automatic deployment, intelligent optimization and bandwidth adjustment on-demand for enterprise customers across campuses, carriers and data center networks. This can improve the resource scheduling efficiency of enterprise cloud services, improving the network efficiency for carrier customers and providing the best customer experience possible.
Based on the open ONOS platform, the AC 3.0 uses an application which has loosely coupled architecture and can be integrated with ODL and provides abundant northbound API capabilities.
Huawei advocates an ‘All Cloud’ strategy and provides cloud-based products and solutions to help customers achieve digital transformation in their operations.
AC 3.0 provides leading SDN solutions for all four business scenarios:
- Data Center Network
- Enterprise Campus
Strength I: Full-scenario control, distributed and combined
AC 3.0 supports a variety of unified control and flexible deployment of business scenarios, to meet the diverse needs of business and operational maintenance.
Strength II: Automation across the whole network, super speedy deployment
Resources access from the whole network based on demand, automatic deployment, intelligent tuning, and realize a variety of commercial business scenes with speedy deployment.
Strength III: Open source, rapid integration
Additionally, AC3.0 is based on the open ONOS platform, has loosely coupled architecture, is compatible with ODL, and supports rapid business innovation.
Carriers: AC 3.0 allows carriers to establish e-commercial network operation platforms, achieve top speed service provisioning and on-demand value-added service customization, build agile and open networks on demand, accelerate digital transformation, and add pipe values.
Enterprises: AC 3.0 accelerates the digital transition from a network support system to the production.
Industries: AC 3.0 provides massive capacity of the network management, and helps industries achieve open IOT data.
SDN Global Commercialization Progress
Huawei has participated in more than 200 projects in SDN domains with carriers and enterprises. This included projects with Telefonica, China Mobile, China Telecom, China Unicom, Telia, Tencent, Alibaba, China Construction Bank, China Southern Power Grid Company Limited and Vision China Media. Projects covers WAN, Data Centers, Enterprise Campus and IOT scenarios.
As of Sept. 6, the AC 3.0 media round table event garnered coverage in more than 40 media outlets. To learn more about AC 3.0, click through the links below for noteworthy articles of coverage stemming from the media round table event.
TechTarget: (German) http://www.searchnetworking.de/news/450303757/Huawei-stellt-Agile-Controller-30-vor
IT168 (Chinese): http://net.it168.com/a2016/0902/2895/000002895739.shtml
IT168 (Chinese): http://net.it168.com/a2016/0907/2904/000002904743.shtml
caijing.com.cn (Chinese): http://tech.caijing.com.cn/20160905/4172057.shtml
Open source SDN is a “hot” technology, with development being driven by a wide range of commercial and non-profit entities. 2015 is emerging as the year when open source SDN starts to move from the lab to widespread deployment for production networks. This transition from development to deployment brings questions of stability, scalability, and security to the fore. If 2015 is the year when open source SDN goes mainstream, then 2015 is the year that we need to identify and resolve security flaws in SDN controllers and switches.
Traditional networks conflate the control and data planes on a physical device, which typically consists of proprietary hardware and software. Software-defined networks factor the control plane out to a SDN controller. The controller uses a protocol such as OpenFlow to control switches, which are now only responsible for handling the data plane. From a security perspective, this division of responsibility has both advantages and disadvantages. The ability to easily segregate the control plane network from the production data network is an obvious advantage. The SDN controller’s ability to control an entire network makes it a very high value target, which is a potential disadvantage compared to a traditional network with a more distributed control plane.
In addition to the control plane administration interfaces exposed by the SDN controller, it has another attack surface: the data plane of the switches it manages. When an OpenFlow switch encounters a packet that does not match any forwarding rules, it passes this packet to the controller for advice. As a result, it is possible for an attacker who is simply able to send data through an SDN switch to exploit a vulnerability on the controller.
As SDN has begun to emerge as a mainstream technology, it has drawn the attention of security researchers. In the last few months, several new vulnerabilities affecting open source SDN controllers have been reported. We’ll look at three in particular that demonstrate the SDN attack surface, and provide examples of the kind of issues we’re likely to see in the future.
1) XML eXternal Entity (XXE) vulnerability in OpenDaylight netconf (CVE-2014-5035)
In late 2014 an XXE flaw was found in OpenDaylight’s netconf interface. Netconf allows for network configuration changes to be instigated using an XML vocabulary. OpenDaylight’s netconf implementation did not disable external entities when processing user-supplied XML documents, thereby exposing an XXE flaw. This is a very common flaw in server-side processes that handle user-supplied XML, and is particularly common in Java applications. A remote attacker, if able to interact with one of OpenDaylight’s netconf interfaces, could use this flaw to exfiltrate files on the OpenDaylight controller. This could include configuration details and plaintext credentials.
For an attacker to exploit this flaw, they need to have access to a netconf interface, which is part of the control plane. Strong access controls for control plane interfaces will greatly reduce the impact of flaws of this nature. To maximize their effectiveness, these access controls should be enabled by default. For more details on this flaw and how to apply a patch, see: https://wiki.opendaylight.org/view/Security_Advisories#.5BImportant.5D_CVE-2014-5035_netconf:_XML_eXternal_Entity_.28XXE.29_vulnerability
2) Denial-of-service (DoS) when deserializing malformed packets in ONOS (CVE-2015-1166)
In early 2015 an interesting DoS flaw was reported to the ONOS project. As mentioned earlier, when an OpenFlow switch encounters a packet that does not match any forwarding rules, it passes this packet to the controller for advice. It was found that the packet deserializers in ONOS would throw exceptions when handling malformed, truncated, or maliciously-crafted packets. The exceptions were not caught and handled, which would result in the relevant switch being disconnected because an exception occurred in an I/O thread. A remote attacker could use this flaw to perform a DoS attack by causing ONOS to disconnect switches.
For an attacker to exploit this flaw, they only need to be able to send malicious crafted packets through a switch controlled by ONOS. This is an example of how the data plane can be used to exploit a vulnerability on the controller. For more details on this flaw and how to apply a patch, see: https://jira.onosproject.org/browse/ONOS-605
3) Topology spoofing via host tracking
In mid-February 2015, another interesting flaw that can be exploited via the data plane was reported. Most SDN controllers include host tracking, allowing hosts to migrate between different physical locations in the network. This host tracking functionality is based on monitoring of Packet-In messages, and does not require any validation, authentication, or authorization. This makes it possible for an attacker to impersonate a host and make the SDN controller believe it has migrated to a physical network location controlled by the attacker.
For an attacker to exploit this flaw, they only need to be able to send malicious messages through a switch controlled by an SDN controller. The only prerequisite is that the attacker must know the MAC address of the target host. For more details on this flaw, see: http://www.internetsociety.org/sites/default/files/10_4_2.pdf
Same same, but different
It is worth noting that while the three vulnerabilities discussed above are new, none of them are particularly novel. XXE is a very well established issue that has affected dozens of Java-based projects. DoS attacks based on triggering an unhandled exception are also common and well established. The topology spoofing flaw is novel in a sense, but it is closely related to MAC spoofing, which is a very old and well-known issue (http://en.wikipedia.org/wiki/MAC_spoofing). This highlights that while SDN is a new and novel technology, it is still just software, and a relatively small number of fundamental issues represent the vast majority of security flaws. As a result, applying tried and true countermeasures is likely to be effective for many of the security flaws that will affect SDN.
The most important countermeasure for security flaws in any software project is an effective security response process. This process should be run by a dedicated team who can handle reports of security flaws discretely. At a minimum, a security response process should provide the following:
* A private channel for people to report security flaws
* The ability to drive the preparation of patches without any details of the flaw becoming publicly visible
* The ability to ship patches quickly
* Clear and concise advisories that communicate the impact of flaws to users, and provide details on how to apply patches
ONOS has now implemented a security response process, which is an important first step. For more details, see: https://wiki.onosproject.org/display/ONOS/Security
Security response is reactive: a flaw is found, and it is addressed by a patch and a corresponding advisory. Of course, it is preferable to address security flaws in a proactive fashion. Several open source projects are now underway that aim to improve the security of SDN controllers, and limit the ability of an attacker to exploit any flaws that become known. We’ll look at two of these projects.
1) Security-mode ONOS
Security-mode ONOS is a new feature that is targeting the upcoming ONOS ‘Cardinal’ release. It is effectively a mandatory access control (MAC) implementation for ONOS applications. Applications can be constrained by a policy dictating which actions they are permitted to perform. This is an important development, as it means that a vulnerability in an ONOS application could not be exploited to perform actions that are not permitted by security-mode ONOS. This is similar to the protection SELinux provides for applications running on Linux systems. For more details, see: https://wiki.onosproject.org/display/ONOS/Security-Mode+ONOS
The same research team that reported the topology spoofing flaw noted above also developed a tool to mitigate it, called Topoguard. It works by verifying the conditions of a host migration. A legitimate host migration would involve a Port Down signal before the host migration finishes. It would also mean that the host would be unreachable at its old physical network location after the migration is complete. Topoguard verifies host migrations by ensuring that these conditions are met, effectively mitigating topology spoofing via host tracking. Topoguard is currently tightly coupled to the Floodlight controller, but it could be ported to other controllers. For more details, see: https://github.com/xuraylei/floodlight_with_topoguard
When I first became involved in the open source SDN community in November 2014, very few meaningful security measures were in place. Since then, the community has started to audit SDN controllers and report flaws, security response processes have been documented and security response teams formed, and powerful defensive technology is starting to be developed. This is a very impressive and encouraging pace of development, and in my opinion open source SDN controllers are on track to provide that level of security that they need to go mainstream.
There are two thorny security problems that open source projects have struggled to handle, and I think ONOS and the wider open source SDN community is now in a position to tackle them.
1) Coordination of vulnerability disclosure
When multiple commercial vendors support a given project, each is incentivized to hold information about security flaws that the other vendors do not. This can be a major source of conflict. It is important that projects are able to coordinate the disclosure of vulnerabilities to all stakeholders simultaneously, without details leaking prior to an agreed upon embargo date.
2) Proactive secure engineering
The defensive technologies discussed above limit the ability of an attacker to exploit flaws, but they do not minimize the risk of security flaws entering the code base in the first place.This can be achieved by implementing measures such as the following:
- Establishing automated QE/CI jobs to catch security flaws and regressions.
- Establishing automated QE/CI jobs to catch known-vulnerable dependencies.
- Documenting a threat model
- Improving documentation to capture security best practices at installation and configuration time
I would like to challenge the vibrant and growing open source SDN community to tackle these problems. I’m ready and willing to help, so please reach out to me at firstname.lastname@example.org if you’d like to get involved.