CORD : Certification Brigade

Current status (April 2019)

  • Brigade working on SEBA reference design, aggregation switch certification. Target date public availability: April 2019
  • Brigade initial work on SEBA reference design, OLT certification on going. No target date set yet. 

Brigade Goals

  • Formulate the guidelines for a CORD Certification program.
  • Define the ways of working for the Certification Program.
  • Bring awareness of the importance of a Certification Program to Operators and Vendors.
  • Evaluate existing test cases/scripts and developing new test cases and scripts for the Program.
  • Promote the Mission and Goals of the Brigade and attract participation from the community to meet the Certification Program goals.
  • Categorize Certification into different types based on use-cases/exemplar platforms.
  • Create sub-set of test cases/scripts required to run successfully for each of the types mentioned above.
  • Provide guidelines to setup an Authorized Certification Lab (ACL).
  • Define clear procedures to validate test results and logs and the formats in which these results and logs are to be submitted.
  • Design a Certification logo.

CORD Certification Program (CCP)


The CORD Certification Program (CCP) is designed to facilitate operators’ assessment of CORD solutions.

CORD certificate provides assurance to the operator community that a vendor’s offering meets common critical functional, performance and life-cycle requirements in CORD environment.

A CORD certificate will allow vendors to gain a competitive edge in CORD market.

CCP allows an operator to save significant efforts of assuring those requirements and thus focus and spend resources on additional – specific requirements.

Enable third-part Certification Labs to run the tests and verify a switch as certified for a specific version of CORD.

Key Facts

  • CCP is designed to support the ONF strategy.

  • The CORD Certification Program will be reflective of the needs of the operator community.

  • A special emphasis is given to shaping the Program in a tight coordination loop with operators (TLT) and a CORD project that is responsible for a particular exemplar platform.

  • CCP intends to provide a simple, flexible ways of working that will be attractive to all parties of the Program.

  • The certification process will be clear and its evolution will be communicated promptly to all stakeholders. In particular, CCP will strive to create a minimal number of types of certificates.

  • This will be accomplished by emphasizing  direct work between vendors and labs and making ONF leadership/supervision as non-intrusive and constructive as possible.

  • The business models of certifying - such as e.g. cost of certification - will be left to direct negotiations between Authorized Certification Lab(ACL)'s and vendors.

  • CCP will target a broad groups of stakeholders as possible. For instance, in addition to obvious choices of switch, server and VNF vendors, CCP will explore a possibility to include vendors of equipment adjacent to CORD,e.g., ONU.

Program Workflow

A process workflow in general formalizes the below activities:

  • CCP Lab Certification - To provide CCP services a third party (non-ONF) lab should meet a certain pre-requisites. Once the pre-requisites are met lab will be upgraded to Authorized Certification Lab ACL status. More details on the ACL program can be found at Authorized CORD Lab Process.
  • Vendor to ACL Interaction - Vendors should familiarize the product to be certified to ACL. Vendor should provide a Formal Request to ACL which includes details like component to be verified, details of component and test Platform (if any specific), target date etc. 
  • ACL to Vendor Interaction -  ACL should familiarize the certification program to the vendor. ACL after analysis of the formal request and complete understanding of it defines an official Test Scope in agreement with the Vendor. This may include many technical rounds of discussion between ACL and the Vendor. Once the test is completed ACL hands over the results and logs as required by the CCP to the Vendor.
  • Vendor to CCP-Technical Committee - The test results, logs and necessary files are submitted to CCP - Technical Committee for analysis. Once approved the Certification logo is issued, else the vendor takes back the comments, clarifies and corrects the failures re-runs the test tests and re-submits the test results.

A process workflow, listing the different steps to obtain a CORD certification, is described in detail at “CORD Certification Test Program-Policy and Procedure Manual”.

Certification Programs

The brigade offers two Certification Programs.  CORD Component Level Certification Program and CORD POD Certification Program.

CORD Component Level Certification Program

The component level verification is a pre-requisite set of test to ensure that a particular component can operate as expected within CORD environment and meets minimal function/performance requirements. The component shall be tested in an isolated environment or within a CORD Pod itself based on the type of the component and how it interacts with other CORD components. The component to be tested can be hardware or a VNF.

CORD POD Certification Program

The POD level verification considers the entire CORD POD as the device under test. The POD level testing will include service operations , data-plane and FCAPS testing.

Details for the Verification procedure can be found at CORD Verification Test Plan.

When defining test cases for CCP a sincere effort will be made to re-use the existing test cases/scripts. There will be test cases which can be re-used as it is, test cases which needs minor modifications and completely new test cases.

An initial draft of the POD level Certification Program can be found at Certification_Brigade_POD_Test_Procedure. Significant amount of work is involved here and members are requested to contribute.

How to get involved

  • Subscribe to the Certification Brigade mailing list and introduce yourself and join the discussion.
  • Dial-in to a Certification Brigade call (details distributed on mailing list and Slack channel).
  • Subscribe to Certification Brigade #Slack Channel


  • Timon Sloane (ONF)
  • ATT - Tom Tofigh <>

Steering Committee

Technical Committee

  • Sreeju Sreedhar <> (TC Chair)
  • Lu Xu <>
  • Christopher Brown <>

Brigade Members

  • BII - Beijing Internet Institute - Le Ma <>
  • China Unicom - Wei Zhou <> and Qiu Chen <>
  • Criterion Network Labs  - JP <>, Krishna<>, Vinayak Tejenkar <>
  • CSIR - Sabelo Dlamini <>
  • CTTL of CAICT - Lu Xu <>
  • ETRI Test Lab - Wangbong Lee <>
  • NCTU NBL - National Chiao Tung University Network Benchmarking Lab
  • UNH IOL - University of New Hampshire Interoperability Lab –  Timothy Winters <>, Christopher Brown <>
  • Villa-Tech - Miguel Villarreal Jr <>
  • Jabil - Claudio Serra <>, Gregory Shmunis <>, Sreeju Sreedhar <>, Roman Bubyr <>
  • Flex - Siddharth Gogar <>
  • Polaris Networks - Ameet Dhillon <>
  • Spirent - SriHarsha Dhanekula <>
  • One Source Integrations - Rich Renner <>, Mark Cannon <>, Rick Witzke <>, Gage Orsburn <>
  • Delta Electronics America - Roger Cortes <>, Michael Hung <>, Durga Bodla <>
  • Add your organization here...


To learn about QA Automation/Framework and Tests, resources can be found at

System Test Guide -> quick start guide to CORD QA

System Tests -> QA wiki link

To reach QA for any questions, Get on to the QA slack channel here -> Slack

Events / Meetings / Forums

The Certification Brigade kick-off call was held on November 15, 2018.

See recording of that meeting here:

See Brigade kick-off presentation here:

Next meeting: March 29 2019 

The Certification Brigade kick-off call was held on August 7, here are links to notes and a recording of the call:
* Notes:
* Recording: