OpenOMCI

v2.0 Service Technology Profiles

June 22nd, 2018 Chip Boling

 Proposed Agenda
● Scope of work to be performed/expectations
● OpenOMCI Startup sequence of events
● Service Technology Profile to OMCI ME Mapping
● Service Technology Profile Bridge Task(s)
● Service Flow Task
● MIB Audit & Resynchronization Considerations
● Service Technology Profile and OMCI Alarms/Performance Monitoring
 Scope of work
● 2 Use Cases Defined
○ AT&T High Speed Internet Service: UNICAST/L2, 4 Classes of Service,
ONU performs tagging operations
○ DT High Speed Internet Service: UNICAST/L2, 8 Classes of Service,
ONU trunks tagged frames

● Question for the community?

○ With the number of Traffic Scheduling and Prioritization options, coupled
with several congestion algorithms, can a small subset be specified as
the minimum viable solution set? ie) Single TCONT per ONU with strict
priority and 4 or 8 GEM Ports/priorities?
This may greatly reduce the number of test cases to perform
 Service Tech Profile to ME Mapping
● What: First pass at mapping of the Service Technology
Profile JSON to the appropriate OMCI ME.
○ Google Sheets Link: VOLTHA Service Technology Profile Mapping to
OMCI MEs

● Very Early example:

○ ADTRAN ONU adtn_mib_download_task.py
○ This is the traditional ‘script’ that the ADTRAN ONU uses to create a
single GEM High Speed Internet Service. Very similar to steps done by
BroadCom ONU, but a bit more parameterized, commented, and runs as
an OpenOMCI Task.
 OMCI Startup Sequence
● Just the startup of the first two state
machines for OpenOMCI.
● PM State machine coding is underway
and starts up after the OMCI
capabilities are retrieved.
● Service Tech Profiles should also be
executed after the OMCI Capabilities
have been retrieved.
● Post-v2.0 ONU pre-provisioning can be
supported once we can perform MIB
resync reliably. Hyperlink to
actual diagram
 MIB Upload (New ONU) Sequence
● Sequence Diagram of a ‘new’ ONU
synchronizing for the first time with the
OpenOMCI MIB Database (MIB Upload)
● Previously synchronized ONUs go
through an Audit process and may
require resynchronization.
● Until first MIB synchronization, the OMCI
capabilities, and ONU create TCONTs
and Priority Queues are unknown.

Hyperlink to
actual diagram
 Service Tech Profile Bridge Task(s)
● In VOLTHA, up to v1.3, all Open-Source ONUs had a fairly script based
approach to setting up a service. This needs to be broken down into
OpenOMCI OMCI tasks and tested
● Work on this started in Sprint 3 with the ADTRAN ONU device adapter.
Pictured in the next three slides.
○ Does not yet contain Priority Queue or Traffic Schedulers
○ Not fully parameterized yet, but getting close
○ First Implementation may be ONU Specific (specific task per ONU
Vendor)
ADTRAN ONU Sequence: VOLTHA v1.3.0
S1
C3
C12
S13 S10 C2
S14
C4
C5
S11 C6

C8 C7

C9

Figure 12: From AT&T’s OpenOMCI Specification, v3.0. S=Set ME, C=Create ME
ADTRAN ONU Sequence: VOLTHA master as of 6/20/2018
S8
C10
C12
S13 S11 C9
S14
C6
S1 C2
C3

S15 C7 C4

C5

Figure 12: From AT&T’s OpenOMCI Specification, v3.0. S=Set ME, C=Create ME
 OpenOMCI ME Sequence: Desirable (all ONUs the same?)
S3
C8
C2
S3 S1 C10 S9 C6 C5
1. Common
Traffic
S... Descriptor
C4
2. HSI C7
C1 S2
3. Flows
S1 C1
S2
3. Enable
C2 C3

n/a?

Figure 12: From AT&T’s OpenOMCI Specification, v3.0. S=Set ME, C=Create ME
 Service Flow Task
● Relates to the Flows steps in the previous slide
● Used to add/remove individual flows to the Extended VLAN Tagging
Configuration ME (#171) and update any Traffic Descriptor ME (#280)
● This values/operations for this task comes from the OpenFlow request
● First implementation can probably a single Task (1 Task for all ONUs)
MIB Audit & Resynchronization Considerations
● Besides dealing with minor differences in OMCI Task for setting up the
Bridge, UNIs, ANIs, … how to resynchronize an ONU after loss of MIB
Synchronization is also difficult.
● Probably best handled in the Service Tech Profile Bridge Task(s) and the
Service Flow Task separately. Pass ME difference list to each task.

● Once resynchronization of the ONUs has been demonstrated on multiple

vendor ONUs, refactor into a single common class if possible (post v2.0)
 PM and Alarm Considerations
● As some Bridge/Flow MEs are created, additional PM ME instances will need
to be created to provide performance intervals.
○ Suggest having PM Interval State machine monitor successful ME
create/deletes, filtered for MEs of interest, and insert/remove as needed
● Interval PM coding in OpenOMCI is underway. Not sure exactly what which
MEs are needed in v2.0 requirements.
● Alarms have not been started. Not sure exactly which MEs is needed in v2.0
and whether or not threshold crossing alarms (TCA) for PM Interval counters
are needed. Can TCA’s be deferred to post-v2.0?
Questions?
 V2.0 OpenOMCI
Vendor ONU Device Adapter Not all currently
defined tasks are
shown below.

MIB Data MIB MIB

MIB Sync
I-Adapter

Reconcile

Events
Sync Task Audit Task

OMCI
Task

MIB Get OMCI

OMCI MIB Upload Resync Capabilities
Onu Device Entry Task Capabilities
Adapter Task Task
Agent Queue/Run
Task Tasks Tasks
Request
PM
(TBD) (TBD)
Intervals
Task Runner
OMCI Alarms
Vendor OLT DA

Rx/Tx MIB OMCI PM Alarm Sync

ME Events

Requests Currently Sync Capabilities Intervals State

Running State State State Machine Software
Machine Machine (TBD) Download
Task(s) Machine
Read
Only CRUD CRUD CRUD
Operations CRUD Operations Operations PUB/SUB
Operations
Interface
OMCI_CC
For ownership &
statistics (not tx/rx) MIB PM Alarm
Database Databases are Database Database
(minimal)
read-only by ONU
OpenOMCI Device Entry
V1.3 OpenOMCI Framework (MIB DB related)
Vendor ONU Device Adapter
Query ME requests

I-Adapter OpenOMCI MIB

OpenOMCI Events
Audit Task

MIB Upload Task MIB

OMCI_CC Resync
Task
Vendor OLT DA

ME Even
MIB
VOLTHA
Get MIB Data
Sync Task Reconcile v1.3.0
OMCI Rx/Tx Task(s) Commitments
OmciAdapter

ts
Requests Task Runner
Agent Stretch
ME Goals
MIB Sync Database
StateMachine ME CRUD requests PUB/SUB
Interface

OnuDeviceEntry Start/Stop requests