vOMCI Proxy and vOMCI Function
Introduction
The vOMCI Function, also known as the vOMC PF (Processing Function), and vOMCI Proxy provide the capabilities needed to:
-
Translate YANG request/responses and notifications to/from the vOLTMF into the OMCI messages
-
Transmit and receive request/responses and notification to/from the OLT
vOMCI Function
The vOMCI function, is deployed as a microservice, is responsible for:
-
Receiving service configurations from the vOLT Management function
-
Translating the received configurations into ITU G.988 OMCI management entities (ME) and formatting them into OMCI messages
-
Encapsulating and sending (receiving and de-encapsulating) formatted OMCI messages (ultimately targeting the ONU attached to the OLT) to (from) the vOMCI Proxy
-
Translating the OMCI messages (representing ONU’s operational data) received from the vOMCI Proxy into data (e.g. notifications, acknowledges, alarms, PM registers) understandable by the vOLT Management function
-
Sending the above ONU operational data to the vOLT Management function
The vOMCI function communicates with the vOLT Management function using Kafka bus that exchange GPB formatted messages as defined in WT-451.
Note: In this release there is a limitation of a single vOMCI Proxy instance for each OLT.
In this release, the communication between the vOMCI Proxy and the vOMCI function uses a gRPC connection where the remote endpoint is the vOMCI Proxy that serves as an application gateway/proxy function between the OLT and vOMCI function.
vOMCI Proxy
The vOMCI Proxy works as an aggregation and interception point that avoids the need for an OLT to directly connect to individual vOMCI functions and can act as a control/interception point between the OLT and vOMCI function that is useful for troubleshooting and other management purposes (e.g., security). As the aggregation/interception point, the vOMCI Proxy is responsible for maintaining the associations between OLTs and the corresponding vOMCI functions.
The vOMCI Proxy, deployed as a microservice, communicates with the vOMCI function.
The vOMCI Proxy is a gRPC endpoint that communicates with the OLT.
The vOMCI architecture diagram below depicts the vOMCI function and vOMCI Proxy microservices:
Deployment
The vOMCI function and vOMCI Proxy are deployed using a shared yaml file and the same docker network. An important part of deploying them correctly and ensuring the connectivity between network functions is assigning the correct GRPC endpoint names and Kafka topics.
Both the vOMCI function and the vOMCI Proxy have the following environmental variables in the yaml file:
- GRPC_SERVER_NAME: is used for setting the GRPC server local endpoint name
- GRPC_CLIENT_NAME: is used for setting the GRPC client local endpoint name
- KAFKA_CONSUMER_TOPICS: is used for setting the kafka consumer topics
- KAFKA_RESPONSE_TOPICS: for setting the response (kafka producer) topics
- KAFKA_NOTIFICATION_TOPICS: for setting the notification (kafka producer) topics
- VOMCI_KAFKA_SENDER_NAME: for setting the sender name in messages sent to the notification (kafka producer) topics
- VOMCI_KAFKA_VOLTMF_NAME: for setting the recipient(vOLTMF) name in messages sent to the notification (kafka producer) topics
Note: Before any communication between the vOMCI function and vOMCI Proxy, for example when set_onu_communication request is received, it is important the remote endpoint name of the other entity to match the local endpoint name of that entity.
The following is an example yaml file that would define the deployment of a vOMCI Function:
omci:
image: obbaa-vomci
hostname: obbaa-vomci
container_name: obbaa-vomci
ports:
- 8801:8801
- 58433:58433
environment:
GRPC_SERVER_NAME: obbaa-grpc-1
LOCAL_GRPC_SERVER_PORT: 58433
KAFKA_BOOTSTRAP_SERVER: "kafka:9092 localhost:9092"
KAFKA_CONSUMER_TOPICS: "OBBAA_ONU_REQUEST"
KAFKA_RESPONSE_TOPICS: "OBBAA_ONU_RESPONSE"
KAFKA_NOTIFICATION_TOPICS: "OBBAA_PROXY_ONU_NOTIFICATION"
VOMCI_KAFKA_SENDER_NAME: "bbf-vomci"
VOMCI_KAFKA_VOLTMF_NAME: "vOLTMF"
networks:
- baadist_default
depends_on:
- zookeeper
- kafka
The following is an example yaml file that would define the deployment of a vOMCI Proxy:
vproxy:
image: obbaa-vproxy
hostname: obbaa-vproxy
container_name: obbaa-vproxy
ports:
- 8433:8433
environment:
GRPC_CLIENT_NAME: obbaa-vproxy-grpc-client-1
GRPC_SERVER_NAME: obbaa-vproxy-grpc-server-1
LOCAL_GRPC_SERVER_PORT: 8433
REMOTE_GRPC_SERVER_PORT: 58433
REMOTE_GRPC_SERVER_ADDR: obbaa-vomci
KAFKA_BOOTSTRAP_SERVER: "kafka:9092 localhost:9092"
# List of Consumer topics, seperated by spaces
KAFKA_CONSUMER_TOPICS: "OBBAA_PROXY_ONU_REQUEST"
KAFKA_RESPONSE_TOPICS: "OBBAA_PROXY_ONU_RESPONSE"
KAFKA_NOTIFICATION_TOPICS: "OBBAA_PROXY_ONU_NOTIFICATION"
networks:
- baadist_default
Limitations of current implementation
- The Kafka interface has to start with specific consumption topics, through which further configuration can be received. These topics are in the environmental variable, under the field “KAFKA_REQUEST_TOPICS”. Additionally, the default Kafka bootstrap servers are under the environment field “KAFKA_BOOTSTRAP_SERVER” or using “kafka:9092 localhost:9092” in its absence.
- Concerning the grpc connections, in the current implementation each VNF instance (vOMCI function & vOMCI Proxy) can run up to one grpc server. Changing the server’s configuration, will result in it stopping and starting a new one.
- If in nf-client “enabled”:false is received, the Kafka consumer is closed and no further message can be received.
Persistency
Persistency is achieved through the use of an SQLite database to store the VNF’s configuration. Each entry is of the form (id, name, configuration, t) where
- id is an auto-incremented integer and the primary key
- name is the given name of the VNF
- configuration is a string containing the configuration of the VNF
- t is a timestamp of the time this entry was added
Every time the configuration of the VNF is updated, or an ONU is created or set, the database is updated, inserting a configuration generated by the VNF’s current state. At startup, the VNF checks if the database has a configuration assigned to it by checking the name and applying the most recent. If no said configuration exists, it gets configured in the default state.
All VNFs may share the same database, which is stored in “/db/database.db”.
vOLTMF to vOMCI/vOMCI Proxy Request Handling
The vOLTMF sends GPB formatted requests as defined in WT-451 for the vOLTMF-vOMCI interface. The messages are transmitted to the vOMCI function and the vOMCI Proxy function using the Kafka bus.
Creating an ONU in the vOMCI function
The following is an example of a create-onu RPC that is directed toward a vOMCI function:
Msg {
header {
msg_id: "1"
sender_name: "vOLTMF"
recipient_name: "vomci-vendor-1"
object_type: VOMCI_FUNCTION
object_name: "vomci-vendor-1"
}
body {
request {
rpc {
input_data: "{\"bbf-vomci-function:create-onu\":{\"name\":\"ont1\"}}"
}
}
}
}
Upon receipt the receiving function ensures that the ONU is created within the function:
- ONU is added to the list of managed ONUs and internal structures are initialized
- Response is sent on the kafka bus
Setting an ONU Management Chain
The following is an example of a set-onu-communication that is directed toward a vOMCI Proxy:
header.msg_id=2
header.sender_name="VOLTMF"
header.recipient_name="vproxy-vendor-1"
header.object_type = VOMCI_PROXY
header.object_name = "vproxy-vendor-1"
body.action.input_data =
"bbf-vomci-function:managed-onus":{
"managed-onu":[
{
"name":"onu1",
"set-onu-communication":{
"onu-communication-available":"true",
"vomci-remote-endpoint-name":"obbaa-grpc-1",
"olt-remote-endpoint-name":"OLT1",
"onu-attachment-point":{
"olt-name":"OLT1",
"channel-termination-name":"CT1",
"onu-id":1
}
}
}
]
}
Upon receipt the receiving function ensures that the ONU communication is established and activation has started within the function:
- if set onu configuration has not been received before for this ONU:
- save the new information regarding the ONU's management chain
- lookup the communication channels with the given endpoint names and add to them the managed ONU
- if the endpoint corresponds to a remote grpc server that is not known, the set-onu-communication request will be rejected by sending a unsuccessful kafka response otherwise send a successful kafka response
- initiate ONU activation sequence (vOMCI function only)
- send responses through kafka notifications (vOMCI function only)
- if ONU already exists and is configured (set ONU configuration has been received before):
- if only communication available changed, only the “communication available” field is handled
Deleting a Managed ONU
The following is an example of a delete-onu action that is directed toward a vOMCI Proxy:
Msg {
header {
msg_id: "6"
sender_name: "vOLTMF"
recipient_name: "proxy-1"
object_type: VOMCI_PROXY
object_name: "proxy-1"
}
body {
request {
action {
input_data: "{\"bbf-vomci-proxy:managed-onus\":{\"managed-onu\":[{\"name\":\"ont1\",\"delete-onu\":{}}]}}"
}
}
}
}
Upon receipt the receiving function ensures that the ONU is deleted within the function:
- ONU is deleted from the list of managed ONUs and any internal structures
- Response is sent on the kafka bus
ONU requests
ONU is added to the list of managed ONUs and internal structures are initialized. The OB-BAA implementation adds a “delta” field to the edit-config message to provide the information needed by the vOMCI function to assist in the translation of the YANG message into the correct OMCI message.
The following example describes an edit-config request that is sent from the vOLTMF toward a vOMCI function with the additional “delta” and identifier fields inserted in the message:
{
"onu_name": "onu1",
"event": "request",
"payload": {
"identifier": "3",
"operation": "edit-config",
"current": {
"ietf-hardware:hardware": {
"component": [
{
"name": "chassis_onu1",
"admin-state": "unlocked",
"class": "iana-hardware:chassis"
},
{
"parent": "chassis_onu1",
"name": "ontcage_onu1",
"parent-rel-pos": 0,
"class": "bbf-hardware-types:cage"
},
{
"parent": "ontcage_onu1",
"name": "ontsfp_onu1",
"parent-rel-pos": 0,
"class": "bbf-hardware-types:transceiver"
},
{
"parent": "ontsfp_onu1",
"name": "ontaniport_onu1",
"parent-rel-pos": 1,
"class": "bbf-hardware-types:transceiver-link"
},
{
"parent": "chassis_onu1",
"name": "ontcard1_onu1",
"admin-state": "unlocked",
"parent-rel-pos": 1,
"class": "bbf-hardware-types:board"
},
{
"parent": "ontcard1_onu1",
"name": "ontuni_uni1_onu1",
"parent-rel-pos": 1,
"class": "bbf-hardware-types:transceiver-link"
}
]
}
},
"delta": {
"ietf-hardware:hardware": {
"component": [{
"parent": "ontcard1_onu1",
"name": "ontuni_uni2_onu1",
"parent-rel-pos": 2,
"class": "bbf-hardware-types:transceiver-link"
},
{
"parent": "ontsfp_onu1",
"name": "ontaniport_onu1",
"parent-rel-pos": 1,
"class": "bbf-hardware-types:transceiver-link"
}
]
}
},
"target": {
"ietf-hardware:hardware": {
"component": [
{
"name": "chassis_onu1",
"admin-state": "unlocked",
"class": "iana-hardware:chassis"
},
{
"parent": "chassis_onu1",
"name": "ontcage_onu1",
"parent-rel-pos": 0,
"class": "bbf-hardware-types:cage"
},
{
"parent": "ontcage_onu1",
"name": "ontsfp_onu1",
"parent-rel-pos": 0,
"class": "bbf-hardware-types:transceiver"
},
{
"parent": "chassis_onu1",
"name": "ontcard1_onu1",
"admin-state": "unlocked",
"parent-rel-pos": 1,
"class": "bbf-hardware-types:board"
},
{
"parent": "ontcard1_onu1",
"name": "ontuni_uni1_onu1",
"parent-rel-pos": 1,
"class": "bbf-hardware-types:transceiver-link"
},
{
"parent": "ontcard1_onu1",
"name": "ontuni_uni2_onu1",
"parent-rel-pos": 2,
"class": "bbf-hardware-types:transceiver-link"
}
]
}
}
}
}
Notifications
Notifications can be sent from the vOMCI function or vOMCI Proxy for various purposes, For example, once the alignment of an ONU has been completed (after getting the MIB Data Sync from the ONU) the vOMCI function sends a notification to the vOLTMF. The following is an example of a onu-alignment-status notification that sent from a vOMCI function:
header {
msg_id: "1"
sender_name: "vomci1"
recipient_name: "vOLTMF"
object_name: "onu1"
}
body {
notification {
data: "{\"bbf-vomci-function:onu-alignment-status\":{\"event-time\": \"2021-06-01T15:53:36+00:00\",\"onu-name\": \"ont1\",\"alignment-status\": \"aligned\"}}"
}
}
ONU Alarm Handling
The vOMCI function receives the ONU alarm’s status then to send notifications that reflect alarm changes. Because of this, the vOMCI function is required to store the status of the ONU’s alarms.
Everytime an alarm message is received from the ONU, the vOMCI function checks all the ONU’s alarms status received and verifies which alarms have changed its state. Then, the notification with the alarms that changed are sent to vOLTMF
For more information about the ONU alarm Handling
Subscribing to vOMCI function for receiving telemetry data of ONUs
The vOMCI function is able to periodically fetch some specified telemetry data from ONUs and push the collected data to the given collection point.
Establishing telemetry subscriptions
The ONU telemetry data, which is specified as a YANG path, and the time interval for pushing data are registered to the vOMCI function through sending a telemetry subscription request, as follows:
Msg {
header {
msg_id: "1"
sender_name: "vOLTMF"
recipient_name: "vomci-vendor-1"
object_type: "VOMCI_FUNCTION"
object_name: "vomci-vendor-1"
}
body {
request {
action{
input_data: <data>
}
}
}
}
where <data> consists of subscription information as follows:
{
"bbf-vomci-function:vomci": {
"managed-onus": {
"managed-onu": [
{
"name": "ont1",
"bbf-obbaa-vomci-telemetry:establish-subscription": {
"updates": [
{
"name": "pm",
"xpaths": [
"ietf-interfaces:interfaces-state"
],
"mode": "periodic",
"interval": 900
}
]
}
}
]
}
}
}
If the vOMCI succeeds to register such a subscription it replies with the id associated to this subscription (which can be later used to refer to this subscription), as follows:
Msg {
header {
msg_id: "1"
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
}
output_data: "{\"bbf-obbaa-vomci-telemetry:subscription-id\": 1}"
}
}
}
}
Note: Telemetry subscription response from vOMCI function Expand source All the telemetry subscriptions are persistently stored, such that in case of any failure in the vOMCI function these subscriptions are restored and continue working after vOMCI recovery.
Note: Currently, vOMCI function is able to stream PM counters of ethernet interfaces. Accordingly, before making telemetry subscriptions, these PM counters must be first enabled, through the ONU YANG configurations.
Streaming telemetry data
As soon as a telemetry subscription is registered, vOMCI function starts to periodically stream the specified ONU’s data on a Kafka topic, which is initially configured as an environment variable. The telemetry data are pushed as notifications, as follows:
Msg {
header {
msg_id: "1"
sender_name: "vomci-vendor-1"
recipient_name: "vOLTMF"
object_type: ONU
object_name: "ont1"
}
body {
notification {
data: <data>
}
}
}
where <data> consists of telemetry data as follows:
{
"bbf-obbaa-vomci-telemetry:telemetry-data": {
"subscription-id": 1,
"onu-name": "ont1",
"collection-time": "2023-04-14 11:31:42.363270",
"last-message": "true",
"values": {
"ietf-interfaces:interfaces-state": {
"interface": [
{
"name": "enet_uni_ont1_1_1",
"type": "iana-if-type:ethernetCsmacd",
"bbf-interface-port-reference:port-layer-if": [
"ontUni_ont1_1_1"
],
"admin-status": "up",
"oper-status": "up",
"bbf-interfaces-performance-management:performance": {
"intervals-15min": {
"history": [
{
"interval-number": 1,
"invalid-data-flag": "false",
"measured-time": 900,
"in-broadcast-pkts": 21,
"in-multicast-pkts": 22,
"in-octets": 20,
"out-broadcast-pkts": 11,
"out-multicast-pkts": 12,
"out-octets": 10,
"time-stamp": "2023-04-14 11:31:42.363177"
}
]
}
}
},
{
"name": "enet_uni_ont1_1_2",
"type": "iana-if-type:ethernetCsmacd",
"bbf-interface-port-reference:port-layer-if": [
"ontUni_ont1_1_2"
],
"admin-status": "up",
"oper-status": "up",
"bbf-interfaces-performance-management:performance": {
"intervals-15min": {
"history": [
{
"interval-number": 1,
"invalid-data-flag": "false",
"measured-time": 900,
"in-broadcast-pkts": 0,
"in-multicast-pkts": 0,
"in-octets": 0,
"out-broadcast-pkts": 0,
"out-multicast-pkts": 0,
"out-octets": 0,
"time-stamp": "2023-04-14 11:31:42.363230"
}
]
}
}
},
{
"name": "ontAni_ont1",
"type": "bbf-xpon-if-type:ani",
"admin-status": "up",
"oper-status": "up"
}
]
}
}
}
}
Retrieving telemetry subscriptions
This list of telemetry subscriptions made in vOMCI function can be retrieved by sending a GET request toward vOMCI function, as follows:
Msg {
header {
msg_id: "2"
sender_name: "vOLTMF"
recipient_name: "vomci-vendor-1"
object_type: "VOMCI_FUNCTION"
object_name: "vomci-vendor-1"
}
body {
request {
get_data {
filter: <data>
}
}
}
}
where <data> consists of requested subscriptions as follows:
{
"bbf-vomci-function:vomci": {
"managed-onus": {
"managed-onu": [
{
"name": "ont1",
"bbf-obbaa-vomci-telemetry:established-subscriptions": {}
}
]
}
}
}
The response is as follows:
Msg {
header {
msg_id: "3"
sender_name: "vomci-vendor-1"
recipient_name: "vOLTMF"
object_type: VOMCI_FUNCTION
object_name: "vomci-vendor-1"
}
body {
response {
get_resp {
data: <data>
}
}
}
}
where <data> consists of the telemetry subscriptions:
{
"bbf-vomci-function:vomci": {
"managed-onus": {
"managed-onu": [
{
"name": "ont1",
"bbf-obbaa-vomci-telemetry:established_subscriptions": [
{
"subscription-id": 1,
"updates": [
{
"name": "pm1",
"xpaths": [
"ietf-interfaces:interfaces-state"
],
"interval": 900
}
]
}
]
}
]
}
}
}
Deleting telemetry subscriptions
A telemetry subscription can be removed from vOMCI function through its subscription ID, as follows:
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: <data>
}
}
}
}
where <data> consists of subscriptions which should be removed as follows:
{
"bbf-vomci-function:managed-onus": {
"managed-onu": [
{
"name": "ont1",
"bbf-obbaa-vomci-telemetry:delete-subscription": {
subscription_id: 1
}
}
]
}
}
The response of the vOMCI function on the subscription request is as follows:
response {
action_resp {
status_resp {}
output_data: "{\"bbf-obbaa-vomci-telemetry:subscription-id\": 1}"
}
}
Note: The vOMCI function removes all the telemetry subscriptions of an ONU, when it receives a onu-delete request for that ONU.
vOMCI function Communication with the OLT
The vOMCI function (vOMC PF) receives requests to translate YANG messages to corresponding OMCI messages. These OMCI messages are directed toward an OLT where the targeted ONU is attached. The vOMC PF interacts with the OLT via the vOMCI Proxy where the vOMCI Proxy is the gRPC remote endpoint for the ONU.