Tag Archives: ONOS

[Update #3] Registrations are now open for ONOS Build 2017!


We’re thrilled to announce that registrations at ONOS Build 2017 are now open!  You can register directly on the event website: http://onosbuild.org/register/

Registration is FREE if you are already actively involved in the ONOS project as a code contributor, brigade member or Ambassador, or if your organization is a member of the ONF. We will also waive the registration fee if you have submitted a participation proposal for a “Community Showcase” or an “SDN Science Fair” poster and you have been accepted (see below). Finally, we offer a 40% discount for general and student registrations made before August 1st.

Call for Participation

As we mentioned in our previous ONOS Build 2017 update, the event’s success is entirely dependent on the community’s participation. There are three ways you can participate as a speaker or presenter:

  • Community Showcase

The Community Showcase is a series of talks, presentations and demos by partners, collaborators and contributors of the ONOS Community. On day 1 and 2, the focus is on ONOS and on day 3, the focus is on CORD as an ONOS Use Case

  • SDN Science Fair

If there is an awesome SDN project you’re working on or if you are working on an experiment or idea that needs feedback or testers, you’ll have your chance to show off what you’re working on and get feedback from SDN experts from all over the world during ONOS Build’s SDN Science Fair.

Exhibitors at the fair will be able to either set up their laptops and demos at small booths or hand a poster during lunch time, while everyone else can wander around the space, stopping to chat, watch demos, ask questions. Prizes will be awarded to the best projects, as voted by conference attendees.

  • Hackathon

The ONOS Hackathon will be an event spanning the length of the conference where participants will develop a new feature for ONOS. The new feature could be as simple as a new small application on ONOS or a new subsystem within ONOS. Best of all, some really cool prizes will be on offer for the top three teams, voted by conference attendees.

Submit a proposal today

If you’re interested in giving a talk at the “Community Showcase”, in presenting an inspiring SDN-related project at the “SDN Science Fair” or in participating in the “ONOS Hackathon” to win a cool prize, make sure to visit website’s participation page to submit a proposal: http://onosbuild.org/cfp/

Help sponsor the event!

Another very important way you can participate in ONOS Build 2017 is as a sponsor. We welcome all organizations who are interested in supporting us as we aim to offer a first class event for our community, while at the same time providing travel subsidies to ONOS contributors around the world who would not be able to attend the event otherwise.

If your organization is interested in becoming an official sponsor, please visit the sponsor page here: http://onosbuild.org/sponsors/

And as always, if you have any questions, make sure to contact the ONOS Build event team at onos-build [at] onlab [dot] us or directly on our Slack channel.

Photo credit

Guru Parulkar Guest Post in Network Computing: Accelerating SDN Deployment




Guest post by Guru Parulkar in Network Computing

The ONF’s Open Innovation Pipeline aims to build integrated solutions to speed SDN adoption.

If you want to transform something, truly change the way it’s done, you first have to break it down. The network infrastructure industry has been undergoing a major transformation and not surprisingly this has involved breaking open the network into parts, which has clear cost and agility benefits. By disaggregating networking devices and separating control from data, software-defined networking (SDN) lets operators run open-source networking software on commodity hardware to take advantage of the open networking movement that has sprung up across the industry.

Click here to read the full guest post by Guru Parulkar in Network Computing.

ONF Showcases New ONOS Release, Use Cases and Field Trials at ONS


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:

SDN-IP enhancements

    • VLAN support
    • VPLS support
    • IGMPv2

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)

Southbound Enhancements

    • Lumentum WaveReady support (TL1)
    • Pipeline support for Nokia OLT
    • RESTCONF

vRouter

    • IPv6 support

Framework

    • New distributed system support – consistent document tree
    • LISP
    • 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
    • RESTCONF

Traffic Engineering

    • Policers and bandwidth monitoring

User Interface

    • 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.

Additional Resources

About ON.Lab
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/.

About ONF

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

Bill Snow

Chief Development Officer at ON.Lab

bill@onlab.us

Press Contact

Meredith Solberg

PR Manager at The Linux Foundation

msolberg@linuxfoundation.org

[ONF Blog] Open Innovation Pipeline: Described


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

Guest Blog: Achieving Next Generation OSS with the TMF ZOOM, ONOS and Huawei


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:

catalyst

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 info@tmforum.org or via https://www.tmforum.org/collaboration/catalyst-program/catalyst-program-benefits/

ONOS Community Blog Series: Deployments Brigade


img_3303 img_3318img_3311

 

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.

img_3325

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.

img_3289img_3295

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 brigade-deployments@onosproject.org. 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.

ONOS Dynamic Configuration Brigade


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.

Guest blog post: ADARA Message Queue contributions to ONOS Hummingbird


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
    • PKT_IN

Message Queue

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.

Community Blog Series: Huawei on ONOS Bootcamps


screen-shot-2016-09-28-at-8-58-25-am

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

screen-shot-2016-09-28-at-8-58-35-am

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

screen-shot-2016-09-28-at-8-58-44-am

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.

 

###