TR 451

Technical Report
TR-451
vOMCI Specification
Issue: 1
Issue Date: June 2022
© The Broadband Forum. All rights reserved.

vOMCI Specification TR-451 Issue 1
Notice
The Broadband Forum is a non-profit corporation organized to create guidelines for broadband network
system development and deployment. This Technical Report has been approved by members of the Forum.
This Technical Report is subject to change. This Technical Report is owned and copyrighted by the
Broadband Forum, and all rights are reserved. Portions of this Technical Report may be owned and/or
copyrighted by Broadband Forum members.
Intellectual Property
Recipients of this Technical Report are requested to submit, with their comments, notification of any relevant
patent claims or other intellectual property rights of which they may be aware that might be infringed by any
implementation of this Technical Report, or use of any software code normatively referenced in this
Technical Report, and to provide supporting documentation.
Terms of Use
1. License
Broadband Forum hereby grants you the right, without charge, on a perpetual, non-exclusive and worldwide
basis, to utilize the Technical Report for the purpose of developing, making, having made, using, marketing,
importing, offering to sell or license, and selling or licensing, and to otherwise distribute, products complying
with the Technical Report, in all cases subject to the conditions set forth in this notice and any relevant
patent and other intellectual property rights of third parties (which may include members of Broadband
Forum). This license grant does not include the right to sublicense, modify or create derivative works based
upon the Technical Report except to the extent this Technical Report includes text implementable in
computer code, in which case your right under this License to create and modify derivative works is limited to
modifying and creating derivative works of such code. For the avoidance of doubt, except as qualified by the
preceding sentence, products implementing this Technical Report are not deemed to be derivative works of
the Technical Report.
2. NO WARRANTIES
THIS TECHNICAL REPORT IS BEING OFFERED WITHOUT ANY WARRANTY WHATSOEVER, AND IN
PARTICULAR, ANY WARRANTY OF NONINFRINGEMENT AND ANY IMPLIED WARRANTIES ARE
EXPRESSLY DISCLAIMED. ANY USE OF THIS TECHNICAL REPORT SHALL BE MADE ENTIRELY AT
THE USER’S OR IMPLEMENTER'S OWN RISK, AND NEITHER THE BROADBAND FORUM, NOR ANY
OF ITS MEMBERS OR SUBMITTERS, SHALL HAVE ANY LIABILITY WHATSOEVER TO ANY USER,
IMPLEMENTER, OR THIRD PARTY FOR ANY DAMAGES OF ANY NATURE WHATSOEVER, DIRECTLY
OR INDIRECTLY, ARISING FROM THE USE OF THIS TECHNICAL REPORT, INCLUDING BUT NOT
LIMITED TO, ANY CONSEQUENTIAL, SPECIAL, PUNITIVE, INCIDENTAL, AND INDIRECT DAMAGES.
3. THIRD PARTY RIGHTS

Without limiting the generality of Section 2 above, BROADBAND FORUM ASSUMES NO RESPONSIBILITY
TO COMPILE, CONFIRM, UPDATE OR MAKE PUBLIC ANY THIRD PARTY ASSERTIONS OF PATENT
OR OTHER INTELLECTUAL PROPERTY RIGHTS THAT MIGHT NOW OR IN THE FUTURE BE
INFRINGED BY AN IMPLEMENTATION OF THE TECHNICAL REPORT IN ITS CURRENT, OR IN ANY
FUTURE FORM. IF ANY SUCH RIGHTS ARE DESCRIBED ON THE TECHNICAL REPORT, BROADBAND
FORUM TAKES NO POSITION AS TO THE VALIDITY OR INVALIDITY OF SUCH ASSERTIONS, OR
THAT ALL SUCH ASSERTIONS THAT HAVE OR MAY BE MADE ARE SO LISTED.
All copies of this Technical Report (or any portion hereof) must include the notices, legends, and other
provisions set forth on this page.
June 2022 © The Broadband Forum. All rights reserved 2 of 113

Issue History
Issue Approval Publication Issue Changes

Number Date Date Editor
1 7 June 2022 7 June 2022 Tim Carey (Nokia) Original
Comments or questions about this Broadband Forum Technical Report should be directed to
info@broadband-forum.org.
Editor: Timothy Carey, Nokia

Dechao Zhang, China Mobile
Work Area Director(s): George Dobrowski, Morris Creek Consulting

Bruno Cornaglia, Vodafone
Mengmeng Li, China Mobile

TABLE OF CONTENTS
1 PURPOSE AND SCOPE ................................................................................................................................... 10

1.1 SCOPE .............................................................................................................................................................. 10
2 REFERENCES AND TERMINOLOGY ................................................................................................................. 13
2.1 CONVENTIONS ................................................................................................................................................... 13
2.2 REFERENCES ...................................................................................................................................................... 13
2.2.1 Published References ................................................................................................................................ 13
2.3 DEFINITIONS ...................................................................................................................................................... 15
2.4 ABBREVIATIONS ................................................................................................................................................. 15
3 TECHNICAL REPORT IMPACT ......................................................................................................................... 17
3.1 ENERGY EFFICIENCY ............................................................................................................................................ 17
3.2 SECURITY .......................................................................................................................................................... 17
3.3 PRIVACY ........................................................................................................................................................... 17
4 OVERVIEW .................................................................................................................................................... 18
5 VOMCI SOLUTION OVERVIEW ....................................................................................................................... 19

5.1 ONBOARDING OF VNFS/CNFS ............................................................................................................................. 19
5.2 VOMCI FUNCTION DESCRIPTION .......................................................................................................................... 19
5.2.1 Onboarding the vOMCI Function .............................................................................................................. 20
5.2.2 Management of the vOMCI Function ....................................................................................................... 20
5.2.2.1 VNF/CNF Requirements ................................................................................................................................... 21
5.2.2.2 Management Requirements ............................................................................................................................ 21
5.2.2.3 ONU Discovery and Operation ......................................................................................................................... 22
5.2.3 OMCI Request and Response Processing .................................................................................................. 22
5.2.3.1 Requirements ................................................................................................................................................... 23
5.2.4 OMCI Notification Processing ................................................................................................................... 24
5.2.4.1 Alarm and Event Handling................................................................................................................................ 24
5.2.4.1.1Notification Translation and Reporting 24
5.2.4.2 Test Invocation and Result Handling ................................................................................................................ 25
5.2.4.3 Requirements ................................................................................................................................................... 25
5.2.5 Performance Monitoring .......................................................................................................................... 26
5.2.5.1 On-demand Retrieval of PM Data .................................................................................................................... 26
5.2.5.2 Periodic Collection of PM Data ........................................................................................................................ 26
5.3 ONU MANAGEMENT PROXY ................................................................................................................................ 26
5.3.1 Management of the ONU Management Proxy ........................................................................................ 27
5.3.2 General Requirements .............................................................................................................................. 28
5.3.3 VNF/CNF Requirements ............................................................................................................................ 29
5.3.4 vOLTMF to ONU Management Proxy Management Interface (MvOLTMF-vOMCI ) ......................................... 30
5.4 VOMCI PROXY .................................................................................................................................................. 31
5.4.1 Management of the vOMCI Proxy ............................................................................................................ 31
5.4.2 General Requirements .............................................................................................................................. 31
5.4.3 VNF/CNF Requirements ............................................................................................................................ 32
5.4.4 vOLTMF to vOMCI Proxy Management Interface ..................................................................................... 32
5.5 OLT DESCRIPTION .............................................................................................................................................. 33
5.5.1 vOMCI Function Connectivity .................................................................................................................... 33
5.5.1.1 Requirements ................................................................................................................................................... 36
5.5.1.1.1Activation Requirements 36
5.5.2 OMCI Message Forwarding ...................................................................................................................... 36
5.5.2.1 ToD Message Forwarding................................................................................................................................. 37

5.5.2.2 Requirements ................................................................................................................................................... 37

5.5.3 vOMCI ONU Notifications ......................................................................................................................... 37
5.5.3.1 Requirements ................................................................................................................................................... 38
5.5.4 Management of the OLT ........................................................................................................................... 38
5.5.4.1 Requirements ................................................................................................................................................... 38
5.6 VOLT MANAGEMENT FUNCTION DESCRIPTION ........................................................................................................ 39
5.6.1 Requirements ............................................................................................................................................ 39
5.6.1.1 ONU Attachment and Initial Provisioning Requirements ................................................................................. 39
5.6.1.2 vOLTMF – vOMCI function Connectivity Requirements ................................................................................... 40
5.6.2 ONU Alarm Management ......................................................................................................................... 41
5.6.2.1 Requirements ................................................................................................................................................... 41
5.6.3 ONU OMCI Topology Management .......................................................................................................... 41
5.6.3.1 Requirements ................................................................................................................................................... 41
5.6.3.2 vOMCI Entity Connectivity Management ......................................................................................................... 42
5.6.3.2.1Requirements 43
5.6.4 ONU Persistent Configuration and State Management ........................................................................... 43
5.6.4.1 ONU Datastore Tags ......................................................................................................................................... 43
5.6.4.2 Requirements ................................................................................................................................................... 44
5.7 VOLT MANAGEMENT FUNCTION TO VOMCI FUNCTION OR VOMCI PROXY INTERFACE (MVOLTMF-VOMCI) ........................... 44
5.7.1 Information Model and Messages ............................................................................................................ 45
5.7.1.1 Message Header .............................................................................................................................................. 45
5.7.1.2 Message Body .................................................................................................................................................. 46
5.7.1.2.1Request and Response Messages 47
5.7.1.2.2Notification Messages 55
5.7.1.3 ONU Device Lifecycle ....................................................................................................................................... 55
5.7.1.4 ONU Topology .................................................................................................................................................. 55
5.7.2 Transmission Encoding ............................................................................................................................. 55
5.7.3 Message Transfer Protocol ....................................................................................................................... 55
5.7.3.1 Message Transfer Using Kafka ......................................................................................................................... 56
5.7.3.1.1Kafka Topics 56
5.7.3.2 Message Transfer Using gRPC .......................................................................................................................... 57
5.7.3.2.1gRPC Channel Initiation 57
5.7.3.2.2gRPC Channel Maintenance 59
5.7.3.2.3Using HTTP/2 as the gRPC Wire Protocol 59
5.7.3.2.4Securing the gRPC Channel 59
5.7.4 Requirements ............................................................................................................................................ 61
5.8 VOMCI FUNCTION TO OLT INTERFACE (MVOMCI-OLT) ................................................................................................ 61
5.8.1 vOMCI Messages ...................................................................................................................................... 62
5.8.1.1 ONU Header Message ...................................................................................................................................... 62
5.8.1.2 OMCI Packet Message...................................................................................................................................... 63
5.8.1.3 vOMCI Message Timeouts ............................................................................................................................... 66
5.8.1.4 vOMCI Error Message ...................................................................................................................................... 67
5.8.1.5 OLT Information Message ................................................................................................................................ 67
5.8.2 Encapsulating vOMCI Messages in GPB for use with gRPC Transport ...................................................... 68
5.8.2.1 Hello vOMCI Service ......................................................................................................................................... 68
5.8.2.2 vOMCI Message Service ................................................................................................................................... 69
5.8.2.2.1Acknowledgements at OMCI layer vs gRPC 69
5.8.2.3 Requirements ................................................................................................................................................... 70
5.8.3 OMCI Message Retransmission Capability ............................................................................................... 70
5.8.4 Use of gRPC to Exchange GPB Encapsulated vOMCI Messages................................................................ 71
5.8.4.1 gRPC Channel Initiation .................................................................................................................................... 71
5.8.4.1.1Remote Entity Contact Information 71
5.8.4.1.2OLT, vOMCI Proxy and vOMCI Function Identification and Configuration 71
5.8.4.2 gRPC Channel Maintenance ............................................................................................................................. 72
5.8.4.3 Using HTTP/2 as the gRPC Wire Protocol ......................................................................................................... 72

5.8.4.4 Securing the gRPC Channel .............................................................................................................................. 72

5.8.4.5 Requirements ................................................................................................................................................... 72
ANNEX A: VOMCI YANG MODULES .............................................................................................................. 74
A.1 OLT YANG MODULES ........................................................................................................................................ 74
A.2 VOLTMF YANG MODULES ................................................................................................................................. 75
A.3 VOMCI FUNCTION YANG MODULES ..................................................................................................................... 76
A.4 ONU MANAGEMENT PROXY FUNCTION YANG MODULES ......................................................................................... 77
A.5 VOMCI PROXY FUNCTION YANG MODULES ........................................................................................................... 78
A.6 DEPENDENCIES ON RELATED YANG MODULES AND STANDARDS ................................................................................. 79
APPENDIX I. VOMCI DEPLOYMENT IN CLOUDCO ......................................................................................... 80
I.1 INTEGRATING THE VOMCI SOLUTION WITH THE BAA LAYER ........................................................................................... 80
I.2 THE VOMCI SOLUTION DEPLOYED AS STANDALONE NFVI.............................................................................................. 81
I.3 CLOUDCO FRAMEWORK WITH VOMCI SOLUTION ........................................................................................................ 83
I.4 VOLTMF IMPLEMENTED AS AN ABSTRACTION LAYER BETWEEN THE OLT AND VOMCI FUNCTION.......................................... 84
APPENDIX II. VOMCI DEPLOYMENT IN FANS............................................................................................ 87

II.1 MANAGEMENT SYSTEM MODEL ............................................................................................................................ 88
II.2 VIRTUAL ACCESS NODE MODEL ............................................................................................................................ 89
APPENDIX III. INTEROPERABILITY OF VOMCI FUNCTIONALITY WITH MULTI-VENDOR ONUS ...................... 91
III.1 MULTI-VENDOR ONU IOP WITH OMCI ................................................................................................................. 91
III.2 MULTI-VENDOR ONU IOP WITH SINGLE VOMCI FUNCTION (1:N SCENARIO) ............................................................... 91
III.3 MULTI-VENDOR ONU IOP WITH SPECIFIC VOMCI FUNCTION (N*1:1 SCENARIO) ......................................................... 92
APPENDIX IV. ONU AUTHENTICATION IN VARIOUS SCENARIOS ................................................................ 93
APPENDIX V. SUPPORTING INTERACTIONS FOR VOMCI DEPLOYMENTS ................................................... 94

V.1 CONFIGURED ONU IS DETECTED ONLINE ................................................................................................................ 94
V.2 AUTOMATED ONU DISCOVERY ............................................................................................................................. 96
V.3 AUTOMATED ONU DISCOVERY FAILURE ................................................................................................................. 98
V.4 SYNCHRONIZE PM-RELATED INTERVALS AND TIMER ................................................................................................. 100
V.5 BACKGROUND ONU SOFTWARE DOWNLOAD SUPPORT ........................................................................................... 102
APPENDIX VI. CONNECTIVITY MANAGEMENT AMONG VOLTMF(S) AND VOMCI FUNCTIONS................... 105
APPENDIX VII. VOMCI FUNCTION CONNECTIVITY USING A SESSION PROXY ............................................. 106
APPENDIX VIII. EXAMPLES OF MVOLTMF-VOMCI MESSAGES ........................................................................... 107

VIII.1 ONU DEVICE DATA MODEL .......................................................................................................................... 107
VIII.1.1 Example ReplaceConfig Message for ONU Target ........................................................................ 107
VIII.1.2 Example Action Message to Set and ONU Management Chain .................................................... 108
APPENDIX IX. EXAMPLES FOR USING DATASTORE TAG ........................................................................... 110
IX.1 USE OF DST IN CONFIGURATION REQUESTS .......................................................................................................... 110
IX.2 USE OF DST WHEN THE VOMCI FUNCTION HAS RESTARTED ..................................................................................... 110
APPENDIX X. VOMCI-AS-A-SERVICE DEPLOYMENT................................................................................. 112
X.1 USE OF THE ONU MANAGEMENT PROXY .............................................................................................................. 113

List of Figures
Figure 1 Scope of the vOMCI Solution .............................................................................................................12

Figure 2 vOMCI Function and vOMCI Proxy Interfaces ...................................................................................20
Figure 3 Multiple Session – OLT to vOMCI Connectivity .................................................................................34
Figure 4 Multiple Session – vOMCI to OLT Connectivity (single vOMCI function) ..........................................34
Figure 5 Multiple Session – vOMCI to OLT Connectivity (vendor specific vOMCI function) ............................35
Figure 6 Multiple Session – vOMCI to OLT Connectivity (vOMCI Proxy) ........................................................35
Figure 7 vOLTMF-vOMCI Message ................................................................................................................45
Figure 8 vOLTMF-vOMCI Header Message....................................................................................................46
Figure 9 vOLTMF-vOMCI Message Body .......................................................................................................47
Figure 10 vOLTMF-vOMCI Request and Response Messages ......................................................................48
Figure 11 vOLTMF-vOMCI Hello Request and Response Messages.............................................................49
Figure 12 vOLTMF-vOMCI GetData Request and Response Messages .......................................................50
Figure 13 vOLTMF-vOMCI ReplaceConfig Request and Response Messages .............................................51
Figure 14 vOLTMF-vOMCI UpdateConfig Request and Response Messages...............................................52
Figure 15 vOLTMF-vOMCI RPC and Action Request and Response Messages ...........................................53
Figure 16 vOLTMF-vOMCI Status Message ...................................................................................................54
Figure 17 vOLTMF-vOMCI Notification Message............................................................................................55
Figure 18 vOLTMF-vOMCI VomciMessageNbi Service ..................................................................................58
Figure 19 vOMCI Message Definition...............................................................................................................62
Figure 20 ONU Header Message .....................................................................................................................63
Figure 21 OmciPacket Message ......................................................................................................................63
Figure 22 ONU Notification ...............................................................................................................................64
Figure 23 ONU Command ................................................................................................................................64
Figure 24 ONU Response to ONU Command..................................................................................................65
Figure 25 ToD Packet Message Command .....................................................................................................66
Figure 26 vOMCI Message Error Message ......................................................................................................67
Figure 27 OLT Information Message ................................................................................................................68
Figure 28 vOMCI SBI Service...........................................................................................................................68
Figure 29 Hello vOMCI Service ........................................................................................................................69
Figure 30 vOMCI Message Service ..................................................................................................................69
Figure 31 vOMCI YANG Modules ....................................................................................................................74
Figure 32 OLT vOMCI YANG Modules ............................................................................................................75
Figure 33 vOLTMF YANG Modules ..................................................................................................................76
Figure 34 vOMCI Function YANG Modules......................................................................................................77
Figure 35 ONU Management Proxy YANG Modules .......................................................................................78
Figure 36 vOMCI Proxy YANG Modules ..........................................................................................................79
Figure 37 CloudCO Framework ........................................................................................................................80
Figure 38 Integrating the vOMCI solution with the CloudCO BAA layer ..........................................................81
Figure 39 vOMCI Solution Deployed as Standalone NFVI...............................................................................82
Figure 40 CloudCO Framework with vOMCI Solution ......................................................................................83
Figure 41 Example of a OLT with individual sessions to vOMCI functions ......................................................84
Figure 42 Example of the vOLTMF to Aggregate vOMCI/ONU communication ..............................................85
Figure 43 Deployment vOLTMF, vOMCI function and vOMCI Proxy in the context of the BAA layer .............86
Figure 44 TR-370 Management System Model................................................................................................87
Figure 45 Virtual Access Node Model ..............................................................................................................88
Figure 46 vOMCI Solution for FANS Management System Model ..................................................................89
Figure 47 vOMCI Solution for FANS Virtual Access Node Model ....................................................................90
Figure 48 ONU IOP with Single vOMCI Function (1:N scenario) .....................................................................91
Figure 49 ONU IOP with Specific vOMCI Functions (N*1:1 scenario) .............................................................92
Figure 50 Configured ONU is Detected Online ................................................................................................94
Figure 51 Automated ONU Discovery ..............................................................................................................97
Figure 52 Automated ONU Discovery Failure ..................................................................................................99
Figure 53 Synchronize PM intervals for a Discovered ONU ..........................................................................101
Figure 54 Background ONU Software Download ...........................................................................................103

Figure 55 Connectivity Among vOMCI functions and vOLTMF(s) .................................................................105

Figure 56 Single Session – OLT to vOMCI Connectivity ................................................................................106
Figure 57 Use of DST in ONU Configuration..................................................................................................110
Figure 58 Use of DST in vOMCI Function Restart .........................................................................................111
Figure 59 vOMCI-as-a-Service .......................................................................................................................112
List of Tables
Table 1 Kafka Topic Categories .......................................................................................................................56

Executive Summary
This Technical Report provides the architecture, requirements, and interface specifications for a virtualized
OMCI (vOMCI) solution that moves the OMCI functionality that is traditionally embedded within Optical Line
Termination (OLT) network elements into the Operator's network. This Technical Report supports various
deployment models of the vOMCI solution where functions (i.e., OMCI translation function, OLT & ONU
management functions) of the architecture can be deployed as virtualized network functions and are
expected to be used within Access domain SDN management and control solutions (e.g., Broadband
Forum’s CloudCO) or as a stand-alone process that can be deployed with existing management system
solutions.
The vOMCI solution allows Operators and Service providers more flexibility in how they create, activate, and
maintain services associated with ONUs. Likewise, the vOMCI solution enables easier interoperability testing
and on-boarding the ONUs within the Operator’s ecosystem and network.

1 Purpose and Scope

This Technical Report specifies the architecture for the vOMCI solution with requirements associated with the
functions that comprise the vOMCI solution and specifications for the interfaces associated with the functions
identified in this Technical Report to attenuate interoperability issues in the xGPON deployments. This
Technical Report complements TR-413 [28] and TR-385 [26] specifications.
1.1 Scope
The scope of this Technical Report is to provide an architecture for the vOMCI solution depicted in Figure 1
providing requirements and interface specifications for the function identified in this section as well as the
requirements for the OLT as they relate to the responsibilities identified in this section of the Technical
Report.
The vOLT Management Function (vOLTMF) shown in Figure 1, is responsible for:

• Receiving YANG notifications from the OLT regarding the ONU presence states.
• Informing the other entities in the vOMCI solution that an ONU can be communicated with for ONU
management purposes.
• Receiving management and control requests from the northbound SDN M&C.
• Generating and sending requests for management of the OLT via the interface with OLT.
• Generating and sending requests to target ONUs via the interface with the vOMCI function or ONU
Management Proxy.
• Receiving from the northbound SDN M&C the information necessary to connect OLTs, vOMCI
functions, vOMCI Proxies and/or ONU Management Proxies.
• Receiving from the northbound SDN M&C the information necessary to associate the vOMCI
function with ONUs.
• Receiving from the northbound SDN M&C the mapping information to associate the ONU
characteristics (i.e., vendor, software info) with the versions supported by vOMCI function instances.
• Receiving notifications including events and alarms from the OLT and vOMCI function, or ONU
Management Proxy and sending notifications to the northbound SDN M&C.
When deployed in the vOMCI solution, the ONU Management Proxy shown in Figure 1, is responsible for:
• Forwarding the management requests that are targeted for ONU or vOMCI function from the
vOLTMF to the vOMCI function instances.
• Correlating responses to the requests previously sent to the vOMCI function instances and
forwarding the responses to the vOLTMF.
• Receiving notifications from a vOMCI function instances and forwarding the notification to the
vOLTMF.
• Load balancing the ONU associations for management traffic across available vOMCI function
instances.
The vOMCI function shown in Figure 1, is responsible for:

• Receiving from the vOLTMF or ONU Management Proxy management commands issued towards
the target ONU(s).
• Translating the received management commands into OMCI management entities (ME) and
formatting them into OMCI messages compliant with ITU-T G.988.
• Encapsulating and sending the above OMCI messages to the target ONU. The messages will pass
through the vOMCI Proxy(s), if required by the vOMCI deployment scenario, and the OLT the target
ONU is attached to.
• Translating the OMCI messages received from an ONU (e.g., containing ONU’s operational data)
through the vOMCI Proxy(s), if required by the vOMCI deployment scenario, and the OLT the target
ONU is attached to.
• Sending the management data and information generated from the received OMCI messages to the
vOLTMF or ONU Management Proxy.
When deployed in the vOMCI architecture, the vOMCI Proxy shown in Figure 1, is responsible for:
• Forwarding the vOMCI message between OLTs and vOMCI functions.
• Optionally perform functions related to the forwarding (e.g., OMCI message retransmission) of the
vOMCI message.
The OLT shown in Figure 1, is responsible for:

• Decapsulating and processing received vOMCI messages and sending them to the target ONU
using the relevant PON OMCI channel.
• Process the OMCI messages received from the ONU and encapsulating them into vOMCI
messages and send them to the vOMCI function or vOMCI Proxy.
• Transmitting PLOAM notifications to the vOLT Management Function.

Figure 1 Scope of the vOMCI Solution

2 References and Terminology

2.1 Conventions
In this Technical Report, several words are used to signify the requirements of the specification. These
words are always capitalized. More information can be found be in RFC 2119 [6].
MUST This word, or the term “REQUIRED”, means that the definition is an absolute
requirement of the specification.
MUST NOT This phrase means that the definition is an absolute prohibition of the
specification.
SHOULD This word, or the term “RECOMMENDED”, means that there could exist
valid reasons in particular circumstances to ignore this item, but the full
implications need to be understood and carefully weighed before choosing a
different course.
SHOULD NOT This phrase, or the phrase “NOT RECOMMENDED” means that there could
exist valid reasons in particular circumstances when the particular behavior
is acceptable or even useful, but the full implications need to be understood
and the case carefully weighed before implementing any behavior described
with this label.
MAY This word, or the term “OPTIONAL”, means that this item is one of an
allowed set of alternatives. An implementation that does not include this
option MUST be prepared to inter-operate with another implementation that
does include the option.
2.2 References
2.2.1 Published References

The following references are of relevance to this Technical Report. At the time of publication, the editions
indicated were valid. All references are subject to revision.
Users of this Technical Report are therefore strongly encouraged to investigate the possibility of applying the
most recent edition of the listed references by checking at the web links reported below, especially for YANG
DMs.
A list of currently valid BBF Technical Reports is published at www.broadband-forum.org/technical-reports.
Users also may find useful BBF’s searchable Resources database for Technical Reports and other BBF
deliverables.
The most recent edition of BBF’s published YANG Data Models can be found at YANG Projects.
Document Title Source Year

[1] G.988 ONU management and control interface (OMCI) ITU-T 2017
specification
[2] G.984.3 Gigabit-capable passive optical networks (G-PON): ITU-T 2014
Transmission convergence (TC) layer specification
[3] G.987.3 10-Gigabit-capable passive optical networks (XG-PON): ITU-T 2-14

Transmission convergence (TC) layer specification

[4] G.9807.1 10-Gigabit-capable symmetric passive optical network ITU 2016
(XGS-PON)
[5] G.989.3 40-Gigabit-capable symmetric passive optical networks ITU 2021
(NG-PON2): Transmission convergence layer
specification
[6] RFC 2119 Key words for use in RFCs to Indicate Requirement IETF 1997
Levels
[7] RFC 5246 The Transport Layer Security (TLS) Protocol Version 1.2 IETF 2008
[8] RFC 5905 Network Time Protocol Version 4: Protocol and IETF 2010
Algorithms Specification
[9] RFC 6125 Representation and Verification of Domain-Based IETF 2011
Application Service Identity within Internet Public Key
Infrastructure Using X.509 (PKIX) Certificates in the
Context of Transport Layer Security (TLS
[10] RFC 6241 Network Configuration Protocol (NETCONF) IETF 2011
[11] RFC 7540 Hypertext Transfer Protocol Version 2 (HTTP/2) IETF 2015
[12] RFC 7895 YANG Module Library IETF 2016
[13] RFC 7950 The YANG 1.1 Data Modeling Language IETF 2016
[14] RFC 7951 JSON Encoding of Data Modeled with YANG IETF 2016
[15] RFC 8259 The JavaScript Object Notation (JSON) Data IETF 2017
Interchange Format
[16] RFC 8528 YANG Schema Mount IETF 2019
[17] RFC 8632 A YANG Data Model for Alarm Management IETF 2019
[18] ATP-247i3 GPON & XG-PON1 ONU Conformance Abstract Test BBF 2014
Plan
[19] TR-101i2 Migration to Ethernet-Based Broadband Aggregation BBF 2011
[20] TR-156i4 Using GPON Access in the context of TR-101 BBF 2017
[21] TR-167i3 GPON-fed TR-101 Ethernet Access Node BBF 2017
[22] TR-178i2 Multi-service Broadband Network Architecture and Nodal BBF 2017
Requirements
[23] TR-280 ITU-T PON in the context of TR-178 BBF 2016
[24] TR-383a4 Common YANG Modules for Access Networks BBF 2021
[25] TR-384 Cloud Central Office Reference Architectural Framework BBF 2017
[26] TR-385i2 ITU-T PON YANG Modules, Issue 2 BBF 2020
[27] TR-370 Fixed Access Network Sharing – Architecture and Nodal BBF 2020
Requirements Issue 2
[28] TR-413 SDN Management and Control Interfaces for CloudCO BBF 2019
Network Functions
[29] Google Google Protobuf Language Guide (proto3) GPB Open NA
Protobuf Source
Community

[30] Google Remote Google Remote Procedure Call (gRPC) gRPC NA

Procedure Call Open
Source
Community
2.3 Definitions
The following terminology is used throughout this Technical Report.
vOMCI Virtualization of the OMCI functionality within the PON Access Network
vOMCI Function A function in the vOMCI solution that is responsible for the translation of ONU
management requests, response and notification between OMCI messages and YANG
objects.
vOMCI The vOMCI-as-a-Service deployment organizes ONU Management Proxy, vOMCI
Service Proxy and vOMCI function into a vOMCI service that is consumed by vOLTMF and
other clients such as a slice management function.
vOLT A function in the vOMCI solution that is responsible for the management of the PON
Management Access Network that includes management of ONUs and OLTs. ONUs can be
Function managed using the vOMCI solution or through the OMCI solution embedded within the
OLT.
YANG Data Modelling Language by IETF
2.4 Abbreviations
This Technical Report uses the following abbreviations:
AVC Attribute Value Change

BAA layer Broadband Access Abstraction layer
BBF Broadband Forum
CRC Cyclic Redundancy Check
CRUD Create, Retrieve, Update and Delete
CloudCO Cloud Central Office
DST Datastore Tag
FANS Fixed Access Network Sharing
GPB Google Protocol Buffers
gRPC Google RPC
HTTP HyperText Transfer Protocol
InP Infrastructure Network Provider
IOP Interoperability
IPTV Internet Protocol Television
LOOC Loss of OMCI Channel communication
JSON JavaScript Object Notation
NBI Northbound Interface
NFVI Network Function Virtualization Infrastructure

MDS MIB Data Synchronization

ME Management Entity
MIB Management Information Base
MIC Message Integrity Check
MSBN Multi Service Broadband Network
M&C Management and Control
OAM Operations Administration and Management
ODN Optical Distribution Network
OMCC ONU Management and Control Channel
OMCI ONU Management and Control Interface
ONU Optical Network Unit
OLT Optical Line Termination
PLOAM Physical Layer Operations, Administration and Maintenance
PON Passive Optical Network
PMAA Persistent Management Agent Aggregator
PNF Physical Network Function
RFC Request For Comments
RPC Remote Procedure Call
vOLT Virtualized OLT
vOLTMF vOLT Management Function
SDN Software Defined Network
SBI Southbound Interface
SN Serial Number
SNMP Simple Network Management Protocol
TCP Transmission Control Protocol
ToD Time of Day
TR Technical Report
URL Universal Resource Locator
VLAN Virtual Local Area Network
VNF Virtual Network Function
VNO Virtual Network Operator
WA Work Area
WT Working Text

3 Technical Report Impact

3.1 Energy Efficiency
This Technical Report may impact energy efficiency, as network functions can now be decoupled from
existing standalone nodes. Use of generic hardware, as such not optimized for a specific network
application, and migration of network functions to more distributed locations could lead to higher energy
consumption. However, on demand allocation of hardware resources and hardware sharing across multiple
applications can produce energy gains. This Technical Report does not intend to quantify these opposite
effects on energy efficiency.
Regulatory differences related to electrical power, Heating, Ventilation and Air Conditioning (HVAC) and fire
protection between traditional central offices and datacenters is out-of-scope for this document.
3.2 Security
Security provides "a form of protection where a separation is created between the assets and the threat."
This Technical Report enables the sharing of a common infrastructure and interfaces between various use
cases that may be operated by different departments (e.g., wireline and mobile) or different companies (other
service providers, including other network service providers). This Technical Report also provides an
increased opportunity for Operators to dynamically control the network service behavior, with the use of
interfaces specified in this Technical Report.
It is noted that existing threats, safeguards, and enhancements remain applicable to this Technical Report’s
deployments in the management and control planes. This specification assumes a foundation of current
security best practices that have been defined for the existing Multi Service Broadband Network (MSBN).
However, some new or amplified concerns also appear and without appropriate precautions, the above
conditions could impact a network’s security.
3.3 Privacy
A multi-tenant vOMCI solution hosts functionality for a set of actors with potentially competing interests that
the vOMCI solution will be required to isolate from each other. At the same time, it is required to enable
business interactions between the same set of actors requiring careful design of the points of contact.
A multi-tenant vOMCI solution is a system of sufficient complexity that it will expose new attack vectors to
malicious parties that have access to the system. For example, the “black box” steady state functionality of a
virtualized system may be identical to a corresponding physical network function implementation, but the
elasticity and dynamic behavior a virtualized system is capable of implies significantly different system
responses to load will be possible, which can be exploited for malicious purposes if poorly designed or
executed.
Privacy involves the need to ensure that information to, from and between customers can only be accessed
by those who have the right to do so. Furthermore, privacy requirements can vary by regulatory region. In
general, two ways to ensure privacy is recognized:
• Preventing data, from being copied to a non-intended destination.
• Encrypting data, so that it cannot be understood even if it is intercepted.
This document does not define any specific mechanisms.

4 Overview
This section provides an overview of the vOMCI functionality in the context of various deployment scenarios
(e.g., CloudCO, FANS) and the general purpose for the vOMCI interfaces.
Details of deployment scenarios are treated, for information in some of the Appendixes.

5 vOMCI Solution Overview

The vOMCI solution assumes the Separated-NE mode described in TR-385 [26] where the OLT and the
ONU are managed and configured independently. The vOMCI solution also assumes a northbound SDN
M&C to manage the Access Network topology.
Note: The support of the two modes (eOMCI, vOMCI managed ONUs) on the same management
architecture is still under investigation.
The vOMCI solution disaggregates the ITU-T G.988 OMCI function traditionally hosted in the OLT into a
virtualized network function called the vOMCI function hosted in the Service Provider’s cloud platform.
The vOMCI function is driven via well-defined CRUD (Create, Read, Update and Delete) primitives derived
from YANG data models (i.e., TR-385 [26]) and performs the translation to the ITU-T G.988 OMCI [1].
By disaggregating the vOMCI function the following benefits can be achieved:

• PON deployment and operations improvements by decoupling the ONU management from the OLT.
This is especially true when the Service Providers uses ONUs and OLTs from different vendors.
• Service agility is increased such that new capabilities can be introduced into the service provider’s
network at a faster rate than if the function remains within the OLT. The vOMCI solution is deployed
in multiple deployment configurations including the Cloud Central Office (CloudCO) framework
described in Appendix I and Fixed Access Network Sharing (FANS) described in Appendix II.
The vOMCI solution can optionally organize the ONU Management Proxy, vOMCI Proxy and the associated
vOMCI function instances into a vOMCI service. The vOMCI service disaggregates from the vOLTMF the
vOMCI service logic such as the association of ONUs and vOMCI function instances, ONU management
chain setup, manipulation of the load balance and scale in/out of the vOMCI function instances. The
complexity of the connectivity between entities (e.g., vOLTMF instance, OLT) that interaction with the vOMCI
service is greatly reduced as the vOLTMF instances and OLTs no longer need to connect directly to each
vOMCI function instance. Instead, the OLTs would connect to a vOMCI Proxy and the vOLTMF instance
would connect to the ONU Management Proxy. Refer to Appendix X for the detailed description of the
vOMCI service.
5.1 Onboarding of VNFs/CNFs

The deployment of vOLTMF, vOMCI functions, ONU Management Proxys and vOMCI Proxys as a VNF or a
CNF requires additional considerations for onboarding in the Service Provider's NFV Infrastructure (NFVI)
that eases the integration of the vOMCI solution into the Cloud environment (i.e., CloudCO BAA layer,
CloudCO infrastructure). Minimally this means that the VNFs/CNFs have to be easily integrated in an
Openstack or a Kubernetes infrastructure and implies that a VNF/CNF requires the associated descriptors
and artifacts to ease its integration in the NFVI using well known tools such as Ansible, Heat and Helm.
As typical of NFV deployments multiple instances of those VNFs/CNFs are onboarded overtime for purposes
like: scalability, load balancing, availability, resilience, migration, upgrades.
It is expected that the virtualization techniques, onboarding procedures and the interfaces associated with
the NFVI are not specific to the elements involved in the vOMCI solution and are not specified in this
document.
5.2 vOMCI Function Description

The vOMCI function is responsible for:
• Translating a data model-based input received via the vOLT Management Function to vOMCI
function interface (MVOLTMF-VOMCI), see section 5.7

• Converting the received input into a corresponding set of one (1) or more OMCI messages
• If OMCI MEs are required to be created, the vOMCI function creates the needed OMCI MEs
• Transmitting in sequence the OMCI messages to the OLT where the target ONU is attached
• If an OMCI messages error occurs, returning an error message to the vOLT Management Function
for the vOLT Management Function to recover the ONU to a good state, if needed
• Translating the OMCI message (e.g., responses to requests, notification events) received from the
ONU into data model-based inputs to the vOLT Management Function
The translation of the data model to and from OMCI messages removes the need for the OLT and vOLT
Management Function to have knowledge of the ITU-T G.988 OMCI messages formats for basic and
extended management entities with the associated sequences needed to perform the OMCI operations. In
addition, the vOMCI function decouples changes in the data model (e.g., updates, extensions) of the vOLT
Management Function from the OMCI messages supported by the ONU.
The interfaces provided by the vOMCI function are depicted in Figure 2.
Figure 2 vOMCI Function and vOMCI Proxy Interfaces
The vOMCI function, ONU Management Proxy and the vOMCI Proxy are VNFs/CNFs can be integrated
within and/or consumed as external microservices by the BAA layer or the CloudCO infrastructure, as
described in Appendix I of this Technical Report.
5.2.1 Onboarding the vOMCI Function

The deployment of the vOMCI function as a VNF requires additional considerations for onboarding the VNF
in the Service Provider's network that eases the integration of the vOMCI solution into their Cloud
environment (i.e., CloudCO BAA layer, CloudCO infrastructure). Minimally this means that the vOMCI
function has to be easily integrated in an Openstack or a Kubernetes infrastructure and implies that a vOMCI
function requires the associated descriptors and artifacts to ease its integration in the infrastructure using
well known tools such as Ansible, Heat and Helm.
5.2.2 Management of the vOMCI Function

The following management information is provided by the vOMCI function:
• State of vOMCI function attributes
• Notifications emitted by the vOMCI function
• Configuration and state of gRPC endpoints, or endpoints supported by other protocols;
• Configuration and state of the OMCI message retransmission capabilities if required by the vOMCI
deployment scenario
• Statistics of OMCI message retransmission capability if required by the vOMCI deployment scenario
• Statistics of vOMCI message requests and responses

• Operational information regarding ONUs associated with the vOMCI function
The data model for the management information defined above is defined in the vOMCI function's YANG
model defined in Annex A: vOMCI YANG Modules.
Additionally, inventory information for the vOMCI function is provided through the administrative interface that
deployed the vOMCI function.
5.2.2.1 VNF/CNF Requirements

R-vOMCI_FUNC.10 – A vOMCI function instance MUST be a stand-alone entity with a unique identity. For
example, the vOMCI function could be deployed in the BAA layer or northbound SDN M&C.
R-vOMCI_FUNC.20 - A vOMCI function MUST provide the capability to manage multiple ONUs, regardless
of how many OLTs to which the ONUs attach.
R-vOMCI_FUNC.30 – A vOMCI function MUST be capable of being deployed in an Openstack infrastructure

or a Kubernetes infrastructure.
R-vOMCI_FUNC.31 - The same vOMCI function application SHOULD be available in variants deployable on
both an Openstack and a Kubernetes infrastructure.
R-vOMCI_FUNC.50 - The vOMCI function MUST be packaged with the template and artifacts needed (e.g.,
Heat template, Helm Chart) to ease its onboarding on the infrastructure.
R-vOMCI_FUNC.51 - The NFVI MUST provide a lifecycle management interface for the vOMCI function.
5.2.2.2 Management Requirements

R-vOMCI_FUNC.60 - The vOMCI function MUST provide a MvOLTMF-vOMCI management interface based on
YANG for configuration and state information.
R-vOMCI_FUNC.70 - The MvOLTMF-vOMCI interface MUST support the management of the vOMCI function’s
notifications.
configuration and state of the gRPC endpoints.
inventory and state.
configuration, state and statistics associated with the retransmission capability, if required by the vOMCI
deployment scenario.
statistics associated with the processed vOMCI messages.
R-vOMCI_FUNC.120 - The MvOLTMF-vOMCI interface MUST support the capability to create and delete ONUs
for the purposes of maintaining the ONU's local information within the vOMCI function.

R-vOMCI_FUNC.130 - The MvOLTMF-vOMCI interface MUST support the capability to configure the ONU
management chain information for the purposes of maintaining the ONU's local information within the vOMCI
function.
R-vOMCI_FUNC.140 - When modifying the information used to identify the ONU management chain, the
vOMCI function SHOULD do so without reconfiguring the ONU.
5.2.2.3 ONU Discovery and Operation

This section specifies requirements for ONU Discovery and Operation derived from Appendix V: Supporting
Interactions for vOMCI Deployments.
R-vOMCI_FUNC.200 The vOMCI function MUST provide the capability to send Get MIB data sync message
to the ONU as defined in ITU-T G.988 9.1.3.
R-vOMCI_FUNC.210 The vOMCI function MUST provide the capability to send MibUpload and
MibUploadNext OMCI messages to the ONU as defined in [ITU-T] G.988 I.1.3.
R-vOMCI_FUNC.220 The vOMCI function MUST provide the capability to send MibReset OMCI message to
the ONU as defined in ITU-T G.988 I.1.4.2.
R-vOMCI_FUNC.230 The vOMCI function MUST provide the capability to report configuration align results to
the vOLTMF as defined in ITU-T G.988 I.1.3.
R-vOMCI_FUNC.240 The vOMCI function MUST provide the capability to send OMCI configuration provision
messages to the ONU.
R-vOMCI_FUNC.250 The vOMCI function MUST provide the capability to send a notification to the vOLTMF
that the alignment of a configured ONU has completed.
R-vOMCI_FUNC.260 The vOMCI function MUST support issuing of OMCI messages to obtain ONU device
and the device's software information.
RvOMCI_FUNC.270 The vOMCI function MUST support issuing of OMCI Synchronize time action defined in
section A.2.33 and A.3.33 of G.988 [1] to align the 15-min PM collection interval.
R-vOMCI_FUNC.280 The vOMCI function MUST support the capability to obtain a time of day reference
from a common time source using the NTP protocol defined in RFC 5905 [8].
R-vOMCI_FUNC.290 The vOMCI function MUST align the ONU to the time of day reference obtained by the
vOMCI function upon discovery and realignment.
R-vOMCI_FUNC.295 The vOMCI function MUST respect OMCI dependency on ME creation and/or
configuration for the subset of ONUs managed by this vOMCI function.
Note: R-vOMCI_FUNC.295 realizes that the ONUs should respect OMCI dependencies as defined
in ITU-T G.988 section 9. However, in the scenario where the ONU cannot or doesn't conform to
dependencies as defined ITU-T G.988 section 9, the vOMCI function must respect the OMCI
dependency of the ONUs managed by this vOMCI function.
5.2.3 OMCI Request and Response Processing

When the vOMCI function receives a request for an ONU from the vOLTMF, the vOMCI function:

• Translates the request into one or more OMCI messages

• Formulates the response from the responses to the OMCI messages
• Correlates request/responses from the vOLTMF to the request/responses sent/received from the
OLT.
Note: The vOLTMF is responsible for ensuring all requests sent to the vOMCI function do not have
any dependencies on any pending request which is waiting response from the vOMCI function.
5.2.3.1 Requirements
R-vOMCI_FUNC.300 – The vOMCI function MUST process YANG requests from the vOLTMF that target the
same ONU on a first-in/first-out order basis.
Note: Time consuming YANG requests typically use an asynchronous request/response/notification

pattern where the response to the YANG request is acknowledged and the results are provided in a
separate notification. For example, software download and diagnostic YANG requests would use the
asynchronous pattern.
Note: The behavior for OMCI requests for a given ONU typically uses a serialized, synchronous
request/response pattern.
R-vOMCI_FUNC.301 – The vOMCI function MUST translate YANG requests received from the vOLTMF into
one or more ITU-T G.988 OMCI messages for transmittal to the targeted ONU. The OMCI messages that
comprise the request are transmitted serially.
R-vOMCI_FUNC.310 – The vOMCI function MUST translate received ITU-T G.988 OMCI messages to a
YANG notification or a YANG response associated with a vOLTMF request.
R-vOMCI_FUNC.320 – The vOMCI function MUST translate ITU-T G.988 OMCI baseline messages as
described in section A.3 of ITU-T G.988.
R-vOMCI_FUNC.330 – The vOMCI function MUST translate ITU-T G.988 OMCI extended messages as
described in section A.2 of ITU-T G.988.
R-vOMCI_FUNC.340 – The vOMCI function MUST maintain the OMCI message request life-cycle including
processing of time-outs and re-transmission policies per ITU-T G.988 processing across the MVOMCI-OLT
interface.
R-vOMCI_FUNC.350 – The YANG data encoded in the target, current, data, filters and error payload objects
of messages used on the MvOLTMF-vOMCI interface, MUST be encoded as per RFC 7951 [14].
R-vOMCI_FUNC.360 – If the vOMCI function fails to complete a request from the vOLTMF, the vOMCI
function must return an error response to the vOLTMF/ONU Management Proxy across the MvOLTMF-vOMCI;
interface.
R-vOMCI_FUNC.370 – The vOMCI function MUST ensure that vOMCI messages received through a
remote-endpoint that are sourced from an ONU is the same remote-endpoint that is assigned to the ONU
management chain for the ONU.
R-vOMCI_FUNC.380 – The vOMCI function MUST provide the capability to be configured with and maintain
the ONUs’ management chain including the ONUs’ name, service endpoint or entity identification
corresponding to both upstream ONU Management Proxy or vOLTMF instances and downstream vOMCI
Proxy instances or OLTs.

R-vOMCI_FUNC.381 – The vOMCI function instances MUST provide the capability to forward, based on the
configured ONUs’ management chain, an ONUs’ vOMCI message to either the OLT or vOMCI Proxy.
R-vOMCI_FUNC.382 – The vOMCI function instances MUST provide the capability to forward, based on the
configured ONUs’ management chain, an ONUs’ response to a management request that was received from
the vOLTMF or ONU Management Proxy.
5.2.4 OMCI Notification Processing

The vOMCI function receives ITU-T G.988 OMCI events (e.g., AVC, Alarms) as payload for a source ONU
from the OLT across the MVOMCI-OLT interface.
Upon reception of an OMCI event, the vOMCI function:

• Translates the ITU-T G.988 OMCI alarm into a YANG notification
• Forwards translated YANG notification to the vOLTMF
• Maintains the YANG notification life-cycle including processing of time-outs and re-transmission
policies
Note: The definitions of the policies used by the vOMCI function for time-out and re-transmission of
notifications is outside the scope of this Technical Report.
As a vOMCI function connects to at most one (1) vOLTMF, the vOMCI function simply forwards the
transmitted YANG notification across the MvOLTMF-vOMCI interface to the connected vOLTMF. If the vOMCI
function cannot deliver the notification, the YANG notification is discarded.
5.2.4.1 Alarm and Event Handling

When an ONU detects faults or conditions that are autonomously reported to a management function as a
notification they are classified as:
• Alarms
• Attribute value change (AVC) events
• Threshold Cross Alert (TCA) events
The ONU reports Alarms and TCAs using the alarm procedures documented in section 9 MIB Description
and 7.2 Fault management of ITU-T G.988 [1]. In addition, when changes occur within the ONU’s state, AVC
events are reported to a management function using the AVC procedures documented in section 9 MIB
Description of ITU-T G.988 [1].
Within the context of this Technical Report, the procedure to translate various types of OMCI notification
messages (i.e., Alarm report, AVC) to the corresponding YANG notification and the corresponding reporting
of the notification from the vOMCI function to the vOLTMF is specified.
Alarm-Reporting Control (ARC) is implemented by the vOMCI function by translating the Alarm reporting
control attributes associated with a specific resource as represented by the resource’s YANG module in TR-
385 [26] into the corresponding OMCI messages for Alarm-reporting control as defined in A.1.4.3 of ITU-T
G.988 [1]. For example, the ANI resource in TR-385 [26] has attributes for ARC administration. The vOMCI
function translates these YANG leaf nodes into the corresponding OMCI message(s) to configure the ANI-G
ME.
5.2.4.1.1 Notification Translation and Reporting

When the vOMCI function receives an OMCI Alarm message (Alarm or TCA) from an ONU, the vOMCI
function translates the OMCI Alarm message for the ME (e.g., ANI-G) into the RFC 8632 [17] YANG Alarm

notification for the corresponding resource identifier (e.g., ANI) and then reports the YANG notification to the
vOLTMF/ONU Management Proxy using the “notification” message defined in section 5.7.1 of this Technical
Report.
When the vOMCI function receives an OMCI AVC message from an ONU, the vOMCI function logs the
OMCI AVC message. The translation of the OMCI AVC message is outside the scope of this Technical
Report.
If the OMCI notification message cannot be translated, the notification is still translated using the
“untranslated-omci-notification ” notification specified in Annex A: vOMCI YANG Modules.
5.2.4.1.1.1 Alarm Synchronization

One aspect of the OMCI alarm message is the sequence number associated with the alarm instance. The
vOMCI function can use the Alarm sequence number that is assigned by the ONU. The procedure for
synchronizing Alarms between the vOMCI function and the ONU is described in section A.1.4.2 of ITU-T
G.988 [1].
If the vOMCI function determines that the OMCI alarm message’s sequence number is not aligned with the
vOMCI function’s expected sequence number, the vOMCI function sends an ONU specific event notification
to the vOLTMF that informs the vOLTMF that the vOMCI function and the ONU are out of alignment for
Alarms.
The vOLTMF then sends a synchronize request to the vOMCI function to synchronize the alarms.
Note: The reason that the vOMCI function does not autonomously synchronize the alarm state but
relies on the vOLTMF to perform the action is because in some circumstances the OLT may be a
management function (e.g., ToD) for the ONU as well as the vOLTMF. As such the vOLTMF is the
function that has the responsibility to ensure alarms are synchronized with the ONU as described in
section 5.6.2 of this Technical Report.
5.2.4.2 Test Invocation and Result Handling

ONUs that have implemented tests using OMCI as described in section A.1.5 of ITU-T G.988 [1] can have
these tests invoked by the vOLTMF using the "action" and "rpc" operations as described in section 5.7.1 of
this Technical Report.
In section A.1.5 of ITU-T G.988 [1], OMCI tests are asynchronous in nature when the test is invoked by the
OLT. A test response that is received from the ONU indicates that the ONU has accepted the test for
processing and results of the test are then sent at a later time by the ONU to the OLT as a test result
notification using the transaction identifier to correlate the test results with the test invocation.
As noted previously, the information element that is common to the Test invocation message and the Test
result message is the transaction identifier that was identified by the Test invocation message. This
transaction identifier is part of all ONU YANG Test RPCs and Test result notifications specified in TR-383
[24] and TR-385 [26] that are aligned with the OMCI Test result message formats specified in section A.2.39
of G.988 [1].
During the translation of the YANG test to the associated OMCI ME that implements the test, the vOMCI
function is required to wait for the test results, if successful or test failure in order to reply to the "rpc" or
"action" operation when the "rpc" or "action" operation requires the test results to be returned.
R-vOMCI_FUNC.400 – The vOMCI function MUST translate OMCI alarm messages received across MVOMCI-
OLT interface into an RFC 8632 [17] alarm-notification to be transmitted across the MvOLTMF-vOMCI interface.

R-vOMCI_FUNC.405 – The vOMCI function MUST provide the capability to forward, based on the
configured ONUs’ management chain, the ONUs’ notification to the associated vOLTMF or ONU
Management Proxy for which the vOMCI function has received management requests for the same ONU.
R-vOMCI_FUNC.410 – The vOMCI function MUST log OMCI attribute-value-change messages received
across MVOMCI-OLT interface.
R-vOMCI_FUNC.420 – If the vOMCI function cannot translate an OMCI Alarm or AVC message into a
specific YANG notification, the vOMCI function MUST translate the OMCI message into a vOMCI
untranslated-omci-notification notification defined in Annex A:vOMCI YANG Modules.
R-vOMCI_FUNC.421 – The vOMCI function MUST be capable of sending an onu-alarm-misalignment

notification defined in Annex A: vOMCI YANG Modules whenever the vOMCI function is unable to align the
vOMCI function's alarms for an ONU with the alarms reported by the ONU.
R-vOMCI_FUNC.430 – The vOMCI function MUST discard YANG notifications that cannot be transmitted
across the MvOLTMF-vOMCI interface.
R-vOMCI_FUNC.440 – When detected, the vOMCI function MUST support sending notifications regarding
the failure of communication with the remote endpoint used for vOMCI communication (e.g., gRPC channel
failure).
5.2.5 Performance Monitoring

Section I.4 of ITU-T G.988 [1] describes the processing behavior for obtaining Performance Monitoring (PM)
data (i.e., current, historical) from ONUs using OMCI classical and extended PM management entities. This
section of the Technical Report describes the responsibilities the vOMCI function has in obtaining and
returning performance monitoring data in the context of on-demand and periodic collection of performance
data.
5.2.5.1 On-demand Retrieval of PM Data

On-demand requests for PM data from ONUs are obtained using the vOMCI function’s request and response
processing as described in section 5.2.3 of this Technical Report using the “get” message described in
section 5.7.1 of this Technical Report. This procedure obtains the “latest” data record for the requested PM
counter.
5.2.5.2 Periodic Collection of PM Data

The periodic collection of PM data has not been specified in this issue of this Technical Report. Future
versions of this Technical Report will specify this functionality.
5.3 ONU Management Proxy

The ONU Management Proxy is an optional entity that is introduced between vOLTMF and vOMCI function
in certain vOMCI deployment scenarios to off-load the following capabilities from the vOLTMF:
• Assuming the responsibility of association of ONUs to vOMCI functions where the determination of
which vOMCI function instance is used to manage an ONU, knowing and reacting to the operational
state of vOMCI functions instances regarding what ONUs can be managed by which vOMCI
Functions.

• Simplifying the connectivity between the vOLTMF and the vOMCI function instances where the
vOLTMF only needs to connect to fewer even one ONU Management Proxy instance and not
directly to all the vOMCI function instances for the ONUs the vOLTMF manages.
• Providing load balancing capabilities for ONU management traffic among vOMCI function instances.
The ONU Management Proxy is responsible for forwarding ONU management requests to vOMCI function
instances from vOLTMF instances based on the association knowledge and state between ONU and vOMCI
function instances.
The ONU Management Proxy correlates ONU management requests/responses between vOLTMF instance
and vOMCI function instance for a specific ONU.
The ONU Management Proxy load-balances ONU associations across available vOMCI function instances
based on the ONU manufacturer, software version or other information that can be associated within an
ONU.
The ONU Management Proxy determines the ONUs’ management chain across vOLTMF instances, ONU
Management Proxy instances, vOMCI function instances, vOMCI Proxy instances, and OLTs. The ONU
Management Proxy can be configured with the ONU's management chain or determine the ONUs’
management chain as vOMCI function instances dynamically scale in or out.
Note: Only one entity (i.e., vOLTMF, ONU Management Proxy) is responsible for fulling the vOMCI
service logic that includes the association of the ONU to the vOMCI function instance including the
calculation of the ONU management chain for the association.
5.3.1 Management of the ONU Management Proxy

The following management information is provided by the ONU Management Proxy:
• State of ONU Management Proxy function attributes
• Configuration and state for the vOMCI service such as the vOMCI entities comprising the service.
For vOMCI functions the vendor and software version as well as supported capabilities (e.g.,
Replica support) is provided.
• Configuration of the connectivity information for the links between the ONU Management Proxy,
vOMCI functions, vOMCI Proxys and OLTs. The link information includes properties such as
whether the link is established on demand and the type of topology (i.e., mesh, star, point-to-point).
The type of topology is used by the ONU Management Proxy to determine the connectivity between
the vOMCI function instance and vOMCI Proxy, ONU Management Proxy and OLTs when the
vOMCI Proxy or vOMCI function instance scale in and out.
• Configuration and state of gRPC endpoints
• Statistics of ONU management requests and responses
• Operational information regarding ONUs, such as which vOMCI function instance is in charge of
management of a specific ONU
The data model for the management information defined above is defined in the ONU Management Proxy's
YANG model defined in Annex A: vOMCI YANG Modules.
Additionally, inventory information for the ONU Management Proxy function is provided through the
administrative interface that deployed the ONU Management Proxy function.

5.3.2 General Requirements

R-ONU_MANAGEMENT_PROXY.10 – The ONU Management Proxy MAY be deployed between the
vOLTMF and vOMCI functions in the vOMCI solution.
R-ONU_MANAGEMENT_PROXY.15 – The ONU Management Proxy MUST have the ability to be

configured with the following information elements to be associated with an ONU:
• ONU attachment point to an OLT that includes: OLT name, xPON technology, channel termination
name and PLOAM ONU-ID
• ONU name that identifies the ONU to the vOMCI function and vOMCI Proxy for requests and
notifications across the MVOLTMF-VOMCI interface
• ONU characteristic information including vendor, software version
R-ONU_MANAGEMENT _PROXY.20 – When deployed, the ONU Management Proxy MUST be capable of
connecting to both multiple instances of vOLTMF and vOMCI function instances using either gRPC or Kafka
as defined in section 5.5 of this Technical Report according to the connectivity configuration info.
R-ONU_MANAGEMENT_PROXY.30 – When deployed, the ONU Management Proxy MUST be capable of

maintaining and managing (i.e., creating, deleting, updating and querying) the association between the
ONUs’ name and the corresponding information (e.g., vendor, software version) of the vOMCI function
instance.

determining and maintaining the ONUs’ management chain across vOLTMF instances, ONU management
instances, vOMCI function instances, vOMCI proxy instances, and OLTs for for communication of ONU
management commands and vOMCI messages, based on both ONUs’ info such as vendor, version info
corresponding to a specific vOMCI function instance version, and the connectivity/topology across ONU
Management Proxy, vOMCI function instances, vOMCI proxy, OLTs ensuring the reachability to the OLT to
which the ONUs are attaching.
R-ONU_MANAGEMENT_PROXY.36 – When deployed, the ONU Management Proxy MUST have the option
to be configured with the ONU's management chain.
R-ONU_MANAGEMENT_PROXY.37 – When deployed, the ONU Management Proxy MUST provide the
capability to either support the configuration of the ONU management chain as defined in R-
ONU_MANAGEMENT_PROXY.36 or determine of the ONU management chain as defined in R-
ONU_MANAGEMENT_PROXY.31.

notifying the vOLTMF when the ONU's management chain is modified by the ONU Management Proxy. The
notification allows for multiple ONUs and contains the new ONU management chain.

associating the ONUs to the valid vOMCI function instances based on the association policy between ONU
and vOMCI function instances.

configuring the vOMCI function instances, vOMCI proxy instances with the related ONUs’ management chain
info including the ONUs’ name, service endpoint info or entity identification corresponding to their both
upstream and downstream neighbor entities.

migrating the management of ONUs to other valid vOMCI function instances, updating the migrated ONUs’

ONU management chain and notifying the ONU management chain dynamic change to the related vOMCI
function instances, vOMCI proxy instances and vOLTMF when vOMCI function instances dynamically scale
in or out.

forwarding ONU management commands defined in section 5.7 of this Technical Report between vOLTMF
and vOMCI function instances.

forwarding a management command (e.g., setting the connectivity information that would be used by the
vOMCI function instances) targeted to a type of a vOMCI function to all of the associated vOMCI function
instances.
R-ONU_MANAGEMENT_PROXY.42 – When deployed, when the ONU Management Proxy does not
receive a response to a command when configuring a vOMCI function instance, the ONU Management
Proxy MUST be capable of retrying the command to the failed instance. After a specific number of retries,
the ONU Management Proxy MUST produce a notification to the vOLTMF for the failure to receive a
response. In addition, the ONU Management Proxy internally resolves the failure so that future requests are
not sent to the failed instance.
R-ONU_MANAGEMENT_PROXY.43 – When deployed, the ONU Management Proxy MUST provide the
capability to forward the vOMCI function instances’ notifications to all of the associated vOLTMF instances.

load-balancing the ONU management requests among multiple vOMCI function instances based in
accordance with the association policy between ONU and vOMCI function instances.

correlating ONU management requests and responses conveyed between the vOLTMF and the vOMCI
functions instance for a specific ONU.

forwarding the ONUs’ notifications to the associated vOLTMF that has sent management requests for the
same ONU.
5.3.3 VNF/CNF Requirements

R-ONU_MANAGEMENT_PROXY.60 – An ONU Management Proxy MUST be a stand-alone entity with a
unique identity.
R-ONU_MANAGEMENT_PROXY.70 – An ONU Management Proxy MUST be capable of being deployed in

an Openstack infrastructure or a Kubernetes infrastructure.
R-ONU_MANAGEMENT_PROXY.71 – The same ONU Management Proxy application SHOULD be

available in variants deployable on both an Openstack and a Kubernetes infrastructure.
R-ONU_MANAGEMENT_PROXY.80 – The ONU Management Proxy MUST be packaged with the template
and artifacts needed (e.g., Heat template, Helm Chart) to ease its onboarding on the infrastructure.
R-ONU_MANAGEMENT_PROXY.81 – The NFVI MUST provide a lifecycle management interface for the
ONU Management Proxy.

5.3.4 vOLTMF to ONU Management Proxy Management Interface (MvOLTMF-vOMCI )

R-ONU_MANAGEMENT_PROXY.200 – The MvOLTMF-vOMCI interface MUST support the management of the
ONU Management Proxy’s configuration and state of the message channels as either gRPC or Kafka.
R-ONU_MANAGEMENT_PROXY.210 – The MvOLTMF-vOMCI interface MUST support the configuration and

state for the vOMCI service such as the vOMCI entities comprising the service. For vOMCI functions the
vendor and software version as well as supported capabilities (e.g., Replica support) is provided.
R-ONU_MANAGEMENT_PROXY.220 – The MvOLTMF-vOMCI interface MUST support the configuration of the

connectivity information for the links between the ONU Management Proxy, vOMCI functions, vOMCI Proxys
and OLTs. The link information includes properties such as whether the link is established on demand and
the type of topology (i.e., mesh, star, point-to-point).

ONU Management Proxy’s inventory and state.

ONU Management Proxy’s statistics associated with the processed ONU management and control
commands.
R-ONU_MANAGEMENT_PROXY.250 – When detected, the MvOLTMF-vOMCI interface MUST supporting

sending notifications regarding the failure of communication with the remote endpoint used for ONU
management and control commands communication (e.g., gRPC channel failure).

vOMCI function instance’s notifications for a type of vOMCI function instances based on a set of criteria (i.e.,
vOMCI function vendor, vOMCI function software version).

vOMCI function’s configuration and state of the gRPC endpoints for a type of vOMCI function instances
based on a set of criteria (i.e., vOMCI function vendor, vOMCI function software version).

vOMCI function’s inventory and state for a type of vOMCI function instances based on a set of criteria (i.e.,
vOMCI function vendor, vOMCI function software version).
R-ONU_MANAGEMENT_PROXY.290 – The MvOLTMF-vOMCI interface MUST support the retrieval of a vOMCI

function’s capabilities (i.e., supported OMCI versions, Replica support) for a type of vOMCI function
instances based on a set of criteria (i.e., vOMCI function vendor, vOMCI function software version).

vOMCI function’s configuration, state and statistics associated with the retransmission capability for a type of
vOMCI function instances based on a set of criteria (i.e., vOMCI function vendor, vOMCI function software
version), if required by the vOMCI deployment scenario.

vOMCI function’s statistics associated with the processed vOMCI messages for a type of vOMCI function
instances based on a set of criteria (i.e., vOMCI function vendor, vOMCI function software version).

5.4 vOMCI Proxy

The vOMCI Proxy is an optional entity. It can be introduced in certain vOMCI deployment scenarios to offer a
number of advantages that includes: scalability, load balancing of ONU management traffic, improved
monitoring of ONU management chain's behavior, seamless upgrade and new deployment of vOMCI
function, support of vOMCI functions deployed in different administrative domains.
The vOMCI Proxy is responsible for forwarding the OMCI messages along the vOMCI message path
between the OLT and vOMCI function. The vOMCI Proxy can attach additional metadata to the OMCI
messages and perform functions related to the processing (e.g., OMCI message retransmission) of the
OMCI message.
The vOMCI Proxy correlates the vOMCI message requests and responses for a specific ONU.
The vOMCI Proxy connects to other OLTs, vOMCI functions using gRPC sessions as defined in section
5.8.2 to exchange vOMCI messages.
5.4.1 Management of the vOMCI Proxy

The following management information is provided by the vOMCI Proxy:
• State of vOMCI Proxy function attributes
• Configuration and state of the OMCI message retransmission capabilities if required by the vOMCI
deployment scenario
• Configuration of the connectivity information for the links between the vOMCI Proxys and OLTs. The
link information includes properties such as whether the link is established on demand and the type
of topology (i.e., mesh, star, point-to-point)
• Statistics of OMCI message retransmission capability if required by the vOMCI deployment scenario
• Operational information regarding ONUs associated with the vOMCI Proxy function
The data model for the management information defined above is defined in the vOMCI Proxy's YANG
model defined in Annex A: vOMCI YANG Modules.
Additionally, inventory information for the vOMCI Proxy function is provided through the administrative
interface that deployed the vOMCI Proxy function.
5.4.2 General Requirements

R-vOMCI_PROXY.10 – The vOMCI Proxy function MAY be deployed between the OLT and vOMCI
functions in the vOMCI solution.
R-vOMCI_PROXY.20 – When deployed, the vOMCI Proxy MUST be capable of forwarding vOMCI
messages defined in section 5.8.1 of this Technical Report between OLTs and vOMCI functions.

R-vOMCI_PROXY.30 – When deployed, the vOMCI Proxy MUST be capable of connecting to multiple
instances of OLTs and vOMCI functions according to the connectivity configuration using gRPC sessions as
defined in section 5.8.2 of this Technical Report.
R-vOMCI_PROXY.40 – When deployed, the vOMCI Proxy MUST be capable of performing the OMCI
message retransmission function for the management of an ONU.
R-vOMCI_PROXY.50 – When deployed, the vOMCI Proxy MUST correlate the vOMCI message requests
and responses for a specific ONU.
R-vOMCI_PROXY.55 – When deployed, the vOMCI Proxy MUST ensure that vOMCI messages received
through a remote-endpoint that are targeted to or sourced from an ONU is the same remote-endpoint that is
assigned to the ONU management chain for the ONU.
R-vOMCI_PROXY.56 – When deployed, the vOMCI Proxy MUST provide the capability to be configured with
the ONUs’ management chain info including the ONUs’ ID, service endpoints info or entity identification
corresponding to both upstream vOMCI function instances and downstream OLTs.
R- vOMCI_PROXY.57 – When deployed, the vOMCI Proxy MUST provide the capability to forward, based
on the configured ONUs’ management chain, the ONUs’ vOMCI message requests to the OLT to which
ONUs’ are attaching.
R- vOMCI_PROXY.58 – When deployed, the vOMCI Proxy MUST provide the capability to forward, based
on the configured ONUs’ management chain, the ONUs’ notifications to the associated vOMCI function
instance from which the vOMCI Proxy has received vOMCI message requests for the same ONU.
5.4.3 VNF/CNF Requirements

R-vOMCI_PROXY.60 – A vOMCI Proxy MUST be a stand-alone entity with a unique identity.
R-vOMCI_PROXY.70 – A vOMCI Proxy MUST be capable of being deployed in an Openstack infrastructure

or a Kubernetes infrastructure.
R-vOMCI_PROXY.71 – The same vOMCI Proxy application SHOULD be available in variants deployable on
both an Openstack and a Kubernetes infrastructure.
R-vOMCI_PROXY.80 – The vOMCI Proxy MUST be packaged with the template and artifacts needed (e.g.,
Heat template, Helm Chart) to ease its onboarding on the infrastructure.
R-vOMCI_PROXY.81 – The NFVI MUST provide a lifecycle management interface for the vOMCI Proxy.
5.4.4 vOLTMF to vOMCI Proxy Management Interface

R-vOMCI_PROXY.90 – The MvOLTMF-vOMCI interface MUST support the management of the vOMCI Proxy’s
configuration and state of the gRPC endpoints.
R-vOMCI_PROXY.91 – The MvOLTMF-vOMCI interface MUST support the management for association between
vOMCI functions/OLTs/ONUs.
inventory and state.

R-vOMCI_PROXY.105 – The MvOLTMF-vOMCI interface MUST support the configuration of the connectivity for
the vOMCI proxy instances with both vOMCI function instances and OLTs.
configuration, state and statistics associated with the retransmission capability, if required by the vOMCI
deployment scenario.
statistics associated with the processed vOMCI messages.
R-vOMCI_PROXY.130 – When detected, the MvOLTMF-vOMCI interface MUST supporting sending notifications
regarding the failure of communication with the remote endpoint used for vOMCI communication (e.g., gRPC
channel failure).
5.5 OLT Description

The Optical Line Termination (OLT) is a physical network function that in the vOMCI solution is responsible
for providing the interface to the:
• Decapsulating and processing received vOMCI messages and sending them to the target ONU
using the relevant PON OMCI channel.
• Process the OMCI messages received from the ONU and encapsulating them into vOMCI
messages and send them to the vOMCI function or vOMCI Proxy.
• Transmitting PLOAM notifications to the vOLT Management Function
5.5.1 vOMCI Function Connectivity

A vOMCI function instance is required to manage multiple ONU devices that have been elected to be
managed by that vOMCI function. The OLT has to be capable of establishing communication sessions with
multiple, different vOMCI function endpoints for managing a set of ONUs.
These relationships require an association between an ONU device and a vOMCI function instance.
For example, in the following figure OLT A is connected to two (2) vOMCI functions, using two (2) vOMCI
communication sessions, where these vOMCI functions manage the ONUs from vendor C and D
respectively.

Figure 3 Multiple Session – OLT to vOMCI Connectivity
Likewise, the vOMCI function can establish communication sessions with multiple OLTs in order to manage
one (1) or more ONUs attached to the OLT where the ONUs are associated with the vOMCI function. For
example, in the following figure, the vOMCI function manages ONU’s from Vendor C and D that are attached
to OLT A and B respectively.
Figure 4 Multiple Session – vOMCI to OLT Connectivity (single vOMCI function)
In the following figure the ONUs from vendor C and D are managed by different vOMCI management
functions.

Figure 5 Multiple Session – vOMCI to OLT Connectivity (vendor specific vOMCI function)
In the following figure, the vOMCI Proxy is used to provide a session aggregation point toward the OLT. For
example, in Figure 5 the OLT required separate communication sessions (gRPC tunnels) to vOMCI functions
for ONU Vendor C and D. Using the vOMCI Proxy, OLT A would only need one communication session to
the vOMCI Proxy.
Figure 6 Multiple Session – vOMCI to OLT Connectivity (vOMCI Proxy)

R-OLT.10 – The OLT MUST provide the capability to be configured with the ONUs’ management chain
including the ONUs’ identifier, remote endpoints or entity identification corresponding to either upstream
vOMCI function instances or vOMCI Proxy instances.
R-OLT.20 – The OLT MUST provide the capability to be configured with the ONU to remote endpoint
association based on one or more of the following criteria:
• Per v-ANI as defined in TR-385 [26]
• ONU vendor
• Any ONU
R-OLT.30 – The OLT MUST provide the capability to communicate with a minimum of four (4) remote
endpoints.
R-OLT.40 – The vOMCI function MUST provide the capability to communicate with one (1) or more OLTs.
R-OLT.50 – The OLT MUST be capable of processing the Network Wide ONU identifiers (i.e., OLT
Id/Channel Termination Id/ONU Id) attached as additional metadata to the received OMCI messages in order
to forward them on the correct OMCI channel of the target ONU.
R-OLT.60 – The OLT MUST be capable of attaching the Network Wide ONU identifier (i.e., OLT Id/ Channel
Termination Id /ONU Id with the associated vOMCI function) as additional metadata to the OMCI messages
responses sent by the ONU before forwarding them to the associated remote endpoint (i.e., vOMCI function,
vOMCI Proxy.
5.5.1.1.1 Activation Requirements

This section of the Technical Report provides requirements derived from Appendix V: Supporting Interactions
for vOMCI Deployments for ONU activation.
R-OLT.100 – If the OLT provides G-PON interfaces, the OLT MUST support the ONU activation process as
defined in Annex D.4 of ITU-T G.984.3.
R-OLT.110 – If the OLT provides XG-PON interfaces, the OLT MUST support the ONU activation process as
defined in Section 12 of ITU-T G.987.3 [3].
R-OLT.120 – If the OLT provides XGS-PON interfaces, the OLT MUST support the ONU activation process
as defined in Annex C.12 of ITU-T G.9807.1 [4].
R-OLT.130 – If the OLT provides NG-PON2 interfaces, the OLT MUST support the ONU activation process
as defined in Section 12 of ITU-T G.989.3 [5].
R-OLT.140 – If the OLT provides G-PON, XG-PON, XGS-PON or NG-PON2 interfaces, the OLT MUST send
ONU presence notification message (including SN and optional PLOAM password/Registration-id) to
vOLTMF as defined in BBF TR-385 issue2 and ITU-T G.984.3 [2] Appendix VI.
5.5.2 OMCI Message Forwarding

The OLT receives requests from the vOMCI function or vOMCI Proxy and processes the vOMCI message
and forwards the decapsulated OMCI message to the destination ONU device through the OMCC channel
that is associated with that ONU device. Likewise, OMCI response messages and OMCI notifications

received from an ONU device are processed and encapsulated into a vOMCI message and sent to the
remote endpoint that is associated with that ONU device.
5.5.2.1 ToD Message Forwarding

In OMCI solutions, the OLT synchronizes the Time of Day with the ONU via the OMCI channel using the
OLT-G ME defined in ITU-T G.984.3 clause 10.4.6, ITU-T G.987.3 clause 13.2, ITU-T G.989.3 clause 13.2
and ITU-T G.988 clause 9.12.2. When using the vOMCI solution, time sensitive information (i.e., GEM
superframe, TstampN) sourced by the OLT cannot be provided by the vOMCI function when the vOMCI
function sends the OLT-G ME, the time sensitive information has to be provided by the OLT. To permit the
OLT to provide the needed time sensitive information, the vOMCI function can either use the:
• tod_packet_msg defined in section 5.8.1 to inform the OLT that the OLT is required to include the
time sensitive information into the OLT-G ME sent by the vOMCI function
• olt_onu info_req defined in section 5.8.1 to query the OLT for information needed for OMCI
functioning. The response to this information includes the time sensitive information that the vOMCI
function needs to pass in the OLT-G ME.
R-OLT.200 – The OLT MUST forward the OMCI messages encapsulated in the payload of the vOMCI
request that is received via the vOMCI function or vOMCI Proxy instance to the OMCC channel associated
with the destination ONU device.
R-OLT.210 – The OLT MUST calculate the Message Integrity Check (MIC) for the OMCI message and insert
the MIC field into the OMCI message as defined in section 11.2.8 of ITU-T G.988 [1] prior to forwarding the
OMCI message to the OMCC channel associated with the destination ONU instance.
R-OLT.220 – The OLT MUST encapsulate the OMCI messages received from the OMCC channel in the
payload of a vOMCI response/notification and forward it to the vOMCI function instance that is associated
with the source ONU device.
R-OLT.230 – The OLT MUST apply the GEM superframe and TstampN sourced from the OLT in the OLT-G
ME when the OLT receives a VomciMessage message with the tod_pack_msg field prior to forwarding the
OMCI message to the OMCC channel associated with the destination ONU instance.
R-OLT.240 – When the OLT receives an OltMessage message with the olt_onu_info_req field, the OLT
MUST respond to the messages with an olt_onu_info_resp message.
R-OLT.250 – When the vOMCI remote-endpoint is assigned to the ONU's vANI and the OLT receives a
vOMCI message targeted for an ONU, the OLT MUST ensure the remote-endpoint through which the
message is received is the same remote-endpoint assigned to the vANI.
R-OLT.260 – The OLT MUST provide the capability to forward, based on the configured ONUs’ management
chain, the ONUs’ vOMCI message responses to the vOMCI function instance or vOMCI Proxy instance.
5.5.3 vOMCI ONU Notifications

The OLT is the endpoint of the PLOAM channel with an ONU device where events occurring during the ONU
discovery, state change, activation and signal loss that are needed by the vOLT Management function are
reported by the OLT to the vOLT Management Function as notifications.

R-OLT.300 – The OLT MUST notify the vOLTMF whenever the ONU enters the ITU-T G.984.3, ITU-T G.987,
ITU-T G.9807 and ITU-T G.989 ONU Activation Operation State “O5”.
R-OLT.310 – The OLT MUST notify the vOLTMF when the ONU exits the ITU-T G.984.3, ITU-T G.987, ITU-
T G.9807 and ITU-T G.989 ONU Activation Operation State “O5” or POPUP state "O6".
R-OLT.320 – The OLT MUST notify the vOLTMF whenever the OLT detects or clears a Loss of OMCI
Channel (LOOC) communication as defined in section 14.2.1 of G.984.3 [2].
R-OLT.330 – The OLT MUST support sending notifications for ONU presence state changes with the
parameters to identify the ONU to the vOLTMF. The notification SHOULD follow the definition of ONU state
change notifications defined in TR-385 [26].
R-OLT.340 – When detected, the OLT MUST supporting sending notifications regarding the failure of
communication with the remote endpoint used for vOMCI communication (e.g., gRPC channel failure).
R-OLT.350 – The OLT MUST provide the capability to forward, based on the configured ONUs’ management
chain, the ONUs’ vOMCI notifications to the associated vOMCI function instance or vOMCI proxy instance
from which the OLT received the vOMCI message requests for the same ONU.
5.5.4 Management of the OLT

OLT management for the vOMCI solution uses the OLT's existing
management interfaces and extends the management information to
include:
• Configuration of the connectivity information for the links between vOMCI Proxys and OLTs. The link
information includes properties such as whether the link is established on demand and the type of
topology (i.e., mesh, star, point-to-point
• Notifications emitted by the OLT
• State of ONUs managed by the OLT
The data model for the management information defined above is defined in the pOLTs PON YANG model
TR-385i2 [26] and the OLT's vOMCI YANG model identified in Annex A:vOMCI YANG Modules.
R-OLT.400 – The OLT MUST support the configuration of the connectivity to either vOMCI function
instances or vOMCI Proxy instances.
R-OLT.405 – The OLT MUST provide the capability for management of the notifications emitted by the OLT.
R-OLT.410 – The OLT MUST provide the capability for management of the configuration and state of the
gRPC endpoints.
R-OLT.420 – The OLT MUST provide the capability for management of the statistics associated with the
vOMCI messages processed within the OLT.

5.6 vOLT Management Function Description

The vOLT Management Function (vOLTMF) is the entity that provides management of the functions
associated with an OLT and the OLT’s corresponding Passive Optical Networks (PON). A portion of these
management functions includes the management of the ONU’s attached to an OLT’s PON. This section of
the Technical Report describes the capabilities needed by the vOLTMF for the implementation of the vOMCI
solution that includes:
• vOMCI function/vOMCI Proxy function configuration (OMCI message retransmission) and monitoring
• OLT/vOMCI function/vOMCI Proxy function infrastructure connectivity to support ONU management
chains. Functionality includes creation and deletion of connections between the entities, monitoring
of the connection
• Configuration of the ONU management chain using the connectivity infrastructure between the:
o OLT and ONU Management Proxy when the ONU Management Proxy is deployed
o OLT/vOMCI function/vOMCI Proxy function when connected directly to a vOMCI function
instance
• Configuration of the connectivity information for the links between the ONU Management Proxy,
vOMCI functions, vOMCI Proxys and OLTs. The link information includes properties such as whether
the link is established on demand and the type of topology (i.e., mesh, star, point-to-point)
• Support for vOMCI interactions, including cancelling and rollback of interactions, between entities
(e.g., OLT, vOMCI function, vOMCI Proxy, vOLTMF) to fulfill services associated with the ONU (e.g.,
automated ONU discovery, ONU detection, multiple and parallel operation for multiple ONUs)
• ONU configuration and operation
5.6.1 Requirements
5.6.1.1 ONU Attachment and Initial Provisioning Requirements

This section of the Technical Report defines requirements for when the vOLTMF is notified about ONU
attachments along with the associated provisioning actions that happen when an ONU is powered on/off,
attaches or detaches from an OLT, or rebooted. The requirements are derived from Appendix V: Supporting
Interactions for vOMCI Deployments.
R-vOLTMF.100 – The vOLTMF MUST inform the vOMCI function, vOMCI Proxy and OLT when an ONU is
to be managed using the vOMCI solution.
R-vOLTMF.110 – The vOLTMF MUST inform the vOMCI function, vOMCI Proxy and OLT when an ONU is
no longer to be managed using the vOMCI solution.
R-vOLTMF.111 – The vOLTMF MUST inform the vOMCI function when an ONU is determined to be online
and to be managed or has gone temporarily offline (e.g., reboot).
R-vOLTMF.112 – When ONU is determined to be online and to be managed, the vOLTMF MUST ensure the
OLT and ONU are properly configured with the ONU's configuration.
R-vOLTMF.120 – The vOLTMF MUST support sending ReplaceConfig message to the vOMCI function.
R-vOLTMF.130 – The vOLTMF MUST support authentication of an ONU as defined in ITU-T G.984.3
Appendix VI, ITU-T G.987.3 section 15.2, ITU-T G.989.3 section 15.2, ITU-T G.9807.1 Annex C.15.
R-vOLTMF.140 – When an ONU is considered as a nomadic ONU that can change the OLT attachment
point to which it attaches, the vOLTMF SHOULD support both authentication of an ONU as defined in ITU-T

G.984.3 Appendix VI, ITU-T G.987.3 section 15.2, ITU-T G.989.3 section 15.2, and ITU-T G.9807.1 Annex
C.15 and also provide capability to check if the ONU is permitted to attach to the attachment point.
R-vOLTMF.150 – The vOLTMF MUST support [R-150], [R-151], [R-154] and [R-155] in TR-156 [20] section
7.2 Initial Provisioning of ONUs.
R-vOLTMF.160 – The vOLTMF MUST support sending commands to the OLT to configure OLT resources
as defined in section 5 of TR-413 [28].
R-vOLTMF.170 – The vOLTMF MUST support sending an ONU discovery notification with the discovered
device and software information and the discovery status (e.g., successful, failed) to the northbound SDN
M&C.
R-vOLTMF.180 – The vOLTMF MUST receive the configuration requests for PON devices from a
northbound SDN M&C, which includes the identification of the PON device (i.e., OLT name, ONU ID).
R-vOLTMF.190 – If there are more than one vOLTMF instance (i.e., vOLTMF cluster) to manage PON
devices, the management and control requests MUST be assigned to one of the instances based on
relationship between the PON device ID and the vOLTMF instances.
R-vOLTMF.191 – The vOLTMF instance MUST ensure that simultaneous uncommitted requests targeted to
the same ONU do not have inter-dependencies between requests.
R-vOLTMF.200 – The vOLTMF MUST be the authoritative source for sending the corresponding
management and control information to either OLTs or ONUs based on the identification of the PON device.
R-vOLTMF.210 – The vOLTMF MUST receive the requests for configuration and operational data of ONUs
from northbound SDN M&C functions.
R-vOLTMF.220 – The vOLTMF MUST provide the capability to send notifications (e.g., device online/offline,
alarms) that originate from PON devices to northbound SDN M&C functions.
R-vOLTMF.221 – When the vOLTMF does not receive a response to a command when configuring a vOMCI
function instance, the vOLTMF MUST be capable of retrying the command to the failed instance. After a
specific number of retries, the vOLTMF MUST produce a notification to the northbound SDN M&C function
for the failure to receive a response. In addition, the vOLTMF internally resolves the failure so that future
requests are not sent to the failed instance.
5.6.1.2 vOLTMF – vOMCI function Connectivity Requirements

This section of the Technical Report defines requirements for interactions between the vOLTMF and vOMCI
function that were derived from Appendix VI: Connectivity Management among vOLTMF(s) and vOMCI
functions.
R-vOLTMF.300 – The vOLTMF SHOULD be implemented with one or clustered instances, where each
vOLTMF instance could interact with one or more vOMCI function instances directly or indirectly. For
example, the ONU Management Proxy.
R-vOLTMF.310 – The vOLTMF SHOULD support parallel configuration requests of multiple different ONUs
that are attached to the same or different PON links.
R-vOLTMF.320 – The vOLTMF MUST maintain the management and control states for all the ONUs.
R-vOLTMF.330 – The vOLTMF MUST provide the capability to configure the ITU-T G.988 timer expiration
timeout (Tmaxi) and number of retries retry counter (Rmaxi) values for a given vOMCI function.

5.6.2 ONU Alarm Management

The vOLTMF provides a digital representation of the ONU’s alarm instances as well as the management
functionality associated with maintaining the Alarms for an ONU.
The vOLTMF represents and manages the alarm instances of an ONU by implementing the following
features and resources and minimally uses the Alarm Management YANG data module as defined by RFC
8632 [17]:
• Alarm List: This feature maintains the current list of alarms
• Alarm Shelving: This feature maintains the current list of shelved alarms. A shelved alarm is an
alarm that has its OMCI ARC attribute enabled.
Note: vOLTMF can implement other features of the Alarm Management YANG data module but the
Alarm List resource and Alarm Shelving are the needed resources and features to interact with an
ONU via the vOMCI function. As such the additional capabilities related to Alarms that can be
provided by the vOLTMF is outside the scope of this Technical Report.
R-vOLTMF.400 – The vOLTMF MUST provide the capability to retrieve the list of current alarms for an ONU.
R-vOLTMF.410 – The vOLTMF MUST provide the capability to retrieve the list of current shelved alarms.
R-vOLTMF.420 – The vOLTMF MUST provide the ability to enable and disable ONU alarm reporting.
5.6.3 ONU OMCI Topology Management

The vOLTMF maintains the topology of ONUs that includes information that identifies the ONU to the OLT,
vOMCI function, vOMCI Proxy function as well as information about the OLT attachment point that connects
the ONU. The topology information is necessary to:
• Maintain configuration information for the ONU that corresponds whether the ONU is managed
through the vOMCI solution or is managed as an embedded solution within the OLT.
• Maintain the ONU management chain that depicts the path vOMCI messages will traverse through
the OLT and if necessary, the instances of the vOMCI function and vOMCI Proxy function in order to
send commands and receives responses and notifications. The ONU management chain is
maintained when the ONU is managed via through the vOMCI solution.
• Maintain the association of the ONU identifiers that correspond to an ONU that are needed by the
OLT, vOMCI function and vOMCI Proxy function in order to send requests and receive notifications
from the entities related to the ONU.
• Inform the OLT, ONU Management Proxy and if necessary, the vOMCI and vOMCI Proxy functions
when an ONU is available for OMCI communication and when the ONU is no longer available for
OMCI communication. The vOLTMF uses onu-presence-state-change notifications from the OLT to
help determine if the ONU has reached an onu-presence-state in which it can be communicated
with through the OLT's OMCI channel (i.e., ITU-T G.984.3 Operation state O5/O6).
R-vOLTMF.500 – The vOLTMF MUST be able to assess whether the vOMCI function can communicate with
the ONU across the ONU management chain and OMCI communication channel.

R-vOLTMF.510 – The vOLTMF MUST provide the capability to receive notifications from the OLT regarding
the OMCI communication channel state between the ONU and OLT.
R-vOLTMF.520 – The vOLTMF MUST provide the capability to receive notifications from the ONU
Management Proxy, vOMCI function, vOMCI Proxy and OLT regarding the operational state of an ONU's
management chain.
R-vOLTMF.530 – When deployed without an ONU Management Proxy, the vOLTMF MUST provide the
capability to configure the vOMCI function whenever an ONU's ONU management chain is modified or the
OMCI communication channel between the ONU and OLT changes.
R-vOLTMF.531 – When deployed without an ONU Management Proxy, the vOLTMF MUST provide the
capability to configure the vOMCI Proxy whenever an ONU's ONU management chain is modified or the
OMCI communication channel between the ONU and OLT changes.
R-vOLTMF.532 – The vOLTMF MUST provide the capability to configure the OLT whenever an ONU's ONU
management chain is modified or the OMCI communication channel between the ONU and OLT changes.
R-vOLTMF.533 – When deployed with the ONU Management Proxy, the vOLTMF MUST provide the
capability to configure the ONU Management Proxy whenever the OMCI communication channel between
the ONU and OLT changes.
R-vOLTMF.542 – The vOLTMF MUST maintain the following information elements to be associated with an
ONU:
• ONU attachment point to an OLT that includes: OLT name, xPON technology, channel termination
name and PLOAM ONU-ID
• ONU name that identifies the ONU to the vOMCI function and vOMCI Proxy for requests and
notifications across the MVOLTMF-VOMCI interface
• ONU characteristic information including ONU vendor and software version
• ONU management chain that identifies the OLT or when deployed without an ONU Management
Proxy, the path between the OLT, vOMCI Proxy, vOMCI functions and OLT for communication of
vOMCI messages between the vOMCI function and the OLT.
R-vOLTMF.543 – The vOLTMF MUST provide the capability to be configured with the mapping information
to associate the ONU characteristics (i.e., vendor, software info) with the versions supported by vOMCI
function instances.
R-vOLTMF.550 – The vOLTMF MUST provide the ability to synchronize the ONU topology and associated
ONU information elements maintained by OLT, ONU Management Proxy, vOMCI function, vOMCI Proxy and
the vOLTMF. The vOLTMF is considered the authoritative source of the ONU topology information.
5.6.3.2 vOMCI Entity Connectivity Management

The vOLTMF establishes an ONU management chain for an ONU using vOMCI entities. For example, the
OLT and when the ONU Management Proxy is not deployed the vOMCI function and vOMCI Proxy function.
However, before the vOLTMF establishes the ONU management chain for an ONU, connectivity between
the vOMCI entities must first be established. The vOLTMF maintains the connectivity information between
vOMCI entities. This information includes the network addressing information and security credentials
needed to establish the communication channels between vOMCI entities across the MVOMCI-OLT interface.

When the ONU Management Proxy is deployed, the ONU Management Proxy establishes an ONU
management chain for an ONU using vOMCI entities (i.e., vOMCI Proxy function, vOMCI function). At the
same time, the ONU Management Proxy maintains the connectivity configuration information between
vOMCI entities.
5.6.3.2.1 Requirements
R-vOLTMF.600 – The vOLTMF MUST maintain the information that is needed to establish the
communication channel between vOMCI entities (i.e., OLT, vOMCI function, vOMCI Proxy).
R-vOLTMF.610 – The vOLTMF MUST provide the capability to configure the OLT with the connectivity
information that is needed to establish the communication channel across the MVOMCI-OLT interface.
R- vOLTMF.611 – When the ONU Management Proxy is deployed, the vOLTMF MUST provide the
capability to be notified when an ONU's manage chain is modified by the ONU Management Proxy.
R- vOLTMF.612 – The vOLTMF MUST provide the capability to configure the OLT with the ONU to remote
endpoint association defined in R-OLT.20 when there is an update to the association.
R-vOLTMF.615 – The vOLTMF MUST provide the capability to configure the ONU Management Proxy with
the connectivity information for the links between the ONU Management Proxy, vOMCI functions, vOMCI
Proxys and OLTs to establish the communication channel across the MVOLTMF-VOMCI interface. The link
information includes properties such as whether the link is established on demand and the type of topology
(i.e., mesh, star, point-to-point).
R-vOLTMF.620 – The vOLTMF MUST provide the capability to configure the vOMCI function with the
connectivity information that is needed to establish the communication channel across the MVOMCI-OLT
interface.
R-vOLTMF.630 – The vOLTMF MUST provide the capability to configure the vOMCI Proxy function with the
connectivity information that is needed to establish the communication channel across the MVOMCI-OLT
interface.
R-vOLTMF.640 – The vOLTMF SHOULD provide the capability to be configured by a northbound SDN M&C
with the connectivity information that is needed to establish the communication channel across the MVOMCI-OLT
interface.
5.6.4 ONU Persistent Configuration and State Management

The vOLTMF provides a digital representation of the ONU for use by various northbound SDN M&C systems.
As such the vOLTMF maintains the authoritative configuration state of the ONU to which the ONU is
synchronized. In addition, the vOLTMF maintains the current set of alarms for the ONU. When the vOLTMF
identifies that the ONU configuration is not aligned with the configuration maintained by the vOLTMF, the
vOLTMF aligns the ONU to the vOLTMF configuration for the ONU. Likewise, when the vOLTMF identifies
that the alarm data store is not current, the vOLTMF requests the current alarm information from the ONU.
5.6.4.1 ONU Datastore Tags

The vOLTMF and vOMCI function maintains the configuration datastore of an ONU. The vOLTMF is the
authoritative datastore of the ONU that is represented by the associated ONU YANG modules. The vOMCI
function maintains the ONU's representation using ITU-T G.988 OMCI MEs. In order keep the vOLTMF's
datastore of an ONU synchronized with the vOMCI's representation of the ONU's datastore, the vOLTMF can
optionally use an ONU datastore tag (DST) that represents the latest synchronization state of the ONU's
configuration datastore as seen by the vOLTMF. While the method of how the value of the DST is

determined is different from how the value of the MIB data sync (MDS) is determined; the usage of ONU
datastore tags is like the MDS used by the vOMCI function to synchronize the ONU's representation in the
ONU with the representation maintained by the vOMCI function.
When the vOLTMF uses the DST attribute of an ONU's datastore whenever the vOLTMF acts on the ONU's
configuration datastore, the vOLTMF uses the datastore_tag field in the ReplaceConfig, UpdateConfig, RPC
and Action messages defined in section 5.7.1. The vOLTMF is able to retrieve the last DST maintained by
the vOMCI function using the datastore_tag field in the GetDataResp message. If the DST is not supported
by either the vOMCI function or vOLTMF or has not been set by the vOLTMF, the datastore_tag field is
defined by the empty string.
R-vOLTMF.700 – The vOLTMF MUST maintain the configuration data for each ONU.
R-vOLTMF.710 – The vOLTMF MUST align (synchronize) the ONU configuration whenever the vOLTMF
detects the ONU is mis-aligned with the configuration maintained by the vOLTMF. One special case includes
whenever the vOMCI function has never completed the MIB synchronization function with the ONU.
R-vOLTMF.720 – The vOLTMF MUST align (synchronize) the ONU alarm state whenever the vOLTMF
detects the ONU alarm status is mis-aligned.
R-vOLTMF.731 – The vOLTMF MUST provide the capability to align ONU alarms detected by the OLT.
R-vOLTMF.750 – When using Datastore Tags to align the configuration data of an ONU and the vOLTMF
acts on the ONU's configuration datastore, the vOLTMF MUST provide a unique, in the context of the ONU,
value for the datastore_tag field in the ReplaceConfig, UpdateConfig, RPC and Action messages defined in
section 5.7.1.
5.7 vOLT Management Function to vOMCI Function or vOMCI

Proxy Interface (MVOLTMF-VOMCI)
The MvOLTMF-vOMCI interface receives YANG configuration data, actions and requests for operational data from
the vOLTMF for a target ONU, the vOMCI function or vOMCI Proxy instances. Similarly, the interface is used
to transmit the resulting responses from the vOMCI function or vOMCI Proxy back to the vOLTMF.
Additionally, the MvOLTMF-vOMCI interface is used by the vOMCI function to send autonomous events or
notifications that are emitted from ONUs to the vOLTMF as well as autonomous events and notifications that
are for the vOMCI function or vOMCI Proxy entities themselves. Furthermore, the interface is used by the
vOLTMF to convey ONU device lifecycle, ONU management chain and topology information to both the
vOMCI function and vOMCI Proxy.
The messages conveyed on the MvOLTMF-vOMCI interface are serialized as Google Protobufs (GPB) [29]. The
YANG models contained within the messages use TR-385 Issue 2 for ONUs and Annex A: vOMCI YANG
Modules for vOMCI function and vOMCI Proxy instances. The YANG models are encoded in JSON using
RFC 7951 [14] encoding.
Note: Encoding of YANG models that are directly converted to GPB instead of encoding the YANG
models using RFC 7951 is for future study.

5.7.1 Information Model and Messages

The information conveyed on the MvOLTMF-vOMCI interface includes data model messages that are targeted to
the ONUs managed by the vOMCI function. Additionally, data model messages can be directed toward the
vOMCI function or vOMCI Proxy instances themselves (e.g., ONU device lifecycle, ONU topology
information).
The messages used on the interface are comprised of a header and a body. The information is the header is
common to all messages and each message within the body has its own set of attributes that comprise the
request, response or notification.
message Msg {
Header header = 1;
Body body = 2;
}
Figure 7 vOLTMF-vOMCI Message
5.7.1.1 Message Header

The message header is comprised of 2 fields which are optional in the
protocol.
The msg_id field is an optional used by the vOLTMF to correlate requests
with responses. Likewise, the vOMCI function, ONU Management Proxy or
vOMCI Proxy can use the msg_id field to identify notifications sent by these
entities.
The sender_name field is an optional field that provides the unique name of
the entity that originated the request, response or notification (i.e., vOMCI
Proxy, vOMCI function, ONU Management Proxy, vOLTMF).
The recipient_name field is an optional field that provides the unique name
of the entity that is to receive the request, response or notification (i.e.,
vOMCI Proxy, vOMCI function, ONU Management Proxy, vOLTMF). The
recipient_name field is used in certain message transfer protocols like Kafka
to verify the intended recipient of the message.
The object_type field is a mandatory field that provides the type of object or
resource (i.e., vOMCI Proxy, vOMCI function, ONU Management Proxy,
ONU) that is the subject of the message.
The object_name field is a mandatory field that provides the name of object
or resource that is the subject of the message.
Note: The configuration of the names for the vOLTMF, ONU Management Proxy, vOMCI function or
vOMCI Proxy instances occurs outside of MVOLTMF-VOMCI interface, such as by command-line
parameter or environment variable passed to the vOMCI function or vOMCI Proxy instances at
startup.
The msg_id, sender_name and recipient_name fields are useful for logging
and troubleshooting purposes as they can help identify interactions between

the vOLTMF and the vOMCI function, ONU Management Proxy or vOMCI
Proxy.
message Header {
string msg_id = 1; // Message identifier to
// 1) Identify requests and notifications
// 2) Correlate requests and response
string sender_name = 2; // Unique name of the entity that
// originated the message
string recipient_name = 3; // The name of the entity that is to
// receive the request
OBJECT_TYPE object_type = 4; // The type of the object or
// resource that is subject of the message
string object_name = 5; // The name of the object or resource
enum OBJECT_TYPE {
ONU = 0;
VOMCI_FUNCTION = 1;
VOMCI_PROXY = 2;
VOLTMF = 3;
ONU_MANAGEMENT_PROXY = 4;
VOMCI_FUNCTION_TYPE = 5; //Category of vOMCI function instances
}
}
Figure 8 vOLTMF-vOMCI Header Message
5.7.1.2 Message Body

The body of the vOLTMF-vOMCI message can be a request, response or
notification message. Request messages originate from the vOLTMF while
response and notification messages originate from the vOMCI function,
ONU Management Proxy or vOMCI Proxy instances.

message Body {
oneof msg_body {
Request request = 1;
Response response = 2;
Notification notification = 3;
}
}
Figure 9 vOLTMF-vOMCI Message Body
5.7.1.2.1 Request and Response Messages

Request messages are originated from the vOLTMF are directed to either
the vOMCI function, ONU Management Proxy or vOMCI Proxy instance.
Additionally, the vOLTMF can direct the message to a specific ONU when
sending a request to the vOMCI function instance.
Response messages are originated from the vOMCI function, ONU
Management Proxy or vOMCI Proxy are directed to the vOLTMF that
originated the request message.

message Request {
oneof req_type {
Hello hello = 2;
GetData get_data = 3;
ReplaceConfig replace_config = 4;
UpdateConfig update_config = 5;
RPC rpc = 6;
Action action = 7;
}
}
message Response {
oneof resp_type {
HelloResp hello_resp = 3;
GetDataResp get_resp = 4;
ReplaceConfigResp replace_config_resp = 5;
UpdateConfigResp update_config_resp = 6;
RPCResp rpc_resp = 7;
ActionResp action_resp = 8;
}
}
Figure 10 vOLTMF-vOMCI Request and Response Messages
5.7.1.2.1.1 Hello Message

This Hello request message is originated by the vOLTMF when the vOLTMF
establishes a connection to the vOMCI function, ONU Management Proxy or
vOMCI Proxy instance. The service_endpoint_name field is used to identify
the local service endpoint where the vOLTMF can be reached. The Hello
response message is used by the vOMCI function, ONU Management Proxy
or vOMCI Proxy instances to identify the service_endpoint that the vOLTMF
used to send the Hello request message. Additionally, the Hello response
message contains capabilities of the server (e.g., support for ONU
configuration replicas within the vOMCI function, support for ONU state).
When the vOLTMF sends messages directly to the vOMCI function
instances that provide support for replicas of the ONU configuration within
the vOMCI function, the vOMCI function would report the
ONU_CONFIG_REPLICA_SUPPORT capability. If the vOMCI function
supports the ability to handle requests that do not use the replica of an
ONU, the vOMCI function would report the ONU_STATE_ONLY_SUPPORT
capability.

If the ONU Management Proxy is deployed, the ONU Management Proxy

will report which versions of types of vOMCI functions the ONU
Management Proxy supports along with the associated capabilities for that
type of vOMCI function. If some types of vOMCI functions provide support
for replicas of the ONU configuration within the vOMCI function, the ONU
Management Proxy would report the ONU_CONFIG_REPLICA_SUPPORT
capability for the corresponding type of vOMCI functions. If some other
types of vOMCI functions support the ability to handle requests that do not
use the replica of an ONU, ONU Management Proxy would report the
ONU_STATE_ONLY_SUPPORT capability with the type of vOMCI function.
message Hello {
string service_endpoint_name = 1; //The service endpoint the client
// used to establish the session
}
message NFInformation {
map<string, string> nf_types = 1; //Valid Key types:
// usage-category, vendor-name,
// software-version
repeated NFCapability capabilities = 2;
enum NFCapability {
NO_CAPABILITY_REPORTED = 0;
ONU_STATE_ONLY_SUPPORT = 1;
ONU_CONFIG_REPLICA_SUPPORT = 2;
}
}
message HelloResp {
string service_endpoint_name = 1; //The service endpoint the server
//used to listen on the session
repeated NFInformation network_function_info = 2;
// The type information and
// capabilities supported by
// the network function
}
Figure 11 vOLTMF-vOMCI Hello Request and Response Messages

5.7.1.2.1.2 Get Data Message

The GetData message is used to retrieve the state information for the entity identified by the object_name of
the request message header. When a vOMCI function provides support for a replica of an ONU
configuration, the GetData message also returns the associated configuration of the ONU.
The filter field in the GetData request message is used to scope the request to specific elements. Each filter
instance contains an expression that represents a NETCONF [10] subtree filter.
The status_response field in the GetData response message is used to convey the status of the message
along with any error codes if the request failed for any reason. The usage of the datastore_tag field in the
GetData response message is described in section 5.6.4.1.
message GetData {
repeated bytes filter = 1;
}
message GetDataResp {
Status status_resp = 1;
bytes data = 2;
string datastore_tag = 3; // Optional: Datastore tag used to
// synchronize the config datastore
}
Figure 12 vOLTMF-vOMCI GetData Request and Response Messages
5.7.1.2.1.3 Replace Configuration Message

The ReplaceConfig message is used to completely replace the configuration of the entity identified by the
object_name of the request message header. The config_inst field contains the full configuration instance of
the targeted entity. The status_response field in the ReplaceConfigResp response message is used to
convey the status of the message along with any error codes if the request failed for any reason. The usage
of the datastore_tag field in the ReplaceConfig message is described in section 5.6.4.1.
Note: vOMCI function, ONU Management Proxy or vOMCI proxy instance implementations ought to
limit unnecessary disruptions in the management, control and user plane traffic due to the
replacement of a configuration.

message ReplaceConfig {
bytes config_inst = 1; // Full configuration instance to
// be used as a replacement of what
// exists for the target
message ReplaceConfigResp {
}
Figure 13 vOLTMF-vOMCI ReplaceConfig Request and Response Messages
5.7.1.2.1.4 Update Configuration Message

The UpdateConfig message is used to update requested part of the configuration of the entity identified by
the object_name of the request message header. When the subject of the request is an ONU there are two
ways of updating the configuration depending on the ONU_CONFIG_REPLICA_SUPPORT or
ONU_STATE_ONLY_SUPPORT capabilities of the vOMCI function. The usage of the datastore_tag field in
the UpdateConfig message is described in section 5.6.4.1.
If the vOMCI function supports the ONU_STATE_ONLY_SUPPORT capability, the vOLTMF can send the
UpdateConfigInstance request message. The current_config_inst field in this message contains the full
configuration of the ONU before the vOLTMF would have applied any requests itself. The delta_config field
contains a list of changes for nodes within the ONU configuration database. Additionally, each node contains
an NETCONF operation to apply to the node.
If the vOMCI function supports the ONU_CONFIG_REPLICA_SUPPORT capability, the vOMCI function
uses the list of changes for nodes within the replica's ONU configuration contained within the delta-config
field.
The status_response field in the UpdateConfigResp response message is used to convey the status of the
message along with any error codes if the request failed for any reason.
Note: vOMCI function, ONU Management Proxy or vOMCI proxy instance implementations ought to
limit unnecessary disruptions in the management, control and user plane traffic due to the update of
a configuration.

message UpdateConfigReplica {
bytes delta_config = 1; // List of Node changes with the
// associated operation to apply to
// the node
}
message UpdateConfigInstance {
bytes current_config_inst = 1; // Full current configuration
// instance
bytes delta_config = 2; // List of Node changes with the
// associated operation to apply to
// the node
}
message UpdateConfig {
oneof req_type {
UpdateConfigInstance update_config_inst = 1;
UpdateConfigReplica update_config_replica = 2;
}
// synchronize the config store
}
message UpdateConfigResp {
}
Figure 14 vOLTMF-vOMCI UpdateConfig Request and Response Messages
5.7.1.2.1.5 RPC and Action Messages

The RPC and Action messages permits operations to executed for the entity identified by the object_name of
the request message header. The input-data and output-data fields contains the instances of YANG
elements that are defined for associated YANG RPC and Action. The usage of the datastore_tag field in the
RPC and Action messages is described in section 5.6.4.1.
The status_response field in the Action and RPC response messages is used to convey the status of the
message along with any error codes if the request failed for any reason.

message RPC {
bytes input_data = 1;
}
message RPCResp {
bytes output_data = 2;
}
message Action {
bytes input_data = 1;
}
message ActionResp {
bytes output_data = 2;
}
Figure 15 vOLTMF-vOMCI RPC and Action Request and Response Messages
5.7.1.2.1.6 Status and Error Messages

The Status message permits vOMCI function or vOMCI Proxy instances to respond to request messages.
The status_code field in the message indicates of the request was successful or if there was an error. If there
was an error with the request, the Status message contains one or more Error messages in the error field of
the Status message. The Error message is based on NETCONF rpcErrorType defined in Appendix B of RFC
6241 [10].

message Error { //Type of error as defined in RFC 6241 section 4.3

string error_type = 1; // Error type defined in RFC 6241
// Appendix B
string error_tag = 2; // Error tag defined in RFC 6241
// Appendix B
string error_severity = 3; // Error severity defined in RFC 6241
// Appendix B
string error_app_tag = 4; // Error app tag defined in RFC 6241
// Appendix B
string error_path = 5; // Error path defined in RFC 6241
// Appendix B
string error_message = 6; // Error message defined in RFC 6241
// Appendix B
}
message Status {
enum StatusCode {
OK = 0;
ERROR_GENERAL = 1;
}
StatusCode status_code = 1;
repeated Error error = 2; //Optional: Error information
}
Figure 16 vOLTMF-vOMCI Status Message
The following JSON fragment is an equivalent representation for the first example shown in the Section 4.3
of RFC 6241 [10] and would be encoded in the error field of the Status message.
Note: Instead of the "rpc-error" field as define in RFC 6241 [10], the root element is named "error".
Error response
"error": {
"error-type": "rpc",
"error-tag": "missing-attribute",
"error-severity": "error",
"error-info": {
"bad-attribute": "message-id",
"bad-element": "rpc"
}
}

5.7.1.2.2 Notification Messages

The Notification message permits vOMCI function or vOMCI Proxy instances to send notification events to
the vOLTMF. The vOMCI function can send notifications for itself or for an ONU as identified in the
object_name field of the message header. The vOMCI Proxy instance identifies itself in the object_name
field of the message header. The YANG notification is contained in the data field of the message.
message Notification {
string event_timestamp = 1; // Timestamp in ISO 8601 format
bytes data = 2;
}
Figure 17 vOLTMF-vOMCI Notification Message
5.7.1.3 ONU Device Lifecycle

The ONU device lifecycle information is used by the vOLTMF to inform the vOMCI function of the creation or
deletion of an ONU device, such as by the BAA Device Manager or other Access SDN M&C. An ONU device
has to be created in the vOMCI function before it can be configured. Similarly, any configuration for an ONU
device in the vOMCI function will be destroyed when the ONU device is deleted.
5.7.1.4 ONU Topology

The ONU topology information is used by the vOLTMF to inform the vOMCI function of the location of the
physical ONUs on the Optical Distribution Network (ODN). The ONU topology information includes the ONU
device name, the OLT device and Channel Termination to which it is connected, and the assigned TC layer
ONU-ID.
The ONU topology information is originated by the physical OLT device as notifications to which the vOLTMF
subscribes. The ONU state change notifications include the TC layer ONU serial number as a unique
identifier for the ONU along with the ONU state and other topology information. The vOLTMF must correlate
the TC layer ONU serial number with a configured ONU device. The vOLTMF then configures the vOMCI
function, vOMCI proxy and OLT with the ONU management chain elements that are relevant for that entity.
For example, the vOLTMF would configure the ONU's olt-remote-endpoint attribute with the remote endpoint
that the vOMCI function would use to send vOMCI messages.
5.7.2 Transmission Encoding

The ONU device and the vOMCI function instance information models and associated messages on the
vOMCI function's MvOLTMF-vOMCI interface are encoded in Google Protobufs. Where YANG data is present in
the messages (such as the examples in Appendix VIII), the YANG data is encoded within JSON using RFC
7951 [14].
5.7.3 Message Transfer Protocol

The message transfer protocol used for the vOMCI function's MvOLTMF-vOMCI interface varies based how the
vOLTMF and vOMCI function are developed and deployed. This Technical Report defines the requirements
for the use of two message transfer protocols Kafka and gRPC.

5.7.3.1 Message Transfer Using Kafka

Kafka is a message transfer protocol used to transfer binary streams of data as event streams using a
producer (publication) – consumer (subscription) design pattern. The vOLTMF, ONU Management Proxy,
vOMCI function and vOMCI Proxy exchange messages defined in section 5.7.1 (i.e., request, response,
notification) by the originating entity publishing the message to a topic on the Kafka bus which is then
consumed by the receiving entity that has subscribed to the topic. In order to keep the naming of topics
flexible, consumers that subscribe to a topic will always determine if the message is supposed to be for them
by inspecting the recipient_name fields of the Request, Response and Notification messages. If the message
is not for the consumer, the consumer silently discards the message.
5.7.3.1.1 Kafka Topics

The determination of the names that a consumer subscribes, and a producer publishes is configured using
the environment in which the vOLTMF and vOMCI function, ONU Management Proxy or vOMCI Proxy is
deployed. For example, if the vOMCI function, ONU Managmeent Proxy or vOMCI Proxy is deployed as a
docker container, the docker configuration file can contain the topics which the vOMCI message will
subscribe and produce. Table 1 Kafka Topic is the list of topic category that vOLTMF and vOMCI function,
ONU Management Proxy or vOMCI Proxy will subscribe and produce:
Table 1 Kafka Topic Categories

Topic Category Description vOLTMF vOMCI function/
ONU Management
Proxy/vOMCI Proxy
VOMCI_NOTIFICATI Notifications from the Subscribe Produce
ON vOMCI function for
ONUs and the
Message function
VOMCI_REQUEST Requests sent by the Produce Subscribe
vOLTMF to the
vOMCI function
VOMCI_RESPONSE Responses to vOMCI Subscribe Produce
requests
Note: These are categories of topics and topic names are specific to deployments.
R-MvOLTMF-vOMCI-Kafka.10 – When using Kafka to transfer messages, an entity (i.e., vOLTMF, vOMCI
function, ONU Management Proxy, vOMCI Proxy) MUST provide the capability act as a Kafka consumer.
function, ONU Management Proxy, vOMCI Proxy) MUST provide the capability act as a Kafka producer.
function, ONU Management Proxy, vOMCI Proxy) acting as a Kafka consumer MUST silently discard
messages for which it is not a recipient by inspecting the recipient_name field of the received message when
the Kafka producer has provided the recipient_name field.
function, ONU Management Proxy, vOMCI Proxy) acting as a Kafka consumer MUST silently discard

messages for which it cannot identify the target recipient by inspecting the recipient_name field of the
received message when the Kafka producer has provided the recipient_name field.
R-MvOLTMF-vOMCI-Kafka.50 – When using Kafka to transfer messages, the vOMCI function or vOMCI Proxy
acting as a Kafka consumer MUST silently discard messages for which it cannot identify the target of the
request by inspecting the object_type and object_name fields of the received request message.
R-MvOLTMF-vOMCI-Kafka.60 – When using Kafka to transfer messages, the vOLTMF acting as a Kafka
consumer MUST silently discard messages for which it cannot identify the source of the response or
notification by inspecting the object_type and object_name field of the received response or notification
message.
R-MvOLTMF-vOMCI-Kafka.70 – Implementations MUST ensure the confidentiality, integrity and authenticity of the
Kafka endpoints and the Kafka broker when exchanging messages between the vOLTMF and ONU
Management Proxy, vOMCI function or vOMCI Proxy.
R-MvOLTMF-vOMCI-Kafka.80 – When using Kafka to transfer request messages defined in section 5.7.1, the
vOMCI solution MAY name Kafka topics that are unique to the ONU Management Proxy, vOMCI function or
vOMCI Proxy instances.
R-MvOLTMF-vOMCI-Kafka.90 – When using Kafka to transfer response and notification messages defined in
section 5.7.1, the vOMCI solution MAY name Kafka topics that are unique to the vOLTMF.
R-MvOLTMF-vOMCI-Kafka.100 – When using Kafka to transfer messages on the MvOLTMF-vOMCI interface the
vOLTMF MUST subscribe and produce messages using the Topic categories defined in Table 1 Kafka
Topic.
R-MvOLTMF-vOMCI-Kafka.110 – When using Kafka to transfer messages on the MvOLTMF-vOMCI interface the
vOMCI function ONU Management Proxy, or vOMCI Proxy MUST subscribe and produce messages using
the Topic categories defined in Table 1 Kafka Topic.
R-MvOLTMF-vOMCI-Kafka.120 – When using Kafka to transfer messages on the MvOLTMF-vOMCI interface, the
vOMCI solution MUST control access to the topics for which clients consume and produce messages.
5.7.3.2 Message Transfer Using gRPC

The vOLTMF, vOMCI function and vOMCI Proxy entities can exchange messages defined in section 5.7.1
(i.e., request, response, notification) using the Google Remote Procedure Call (gRPC) [30] message transfer
protocol.
5.7.3.2.1 gRPC Channel Initiation

gRPC channels between the vOLTMF and vOMCI function, ONU Management Proxy or vOMCI Proxy is
initiated by the vOLTMF to the vOMCI function, ONU Management Proxy or vOMCI Proxy. When the
vOLTMF initiates the gRPC channel, the vOLTMF supports the gRPC client interface while vOMCI function,
ONU Management Proxy or vOMCI Proxy that support the reception of the messages across the gRPC
channel supports the gRPC server interface.
Even though the vOLTMF is the client entity of the gRPC channel, the vOMCI function, ONU Management
Proxy or vOMCI Proxy can transmit messages such as Notifications.

5.7.3.2.1.1 gRPC Services

The communication of messages between the vOLTMF and vOMCI function, ONU Management Proxy or
vOMCI Proxy are implemented using gRPC Services that permit the vOLTMF to send request messages and
receive responses defined in section 5.7.1 using the VomciMessageNBI service's Hello, GetData,
ReplaceConfig, UpdateConfig(Replicate|Instance), RPC or Action RPCs. Likewise, vOMCI function, ONU
Management Proxy or vOMCI Proxy can send notifications messages defined in section 5.7.1 using the
VomciMessageNBI service's ListenforNotification RPC. The VomciMessageNBI service is defined below:
service VomciMessageNbi {
rpc Hello(tr451_vomci_nbi_message.v1.Msg) returns
(tr451_vomci_nbi_message.v1.Msg);
rpc GetData(tr451_vomci_nbi_message.v1.Msg) returns

rpc ReplaceConfig(tr451_vomci_nbi_message.v1.Msg) returns

rpc UpdateConfigReplica(tr451_vomci_nbi_message.v1.Msg) returns

rpc UpdateConfigInstance(tr451_vomci_nbi_message.v1.Msg) returns

rpc RPC(tr451_vomci_nbi_message.v1.Msg) returns

rpc Action(tr451_vomci_nbi_message.v1.Msg) returns

rpc ListenForNotification (google.protobuf.Empty) returns (stream

tr451_vomci_nbi_message.v1.Msg);
}
Figure 18 vOLTMF-vOMCI VomciMessageNbi Service
5.7.3.2.1.2 Remote Entity Contact Information

When the vOLTMF requests to establish a gRPC channel with the peer entity (i.e., ONU Management Proxy,
vOMCI function, vOMCI Proxy), the initiating entity has to have the information necessary to contact the peer
entity. This information includes:
• URL of the peer entity (e.g., host name, port)
• Security credentials necessary to establish the identity of the initiating entity

• Security credentials necessary to verify the identity of the peer entity
5.7.3.2.2 gRPC Channel Maintenance

gRPC channels between the vOLTMF and vOMCI function or vOMCI Proxy are considered persistent
connections where if the initiation attempt fails or connectivity of the established gRPC channel fails, the
gRPC client attempts to reconnect using a reconnection strategy. Likewise, to ensure that a connection is
healthy the gRPC client periodically initiates ping requests to ensure the health of the gRPC channel.
Likewise, the interval for the HTTP/2 Ping frames that the sent from the gRPC client to server is configurable.
5.7.3.2.3 Using HTTP/2 as the gRPC Wire Protocol

The most common wire protocol used by gRPC is HTTP/2 where many of the attributes of the persistent
connection uses underlying features provided by HTTP/2 as defined in RFC 7540 [11] (e.g., keep-alive). The
gRPC to HTTP/2 bindings include the values for the request and response headers along with trailers for the
HTTP/2 response and are defined by the gRPC specification.
For gRPC requests implementations are able to define and adjust the request timeouts (i.e., grpc-timeout)
and if compression is used (grpc-encoding).
When using HTTP/2 as the gRPC wire protocol, HTTP/2 servers can send a GOAWAY frame to the HTTP/2
client indicating that HTTP/2 server will no longer accept connections. When this occurs the entity, acting as
the gRPC and HTTP/2 client will not attempt to re-connect to the peer entity and will provide a notification or
log entry that the entity cannot establish communications to the peer entity.
5.7.3.2.4 Securing the gRPC Channel

The gRPC channel between the peer entities is secured using TLS version 1.2 [7] or higher as required by
the gRPC specification. This Technical Report uses the TLS session to provide confidentiality and integrity
protection of the gRPC channel along with authentication of the entities. The determination of the authenticity
of the vOLTMF and vOMCI function, ONU Management Proxy or vOMCI Proxy is provided through the
exchange and validation of X.509 certificates.
R-MvOLTMF-vOMCI-gRPC.10 – When using gRPC to transfer messages, the vOLTMF MUST provide the
capability to initiate the gRPC channel establishment procedure acting as a gRPC client.
R-MvOLTMF-vOMCI-gRPC.20 – When using gRPC to transfer messages, the vOMCI function MUST provide
gRPC server capabilities.
R-MvOLTMF-vOMCI-gRPC.30 – When using gRPC to transfer messages, the vOMCI Proxy MUST provide gRPC
server capabilities.
R-MvOLTMF-vOMCI-gRPC.35 – When using gRPC to transfer messages, the ONU Management Proxy MUST
provide gRPC server capabilities.
R-MvOLTMF-vOMCI-gRPC.40 – When establishing a gRPC channel between the vOLTMF and vOMCI function,
the vOLTMF MUST send the Hello message in order to exchange attachment points and other information
needed to exchange messages.
R-MvOLTMF-vOMCI-gRPC.50 – When establishing a gRPC channel between the vOLTMF and vOMCI function,
ONU Management Proxy or vOMCI Proxy, the vOLTMF MUST send the ListenForRx RPC in order to allow
the peer entity to send messages.

R-MvOLTMF-vOMCI-gRPC.60 – When the vOLTMF acts as a gRPC client, the vOLTMF MUST provide the
capability to establish gRPC channels to one (1) or more remote entities using the peer entity's contact
information defined in section 5.8.4.1.1 of this Technical Report.
R-MvOLTMF-vOMCI-gRPC.70 – The gRPC channel established between the vOLTMF and vOMCI function, ONU
Management Proxy or vOMCI Proxy MUST be a persistent connection where if the initiation attempt fails or
the connectivity of the established gRPC fails, the gRPC client attempts to reconnect using the reconnection
strategy defined by the gRPC specification.
R-MvOLTMF-vOMCI-gRPC.80 – When the vOLTMF cannot establish a gRPC channel with a remote entity, the
initiating entity MUST provide a notification that communication with the remote entity cannot be established
along with a possible reason (e.g., HTTP/2 GOAWAY frame).
R-MvOLTMF-vOMCI-gRPC.90 – For established gRPC channels, the vOLTMF MUST ping the remote entity on a
periodic interval. The ping interval MUST be configurable and default value MUST be 5 minutes.
R-MvOLTMF-vOMCI-gRPC.100 – When sending gRPC messages, the requesting entity MUST provide a timeout
for the request and indicate if compression is used for encoding. The gRPC request timeout and
compression values MUST be configurable. The default value for the grpc-timeout MUST be 30 seconds and
the default value for the grpc-encoding MUST NOT include compression.
R-MvOLTMF-vOMCI-gRPC.110 – Implementations MUST ensure the confidentiality, integrity, and authenticity of

the gRPC channels when exchanging messages between the vOLTMF and vOMCI function, ONU
Management Proxy or vOMCI Proxy.
R-MvOLTMF-vOMCI-gRPC.120 – The vOLTMF, vOMCI function, ONU Management Proxy and vOMCI Proxy
service endpoints MUST implement TLS 1.2 as described in RFC 5246 [7].
R-MvOLTMF-vOMCI-gRPC.130 – When the vOLTMF, acting as the gRPC client, receives the remote entities'
X.509 certificate while establishing TLS session, the vOLTMF MUST identify the remote entity according to
section 6 of RFC 6125 [9].
R-MvOLTMF-vOMCI-gRPC.140 – The vOMCI function, ONU Management Proxy or vOMCI Proxy, acting as a
gRPC server, MUST authenticate the vOLTMF using the X.509 certificate presented by the initiating entity
according to section 6 of RFC 6125 [9].

5.7.4 Requirements
R-MvOLTMF-vOMCI.10 – The ONU device data model used on the MvOLTMF-vOMCI interface MUST be compliant
with TR-385i2 [26].
R-MvOLTMF-vOMCI.20 – The vOMCI function instance data model used on the MvOLTMF-vOMCI interface MUST be
compliant with Annex A: vOMCI YANG Modules.
R-MvOLTMF-vOMCI.30 – The vOMCI Proxy instance data model used on the MvOLTMF-vOMCI interface MUST be
compliant with Annex A: vOMCI YANG Modules.
R-MvOLTMF-vOMCI.40 – Messages used on the MvOLTMF-vOMCI interface MUST be encoded using Google
Protobufs version 3.0 [29].
R-MvOLTMF-vOMCI.50 – YANG data used with the GPB messages on the MvOLTMF-vOMCI interface MUST be
encoded as JSON in RFC 7951 [14].
R-MvOLTMF-vOMCI.60 – Upon reception of the message request, if the vOMCI function, ONU Management
Proxy or vOMCI Proxy does not support the version of the message request, the vOMCI function MUST
generate an unsupported-version-vomci-func-message notification specified in Annex A: vOMCI YANG
Modules.
R-MvOLTMF-vOMCI.70 – When a message response is received by the vOLTMF and the vOLTMF does not
support the version specified in the message, the vOLTMF MUST log the failed message reception.
R-MvOLTMF-vOMCI.80 – When a message notification is received by the vOLTMF and the vOLTMF does not
support the version specified in the message, the vOLTMF MUST log the failed message reception.
R-MvOLTMF-vOMCI.80 – The information model for ONU device data model used on the MvOLTMF-vOMCI interface
MUST support the RFC-7895 [12] YANG Modules data module.
5.8 vOMCI Function to OLT Interface (MVOMCI-OLT)

The MVOMCI-OLT interface transfers OMCI messages that have been translated by the vOMCI function to the
OLT for delivery to the target ONU via the OLT’s OMCI channel. Similarly, the MVOMCI-OLT interface is used to
receive notifications and operational data from the OLT that were originated from the ONU via the OMCI
channel.
The messages that are conveyed across the MVOMCI-OLT interface are serialized in Google Protocol Buffers
(GPB) along with other information elements that help with the forwarding of the message as well as
assistance in the operation and troubleshooting of the message flow between the vOMCI function and the
OLT. These messages are known as vOMCI messages and are defined in section 5.8.1.
The vOMCI messages that are exchanged between the OLT and vOMCI function can transit through
optional, intermediate entities known as vOMCI Proxys.
The vOMCI function, OLT and vOMCI Proxy entities transfer vOMCI messages using the Google RPC
(gRPC) message transfer protocol.

5.8.1 vOMCI Messages

The vOMCI message (VomciMessageSbi) protobuf definition provides the definition for the request and
response messages that are exchanged between the OLT and the vOMCI function. These vOMCI messages
can be forwarded through vOMCI Proxy intermediate entities.
The vOMCI message is defined by the GPB VomciMessage definition can be an request or a response
message defined for:
• OMCI packet transmission
• Error message that is not associated with any vOMCI message response (e.g., message delivery
errors)
message VomciMessage {
string request_payload_id = 1; //Optional: The request payload identifier received
from the vOLTMF by the vOMCI function.
oneof msg{
VomciError error_msg = 2;
OmciPacket omci_packet_msg = 3;
OmciPacket tod_packet_msg = 4;
OltInfoMessage olt_info_msg = 5;
}
}
message VomciError {
enum VomciErrorCode {
ERROR_GENERAL = 0;
NO_ROUTE_TO_ONU = 1; //The entity does not know which remote endpoint to send the
message to the ONU
NO_RESPONSE_FROM_ONU = 2; //The entity did not receive an expected response for a
request from the ONU
UNSUPPORTED_REQUEST = 3; //The entity does not support the request
}
VomciErrorCode error_code = 1;
string error_description = 2; //Optional: Error description
}
Figure 19 vOMCI Message Definition
In Figure 19 the VomciMessage message optionally contains the request_payload_id , the value of this field
can be passed between the vOLTMF and the vOMCI function in order to correlate the requests/responses
that are communicated across the MvOLTMF-vOMCI interface with the messages communicated across the
MvOMCI-OLT interface.
For vOMCI solutions that correlate VomciMessage request and response messages (e.g., vOMCI function,
vOMCI Proxy when performing OMCI message retransmission), the vOMCI Proxy and vOMCI function
inserts the value of the request_payload_id field from the VomciMessage response message into the
VomciMessage message prior to transmission of the VomciMessage response message.
5.8.1.1 ONU Header Message

vOMCI messages that are targeted for an ONU that is attached to an OLT, uses the OnuHeader message to
convey information related to the ONU.

message OnuHeader {
string olt_name = 1; //The OLT name
string chnl_term_name = 2; //The reference identifier to the channel termination of
the TR-385 vANI
uint32 onu_id = 3; //The TC layer ONU-ID identifier of the TR-385 vANI
}
Figure 20 ONU Header Message
In Figure 20 the OnuHeader message contains the fields (i.e., olt-name, chanl_term_name and onu_id) that
are used by the OLT and vOMCI Proxy entities to address an ONU instance.
5.8.1.2 OMCI Packet Message

The OmciPacket message encapsulates a standard OMCI payload (without the MIC/CRC field) that has
been annotated with the corresponding ONU header, message information that assists in entities treatment
of the contents of the OMCI Payload. The OmciPacket messages can be sent in either direction between the
OLT, vOMCI Proxy and vOMCI function entities. The OmciMsgRetrans message is used when transmitting
OmciPacket message requests that originate from the vOMCI function toward the OLT as described in
section 5.8.3.
message OmciMsgRetrans {
uint32 t_maxi = 1; //Optional: The maximum threshold value, in milliseconds, for timer
expiration as defined in ITU-T G.988/B.2. A value of 0 indicates that the field is not
defined.
uint32 r_maxi = 2; //Optional: The maximum retries associated with this message as
defined in ITU-T G.988/B.2 plus 1 (e.g., Value 1 is the first retry) A value of 0
indicates that the field is not defined.
}
message MessageInfo {
OmciMsgRetrans omci_msg_retrans = 1; //Optional: OMCI message retransmission applied
}
message OmciPacket {
OnuHeader header = 1;
MessageInfo msg_info = 2; //Optional: Message information
bytes payload = 3; //OMCI message payload without the CRC/MIC
}
Figure 21 OmciPacket Message
Figure 22, Figure 23, and Figure 24 provides examples of the message sequence for ONU notifications,
ONU commands and a response to an ONU command.

Figure 22 ONU Notification
Figure 23 ONU Command

Figure 24 ONU Response to ONU Command

Figure 25 ToD Packet Message Command
5.8.1.3 vOMCI Message Timeouts

In deployments where the vOMCI Proxy or vOMCI function entities maintains the state of commands that are
directed to ONUs, the vOMCI messages that the vOMCI Proxy or vOMCI function tracks could become stale
because of various exceptions and timeouts within the deployment. In order to "clean up" the tracking of the
command, the vOMCI Proxy or vOMCI function is configured with or utilizes a default value for a timeout that
instructs the vOMCI Proxy and vOMCI function to discard any tracking of vOMCI messages that have
expired. When the vOMCI Proxy and vOMCI function discards vOMCI messages, the vOMCI Proxy and
vOMCI function increments a counter associated with the discard action and log the discard event.
Note: The message timeout described in this section is only applicable when the vOMCI Proxy or
vOMCI function entity is not currently performing the OMCI message retransmission function for the
vOMCI message. The reason is that the OMCI message retransmission function's timers described
in section 5.8.3 take precedence in the "clean up" of the commands over the configured timeout
values.
R-vOMCI_Msg_TO.100 – If the vOMCI function or vOMCI Proxy is not currently performing the OMCI
message retransmission function but is tracking vOMCI messages from the vOMCI function to an ONU, the
vOMCI function or vOMCI Proxy MUST provide the capability to timeout the vOMCI message that it is
tracking based on the configured or default timeout value.
R-vOMCI_Msg_TO.110 – If the vOMCI function or vOMCI Proxy times out vOMCI messages from the
vOMCI function to an ONU, the vOMCI function or vOMCI Proxy MUST count the timed out message and log
the timeout event of the vOMCI message.

5.8.1.4 vOMCI Error Message

In certain error cases, OLT, vOMCI Proxy and vOMCI function entities could have problems in processing an
vOMCI message that isn't related to the type of message or the underlying message transfer (e.g., GPB
encoding error) but instead is related to the delivery of the vOMCI message to the ONU itself. In this case,
the OLT, vOMCI Proxy and vOMCI function can return the vOMCI Error message that describes the problem
that was encountered.
message VomciError {
enum VomciErrorCode {
ERROR_GENERAL = 0;
NO_ROUTE_TO_ONU = 1; //The entity does not know which remote endpoint to send the
message to the ONU
NO_RESPONSE_FROM_ONU = 2; //The entity did not receive an expected response for a
request from the ONU
}
VomciErrorCode error_code = 1;
string error_description = 2; //Optional: Error description
}
Figure 26 vOMCI Message Error Message
5.8.1.5 OLT Information Message

When the vOMCI function requires information from the OLT that is needed to assist in communicating
information about the OLT to the ONU, the vOMCI function can use the OLT message to retrieve the OLT's
information that can then be provided by the vOMCI function to the ONU.

message OltInfoMessage {
oneof msg {
OltOnuInfoReq olt_onu_info_req = 1;
OltOnuInfoRsp olt_onu_info_rsp = 2;
}
}
message OltOnuInfoReq {
OnuHeader header = 1; //OLT information is scoped toward a specific ONU
}
message OltOnuInfoRsp {
OnuHeader header = 1; //OLT information is scoped toward a specific ONU
uint32 gem_superframe_seq = 2; //The sequence number of the specified GEM
superframe as defined in the OLT-G ME in ITU-T G.988
string tstampn = 3; //The TstampN as defined in the OLT-G ME in ITU-T G.988
}
Figure 27 OLT Information Message
5.8.2 Encapsulating vOMCI Messages in GPB for use with gRPC Transport
vOMCI messages encapsulated in a GPB message using the schema defined in this section of the Technical
Report. GPB message services are defined for communication between the OLT, vOMCI Proxy, and vOMCI
function entities. These services are identified below:
service VomciHelloSbi {
rpc HelloVomci (tr451_vomci_sbi_message.v1.HelloVomciRequest) returns
(tr451_vomci_sbi_message.v1.HelloVomciResponse);
}
service VomciMessageSbi {
rpc ListenForVomciRx (google.protobuf.Empty) returns (stream
tr451_vomci_sbi_message.v1.VomciMessage);
rpc VomciTx (tr451_vomci_sbi_message.v1.VomciMessage) returns
(google.protobuf.Empty);
}
Figure 28 vOMCI SBI Service
5.8.2.1 Hello vOMCI Service

The Hello vOMCI service (VomciHelloSbi) is used by the OLT, vOMCI Proxy or vOMCI function when
contacting the peer entity using the HelloVomci RPC. The information that is provided is information that the

peer entity needs on subsequent OMCI message exchanges between the OLT, vOMCI Proxy, and the
vOMCI function. The gRPC client uses the HelloVomciRequest message where the OLT, vOMCI function, or
vOMCI Proxy identifies the endpoint name that the gRPC client advertises when connected to the gRPC
server (i.e., gRPC client's local-endpoint). The HelloVomciResponse message provided by the gRPC server
includes the endpoint name that the server advertises (i.e., gRPC server local-endpoint). Whenever the
endpoint name changes, the entities that has been changed must gracefully terminate all sessions between
the entities. New sessions will then be re-initiated the sessions using the new endpoint name.
message Hello {
string endpoint_name = 1; //OLT, vOMCI Proxy or vOMCI function endpoint name
}
message HelloVomciRequest {
Hello local_endpoint_hello = 1;
}
message HelloVomciResponse {
Hello remote_endpoint_hello = 1;
}
Figure 29 Hello vOMCI Service
5.8.2.2 vOMCI Message Service

The vOMCI message service (VomciServiceSbi) provides the RPCs needed to exchange vOMCI messages
between the OLT, vOMCI function and vOMCI Proxy that use gRPC to transfer vOMCI messages.
Since OLT, vOMCI function and vOMCI Proxy entities require a gRPC stream in order to send vOMCI
messages, one of the OLT, vOMCI function and vOMCI Proxy entities instantiates the stream by sending the
ListenForVomciRx message to the peer entity, which the peer entity then uses to send any vOMCI
messages as response on the stream.
service VomciMessageSbi {
rpc ListenForVomciRx (google.protobuf.Empty) returns (stream
tr451_vomci_sbi_message.v1.VomciMessage);
rpc VomciTx (tr451_vomci_sbi_message.v1.VomciMessage) returns
(google.protobuf.Empty);
}
Figure 30 vOMCI Message Service
5.8.2.2.1 Acknowledgements at OMCI layer vs gRPC

The gRPC layer provides for two-way RPC invocation with input parameters and output result. For
encapsulating OMCI messages, the response with result is not required as ITU-T G.988 specification
provides its own re-transmission mechanism. Separate RPCs (i.e., VomciTx() ListenForvOmciRx()) are used
to deliver the messages. Likewise, OMCI messages are correlated using the ITU-T G.988 message

identification mechanisms. The entity that originates the OMCI request or notification is responsible for
correlating the responses for the OMCI requests or notification.
R-ENC.10 – An implementation using Google protocol buffers encoding to encode vOMCI messages MUST
conform to the schema defined in section 5.8.2.
R-ENC.15 – An implementation that uses gRPC to transfer Google protocol buffers encoded messages
MUST conform to the Google Protobuf services defined in section 5.8.2.
R-ENC.20 – When exchanging OmciPacket messages, message re-transmission MUST be implemented

according to section B.2 of ITU-T G.988.
R-ENC.30 – When exchanging OmciPacket messages, message correlation MUST be implemented

according to section 11.2.1 of ITU-T G.988.
5.8.3 OMCI Message Retransmission Capability

OMCIPacket messages that encapsulate OMCI message requests from the vOMCI function have
retransmission that complies with clause B.2.1 of ITU-T G.988 [1]. The OMCI message retransmission
capability can be implemented in the vOMCI function or vOMCI Proxy.
In order to implement the retransmission, the vOMCI Proxy and vOMCI function needs to be configured, via
its external management interface, with the ITU-T G.988 retransmission (or re-send) thresholds for timer
expiration timeout (Tmaxi) and number of retries retry counter (Rmaxi) to be used to control the processing for
high priority and low priority messages.
If the vOMCI function performs the OMCI message retransmission and needs to have retransmission
behavior that is different from what is configured by the vOLTMF (e.g., MibReset, Software Download), the
vOMCI function can optionally use different retransmission elements.
When the retransmission is performed by the vOMCI Proxy and if vOMCI function needs to have special
retransmission behavior that is different from what is configured by the vOLTMF (e.g., MibReset, Software
Download), the vOMCI function can optionally send the suggested retransmission elements in the in the
OMCIPacket message.
Based on configuration from the vOLTMF or using its default configuration, the vOMCI Proxy can accept or
ignore the suggested retransmission elements in the OMCIPacket message.
R-vOMCI_RT.10 – When the vOMCI function initiates the OMCIPacket message for an ONU, the vOMCI
function SHOULD use the OMCI message retransmission elements (e.g., timer expiration timeout (Tmaxi) and
number of retries retry counter (Rmaxi)) for an ONU that the vOMCI function has been configured using default
values or those values configured from the vOLTMF.
R-vOMCI_RT.20 – When performing OMCI message retransmission, vOMCI function MAY use different
OMCI message retransmission values if the vOMCI function determines other values are needed for
successfully completing the OMCI message (e.g., MibReset, Software Download) to an ONU.
R-vOMCI_RT.30 – When the vOMCI Proxy performs OMCI message retransmission, the vOMCI function
MAY send OMCI message retransmission values if the vOMCI function determines other values are needed
for successfully completing the OMCI message (e.g., MibReset, Software Download) to an ONU.

R-vOMCI_RT.40 – When the vOMCI Proxy is configured to perform OMCI message retransmission for an
ONU, the vOMCI Proxy SHOULD use the OMCI message retransmission elements (e.g., timer expiration
timeout (Tmaxi) and number of retries retry counter (Rmaxi)) for an ONU that the vOMCI Proxy has been
configured using default values or those values configured from the vOLTMF.
R-vOMCI_RT.50 – When the vOMCI Proxy is configured to accept the OMCI retransmission elements in the
OMCIPacket message, the vOMCI Proxy MUST use the retransmission elements in the OMCIPacket
message when the retransmission elements are present in the OMCIPacket message.
5.8.4 Use of gRPC to Exchange GPB Encapsulated vOMCI Messages

OMCI messages that have been encoded using Google Protobufs as described in section 5.8.2 of this
Technical Report are transferred between the OLT, vOMCI Proxy function and vOMCI function using Google
Remote Procedure Call (gRPC).
5.8.4.1 gRPC Channel Initiation

gRPC channels between the OLT, vOMCI Proxy and vOMCI function can be initiated by any of the OLT,
vOMCI Proxy and vOMCI function entities, depending on capabilities (i.e., gRPC client, gRPC server)
provided by the OLT, vOMCI Proxy and vOMCI function. OLT, vOMCI Proxy and vOMCI function entities that
initiate the gRPC channel supports the gRPC client interface while entities that support the reception of the
initiation of the gRPC channel supports the gRPC server interface. OLT, vOMCI Proxy and vOMCI function
entities can simultaneously support both the gRPC client and gRPC server interfaces. Regardless of which
entity initiates the gRPC channel, since an OLT, vOMCI Proxy and vOMCI function can initiate messages,
the asynchronous, bi-directional streaming RPC method is used to exchange messages. When either the
OLT, vOMCI Proxy and vOMCI function initiates the gRPC channel, the initiating entity has to send the Hello
and Listen RPCs.
Note: In the scenario where both OLT, vOMCI Proxy and vOMCI function entities implements the
gRPC client and gRPC server interfaces, the resulting solution will establish two (2) gRPC channel in
each direction resulting in two (2) HTTP/2 and associated TCP connections.
5.8.4.1.1 Remote Entity Contact Information

When either the OLT, vOMCI Proxy and vOMCI function requests to establish a gRPC channel with the peer
OLT, vOMCI Proxy and vOMCI function, the initiating OLT, vOMCI Proxy and vOMCI function has to have
the information necessary to contact the peer entity. This information includes:
• URL of the peer entity (e.g., host name, port)
• Security credentials necessary to establish the identity of the initiating entity
• Security credentials necessary to verify the identity of the peer entity
5.8.4.1.2 OLT, vOMCI Proxy and vOMCI Function Identification and Configuration
Based on the capabilities of OLT, vOMCI Proxy and vOMCI function and depending on the ONUs that are
connected to the OLT, OLT, vOMCI Proxy and vOMCI function can establish gRPC channels with multiple
instances of peer OLT, vOMCI Proxy and vOMCI function. The determination of peer entity instance(s) that
an initiating entity establishes a channel is configured through the provisioning interface of the initiating
entity.

5.8.4.2 gRPC Channel Maintenance

gRPC channels between the OLT, vOMCI Proxy and vOMCI function are considered persistent connections
where if the initiation attempt fails or connectivity of the established gRPC channel fails, the gRPC client
attempts to reconnect using a reconnection strategy. Likewise, to ensure that a connection is healthy the
gRPC client periodically initiates ping requests to ensure the health of the gRPC channel. Likewise, the
interval for the HTTP/2 Ping frames that the sent from the gRPC client to server is configurable.
5.8.4.3 Using HTTP/2 as the gRPC Wire Protocol

The most common wire protocol used by gRPC is HTTP/2 where many of the attributes of the persistent
connection uses underlying features provided by HTTP/2 as defined in RFC 7540 [11] (e.g., keep-alive). The
gRPC to HTTP/2 bindings include the values for the request and response headers along with trailers for the
HTTP/2 response and are defined by the gRPC specification.
For gRPC requests implementations are able to define and adjust the request timeouts (i.e., grpc-timeout)
and if compression is used (grpc-encoding).
When using HTTP/2 as the gRPC wire protocol, HTTP/2 servers can send a GOAWAY frame to the HTTP/2
client indicating that HTTP/2 server will no longer accept connections. When this occurs the OLT, vOMCI
Proxy and vOMCI function, acting as the gRPC and HTTP/2 client will not attempt to re-connect to the peer
OLT, vOMCI Proxy and vOMCI function and will provide a notification or log entry that the OLT, vOMCI Proxy
and vOMCI function cannot establish communications to the peer OLT, vOMCI Proxy and vOMCI function.
5.8.4.4 Securing the gRPC Channel

The gRPC channel between the peer OLT, vOMCI Proxy and vOMCI function entities is secured using TLS
version 1.2 [7] or higher as required by the gRPC specification. This Technical Report uses the TLS session
to provide confidentiality and integrity protection of the gRPC channel along with authentication of the OLT,
vOMCI Proxy and vOMCI function entities. The determination of the authenticity of the OLT, vOMCI Proxy
and vOMCI function entities is provided through the exchange and validation of X.509 certificates.
R-gRPC.10 – When using gRPC to transfer vOMCI messages, an OLT, vOMCI Proxy and vOMCI function
SHOULD provide the capability to initiate the gRPC channel establishment procedure acting as a gRPC
client.
R-gRPC.20 – When using gRPC to transfer vOMCI messages, an OLT, vOMCI Proxy and vOMCI function
SHOULD provide gRPC server capabilities.
R-gRPC.30 – When establishing a gRPC channel between the OLT, vOMCI Proxy and vOMCI function, the
Bi-directional streaming RPC method is used to exchange messages.
initiating entity (i.e., OLT, vOMCI function, vOMCI Proxy) MUST send the HelloVomci RPC in order to
exchange host names and endpoint information needed to exchange messages.
initiating entity (i.e., OLT, vOMCI function, vOMCI Proxy) MUST send the ListenForVomciRx RPC in order to
allow the peer entity to send vOMCI messages.

R-gRPC.60 – When the OLT, vOMCI Proxy and vOMCI function acts as a gRPC client, the entity MUST
provide the capability to establish gRPC channels to one (1) or more remote entities using the peer entity's
contact information defined in section 5.8.4.1.1 of this Technical Report.
R-gRPC.70 – The gRPC channel established between the OLT, vOMCI Proxy and vOMCI function MUST be
a persistent connection where if the initiation attempt fails or the connectivity of the established gRPC fails,
the gRPC client attempts to reconnect using the reconnection strategy defined by the gRPC specification.
R-gRPC.80 – When the OLT, vOMCI Proxy and vOMCI function cannot establish a gRPC channel with a
remote entity, the initiating entity MUST provide a notification that communication with the remote entity
cannot be established along with a possible reason (e.g., HTTP/2 GOAWAY frame).
R-gRPC.90 – For established gRPC channels, the initiating OLT, vOMCI Proxy and vOMCI function MUST
ping the remote entity on a periodic interval. The ping interval MUST be configurable and default value
MUST be 5 minutes.
R-gRPC.100 – When sending gRPC requests, the requesting OLT, vOMCI Proxy and vOMCI function MUST
provide a timeout for the request and indicate if compression is used for encoding. The gRPC request
timeout and compression values MUST be configurable. The default value for the grpc-timeout MUST be 30
seconds and the default value for the grpc-encoding MUST NOT include compression.
R-gRPC.110 – Implementations MUST ensure the confidentiality, integrity, and authenticity of the gRPC
channels when exchanging messages between the OLT, vOMCI Proxy, and vOMCI function.
R-gRPC.120 – The OLT, vOMCI Proxy and vOMCI function endpoints MUST implement TLS 1.2 as
described in RFC 5246 [7].
R-gRPC.130 – When an initiating OLT, vOMCI Proxy and vOMCI function, acting as the gRPC client,
receives the remote entities' X.509 certificate while establishing TLS session, the initiating entity MUST
identify the remote entity according to section 6 of RFC 6125 [9].
R-gRPC.140 – The OLT, vOMCI Proxy and vOMCI function, acting as a gRPC server, MUST authenticate
the initiating entity using the X.509 certificate presented by the initiating entity according to section 6 of RFC
6125 [9].

Annex A: vOMCI YANG Modules

This section describes the YANG modules to be used when managing the vOMCI function, ONU
Management Proxy, vOMCI Proxy function, OLT and vOLTMF for the purposes of this Technical Report.
These functions use the following YANG modules that are common to these managed entities or are used
from other Broadband Forum Technical Reports and IETF RFCs:
Figure 31 vOMCI YANG Modules
The <Function>-<Transport>-<Client|Server> YANG modules in Figure 31 depicts the transport specific

YANG modules supported by each of the functions in the vOMCI solution. These modules include:
• bbf-olt-vomci-grpc-client.yang, bbf-olt-vomci-grpc-server.yang
• bbf-onu-management-proxy-grpc-client.yang, bbf-onu-management-proxy-grpc-server.yang, bbf-
onu-management-proxy-kafka-agent.yang
• bbf-voltmf-grpc-client.yang, bbf-voltmf-kafka-agent.yang
• bbf-vomci-function-grpc-client.yang, bbf-vomci-function-grpc-server.yang, bbf-vomci-function-kafka-
agent.yang
• bbf-vomci-proxy-grpc-client.yang, bbf-vomci-proxy-grpc-server.yang, bbf-vomci-proxy-kafka-
agent.yang
Note: The bbf-network-function, bbf-network-function-client, bbf-network-function-server, bbf-grpc-

client, bbf-grpc-server and bbf-kafka-agent YANG modules are expected to be part of a future issue
of TR-383.
A.1 OLT YANG Modules

The OLT YANG module defines the management data model needed to:
• Establish gRPC endpoints for the vOMCI Proxy and/or vOMCI function.
• Configuration and state information for the ONU management chain that identifies the remote
endpoint toward the vOMCI Proxy and/or vOMCI function.
The OLT model is defined in the following modules located in the application directory on Github:
• bbf-olt-vomci.yang
• bbf-olt-vomci-state.yang
• bbf-olt-grpc-client.yang
• bbf-olt-grpc-server.yang

The OLT model uses the following YANG modules that are common to these managed entities or are used
from other Broadband Forum Technical Reports and IETF RFCs:
Figure 32 OLT vOMCI YANG Modules
A.2 vOLTMF YANG Modules

The vOLTMF YANG module defines the management data model needed to:
• Maintain the network function topology for the vOMCI solution.
• Establish gRPC endpoints for the ONU Management Proxy, vOMCI Proxy function, pOLT and
vOMCI function.
• Maintain the ONU metadata for the configuration and state information associated with the vOMCI
solution. Supports both stand-alone and embedded ONU management models.
• Notification for discovered ONUs with associated device and software information.
The vOMCI function model is defined in the following modules located in the application directory on Github:
• bbf-voltmf.yang
• bbf-voltmf-state.yang
• bbf-voltmf-grpc-client.yang
• bbf-voltmf-kafka-agent.yang
The vOLTMF model uses the following YANG modules that are common to these managed entities or are
used from other Broadband Forum Technical Reports and IETF RFCs:

Figure 33 vOLTMF YANG Modules
A.3 vOMCI function YANG Modules

The vOMCI function YANG module defines the management data model needed to:
• Configuration and state information for ONUs using the vOMCI function.
• Establish gRPC endpoints for the vOMCI Proxy and OLT.
endpoint toward the OLT.
• Configuration and state for the OMCI retransmission capability.
• Notifications for:
o Alignment result of an ONU.
o ONU misalignment alarm.
o When the vOMCI function cannot translate a message from the ONU.
o When the vOMCI function cannot translate a message from the vOLTMF or ONU
Management Proxy.
The vOMCI function model is defined in the following modules located in the application directory on Github:
• bbf-vomci-function.yang
• bbf-vomci-function-grpc-client.yang
• bbf-vomci-function-grpc-server.yang
• bbf-vomci-function-kafka-agent.yang
The vOMCI function model uses the following YANG modules that are common to these managed entities or
are used from other Broadband Forum Technical Reports and IETF RFCs:

Figure 34 vOMCI Function YANG Modules
A.4 ONU Management Proxy function YANG Modules

The ONU Management Proxy function YANG module defines the management data model needed to:
• Maintain the network function topology for the vOMCI solution.
• Establish gRPC endpoints for the vOLTMF instances and vOMCI function instances.
• Configuration and state for the association policy between ONUs and vOMCI function instances.
endpoints toward the vOLTMF instance and the vOMCI function instance for an ONU.
• State information of the forwarding table used to associate an ONU to a vOLTMF and vOMCI
function instance.
• Configuration and state information for ONUs using the ONU Management Proxy.
The ONU Management Proxy model is defined in the following modules located in the application directory
on Github:
• bbf-onu-management-proxy.yang
• bbf-onu-management-proxy-state.yang
• bbf-onu-management-proxy-grpc-client.yang
• bbf-onu-management-proxy-grpc-server.yang
• bbf-onu-management-proxy-kafka-agent.yang
The ONU Management Proxy model uses the following YANG modules that are common to these managed
entities or are used from other Broadband Forum Technical Reports and IETF RFCs:

Figure 35 ONU Management Proxy YANG Modules
A.5 vOMCI Proxy function YANG Modules

The vOMCI Proxy function YANG module defines the management data model needed to:
• Establish gRPC endpoints for the pOLT and vOMCI function.
• Configuration and state for the OMCI retransmission capability.
endpoint toward the OLT and the vOMCI function for an ONU.
• Configuration and state information for ONUs using the vOMCI Proxy.
The vOMCI Proxy model is defined in the following modules located in the application directory on Github:
• bbf-vomci-proxy.yang
• bbf-vomci-proxy-grpc-client.yang
• bbf-vomci-proxy-grpc-server.yang
• bbf-vomci-proxy-kafka-agent.yang
The vOMCI Proxy model uses the following YANG modules that are common to these managed entities or
used from other Broadband Forum Technical Reports and IETF RFCs:

Figure 36 vOMCI Proxy YANG Modules
A.6 Dependencies on Related YANG Modules and Standards

The YANG modules in this Technical Report are based on YANG 1.1 (RFC 7950 [13])
The following YANG modules are used by this Technical Report:

• bbf-grpc-client
• bbf-grpc-server
• bbf-kafka-agent
• bbf-network-function-client
• bbf-network-function-server
• bbf-network-function
• bbf-device-aggregation [24]
• bbf-xponvani [26]
• ietf-yang-schema-mount [16]

Appendix I.vOMCI Deployment in CloudCO

The TR-384 [25] CloudCO framework provides the capability to manage Access PNFs using the Access
SDN M&C and the BAA layer or directly via the Access SDN M&C’s management function as depicted in
Figure 37.
Figure 37 CloudCO Framework
When deploying the vOMCI solution in the CloudCO framework, the vOLT Management Function is
performed by the BAA layer or directly by the Access SDN M&C.
I.1 Integrating the vOMCI Solution with the BAA

layer
The CloudCO’s BAA layer provides a persistent, digital representation of the Access PNFs regardless of the
operational status (e.g., online, offline) of the PNF. In addition, the BAA layer provides the adaptation of the
PNFs with device specific interfaces into the standard YANG representations that are used by the Access
SDN M&C across the Minf interface. Several functions within the BAA Core along with the vOLTMF provide
the capabilities defined by the vOLT Management Function specified in section 5.6 of this Technical Report.
Likewise, the vOMCI function, ONU Management Proxy and vOMCI Proxy are implemented as micro-
services where they communicate to the vOLTMF via the vOLTMF adapter that complies with the MvOLTMF-
vOMCI interface. These functions and interfaces are depicted in Figure 38.

Figure 38 Integrating the vOMCI solution with the CloudCO BAA layer
This way the BAA layer exposes to the northbound Access SDN Management and Control function the same
representation and management capabilities for an ONU regardless of the fact the ONU device is
embedded-OMCI or virtual-OMCI managed.
I.2 The vOMCI Solution Deployed as Standalone

NFVI
In deployment scenarios where the BAA layer is not used in the CloudCO framework, the Access SDN M&C
can directly interact with the vOLT Management function. In this deployment scenario the vOLT Management
function and the vOMCI function are deployed within an independent Network Function Virtualization
Infrastructure (NFVI) as depicted in Figure 39.

Figure 39 vOMCI Solution Deployed as Standalone NFVI

I.3 CloudCO Framework with vOMCI Solution

The options for deployment of the vOMCI solution in the CloudCO framework as described in I.1 and I.2 is
depicted in Figure 40 CloudCO Framework with vOMCI Solution.
Figure 40 CloudCO Framework with vOMCI Solution
The vOMCI solution toward the Access PNFs is via the SBI of the vOMCI function and/or vOMCI Proxy as
specified in section 5.8 of this Technical Report. Depending on the deployment scenario the vOLT
Management function’s capabilities as specified in section section 5.6 of this Technical Report are provided
by either the Access SDN M&C or the BAA layer. Regardless of how the vOMCI function is deployed (e.g.,
stand-alone, VNF), the capabilities of the vOMCI function and vOMCI Proxy as specified in section 5.2 of
this Technical Report and exposed through vOMCI function’s NBI remain the same. The only difference is
the protocol used to convey the information elements which is specified in section 5.7 of this Technical
Report.

I.4 vOLTMF Implemented as an Abstraction

Layer between the OLT and vOMCI function
In appendix I.3, the vOLTMF is either considered part of the BAA layer or as a stand-alone entity as part of
the CloudCO. In these previous deployment options, the OLT connects to each instance of the vOMCI
function for the ONUs that are attached to the OLT as depicted in the figure below.
Figure 41 Example of an OLT with individual sessions to vOMCI functions
An alternative deployment option this section introduces an aggregation of the communication sessions
between OLT and one or more vOMCI functions. In doing the aggregation of the communication sessions,
the OLT doesn’t require connectivity information about each of the vOMCI functions. Instead the OLT only
needs connect with the vOMCI Proxy that can be deployed with the vOLTMF to isolate the deployment
information of vOMCI function. In doing so, the OLT no longer needs to know how to connect to the vOMCI
function which allows the vOMCI function to only need knowledge of the ONU(s) as the service termination
point instead of the attached OLT. This alleviates the strict coupling between the OLT and vOMCI function
which may expose too much information of vOMCI function instance (e.g., the locations, numbers,
capacities, life cycles entities in the vOMCI solution) to parties that are not part of the vOMCI solution. This
coupling can also complicate or possibly inhibit the flexible migration of vOMCI functions in a Cloud
deployment.

When the vOLTMF is used as the aggregation entity, the vOLTMF has knowledge of the vOMCI solution to
include the vOMCI functions, OLTs and ONU attachments and thus is able to easily provide the capabilities
to proxy messages between the ONU and vOMCI function via dedicated channels to the requisite OLT. This
deployment is depicted below.
Figure 42 Example of the vOLTMF to Aggregate vOMCI/ONU communication
When the vOMCI function is integrated with the BAA layer as described in appendix I.1 the communication
sessions are managed by BAA layer functionality that comprise the vOLTMF as depicted below.

Figure 43 Deployment vOLTMF, vOMCI function and vOMCI Proxy in the context of the BAA layer
In Figure 43, the MvOLTMF-vOMCI interfaces are established from the vOLTMF to the vOMCI function. The
MvOMCI-OLT interfaces is established between the vOMCI function, vOMCI Proxy and OLT. The vOLTMF
maintains the ONU management chain topology for each ONU and establishes the necessary connectivity to
the ONU. Only one communication session is necessary to be initiated/maintained between a vOMCI Proxy
and OLT. The vOMCI Proxy acts as an application gateway that forwards messages between the vOMCI
function and the ONU via the attached OLT.

Appendix II. vOMCI Deployment in FANS

TR-370 [27] Fixed Access Network Sharing (FANS) describes an architectural framework for sharing
resources of an Access Node where Infrastructure Network Provider’s slices the Access Node’s resources
that are shared and allocated to virtual network operators (VNOs). TR-370 [27] defines two possible models
for resources sharing or slicing:
• Management System based, which performs network slicing at management system level and not
directly into the equipment itself. This model is described in Figure 44.
• Virtual Access Node based, which separates the physical access node into multiple, virtual
partitions, each containing ports and forwarding resources directly managed by a VNO. This model is
described in Figure 45.
Figure 44 TR-370 Management System Model

Figure 45 Virtual Access Node Model
II.1 Management System Model

When FANS is deployed using the Management System Model, the vOLT Management function resides with
the Centralized Management System and implements the capabilities defined by the vOLT Management
function (e.g., xPON Function, PMAA function, representation of the OLT and ONU’s configuration and state)
specified in section 5.6 of this Technical Report. As there isn’t a Virtualized Access Node in the Management
System model, the vOMCI function is a new functional element that can reside in the Centralized
Management System or can be introduced with the network as a network function. When deployed with the
Centralized Management System, the Centralized Management System provides the capabilities and
interfaces provided by the vOMCI function as specified in sections 5.2, 5.7 and 5.8 of this Technical Report.
These deployment options are depicted in Figure 46.

Figure 46 vOMCI Solution for FANS Management System Model
II.2 Virtual Access Node Model

When FANS is deployed using the Virtual Access Node Model, the vOLT Management function resides on
the Centralized Management System, implementing the capabilities defined by the vOLT Management
function (e.g., xPON Function, PMAA function, representation of the OLT and ONU’s configuration and state)
specified in section 5.6 of this Technical Report. The NFVI that hosts the Virtualized Access Node provides
the capabilities and interfaces provided by the vOMCI function as specified in sections 5.2, 5.7 and 5.8 of
this Technical Report or the vOMCI function can reside as a stand-alone function within another NFVI host.
This deployment option is depicted in Figure 47.

Figure 47 vOMCI Solution for FANS Virtual Access Node Model

Appendix III. Interoperability of vOMCI

Functionality with Multi-vendor ONUs
The discovery and management of ONUs in the xPON architecture uses two (2) communication messaging
approaches – PLOAM whose messages are communicated at the transmission convergence (TC) layer’s
PLOAM channel and OMCI messages which are communicated across the OMCI channel. ITU-T G.988
clearly defines the messages and management entities (ME) but it does not provide guidance on how the
MEs are used to support the configuration and operation of ONUs for various services. For example, the
deployment of high-speed internet or IPTV services by an operator can use different VLAN architectures that
require the use of different MEs in different sequences creating interoperability (IOP) problems when the
same services (i.e., IPTV service) are needed across a mix of OLT and ONU vendors. This section describes
the problem of multi-vendor interoperability for OMCI messaging in more detail along with two (2) likely
deployment scenarios.
III.1 Multi-vendor ONU IOP with OMCI

xPON architectures use OMCI messages to configure and manage functionality provided by the ONU,
including service level configuration. In solutions where the OMCI channel is embedded within the OLT,
multi-vendor ONU interoperability requires the OLT and subtended ONU establish a common consensus on
what OMCI messages to use as well as the sequence needed to fulfil the management request. These MEs
and their sequence can differ from ONU or OLT vendor. As such, service providers typically define the OMCI
MEs that are used for a service and rely on vendors to determine the proper sequencing of the OMCI
messages. These OMCI lists for a service can differ between OLT or ONU vendors and service providers
have to spend significant time, using a protocol analyzer, to determine the correct OMCI messages and
sequences that are used for the various service interactions. When multiplied by the number of OLT and
ONU vendors, the cost and time of this validation becomes prohibitive.
III.2 Multi-vendor ONU IOP with Single vOMCI

Function (1:N scenario)
In the 1:N deployment scenario, the service provider is able to define the OMCI ME list for each service and
establish the single vOMCI function that can be used with ONUs from different vendors. Because the OLT is
not involved in the OMCI message interactions for the service, service providers can verify this single vOMCI
function and re-use it to manage all the ONUs. This deployment scenario provides significant reduction in
time and cost to validate the solution and reduces the complexity of the ONU IOP with respect to the OLT
itself.
Figure 48 ONU IOP with Single vOMCI Function (1:N scenario)

III.3 Multi-vendor ONU IOP with Specific vOMCI

Function (N*1:1 scenario)
In the N*1:1 deployment scenario, the OMCI message set or sequencing for the service can vary from ONU
vendor or ONU models within a vendor. This deployment scenario requires the capability to group ONUs by
various categories like vendor, ONU model or even an ONU device. Each group of ONUs are then able to be
associated with a specific vOMCI function. The service provider can reduce the cost to validate the OMCI
messages and focus on the service along with the cost of validating the solution.
Figure 49 ONU IOP with Specific vOMCI Functions (N*1:1 scenario)

Appendix IV. ONU Authentication in Various

Scenarios
When an ONU attaches to the OLT, the ONU and OLT engage in series of PLOAM interactions that results
in the ONU being authenticated as described in ITU-T G.984.3 Appendix VI, ITU-T G.987.3 section 15.2,
ITU-T G.989.3 section 15.2 and ITU-T G.9807.1 Annex C.15. Additionally, section 7.1 of TR-156 [20]
describes additional methods to authenticate ONUs that can be performed by the OLT or remote
management systems (e.g., vOLTMF) when ONUs are initially provisioned.
In addition to the methods discussed in TR-156 section 7.1, ITU-T G.984.3 Appendix VI, ITU-T G.987.3
section 15.2, ITU-T G.989.3 section 15.2 and ITU-T G.9807.1 Annex C.15, there is a need in certain retail
scenarios for ONUs and when the ONU can attach to a subset of attachment points within the network (e.g.,
nomadic ONU) for management systems to be able to validate that the ONU can attach to an attachment
point by validating the permitted attachment points that an ONU can be activated upon. This verification
check typically is performed based on the allowed topology of attachment points for the ONU.
Further, when an ONU for a subscriber has not been correctly configured for authentication of the ONU (e.g.,
incorrect attachment point), remote management systems (e.g., vOLTMF) need to be able to authenticate
the ONU using information maintained by the remote management system such as a list of valid serial
numbers or registration IDs. Additionally, the remote management system can consider the verification of
attachment point to avoid unlimited access from unexpected attachment points.

Appendix V. Supporting Interactions for vOMCI

Deployments
This appendix defines a series of interactions that are needed to support vOMCI deployments. The purpose
of describing these interactions is to identify any requirements that are needed for the interfaces or elements
(e.g., OLT, vOLTMF, vOMCI function) of the vOMCI solution.
V.1 Configured ONU is Detected Online

Appendix I of ITU-T G.988 provides a procedure to "bring-up" an ONU that has never been synchronized
with the needed management entities (e.g., vOLTMF). This procedure in ITU-T G.988 is called the "New
ONU Bring-up" method.
This section describes the interactions necessary to implement the New ONU bring-up method of Appendix I
of ITU-T G.988.
Figure 50 Configured ONU is Detected Online
The ONU is detected online (OMCC channel has been established) and goes to PLOAM O5-O6 state as
defined in Annex D.4/ITU-T G.984.3 [2], Section 12/ITU-T G.987.3 [3], Appendix C.12/ITU-T G.9807.1 [4]
and Section 12/ITU-T G.989.3 [5].
1) OLT sends the ONU state change notification (including serial number and optional PLOAM password) to
the vOLTMF. The ONU state-change notification is defined in TR-385 issue2 and ITU-T G.984.3 Appendix
VI.
2) vOLTMF notifies vOMCI function that an ONU has come online and will use the specified ONU
management chain.
3) When the vOMCI function sees an expected ONU has been detected to come online, the vOMCI function
sends Get MIB data sync message to ONU as defined in ITU-T G.988 section 9.1.3.

4) vOMCI function reports the configuration align result of the ONU to vOLTMF as defined in ITU-T G.988
Appendix I.1.2.2.
5) If the ONU's configuration is misaligned, the vOLTMF aligns the ONU by sending the ONU's current
configuration to the ONU.
5a) vOLTMF sends the ONU's configuration via the ReplaceConfig request message.
5b) vOMCI function issues a MibReset OMCI message as defined in ITU-T G.988 Appendix I.1.4.2.
5c) vOMCI function issues a MibUpLoad OMCI message as defined in ITU-T G.988 Appendix
I.1.1.1.2.
5d) vOMCI function issues any additional configuration necessary to complete the ONU alignment
request.
5e) vOMCI function sends a ReplaceConfigResp response message to the vOLTMF with the result
of the operation.
6) If the ONU's configuration is aligned, the vOLTMF requests the alarms from an ONU.
6a) vOLTMF sends a request for the alarms via the GetData request message as defined in section
5.7.1 of this Technical Report.
6b) vOMCI function issues a “Get all alarms OMCI message as defined in ITU-T G.988 Section
11.2.2
7) The vOLTMF sends the OLT’s configuration to the OLT.
8) If the configuration is aligned, the vOLTMF reports that ONU is detected and aligned to the Access SDN
M_C.

V.2 Automated ONU Discovery

When an ONU is attached to an OLT the ONU identifies itself to the OLT via its serial number or registration
ID. Upon recognition of the ONU the OLT informs the vOLTMF of the discovered ONU.
In this scenario, the ONU has not been properly authenticated requiring the vOLTMF to request additional
ONU device information from the vOMCI. Upon receiving the device information of the ONU via the vOMCI
function, the vOLTMF reports the discovery of the ONU to other interested parties (e.g., Access SDN M&C).
Note: If the ONU passes authentication, the flow is shown in section Configured ONU is detected
Online.
The figure below describes this interaction.

Figure 51 Automated ONU Discovery

the vOLTMF. The ONU state change notification is defined in TR-385 issue2 and ITU-T G.984.3 Appendix
VI.
2) vOLTMF identifies the vOMCI function that can obtain the device and software information for the ONU.
3) Get ME operation for software and hardware properties of the ONU
3a) vOLTMF sends a request to get the device information including the software version.
3b) vOMCI function sends the ONU-G ME get operation defined in ITU-T G.988 clause 9.1.1.
3c) vOMCI function sends the ONU2-G ME get operation defined in ITU-T G.988 clause 9.1.2.
3d) vOMCI function sends the Software image ME get operation defined in ITU-T G.988 clause
9.1.4.
3e) vOMCI function returns the response for getting ONU device information to the vOLTMF.
4) Report automatically discovered ONU that includes information about ONU device and software
information obtained in the get response to the Access SDN M_C.
V.3 Automated ONU Discovery Failure

When an ONU is attached to an OLT the ONU identifies itself to the OLT via its serial number. Upon
recognition of the ONU the OLT informs the vOLTMF of the discovered ONU.
In this scenario, the vOLTMF cannot either discern which vOMCI function instance can be used to send the
request to obtain the device and software information from the ONU or the selected vOMCI function cannot
successfully obtain the device and software information.

Figure 52 Automated ONU Discovery Failure

the vOLTMF. The ONU state change notification is defined in TR-385 issue2 and ITU-T G.984.3 Appendix
VI.
2) vOLTMF identifies the vOMCI function that can obtain the device and software information for the ONU.
3) If the vOMCI function is identified, the vOLTMF sends Get ME operation for software and hardware
properties of the ONU.
3a) vOLTMF sends a request to get the device information including the software version.
3b) vOMCI function sends the ONU-G ME get operation defined in ITU-T G.988 clause 9.1.1.
3c) vOMCI function fails to receive the ONU2-G ME get operation defined in ITU-T G.988 clause
9.1.2.
3d) vOMCI function returns the failed response for getting ONU device information to the vOLTMF.
4) Report failed automatically discovered ONU that includes additional information about the failure to the
Access SDN M_C.
V.4 Synchronize PM-related intervals and timer

The ONUs that are managed in the vOMCI solution can be aligned to a common 15-min collection interval by
the vOMCI function. The ONUs’ PM interval is periodically synchronized with the corresponding PM interval
maintained by the vOMCI. This is achieved by utilizing the OMCI synchronize time action to align individual
ONUs when necessary (e.g., newly detected, alignment/realignment). Furthermore, the instances of the
vOMCI function should also be synchronized to a common clock via the NTP protocol. Thus, ONUs managed
by separate vOMCI functions can also be synchronized between each other with rather high precision or
accuracy provided by the OMCI synchronize time action.
Section I.4 of ITU-T G.988 [1] describes the capability where PM MEs can be synchronized to a common 15-
min collection interval starting point by sending a request to the ONU to synchronize the PM collection
interval using the OMCI synchronize time action as described in appendix A.2.33 and A.3.33 of ITU-T G.988
[1].
An example scenario, the Figure 53 describes the PM 15-min collection interval alignment activity upon
discovery on an ONU by adding an additional step in the discovery of the ONU as depicted in Figure 50:
Figure 53 Synchronize PM intervals for a Discovered ONU
V.5 Background ONU Software Download

Support
Typically, ONU Software download via OMCI is a prolonged process, especially if baseline OMCI messages
are used for image transfer. The vOMCI function can identify whether ONU supports extended OMCI
messages by querying ONU2-G ME, as defined in ITU-T G.988 clause 9.1.2 and use extended OMCI
messages if supported by the ONU.
Since image transfer is lengthy and involves multiple “Download section”, “Download section response”
iterations, the vOMCI function must allow other configuration interactions while image transfer is in progress
in the background. Following software download, the new software image can optionally be committed
and/or activated. If software image is activated, ONU restarts and then the ONU is discovered as described
appendix V.2.
The background ONU software download example is depicted in Figure 54:
Figure 54 Background ONU Software Download
1) Access SDN M_C requests vOLTMF to download a new ONU software image using download” action, as
defined in Common YANG, bbf-software-management.yang.
2) vOLTMF forwards the “download” action to vOMCI function instance managing the target ONU.
3) vOMCI function transfers software image using “Start download” operation, followed by multiple
“Download Section” operations”, followed by “End Download” operation. All operations are applied to
“Software Image” ME, as defined in ITU-T G.988 Clause 9.1.4.
ONU image transfer typically takes from multiple seconds to multiple minutes. vOMCI function must be able
to modify and query ONU configuration whilst image transfer is in progress. In the diagram above it is shown
as “Unrelated request X” in the step 3b.
4) vOMCI function notifies vOLTMF that software download is completed using revision-downloaded
notification, as defined in Common YANG, bbf-software-management.yang.
5) vOLTMF notifies Access SDN M_C.
Appendix VI. Connectivity Management among

vOLTMF(s) and vOMCI functions
In Figure 55 one or more vOLTMF instances manage the connectivity and interaction with multiple vOMCI
function instances (i.e., vOMCI1, vOMCIn). Each vOLTMF instance could interact with one or more vOMCI
function instances directly or indirectly, e.g., via load balancing. The vOLTMF is responsible for the workflow
and sequencing the requests to the ONU. Each vOLTMF instance can perform parallel configurations of
multiple different ONUs. Moreover, the vOLTMF takes the responsibility of maintaining the management and
control states of the ONUs and makes the ONU management and control complete and accurate.
Figure 55 Connectivity Among vOMCI functions and vOLTMF(s)
Appendix VII. vOMCI Function Connectivity

Using a Session Proxy
In certain deployments the OLT can consolidate the communication with N vOMCI functions using the same
communication session to a communication end-point that acts as a transparent session proxy.
In Figure 3, the OLT A uses 2 communication sessions to the vOMCI function instances. However, if a
single session from OLT A is required, the vOMCI Proxy can be used. This deployment scenario works well
where the OLT is resource constrained.
Figure 56 Single Session – OLT to vOMCI Connectivity
Appendix VIII. Examples of MvOLTMF-vOMCI

Messages
Section 5.7.1 provides the information model and message definition for messages that are conveyed across
the MvOLTMF-vOMCI interface. This appendix provides examples for usage of the various requests that use the
MvOLTMF-vOMCI interface.
VIII.1 ONU Device Data Model

Section 5.7.1 describe the message format that is used to convey the data model and operations to
configure and operate an ONU device. This section describes examples of the ReplaceConfig request
message and an example Notification for ONU alignment.
VIII.1.1 Example ReplaceConfig Message for ONU

Target
The following is an example of a ReplaceConfig request to configure onu1:
ReplaceConfig
Msg {
header {
msg_id: "2"
sender_name: "vOLTMF"
recipient_name: "vomci-vendor-1"
object_type: ONU
object_name: "ont1"
}
body {
request {
replace_config {
config_inst: "{\"bbf-qos-filters:filters\":{},\"ietf-ipfix-
psamp:ipfix\":{},\"ietf-hardware:hardware\":{},\"bbf-qos-
classifiers:classifiers\":{},\"ietf-pseudowires:pseudowires\":{},\"bbf-
ghn:ghn\":{},\"bbf-qos-policies:qos-policy-profiles\":{},\"bbf-
vdsl:vdsl\":{},\"bbf-xpongemtcont:xpongemtcont\":{},\"ietf-
system:system\":{},\"bbf-qos-policer-envelope-profiles:envelope-
profiles\":{},\"bbf-ghs:ghs\":{},\"ietf-interfaces:interfaces\":{},\"bbf-qos-
policies:policies\":{},\"bbf-qos-traffic-mngt:tm-profiles\":{},\"bbf-qos-
policing:policing-profiles\":{},\"bbf-selt:selt\":{},\"bbf-l2-dhcpv4-relay:l2-
dhcpv4-relay-profiles\":{},\"ieee802-dot1x:nid-group\":{},\"ietf-
alarms:alarms\":{},\"ietf-netconf-acm:nacm\":{},\"bbf-hardware-rpf-
dpu:rpf\":{},\"bbf-pppoe-intermediate-agent:pppoe-profiles\":{},\"bbf-
fast:fast\":{},\"bbf-mgmd:multicast\":{},\"bbf-melt:melt\":{},\"bbf-subscriber-
profiles:subscriber-profiles\":{},\"bbf-ldra:dhcpv6-ldra-profiles\":{},\"bbf-
l2-forwarding:forwarding\":{}}"
}
}
}
}
ReplaceConfigResp response
Msg {
header {
msg_id: "2"
sender_name: "vomci-vendor-1"
recipient_name: "vOLTMF"
object_type: ONU
object_name: "ont1"
}
body {
response {
replace_config_resp {
status_resp{
status_code=0
}
}
}
}
}
VIII.1.2 Example Action Message to Set and ONU

Management Chain
The following is an example of an Action message that is sent from the vOLTMF to a vOMCI function in
order to set an ONU's management chain.
Action
Msg{
header {
msg_id: "3"
sender_name: "vOLTMF"
recipient_name: "vomci-vendor-1"
object_type: VOMCI_FUNCTION
object_name: "vomci-vendor-1"
}
body {
request {
action {
input_data: "{\"bbf-vomci-function:managed-onus\":{\"managed-
onu\":[{\"name\":\"ont1\",\"set-onu-communication\":{\"onu-attachment-
point\":{\"olt-name\":\"OLT1,\"channel-termination-name\":\"CT_1\",\"onu-
id\":1},\"voltmf-remote-endpoint\":\"vOLTMF_Kafka\",\"onu-communication-
available\":true,\"olt-remote-endpoint\":\"proxy-grpc-1\"}}]}}" }
}
}
Action response
Msg {
header {
msg_id: "3"
sender_name: "vomci-vendor-1"
recipient_name: "vOLTMF"
object_type: VOMCI_FUNCTION
object_name: "vomci-vendor-1"
}
body {
response {
action_resp {
status_resp {
status_code=0
}
}
}
}
}
Appendix IX. Examples for Using Datastore Tag

Section 5.6.4.1 discusses that DSTs can be used between the vOLTMF and vOMCI function in order keep
the ONU configuration datastore maintained by the vOLTMF with the ONU datastore information kept by the
vOMCI function. This section describes several examples that depict the usage of the DST.
IX.1 Use of DST in Configuration Requests

The vOLTMF can use the datastore tag to ensure the latest ONU configuration known by the vOMCI function
is the latest ONU configuration known by the vOLTMF. The vOLTMF does this by communicating the latest
datastore tag value to the vOMCI function in configuration requests as depicted in Figure 57. In this figure
the vOLTMF sends a different value for the DST each time the vOLTMF makes an update to the ONU's
configuration data. The vOMCI function maintains the latest successful provisioning/configuration request in
addition to maintaining the OMCI MIB Data Sync value received from the ONU. The vOLTMF can then
determine if the ONU configuration maintained by the vOLTMF and vOMCI function is synchronized by
comparing the value of the DST retrieved using the GetData message.
Figure 57 Use of DST in ONU Configuration
IX.2 Use of DST when the vOMCI function has

Restarted
When a vOMCI function is restarted, the vOLTMF can use the DST to quickly determine if the vOMCI
function's ONU configuration is aligned with the vOLTMF ONU configuration. The use of the DST along with
the vOMCI function's use of the MDS provides an efficient and fast mechanism to ensure the configuration
information for an ONU in the ONU, vOMCI function and vOLTMF are aligned. In Figure 58, when the vOMCI
function is restarted, the vOMCI function aligns itself with the ONU using the MDS and then reports the DST
in the alignment notification where the vOLTMF can then use to determine if the DST reported by the vOMCI
function is the same as the DST value maintained by the vOLTMF. Between the alignment result and the
DST value the vOLTMF can determine if the ONU needs to have its configuration restored.
Figure 58 Use of DST in vOMCI Function Restart
Appendix X. vOMCI-as-a-Service Deployment

The vOMCI-as-a-Service deployment organizes the ONU Management Proxy, vOMCI Proxy and vOMCI
function entities defined in this Technical Report into a vOMCI service that is consumed by multiple client
instances within the vOLTMF that is in charge of the various management functionalities such as ONU
access and slice management as depicted in Figure 59 below:
Figure 59 vOMCI-as-a-Service
By organizing the ONU Management Proxy, vOMCI Proxy and the associated vOMCI function instances as a
service and disaggregating from the vOLTMF the vOMCI service logic such as association of ONUs and
vOMCI function instances, ONU management chain setup, manipulation of the load balance and scale in/out
of the vOMCI function instances, the complexity of the connectivity between entities (e.g., vOLTMF instance,
OLT) that interface with the service is greatly reduced as the vOLTMF instances and OLTs no longer need to
connect directly to each vOMCI function instances. Instead the OLTs would connect to a vOMCI Proxy and
the vOLTMF instance connects to the ONU Management Proxy. This simplification has the following
benefits:
• When the scaling behavior of the vOMCI function instances rapidly changes (e.g., during restoration
of a geographic outage) and/or the number of vOMCI function instances needed to manage the
ONUs is large, the vOLTMF and OLT instances are no longer affected instead the burden of
interactions toward the vOMCI function instances is contained within the vOMCI service and it's
ONU Management Proxy and vOMCI Proxy entities.
• Simplification of the clients consuming vOMCI services such as vOLTMF instances is accomplished
by relying on the ONU Management Proxy to maintain the connectivity to the vOMCI function
instances and also provide the capability of allocating ONUs to vOMCI function instances. The
distribution of this functionality to allocate, monitor and maintain the association between the ONU
and vOMCI function instance to the vOMCI Service's ONU Management Proxy creates a less
complex vOLTMF instance along with a reduction in the more error-prone configuration tasks for
each vOLTMF instance. This simplification is an enabler to efficiently scale vOLTMF instances
within the vOLTMF service.
• Monitoring and management of the vOMCI function instances can be more effectively performed by
the vOMCI service as the vOMCI function instances are scaled and maintained and ONUs are re-
allocated between vOMCI functions instances.
X.1 Use of the ONU Management Proxy

The features of ONU Management Proxy defined in this Technical Report is critical to an effective
deployment of the vOMCI service for the following reasons:
• ONUs are allocated by the ONU Management Proxy based on policies with associated ONU criteria
not on a per ONU instance. This becomes a factor in large deployments where there are tens of
millions of ONU's managed via thousands of vOMCI function instances and hundreds of instances
of the vOLTMF.
• Connectivity toward the dynamic behavior of the vOMCI functions is hidden from the vOLTMF
instances. This removes the need for the vOLTMF instance to know how to connect to individual
vOMCI function instances (e.g., be configured with the vOMCI function instance's IP address, port,
Kafka topics, gRPC credentials)
• Choices of message transport protocol (i.e., Kafka, gRPC) by vendor of a vOMCI function is hidden
from the vOLTMF instances. This alleviates the need for the vOLTMF to support multiple message
transport protocols as new vOMCI functions are added to support new types of ONUs or new
software versions for ONUs where the vendor of the vOMCI function supports a message transport
protocol that is not currently supported by the vOLTMF instances.
End of Broadband Forum Technical Report TR-451

TR 451

Uploaded by

Document Informationclick to expand document information

Document Informationclick to expand document information

Copyright:

Available Formats

TR 451

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

TR 451

Uploaded by

Copyright:

Available Formats

Technical Report

© The Broadband Forum. All rights reserved.

3. THIRD PARTY RIGHTS

June 2022 © The Broadband Forum. All rights reserved 2 of 113

Issue Approval Publication Issue Changes

Editor: Timothy Carey, Nokia

Work Area Director(s): George Dobrowski, Morris Creek Consulting

June 2022 © The Broadband Forum. All rights reserved 3 of 113

1 PURPOSE AND SCOPE ................................................................................................................................... 10

5 VOMCI SOLUTION OVERVIEW ....................................................................................................................... 19

June 2022 © The Broadband Forum. All rights reserved 4 of 113

5.5.2.2 Requirements ................................................................................................................................................... 37

June 2022 © The Broadband Forum. All rights reserved 5 of 113

5.8.4.4 Securing the gRPC Channel .............................................................................................................................. 72

APPENDIX II. VOMCI DEPLOYMENT IN FANS............................................................................................ 87

APPENDIX V. SUPPORTING INTERACTIONS FOR VOMCI DEPLOYMENTS ................................................... 94

APPENDIX VIII. EXAMPLES OF MVOLTMF-VOMCI MESSAGES ........................................................................... 107

June 2022 © The Broadband Forum. All rights reserved 6 of 113

Figure 1 Scope of the vOMCI Solution .............................................................................................................12

June 2022 © The Broadband Forum. All rights reserved 7 of 113

Figure 55 Connectivity Among vOMCI functions and vOLTMF(s) .................................................................105

Table 1 Kafka Topic Categories .......................................................................................................................56

June 2022 © The Broadband Forum. All rights reserved 8 of 113

June 2022 © The Broadband Forum. All rights reserved 9 of 113

1 Purpose and Scope

The vOLT Management Function (vOLTMF) shown in Figure 1, is responsible for:

The vOMCI function shown in Figure 1, is responsible for:

June 2022 © The Broadband Forum. All rights reserved 10 of 113

The OLT shown in Figure 1, is responsible for:

• Transmitting PLOAM notifications to the vOLT Management Function.

June 2022 © The Broadband Forum. All rights reserved 11 of 113

Figure 1 Scope of the vOMCI Solution

June 2022 © The Broadband Forum. All rights reserved 12 of 113

2 References and Terminology

2.2.1 Published References

Document Title Source Year

June 2022 © The Broadband Forum. All rights reserved 13 of 113

Transmission convergence (TC) layer specification

June 2022 © The Broadband Forum. All rights reserved 14 of 113

[30] Google Remote Google Remote Procedure Call (gRPC) gRPC NA

AVC Attribute Value Change

June 2022 © The Broadband Forum. All rights reserved 15 of 113

MDS MIB Data Synchronization

June 2022 © The Broadband Forum. All rights reserved 16 of 113

3 Technical Report Impact

This document does not define any specific mechanisms.

June 2022 © The Broadband Forum. All rights reserved 17 of 113

June 2022 © The Broadband Forum. All rights reserved 18 of 113

5 vOMCI Solution Overview

By disaggregating the vOMCI function the following benefits can be achieved:

5.1 Onboarding of VNFs/CNFs

5.2 vOMCI Function Description

June 2022 © The Broadband Forum. All rights reserved 19 of 113

The interfaces provided by the vOMCI function are depicted in Figure 2.

Figure 2 vOMCI Function and vOMCI Proxy Interfaces

5.2.1 Onboarding the vOMCI Function

5.2.2 Management of the vOMCI Function