The CORD wiki contains community-related information. If you're looking for documentation on the software in the CORD reference implementation (version 4.0 and later), you should go to:
Skip to end of metadata
Go to start of metadata

Contributing to VOLTHA 


ONF/AT&TJulie LorentzenJulie_Lorentzen@labs.att.comScrum Master - VOLTHA
AT&TShawn Yingsying@labs.att.comProduct Owner - VOLTHA
Deutsche TelekomBjoern 
Deutsche TelekomManuel 
TelefonicaMaria L. 
Turk TelekomBora 
CienaSergio Slobodrianslobodr@ciena.comArchitect - Core
CienaDavid Bainbridgedbainbri.ciena@gmail.comArchitect - Core
NokiaSireesha KoraSireesha.kora@nokia.comArchitect
RadisysAmit Ghoshamit.ghosh@radisys.comArchitect
RadisysShaun MissetShaun.Missett@Radisys.comArchitect - System
RadisysKim Kempfkim.kempf@radisys.comArchitect - ASFvOLT16 Adapter

Architect - Adtran Adapter

AdtranBalaji Purushothamanbalaji.purushothama@adtran.comArchitect - Adtran Adapter
CalixEvan Parkerevan.parker@calix.comProduct Manager - Calix Adapter
TibitPaul Graypaul.gray@tibitcom.comArchitect - Tibit Adapter
TibitJay Teborekjay.teborek@tibitcom.comProduct Manager - Tibit Adapter



VOLTHA Project Overview

Flexible and agile service adaptation at the cost of commodity servers and whitebox switches VOLTHA introduces the next-generation optical access system architecture, based on SDN/NFV technologies. Disaggregating PON functions to functional modules with open interfaces supports the CORD vision for open source reference implementations to service "Access-as-a-Service" use cases.   VOLTHA  is a vOLT hardware abstraction component that supports the CORD Project objective of multi-vendor, multi-domain "any broadband access as a service" reference implementation for the Central Office. VOLTHA provides isolation between an abstract (vendor agnostic) PON management system, and a set of vendor-specific PON hardware devices. On its north-bound interface, VOLTHA provides a set of abstract APIs which north-bound systems can interact with the PON networks.  On its south-bound side, VOLTHA communicates with PON hardware devices using vendor-specific protocols and protocol extensions through adapters.

Release and Project Management

Working as an open source community team

  • The intended host of this project is the CORD project (
  • All source code to be developed via the gerrit system of opencord.
  • All parts of VOLTHA will be managed as one git repository (any proprietary plugin code by vendors will be kept in separate repos/places).
  • All project documentation must be kept with the git repository (preferably as markdown (*.md) files, with drawings created with preferably Inkscape (has to be editable and PNGs can be redesigned).
  • All major changes, decisions, etc., must be done with VOLTHA TST approvals, and pursuant of the CORD project governance rules.

VOLTHA Release Acceleration

  • Agile + Continuous Integration - Mandatory Test Driven Development
  • Single source code repo with automated build
  • Transparency - Everyone should know what is going on
  • Design Specs for all major new features - get the team engaged for cross functional support on features (dev, test, doc etc)
  • WIKI is the main source of true for documentation, not google docs
  • All contributions upstream tracked in JIRA and linked to Gerrit
  • Keep JIRA up-to-date to avoid duplication of efforts or gaps in sprint deliverables

Release Model and Cadence

vOLTHA will follow the CORD release model, branching, versioning and tagging best practices found here: Release Management

vOLTHA Branch and Adapters

Currently Adapters are part of vOLTHA container package, releasing in cadence with vOLTHA suite. Subsequent to v1.0 release, adapters will be split off vOLTHA master branch and maintained in one of two ways: (1) create master branch per adapter, or (2) create a developer branch per adapter and merge into vOLTHA master.  Both methods have pros and cons to be voted by vOLTHA TST members.. The main objective is not to destabilize vOLTHA, and allows for adapter release flexibility, where major features, bug fixes, and updates can be applied out of band (e.g. vOLTHA release).

vOLTHA Module Ownership

VOLTHA Architecture:  VOLTHA v1.x Architecture

vOLTHA may be deployed on a compute environment (e.g., in the CO, or Operators centralized cloud such as AT&T's AIC), in which case it communicates with the OLTs via an aggregation network.


This section summarizes high level functional requirements of a PON system to make it compatible with vOLTHA and CORD based disaggregated access design. vOLTHA supports PON systems that adhere to a separation of control plane from hardware. This means, protocols implemented on the OLT in legacy systems are now implemented in the SDN controller, sitting above vOLTHA, and thus separated from hardware.   Examples of such protocols:

  • 802.1x (EAPOL) authentication
  • DHCP
  • IGMP

Terms to understand while reading the initial design and implementation:

  • Downstream refers to data flowing from the upstream network or Voltha Core toward the subscriber's residential gateway (RG). In the diagram this corresponds to the left to right direction.
  • Upstream refers to data flowing from the direction of the RG toward the direction of Voltha Core or the upstream network. In the diagram this corresponds to the right to left direction.


Reference Points supported in v1.0

(Pa) vOLTHA Adapter Interface

Uniform, abstract, vendor agnostic programmatic (Python) interface between vOLTHA's Core and a vendors OLTH adapter:


  • Downstream:
    • Invoking management- and control-plane operations on the OLT.
    • Passing management operation protocol frames on behalf of an ONU Adapter to the ONU via the OLT
    • Forwarding control protocol frames to be injected by the OLT toward the RG (e.g., 802.1x, IGMP)
  • Upstream:
    • Signaling asynchronous events to Voltha Core (e.g., OLT discovered, ONU activated, alarms, and performance metric data)
    • Forwarding control-plane messages diverted from the PON network toward the SDN controller (e.g., 802.1x, IGMP

(Pc) Control and Management Channels

This interface carries management and control protocol communication between vOLTHA and the PON complex. This can include protocols terminated by the OLT, by ONU or by RG. Encapsulation of these protocols at (Pc) can be OLT vendor specific, but their payload may be specific to the vendor of the respective device. The management protocols targeting the OLT can be completely specific to the OLT vendor.  If vOLTHA is connected to the OLT device via an aggregation network, (Pc) messages need to be isolated from other data plane traffic using an isolation mechanism applicable to the aggregation network, such as using one or more dedicated vLANs.


  • Downstream:
    • Invoke OLT management operations using possibly proprietary protocols, specific to the OLT vendor. Examples: configure OLT device attributes; disable an ONU port.
    • Invoke ONU management operations using protocols specific to the ONU (OMCI, EOAM, etc.), and tunneled by the OLT Adapter and OLT so that it may be encapsulated at Pc in ways specific to the OLT vendor.
    • Carry control plane messages to be forwarded toward the RG. If the injection of such frames into the PON is done by the OLT, the encapsulation method of these frames at Pc can be OLT vendor specific. Thus, the OLT Adapter and the OLT play a tunneling/forwarding role.
  • Upstream:
    • Respond to OLT management operations
    • Carry ONU management protocol responses from the ONU to the ONU Adapter via the OLT Adapter
    • Carry control plane protocol messages isolated by the OLT and to be destined to the SDN controller. The encapsulation of such messages can be OLT vendor specific at Pc, but must encode/preseve the source (e.g., ONU port number) so that the source of the message can be identified.

(Pd) Data Plane Channels

This reference point carries all unicast and multicast "payload" data flows of the subscriber, flows with which Voltha is not be concerned, including the subscriber's Internet, VoIP and multicast-based video (TV) traffic. Thus, it can include both unicast and multicast flows. It can also include control and management plane flows for protocols not involving Voltha and the SDN controller.

(Po) OLT Upstream-facing Interface

This is the interface with which an OLT device is connected to the access aggregation network, i.e., to an upstream data network and to its control- and management systems. This interface thus carries the payload of both Pd and Pc. Pc and Pd flows may be carried via the same OLT physical port (in-band management and control). In the in-band case, flows of Pd vs Pc are typically isolated by VLANs. In the case of out-of band management and control Pc and Pd may be isolated via dedicated physical ports (e.g., when Pc as a whole or portions of Pc protocols access the OLT via its management port).

(Pr) ONU residential-facing interface

This is typically a L2 (Ethernet) interface carrying control plane and data plane flows to and from the RG. This includes all subscriber "payload" flows, such as Internet, VoIP and video service traffic, but it also includes control protocol flows terminated by Voltha or the SDN controller. However this distinction is invisible at this reference point, as the RG must be able to behave in the same way irregardless of being used in a disaggregated (Voltha-based) PON network or in a conventional legacy PON network

VOLTHA Architecture: Component Definition


Put definition here

VOLTHA HA Design - vOLT-HA High Availability.pdf

VOLTHA HA Design Review Recordings - 2017-05-31 12.34 VOLTHA Meeting.mp4

Protocol Plug-in Framework

Put definition here

OpenFlow Plug-in

REST Plug-in

RESTConf/NETConf Plug-in(s)

Kafka Publish Plug-in

Extensible Framework

Put definition here

PM Statistics Plug-in

Alarms Framework

Software Lifecycle Management Framework

Put definition here

PON Configuration

Put definition here

VOLTHA Design - xPON in VOLTHA - Proposal.pdf

Current Architecture Review Recording - 2017-06-01 08.04 VOLTHA Meeting.mp4

Continuation of xPON Config Architecture Review Recording - 2017-06-06 09.03 VOLTHA Meeting.mp4

VOLTHA Adapters

 Put definition here

  1. Tibit MicroOLT Adapter

  2. Edge-core ASFvOLT16 Adapter - Maple Adapter

VOLTHA Security

Put definition here

Voltha Security Architecture - vOLTHA Security Architecture Proposal - v1.0.doc 


VOLTHA Release Plans and Release Notes

Component / FeatureRelease DateRelease NotesComments
VOLTHA v1.0.0Sep 12, 2017vOLTHA v1.0.0 Release NotesMajor release focuses new features and feature enhancements for AT&T POC III requirements building on previous POC I/II features functionality.
VOLTHA v1.1.0Oct 6, 2017N/A

Minor release focuses on inclusion of Edge-core ASFvOLT16 XGS-PON OLT Adapter.

ASFvOLT16 design based on Broadcom Maple PON MAC silicon supporting 16x XFP ports of XGS-PON or NG-PON2 (10Gb/10Gb) and four QSFP28 Ethernet uplink ports. 

VOLTHA v1.1.1Nov 16, 2017N/AMaintenance release focuses on bug fixes in preparation for AT&T POC IV / Field Trial
VOLTHA v1.2.0Dec 21, 2017vOLTHA v1.2.0 Release Notes Minor release focuses on enhancements to ASFvOLT16 Adapter and support for T&W ONU
VOLTHA v1.2.1March 16, 2018vOLTHA v1.2.1 Release NotesPatch release for CORD 5.0 integration, REGID support for ONU Registration and bug fixes.
VOLTHA v1.3April 30, 2018 Proposed minor release: migration to Kubernetes, OpenOMCI
VOLTHA v2.0July 31, 2018 Major release focuses on Feature Enhancements; Containerized Adapters, NETconf support, G.Fast Adapter support, migration to Kubernetes



Technical Lock-down Meetings

QuarterStarting Date/TimeEnding Date/TimeLocation
1Q2018Jan 10 / 08:00Jan 11 / 17:00San Ramon, CA, USA
2Q2018April 10 / 13:00April 12 / 12:00Dallas, TX, USA
3Q2018Mid JulyMid JultyTBD
4Q2018Mid OctMid OctTBD



References Broadband / Wireline


VOLTHA TST Recordings

Recordings have been moved to vOLTHA TST Meeting Recordings.


  • No labels