{"activeVersionTag":"latest","latestAvailableVersionTag":"latest","collection":{"info":{"_postman_id":"c6920b23-dcab-4b53-aa71-8f657d9e3447","name":"bbf-api","description":"Collection of Broadband Forum artifacts packaged to be consumable in a modern Kubernetes environment at scale.\n\n# Broadband Forum Ecosystem\n\n\n\n# Broadband Access Abstraction\n\nAbstracting the access method from the hardware divides the problem simplifying the approach.\n\n\n\n# Broadband Forum Modules\n\n\n\nThis Technical Report currently defines the following interface-related YANG modules: \n• bbf-fastdsl: An interface object supporting xDSL and G.fast. \n• bbf-ghs: Includes standardized parameters to startup (“handshake”) G.fast or VDSL. \n• bbf-fast: Includes all standardized parameters for G.fast configuration, status monitoring, \nperformance management, testing and diagnostics. \n• bbf-vdsl: Includes all standardized parameters for VDSL2 configuration, status \nmonitoring, performance management, testing and diagnostics. \n• bbf-selt: Includes all standardized parameters for configuration and test results of SingleEnded Line Test (SELT). \n• bbf-melt: Includes all standardized parameters for configuration and test results of \nMetallic Line Test (MELT). \n• bbf-hardware-rpf-dpu: Includes all standardized parameters for Reverse Power Feeding \n(RPF) configuration, status monitoring and event notifications. \n• bbf-gbond: Includes all standardized parameters for managing physically bonded access \nlines.\n\n# Broadband Forum Model Relationships\n\n\n\n# FTTdp Access Network\n\n\n\n# bbf-xpon\n\nThe bbf-xpon collection contains YANG definitions for supporting the Broadband Forum requirements on management of ITU-T Passive Optical Network (PON) interfaces as defined in ITU-T G.984.x, G.987.x, ITU-T G.989.x and ITU-T G.9807.x. As such, this module is specific to access network equipment (e.g., BBF-specified Access Nodes and FTTdp DPUs).\n\n\n\nBBF-XPON is a project within the Broadband Forum that focuses on the standardization of passive optical networks (PONs) that use the XGS-PON and NG-PON2 technologies. RESTCONF is a protocol that provides a RESTful API for accessing and manipulating configuration data on network devices. In the context of the BBF-XPON project, RESTCONF is used to manage and configure XGS-PON and NG-PON2 networks.\n\n\n\nThe BBF-XPON YANG models define a set of data structures and schema that describe the configuration and management of XGS-PON and NG-PON2 networks. These models are designed to be vendor-neutral and interoperable, allowing different network devices from different vendors to be managed in a consistent and standardized manner.\n\nRESTCONF provides a standard way for applications to interact with network devices using HTTP methods such as GET, PUT, POST, and DELETE. This allows administrators and developers to easily manage and configure XGS-PON and NG-PON2 networks using a RESTful API. For example, an application can use a RESTCONF client to retrieve information about the state of the network or to modify the configuration of a specific device or service.\n\nBy standardizing the configuration and management of XGS-PON and NG-PON2 networks using YANG models and RESTCONF, the BBF-XPON project aims to simplify the deployment and maintenance of these networks, while also promoting interoperability and reducing vendor lock-in.\n\n### Residential\n\n\n\n### Metro-Ethernet\n\n\n\n### Telecom Interests\n\nWhen provisioning subscriber service activation for bbf-xPON (Broadband Forum Passive Optical Network) technology, the following traditional telecom parameters are typically used:\n\n- Optical power levels: This refers to the strength of the light signals transmitted over the optical fiber. The optical power levels must be within the acceptable range to ensure reliable transmission.\n- Signal-to-Noise Ratio (SNR): This is the ratio of the signal power to the noise power in the line. It indicates the quality of the signal and is used to determine the maximum possible data rate that can be transmitted over the line.\n- Bit Error Rate (BER): This is a measure of the number of errors that occur in the data transmitted over the line. A low BER indicates a high-quality signal.\n- Maximum Attainable Data Rate (MADR): This is the maximum data rate that can be achieved over the line, based on its physical characteristics such as length, attenuation, and noise levels.\n- Minimum Guaranteed Data Rate (MGDR): This is the minimum data rate that the service provider guarantees to deliver to the subscriber, based on the line's physical characteristics and the service plan subscribed to by the customer.\n- Profile Configuration: The service provider configures the line profile based on the line's physical characteristics and the service plan subscribed to by the customer. The profile determines the modulation scheme, the frequency bands used, and the error correction mechanism used to transmit data over the line.\n- VLAN Configuration: This is the configuration of the Virtual Local Area Network (VLAN) that the customer's traffic is assigned to. The VLAN is used to separate the customer's traffic from other traffic on the service provider's network.\n \n\nBy using these traditional telecom parameters, service providers can provision bbf-xPON subscriber service activation and ensure that customers receive the highest possible quality of service.\n\n### Vendor\n\nThe Broadband Forum (BBF) is an industry consortium that develops standards and specifications for broadband networking technologies. One of the standards developed by the BBF is the XGS-PON (10G symmetric Passive Optical Network) standard, which defines the transmission of high-speed data over fiber optic networks.\n\nSeveral vendors offer equipment that conforms to the BBF-XGS-PON standard. Here are some examples:\n\n1. Nokia: Nokia offers a range of XGS-PON optical line terminals (OLTs) and optical network terminals (ONTs) that conform to the BBF-XGS-PON standard. These devices support high-speed broadband services with symmetric speeds of up to 10 Gbps.\n2. Huawei: Huawei offers XGS-PON OLTs and ONTs that conform to the BBF-XGS-PON standard. These devices support high-speed broadband services with symmetric speeds of up to 10 Gbps, as well as advanced features such as network slicing and quality of service (QoS) management.\n3. ZTE: ZTE offers XGS-PON OLTs and ONTs that conform to the BBF-XGS-PON standard. These devices support high-speed broadband services with symmetric speeds of up to 10 Gbps, as well as features such as traffic aggregation and network protection.\n4. Adtran: Adtran offers XGS-PON OLTs and ONTs that conform to the BBF-XGS-PON standard. These devices support high-speed broadband services with symmetric speeds of up to 10 Gbps, as well as advanced features such as network slicing and service level agreement (SLA) management.\n5. Calix: Calix offers XGS-PON OLTs and ONTs that conform to the BBF-XGS-PON standard. These devices support high-speed broadband services with symmetric speeds of up to 10 Gbps, as well as features such as traffic engineering and policy-based routing.\n \n\nOverall, equipment that conforms to the BBF-XGS-PON standard provides reliable and high-performance connectivity over fiber optic networks, making it a cost-effective solution for delivering high-speed broadband services to homes and businesses.\n\n# bbf-vdsl\n\nThe bbf-vdsl collections contains of YANG definitions for supporting the Broadband Forum requirements on management of Very High-speed Digital Subscriber Line (VDSL) interfaces as defined in ITU-T G.993.x, ITU-T G.997.1 and BBF TR-252. As such, this module is specific to access network equipment (e.g., BBF-specified Access Nodes and FTTdp DPUs).\n\nThe BBF-VDSL project is an initiative within the Broadband Forum to standardize the management and configuration of broadband access networks that use Very-high-bit-rate Digital Subscriber Line (VDSL) technology. RESTCONF is a protocol that provides a RESTful API for accessing and manipulating configuration data on network devices. In the context of the BBF-VDSL project, RESTCONF is used to manage and configure VDSL networks.\n\nThe BBF-VDSL YANG models define a set of data structures and schema that describe the configuration and management of VDSL networks. These models are designed to be vendor-neutral and interoperable, allowing different network devices from different vendors to be managed in a consistent and standardized manner.\n\nRESTCONF provides a standard way for applications to interact with network devices using HTTP methods such as GET, PUT, POST, and DELETE. This allows administrators and developers to easily manage and configure VDSL networks using a RESTful API. For example, an application can use a RESTCONF client to retrieve information about the state of the network or to modify the configuration of a specific device or service.\n\nBy standardizing the configuration and management of VDSL networks using YANG models and RESTCONF, the BBF-VDSL project aims to simplify the deployment and maintenance of these networks, while also promoting interoperability and reducing vendor lock-in. The use of RESTCONF and YANG models allows for automation of network operations and reduces the need for manual configuration, which can help to reduce errors and increase efficiency.\n\n## Submodules\n\n• bbf-vdsl-availability.yang \n• bbf-vdsl-base-body.yang \n• bbf-vdsl-base.yang \n• bbf-vdsl-data-gathering-profile-body.yang \n• bbf-vdsl-data-rate-profile-body.yang \n• bbf-vdsl-downstream-power-back-off-profile-body.yang \n• bbf-vdsl-impulse-noise-monitoring-profile-body.yang \n• bbf-vdsl-impulse-noise-protection-delay-profile-body.yang \n• bbf-vdsl-inventory-body.yang \n• bbf-vdsl-line-spectrum-profile-body.yang \n• bbf-vdsl-line-status-body.yang \n• bbf-vdsl-line.yang \n• bbf-vdsl-mode-specific-psd-profile-body.yang \n• bbf-vdsl-noise-margin-profile-body.yang \n• bbf-vdsl-performance-management.yang \n• bbf-vdsl-pointers.yang \n• bbf-vdsl-quality-profiles.yang \n• bbf-vdsl-radio-frequency-interference-profile-body.yang \n• bbf-vdsl-re-initialization-policy-profile-body.yang \n• bbf-vdsl-service-profiles.yang \n• bbf-vdsl-sos-profile-body.yang \n• bbf-vdsl-spectrum-profiles.yang \n• bbf-vdsl-status-monitoring.yang \n• bbf-vdsl-test-diagnostics.yang \n• bbf-vdsl-test-mode-body.yang \n• bbf-vdsl-threshold-crossing-alert-body.yang \n• bbf-vdsl-threshold-management.yang \n• bbf-vdsl-upstream-power-back-off-profile-body.yang \n• bbf-vdsl-vectoring-profile-body.yang \n• bbf-vdsl-virtual-noise-profile-body.yang \n• bbf-vdsl-xtu-band-status-body.yang \n• bbf-vdsl-xtu-channel-performance-body.yang \n• bbf-vdsl-xtu-channel-status-body.yang \n• bbf-vdsl-xtu-channel-threshold-profile-body.yang \n• bbf-vdsl-xtu-data-gathering-report-body.yang \n• bbf-vdsl-xtu-line-performance-body.yang \n• bbf-vdsl-xtu-line-status-body.yang \n• bbf-vdsl-xtu-line-threshold-profile-body.yang \n• bbf-vdsl-xtu-sub-carrier-status-body.yang \n• bbf-vdsl-xtu.yang\n\n## bbf-vdsl-alarms\n\nThis module contains a collection of YANG definitions for supporting the Broadband Forum \nrequirements on management of Very High-speed Digital Subscriber Line (VDSL) interfaces as \ndefined in G.993.2 \\[14\\], ITU-T G.997.1 \\[17\\] and BBF TR-252 \\[2\\]. As such, this module is specific \nto access network equipment (e.g., BBF-specified Access Nodes and FTTdp DPUs). Specifically, this module contains a set of alarm definitions related to VDSL interfaces.\n\n### Vendor\n\nThe Broadband Forum (BBF) is an industry consortium that develops standards and specifications for broadband networking technologies. One of the standards developed by the BBF is the Very-high-bit-rate Digital Subscriber Line (VDSL) standard, which defines the transmission of high-speed data over copper telephone lines.\n\nSeveral vendors offer equipment that conforms to the BBF-VDSL standard. Here are some examples:\n\n1. Adtran: Adtran offers a range of VDSL2 modems and gateways that conform to the BBF-VDSL standard. These devices support advanced features such as vectoring and bonding to improve performance and reliability.\n2. Nokia: Nokia offers VDSL2 line cards for their ISAM FX access platform that conform to the BBF-VDSL standard. These line cards support advanced features such as vectoring and G.vector to improve performance over noisy copper lines.\n3. Calix: Calix offers a range of VDSL2 modems and gateways that conform to the BBF-VDSL standard. These devices support advanced features such as vectoring and bonding to improve performance and reliability.\n4. Huawei: Huawei offers VDSL2 access devices that conform to the BBF-VDSL standard. These devices support advanced features such as vectoring and G.vector to improve performance over noisy copper lines.\n5. Zyxel: Zyxel offers VDSL2 modems and gateways that conform to the BBF-VDSL standard. These devices support advanced features such as vectoring and bonding to improve performance and reliability.\n \n\nOverall, equipment that conforms to the BBF-VDSL standard provides reliable and high-performance connectivity over existing copper telephone lines, making it a cost-effective solution for delivering high-speed broadband services to homes and businesses.\n\n# bbf-fast\n\nThe bbf-fast collection contains YANG definitions for supporting the Broadband Forum requirements on management of FAST interfaces as defined in ITU-T G.9700, ITU-T G.9701, ITU-T G.997.2 and BBF TR-371. As such, this module is specific to access network equipment (e.g., BBF-specified Access Nodes and FTTdp DPUs).\n\n\"bbf-fast\" refers to the Broadband Forum's Fast Access to Subscriber Terminals project, which aims to standardize the management and control of broadband access networks using YANG models. YANG models are used to define data models for network management protocols such as NETCONF and RESTCONF. In the context of the BBF-FAST project, YANG models are used to standardize the configuration and management of broadband access networks.\n\nThe BBF-FAST YANG models define a variety of data structures and schema for describing network devices, interfaces, services, and other elements of a broadband access network. These models are designed to be vendor-neutral and interoperable, allowing different network devices from different vendors to be managed in a consistent and standardized manner.\n\nRESTCONF is a protocol that allows RESTful API calls to be made to a network device to retrieve or modify its configuration data. The BBF-FAST YANG models can be used to define the structure and format of the data that is exchanged between a RESTCONF client and a network device. This makes it easier for network administrators and developers to build applications that can manage and control broadband access networks using a standardized API.\n\n## Submodules\n\n• bbf-fast-availability \n• bbf-fast-base \n• bbf-fast-channel-performance-body \n• bbf-fast-channel-status-body \n• bbf-fast-channel-threshold-profile-body \n• bbf-fast-data-rate-profile-body \n• bbf-fast-fast-rate-adaptation-profile-body \n• bbf-fast-fast-retrain-policy-profile-body \n• bbf-fast-ftu-inventory-body \n• bbf-fast-impulse-noise-monitoring-profile-body \n• bbf-fast-inventory \n• bbf-fast-line-spectrum-profile-body \n• bbf-fast-line-performance-body \n• bbf-fast-line-status-body \n• bbf-fast-line-threshold-profile-body \n• bbf-fast-link-state-body \n• bbf-fast-noise-margin-profile-body \n• bbf-fast-pointers \n• bbf-fast-perf-types \n• bbf-fast-performance-management \n• bbf-fast-quality-profiles \n• bbf-fast-read-test-body \n• bbf-fast-retransmission-profile-body \n• bbf-fast-rfi-profile-body \n• bbf-fast-service-profiles \n• bbf-fast-spectrum-profiles \n• bbf-fast-status-monitoring \n• bbf-fast-tdd-profiles \n• bbf-fast-tdd-profile-body \n• bbf-fast-test-diagnostics \n• bbf-fast-test-mode-body \n• bbf-fast-threshold-crossing-alert-body \n• bbf-fast-threshold-management \n• bbf-fast-update-test-body \n• bbf-fast-upstream-power-back-off-profile-body \n• bbf-fast-vectoring-profile-body\n\n## bbf-fast-alarm-types\n\nThis module contains a collection of YANG definitions for supporting the Broadband Forum requirements on management of G.fast interfaces as defined in ITU-T G.9700 \\[22\\], ITU-T G.9701 \\[23\\], ITU-T G.997.2 \\[18\\] and BBF TR-371 \\[5\\]. As such, this module is specific to access network equipment (e.g., BBF-specified Access Nodes and FTTdp DPUs). Specifically, this module contains a set of alarm definitions related to FAST interfaces.\n\n### Vendor\n\nThe Broadband Forum (BBF) is an industry consortium that develops standards and specifications for broadband networking technologies. One of the standards developed by the BBF is the G.fast (ITU-T G.9701) standard, which defines the transmission of high-speed data over existing telephone lines, including both copper and fiber optic lines.\n\nSeveral vendors offer equipment that implements the BBF-G.fast standard. Here are some examples:\n\n1. ADTRAN: ADTRAN offers a range of G.fast modems that support the BBF-G.fast standard. These modems enable service providers to deliver high-speed broadband services over existing copper telephone lines, with speeds of up to 1 Gbps over short distances.\n2. Broadcom: Broadcom offers a range of G.fast chipsets that support the BBF-G.fast standard. These chipsets enable equipment vendors to build G.fast modems and gateways that deliver high-speed broadband services over existing telephone lines.\n3. Huawei: Huawei offers G.fast modems and gateways that support the BBF-G.fast standard. These devices enable service providers to deliver high-speed broadband services over existing telephone lines, with speeds of up to 1 Gbps over short distances.\n4. Nokia: Nokia offers G.fast modems and gateways that support the BBF-G.fast standard. These devices enable service providers to deliver high-speed broadband services over existing telephone lines, with speeds of up to 1 Gbps over short distances.\n5. Zyxel: Zyxel offers G.fast modems and gateways that support the BBF-G.fast standard. These devices enable service providers to deliver high-speed broadband services over existing telephone lines, with speeds of up to 1 Gbps over short distances.\n \n\nOverall, equipment that implements the BBF-G.fast standard provides a cost-effective way to deliver high-speed broadband services over existing telephone lines, without the need to install new fiber optic infrastructure. By leveraging the existing telephone infrastructure, BBF-G.fast equipment can provide high-speed broadband services to a larger number of customers, and at a lower cost than traditional fiber optic installations. However, it is important to note that BBF-G.fast is only effective over short distances, typically less than 250 meters, so it may not be suitable for all deployment scenarios.\n\n# bbf-fastdsl\n\nThis module contains a collection of YANG definitions for supporting the Broadband Forum \nrequirements on management of interfaces which support one or more DSL or G.fast technologies.\n\n### DPU/PMA Behavior\n\nThe requirements in this section only apply to DPUs and PMAs that comply with TR-301 \\[4\\]. \nThe following describes the behavior of objects on a DPU with respect to FAST and VDSL \nconfiguration and state data objects. \n• On initial startup, the DPU MUST instantiate a FastDSL object for each FastDSL-capable \nport supported by non-removable hardware. \n• The DPU MUST NOT instantiate FastDSL objects for ports supported by removable \nhardware. \n• The PMA MUST instantiate FastDSL objects for ports supported by removable hardware. \n• The DPU notifies the PMA of the insertion of removable hardware. \n• FAST and VDSL configuration objects (associated with the FastDSL object) are configured \nby the PMA. \n• The PMA will configure the FastDSL object for FAST and/or VDSL mode (configuring \nboth modes implicitly means G.hs is used to determine the operational mode). \n• If the PMA configures the FastDSL object for a mode not supported by the DPU, the DPU \nsets the appropriate availability status and either the issue tag \"configured-mode-fast-notsupported\" or \"configured-mode-vdsl-not-supported\". \n• When the handshake completes with the selection of FAST or VDSL, the corresponding \nstate object will be created (if not yet existing). \n• When the technology changes through handshake, the old state object will be deleted and the new one will be created. There will therefore never be more than one state object (and until \nthe first handshake completes there will be none).\n\n# bbf-gbond\n\nThe bbf-gbond of YANG definitions for supporting the Broadband Forum requirements on bonding of physical interfaces as defined in ITU-T G.998.1, ITU-T G.998.2, ITU-T G.998.3 and BBF TR-159. As such, this module is specfic to access network equipment (e.g., BBF-specified Access Nodes and FTTdp DPUs).\n\nThe BBF-GBOND project is an initiative within the Broadband Forum that aims to standardize the management and configuration of broadband access networks that use G.Bond (also known as ITU-T G.998) technology, which enables the aggregation of multiple DSL lines to increase the available bandwidth. RESTCONF is a protocol that provides a RESTful API for accessing and manipulating configuration data on network devices. In the context of the BBF-GBOND project, RESTCONF is used to manage and configure G.Bond networks.\n\nThe BBF-GBOND YANG models define a set of data structures and schema that describe the configuration and management of G.Bond networks. These models are designed to be vendor-neutral and interoperable, allowing different network devices from different vendors to be managed in a consistent and standardized manner.\n\nRESTCONF provides a standard way for applications to interact with network devices using HTTP methods such as GET, PUT, POST, and DELETE. This allows administrators and developers to easily manage and configure G.Bond networks using a RESTful API. For example, an application can use a RESTCONF client to retrieve information about the state of the network or to modify the configuration of a specific device or service.\n\nBy standardizing the configuration and management of G.Bond networks using YANG models and RESTCONF, the BBF-GBOND project aims to simplify the deployment and maintenance of these networks, while also promoting interoperability and reducing vendor lock-in. The use of RESTCONF and YANG models allows for automation of network operations and reduces the need for manual configuration, which can help to reduce errors and increase efficiency.\n\n### Vendor\n\nThe Broadband Forum (BBF) is an industry consortium that develops standards and specifications for broadband networking technologies. One of the standards developed by the BBF is the G.bond (ITU-T G.998.4) standard, which defines the bonding of multiple copper pairs to increase the bandwidth and reliability of broadband connections.\n\nSeveral vendors offer equipment that implements the BBF-G.bond standard. Here are some examples:\n\n1. ADTRAN: ADTRAN offers a range of G.bond modems that support the BBF-G.bond standard. These modems bond multiple copper pairs to increase the bandwidth and reliability of broadband connections. They also support advanced features such as vectoring and G.vector to further improve performance over noisy copper lines.\n2. Broadcom: Broadcom offers a range of G.bond chipsets that support the BBF-G.bond standard. These chipsets enable equipment vendors to build G.bond modems and gateways that bond multiple copper pairs to increase the bandwidth and reliability of broadband connections.\n3. Nokia: Nokia offers G.bond modems and gateways that support the BBF-G.bond standard. These devices bond multiple copper pairs to increase the bandwidth and reliability of broadband connections, and support advanced features such as vectoring and G.vector to further improve performance over noisy copper lines.\n4. Sagemcom: Sagemcom offers G.bond modems and gateways that support the BBF-G.bond standard. These devices bond multiple copper pairs to increase the bandwidth and reliability of broadband connections, and support advanced features such as vectoring and G.vector to further improve performance over noisy copper lines.\n5. Zyxel: Zyxel offers G.bond modems and gateways that support the BBF-G.bond standard. These devices bond multiple copper pairs to increase the bandwidth and reliability of broadband connections, and support advanced features such as vectoring and G.vector to further improve performance over noisy copper lines.\n \n\nOverall, equipment that implements the BBF-G.bond standard provides a cost-effective way to increase the bandwidth and reliability of broadband connections over existing copper telephone lines. By bonding multiple copper pairs, BBF-G.bond equipment can provide higher speeds and improved performance, even over noisy and degraded copper lines.\n\n# bbf-ghn\n\nTR-374: YANG Modules for Management of G.hn Systems in FTTdp Architectures.\n\n\n\nIncludes all standardized parameters and associated types for G.hn configuration, \nstatus monitoring, performance management, testing and diagnostics of a G.hn network \nconnected to the interface.\n\n# bbf-ghs\n\nThis module contains a collection of YANG definitions for supporting the Broadband Forum requirements on management of handshake as defined in ITU-T G.994.1 clause 14. As such, this \nmodule is specific to access network equipment (e.g., BBF-specified Access Nodes and FTTdp DPUs).\n\n## Submodules\n\n• bbf-ghs-base \n• bbf-ghs-pointers \n• bbf-ghs-handshake-profiles \n• bbf-ghs-handshake-profile-body\n\n# bbf-melt\n\nThis module contains a collection of YANG definitions for supporting the Broadband Forum \nrequirements on management of Metallic Line Test (MELT) as defined in ITU-T G.996.2 \\[16\\] and \nBBF TR-298 \\[3\\]. As such, this module is specific to access network equipment (e.g., BBF-specified Access Nodes and FTTdp DPUs).\n\n## Submodules\n\n• bbf-melt-base.yang \n• bbf-melt-pmd-control-body.yang \n• bbf-melt-pmd-measurement-parameter-body.yang \n• bbf-melt-pmd-profile-body.yang \n• bbf-melt-pmd-profiles.yang \n• bbf-melt-pmd-reporting-parameter-body.yang \n• bbf-melt-pmd-status-body.yang \n• bbf-melt-pmd.yang \n• bbf-melt-pointers.yang \n• bbf-melt-processing-derived-parameter-body.yang \n• bbf-melt-processing-profile-body.yang \n• bbf-melt-processing-profiles.yang \n• bbf-melt-result-parameters.yang\n\n# bbf-selt\n\nThis module contains a collection of YANG definitions for supporting the Broadband Forum \nrequirements on management of Single Ended Line Test (SELT) as defined in ITU-T G.996.2 \\[16\\] \nand BBF TR-298 \\[3\\]. As such, this module is specific to access network equipment (e.g., BBFspecified Access Nodes and FTTdp DPUs).\n\nSubmodules\n\n• bbf-selt-base.yang \n• bbf-selt-pmd-control-body.yang \n• bbf-selt-pmd-measurement-parameter-body.yang \n• bbf-selt-pmd-profile-body.yang \n• bbf-selt-pmd-profiles.yang \n• bbf-selt-pmd-status-body.yang \n• bbf-selt-pmd.yang \n• bbf-selt-pointers.yang \n• bbf-selt-processing-derived-parameter-body.yang \n• bbf-selt-processing-profile-body.yang \n• bbf-selt-processing-profiles.yang \n• bbf-selt-result-parameters.yang\n\n\n\n# Dependencies on Related YANG modules and Standards\n\nTR-355 is based on YANG 1.1 (RFC 7950 \\[11\\]). The following YANG modules are used by TR-355: \n• bbf-alarm-types@2020-10-13 \\[6\\] \n• bbf-availability@2022-03-01 \\[6\\] \n• bbf-hardware-types@2022-03-01 \\[6\\] \n• bbf-interfaces-performance-management@2022-03-01 \\[6\\] \n• bbf-yang-types@2022-03-01 \\[6\\] \n• iana-if-type@2021-06-21 \\[10\\] \n• ietf-hardware@2018-03-13 \\[13\\] \n• ietf-interfaces.yang@2014-05-08 \\[9\\] \n• ietf-yang-types.yang@2013-07-15 \\[10\\]\n\n# vOLT Management Function (vOLTMF)\n\n## Introduction\n\nThis section describes the high-level design of the vOLT Management function (vOLTMF) used to manage ONUs through the vOMCI solution. This section describes communication between the vOLTMF, vOMCI Proxy and vOMCI function upon:\n\n- Creating and deleting ONUs\n- Receiving onu-state-change notifications\n- Sending requests to ONUs\n \n\nThe vOLTMF manages ONUs through a standard ONU adapter that is deployed in BAA, the association of which is based on the model, type, vendor and version mentioned while creating the ONU. The standard ONU adapter uses the standard library of the YANG modules for ONUs that the vOLTMF refers to for handling ONU requests, responses and notifications from external management systems. The following figure depicts the vOLTMF and ONU Adapter components that reside in the BAA microservice.\n\n\n\nThe vOLTMF performs actions upon receiving notifications and requests either from an OLT device or other components within the BAA core. For example, the onu-state-change notification that is sent by the OLT device on its Northbound Interface (NBI) that is received by BAA core. The BAA core propagates the notification towards vOLTMF and BAA NBI so that it can be handled by the Access SDN M&C.\n\nUpon reception of the notification, the vOLTMF processes the notification, checks if a preconfigured ONU device exists and authenticates the ONU, the vOLTMF transforms the notification to Google Protobufs (GPB) format and propagates the set-onu-communication Action towards the vOMCI function and vOMCI-proxy via the Kafka bus.\n\nAll the YANG requests are sent towards the vOMCI function and vOMCI Proxy via the Kafka bus in GPB format. Once the vOMCI function/Proxy processes the requests, the vOMCI function sends the notification/request response in GPB format back to the vOLTMF via the Kafka bus and the response is received through the KafkaNotificationCallback#onNotification().\n\nUpon receiving the response, the vOLTMF is responsible for processing the response and performs actions accordingly.\n\n### vOLTMF Threadpools\n\nThere could be multiple interactions between the vOLTMF and the vOMCI function including parallel configuration requests/commands for either the same or different ONUs. These interactions are parallel and asynchronous such that the requests are not idle/blocked while waiting for responses because the vOLTMF has separate task queues and threadpools to handle the request/response interactions. The following table shows the list of vOLTMF threadpools that spawned as new Runnable tasks:\n\n| Name | Description |\n| --- | --- |\n| processNotificationRequestPool | Used for processing the mediated device event listener callbacks (deviceAdded, deviceRemoved) and device notification requests (onu-state-change notifications). |\n| kafkaCommunicationPool | Used to process the individual GET/COPY-CONFIG/EDIT-CONFIG requests inside a MediatedDeviceNetconfSession spawned by processRequestResponsePool.. |\n| kafkaPollingPool | Used to start up the KafkaConsumer implementation and polling for responses from vOMCI-function/vOMCI Proxy. |\n| processNotificationResponsePool | Used for processing notification responses from the vOMCI-function/vOMCI Proxy. |\n| processRequestResponsePool | Used for processing GET/COPY-CONFIG/EDIT-CONFIG requests and responses from the vOMCI-function/vOMCI Proxy. |\n\n## vOMCI function and vOMCI Proxy deployment\n\nPrior to communicating with an vOMCI function or vOMCI Proxy, the vOLTMF has the following preconditions:\n\n- An external orchestration or administration function (e.g., VNF manager) has deployed the vOMCI function and vOMCI Proxy instances\n- An external management function has configured the BAA layer with the connectivity parameters necessary for the vOLTMF to connect with the vOMCI function or vOMCI Proxy instance.\n \n\nFor this release, the communication channel between the vOMCI function and the vOLTMF uses a Kafka message transport that is used to send management requests and receive notifications to/from vOMCI function for the ONU or the function itself. Likewise a Kafka management channel exists between the vOMCI Proxy and the BAA core. The BAA core acts as an intermediary between the vOMCI entities and the SDN M&C, converting NETCONF requests to YANG messages using the same messages that the vOLTMF uses to communicate with the vOMCI function.\n\n\n\n## Network function management\n\nThe figure below depicts an example deployment of vOMCI function and vOMCI Proxy instances that are connected to the vOLTMF and BAA core using a Kafka bus. These connections and entities use the messages associated with TR-451's vOLTMF-vOMCI interface. Additionally the vOMCI function, vOMCI Proxy instances and the OLT are interconnected using gRPC channels. These entities use the messages associated with TR-451's vOMCI-OLT interface. Finally the OLT connects to the BAA core using NETCONF for management of the OLT. These entities use the messages associated with TR-413's Minf NBI interface for PNF of type OLT.\n\n\n\n### Use of Endpoints for Connectivity\n\nNetwork functions and entities like the vOLTMF and BAA core expose server endpoints (local-endpoints) that can be used by remote entities in order to establish as connection for communication. Likewise entities use client endpoints associated with a remote entity (remote-endpoints) in order to establish communication with the remote-entity. These endpoints have identifying names that are used to ensure an entity is communicating with a remote-endpoint over the correct connection.\n\nIn the case of the Kafka message transport, the vOLTMF connects as client to a Kafka broker and publishes and consumes information to a remote entity though a specified set of topics. In the case of the gRPC message transport the entity that acts as the server would expose the local-endpoint and the entity that acts as the client would use a remote-point of the remote entity.\n\nThe following figure depicts an example of the local-endpoints that are exposed by entities to which the remote entity would connect using the remote-endpoint information. The vOLTMF has two (2) logical local-endpoints (vOLTMF_Kafka_1, vOLTMF_Kafka_2) that are respectively used by vomci-vendor-1 and proxy-1 to exchange messages with the vOLTMF. Likewise the vOLTMF uses logical local-endpoints exposed by the vomci-vendor-1 and proxy-1 as the vOLTMF's client remote-endpoints.\n\n\n\nNote: The underlying connectivity between the entities has to be established before the vOLTMF can begin to manage an ONU.\n\nThe vOLTMF uses the network-function-settings in the bbf-obbaa-network-manager.yang tree as described below to define its server-based local endpoints as well as a list of client-based remote-endpoints. Since the client-based remote-endpoints is simply a list of remote-endpoints, the remote-endpoint-name within the meta-data of a network-function is used to correlate the endpoints from the vOLTMF's client list to the network-function from the vOLTMF's list of network functions.\n\n\n\n### Use of Endpoints for the ONU Management Chain\n\nThe vOLTMF uses endpoints that link to together network functions in a topology in order to determine an ONU's management chain.\n\nThe bbf-obbaa-onu-management.yang tree contains meta-data that maintains the endpoints and links when discovery of the topology is not possible as shown in the network-function-links node below:\n\n\n\n## Kafka topics for the vOMCI function and vOMCI Proxy\n\nWhen a new vOMCI function or vOMCI Proxy is deployed in the cloud, an external management function has to configure the BAA layer regarding information about the network to include how the vOLTMF should connect with the vOMCI function or vOMCI Proxy. When Kafka is used as the message transport the vOMCI function or vOMCI Proxy's endpoint information needs to be configured as shown below:\n\n```\n true\n vOMCi-kfk-1\n bbf-nf-types:vomci-function-type\n vOLTMF_Kafka_1\n client-id1\n vomci1-request\n VOMCI_REQUEST\n group-id\n vomci1-response\n VOMCI_RESPONSE\n vomci1-notification\n VOMCI_NOTIFICATION\n vomci1\n kafka-host\n proxy-kfk-1\n bbf-nf-types:vomci-proxy-type\n vOLTMF_Kafka_2\n client-id2\n vomci-proxy-request\n VOMCI_REQUEST\n group-id\n vomci-proxy-response\n VOMCI_RESPONSE\n vomci-proxy-notification\n VOMCI_NOTIFICATION\n vomci-proxy\n kafka-host\n vomci-vendor-1\n bbf-nf-types:vomci-function-type\n vOMCi-kfk-1\n proxy-1\n bbf-nf-types:vomci-proxy-type\n proxy-kfk-1\n\n```\n\n### Obtaining Kafka Topics when Communicating with an ONU\n\nEach ONU that is managed via vOMCI has to be associated with a vOMCI function that is represented as part of the ONU's metadata maintained by the BAA core. Before publishing messages for an ONU, the vOLTMF needs to determine the Kafka topics on which the messages must be published. The vOLTMF does so by invoking the following API in the NetworkFunctionDao.java:\n\n**String getKafkaTopicName(String networkFunctionName, KafkaTopicPurpose kafkaTopicPurpose);**\n\n- kafkaTopicPurpose is an enum with the following definition:\n \n\n```\npublic enum KafkaTopicPurpose{\n VOMCI_NOTIFICATION, VOMCI_REQUEST, VOMCI_RESPONSE\n}\n\n```\n\n- networkFunctionName corresponding to the vOMCI function can be retrieved using the API DeviceDao#getVomciFunctionName(deviceName).\n \n\n### Lifecycle Management of Network Functions and Topic Maintenance\n\nThe NetworkFunctionSubsystem is used to create, modify and delete network functions. When a new network function is deployed, the vOLTMF must subscribe to the Kafka topics configured with purpose as VOMCI_NOTIFICATION and VOMCI_RESPONSE in order to listen to messages coming from that network function. When the network function is undeployed the subscribed topics must be unsubscribed. All the requests from vOLTMF to the networkfunction are forwarded on the topic with purpose VOMCI_REQUEST.\n\n## gRPC connection establishment between pOLT and vOMCI Proxy or vOMCI function\n\nThe communication channel between the pOLT and the vOMCI Proxy or vOMCI function uses gRPC as the message transport. Prior to any communication with the ONU the communication session between the the vOMCI function and vOMCI Proxy has to be established. For establishing the connection between the pOLT and the vOMCI Proxy or the vOMCI function, the association between the pOLT and vOMCI Proxy or vOMCI function has to be configured in the BAA layer by the Access SDN M&C. The following code block provides an example configuration for associating vOMCI Proxy within the pOLT.\n\n```\n OLT1\n true\n olt-grpc-2\n olt-grpc-2\n bbf-nf-types:vomci-proxy-type\n vOMCIProxy\n 192.168.240.1\n 8433\n client_rule1\n 1\n ABCD\n olt-grpc-2\n true\n\n```\n\nNote:\n\n1. Once this is configured on pOLT, the pOLT sends the HelloVomciRequest to the vOMCI proxy. After receiving the HelloVomciRequest, the vOMCI proxy registers this pOLT and uses this information when the vOMCI proxy has to forward OMCI messages towards this pOLT.\n2. The remote address in the vOMCIProxy access-point is the docker network’s gatewayip address. In our setup, baadist_default – is the docker network created via the docker-compose file that has vOMCIProxy and so baadist_default’s gateway IP address is used as the remote address in the vOMCIProxy access-point..\n \n\n## ONU Management\n\n### ONU Device Data Model\n\nIn OB-BAA, the ONU is managed as a separate network element, like the OLT and uses a new a connection type \"mediated-session\" as defined by the [Aggregrators](https://obbaa.broadband-forum.org/architecture/aggregator/#aggregator) component's bbf-network-manager.yang YANG module in order to communicate with the ONU. Additionally, a YANG module that represents the ONU's management metadata is defined in bbf-obbaa-onu-management.yang. The metadata information in this YANG module includes data needed to discover and authenticate the ONU among other items. For example:\n\n- The _onu-state-info_ container holds the actual information read from the ONU when it becomes online.\n- The _onu-config_ container contains the information for authenticating the ONU and that must be provided when creating the pONU instance in OB-BAA> It includes:\n - planned-onu-management-mode (please refer to ONU Authentication Function for more details).\n - serial-number\n - registration-id\n - expected-attachment-point\n\nThe bbf-obbaa-onu-management.yang and bbf-network-manager.yang YANG modules can be found in the /resources/models/yang/aggregator-yang directory.\n\n```\nmodule: bbf-obbaa-network-manager\n +--rw network-manager\n +--rw managed-devices\n | +--rw device* [name]\n | +--rw name string\n | +--rw device-management\n | | +--rw type? string\n | | +--rw interface-version? string\n | | +--rw model? string\n | | +--rw vendor? string\n | | +--rw push-pma-configuration-to-device? boolean\n | | +--ro is-netconf? boolean\n | | +--rw device-connection\n | | | +--rw connection-model? enumeration\n | | | +--rw (protocol)\n | | | +--:(password-auth)\n | | | | +--rw password-auth\n | | | | +--rw authentication\n | | | | +--rw address inet:ip-address\n | | | | +--rw management-port? uint32\n | | | | +--rw user-name? string\n | | | | +--rw password? string\n | | | +--:(snmp-auth)\n | | | | +--rw snmp-auth\n | | | | +--rw snmp-authentication\n | | | | +--rw address inet:ip-address\n | | | | +--rw agent-port? inet:port-number\n | | | | +--rw trap-port? inet:port-number\n | | | | +--rw snmp-version? enumeration\n | | | | +--rw (auth-info)?\n | | | | +--:(community-string)\n | | | | | +--rw community-string? string\n | | | | +--:(snmpv3-auth)\n | | | | +--rw snmpv3-auth\n | | | | +--rw user-name? string\n | | | | +--rw security-level? enumeration\n | | | | +--rw auth-protocol? enumeration\n | | | | +--rw auth-password? string\n | | | | +--rw priv-protocol? enumeration\n | | | | +--rw priv-password? string\n | | | +--:(duid)\n | | | | +--rw duid? string\n | | | +--:(mediated-protocol)\n | | | +--rw mediated-protocol? enumeration\n | | +--ro device-state\n | | +--ro configuration-alignment-state? string\n | | +--ro connection-state\n | | +--ro connected? boolean\n | | +--ro connection-creation-time? yang:date-and-time\n | | +--ro device-capability* string\n | +--rw device-notification\n | | +---n device-state-change\n | | +-- event? enumeration\n | +--rw root\n +--rw network-functions-settings\n | +--rw nf-client {nf-client-supported}?\n | | +--rw enabled? boolean\n | | +--rw nf-initiate!\n | | +--rw remote-endpoints\n | | +--rw remote-endpoint* [name]\n | | +--rw name bbf-yang:string-ascii64\n | | +--rw nf-type? identityref\n | | +--rw on-demand? boolean\n | | +--rw local-endpoint-name? bbf-yang:string-ascii64\n | | +--rw (client-transport)\n | | | +--:(grpc) {bbf-nfc:grpc-client-supported}?\n | | | | +--rw grpc\n | | | | +--rw grpc-client-parameters\n | | | | +--rw channel\n | | | | | +--rw ping-interval? uint32\n | | | | +--rw connection-backoff {bbf-grpc:connection-backoff-supported}?\n | | | | +--rw initial-backoff? uint16\n | | | | +--rw min-connect-timeout? uint16\n | | | | +--rw multiplier? decimal64\n | | | | +--rw jitter? decimal64\n | | | | +--rw max-backoff? uint16\n | | | +--:(kafka-agent) {bbf-nfc:kafka-agent-supported}?\n | | | +--rw kafka-agent\n | | | +--rw kafka-agent-parameters\n | | | +--rw client-id? string\n | | | +--rw publication-parameters {bbf-kafkaa:publication-supported}?\n | | | | +--rw topic* [name]\n | | | | +--rw name string\n | | | | +--rw purpose? string\n | | | | +--rw partition? string\n | | | +--rw consumption-parameters {bbf-kafkaa:consumption-supported}?\n | | | +--rw group-id? string\n | | | +--rw topic* [name]\n | | | +--rw name string\n | | | +--rw purpose? string\n | | | +--rw partition? string\n | | +--rw access-point* [name]\n | | | +--rw name bbf-yang:string-ascii64\n | | | +--rw (message-transport)\n | | | +--:(grpc) {bbf-nfc:grpc-client-supported}?\n | | | | +--rw grpc\n | | | | +--rw grpc-transport-parameters\n | | | | +--rw remote-address inet:host\n | | | | +--rw remote-port? inet:port-number\n | | | | +--rw local-address? inet:ip-address {local-binding-supported}?\n | | | | +--rw local-port? inet:port-number {local-binding-supported}?\n | | | | +--rw proxy-server! {proxy-connect}?\n | | | | | +--rw (proxy-type)\n | | | | | +--:(socks4)\n | | | | | | +--rw socks4-parameters\n | | | | | | +--rw remote-address inet:ip-address\n | | | | | | +--rw remote-port? inet:port-number\n | | | | | +--:(socks4a)\n | | | | | | +--rw socks4a-parameters\n | | | | | | +--rw remote-address inet:host\n | | | | | | +--rw remote-port? inet:port-number\n | | | | | +--:(socks5)\n | | | | | +--rw socks5-parameters\n | | | | | +--rw remote-address inet:host\n | | | | | +--rw remote-port? inet:port-number\n | | | | | +--rw authentication-parameters!\n | | | | | +--rw (auth-type)\n | | | | | +--:(gss-api) {socks5-gss-api}?\n | | | | | | +--rw gss-api\n | | | | | +--:(username-password) {socks5-username-password}?\n | | | | | +--rw username-password\n | | | | | +--rw username string\n | | | | | +--rw (password-type)\n | | | | | +--:(cleartext-password)\n | | | | | | +--rw cleartext-password? string\n | | | | | +--:(encrypted-password) {password-encryption}?\n | | | | | +--rw encrypted-password\n | | | | | +--rw encrypted-by\n | | | | | +--rw encrypted-value binary\n | | | | +--rw keepalives! {keepalives-supported}?\n | | | | +--rw idle-time uint16\n | | | | +--rw max-probes uint16\n | | | | +--rw probe-interval uint16\n | | | +--:(kafka-agent) {bbf-nfc:kafka-agent-supported}?\n | | | +--rw kafka-agent\n | | | +--rw kafka-agent-transport-parameters\n | | | +--rw remote-address inet:host\n | | | +--rw remote-port? inet:port-number\n | | | +--rw local-address? inet:ip-address {local-binding-supported}?\n | | | +--rw local-port? inet:port-number {local-binding-supported}?\n | | | +--rw proxy-server! {proxy-connect}?\n | | | | +--rw (proxy-type)\n | | | | +--:(socks4)\n | | | | | +--rw socks4-parameters\n | | | | | +--rw remote-address inet:ip-address\n | | | | | +--rw remote-port? inet:port-number\n | | | | +--:(socks4a)\n | | | | | +--rw socks4a-parameters\n | | | | | +--rw remote-address inet:host\n | | | | | +--rw remote-port? inet:port-number\n | | | | +--:(socks5)\n | | | | +--rw socks5-parameters\n | | | | +--rw remote-address inet:host\n | | | | +--rw remote-port? inet:port-number\n | | | | +--rw authentication-parameters!\n | | | | +--rw (auth-type)\n | | | | +--:(gss-api) {socks5-gss-api}?\n | | | | | +--rw gss-api\n | | | | +--:(username-password) {socks5-username-password}?\n | | | | +--rw username-password\n | | | | +--rw username string\n | | | | +--rw (password-type)\n | | | | +--:(cleartext-password)\n | | | | | +--rw cleartext-password? string\n | | | | +--:(encrypted-password) {password-encryption}?\n | | | | +--rw encrypted-password\n | | | | +--rw encrypted-by\n | | | | +--rw encrypted-value binary\n | | | +--rw keepalives! {keepalives-supported}?\n | | | +--rw idle-time uint16\n | | | +--rw max-probes uint16\n | | | +--rw probe-interval uint16\n | | +---n remote-endpoint-status-change\n | | +-- access-point -> ../../access-point/name\n | | +-- connected boolean\n | | +-- remote-endpoint-state-last-change yang:date-and-time\n | +--rw nf-server {nf-server-supported}?\n | +--rw enabled? boolean\n | +--rw listen!\n | +--rw idle-timeout? uint16\n | +--rw listen-endpoint* [name]\n | +--rw name bbf-yang:string-ascii64\n | +--rw (transport)\n | | +--:(grpc)\n | | +--rw grpc\n | | +--rw grpc-server-parameters\n | | +--rw local-endpoint-name? bbf-yang:string-ascii64\n | | +--rw local-address inet:ip-address\n | | +--rw local-port? inet:port-number\n | | +--rw keepalives! {keepalives-supported}?\n | | +--rw idle-time uint16\n | | +--rw max-probes uint16\n | | +--rw probe-interval uint16\n | +--rw remote-endpoints\n | +--ro remote-endpoint* [name]\n | | +--ro name bbf-yang:string-ascii64\n | +---n remote-endpoint-status-change\n | +-- remote-endpoint -> ../../../remote-endpoints/remote-endpoint/name\n | +-- connected boolean\n | +-- remote-endpoint-state-last-change yang:date-and-time\n +--rw network-functions\n | +--rw network-function* [name]\n | +--rw name string\n | +--rw type? identityref\n | +--rw remote-endpoint-name? string\n | +--rw root\n +--ro new-devices\n | +--ro new-device* [duid]\n | +--ro duid string\n | +--ro device-capability* string\n +--ro device-adapters\n +--ro device-adapter-count? string\n +--ro device-adapter* [type interface-version model vendor]\n +--ro type string\n +--ro interface-version string\n +--ro model string\n +--ro vendor string\n +--ro push-pma-configuration-to-device? boolean\n +--ro is-netconf? boolean\n +--ro description? string\n +--ro developer? string\n +--ro revision? string\n +--ro upload-date? yang:date-and-time\n +--ro in-use? boolean\n +--ro devices-related\n | +--ro device-count? uint32\n | +--ro device* [name]\n | +--ro name -> /network-manager/managed-devices/device/name\n +--ro yang-modules\n | +--ro module* [name revision]\n | +--ro name -> /yanglib:modules-state/module/name\n | +--ro revision -> /yanglib:modules-state/module/revision\n +--ro factory-garment-tag\n +--ro total-number-of-modules-present? string\n +--ro number-of-modules-present-in-standard-adapter? string\n +--ro percentage-adherence-to-standard-module? string\n +--ro deviated-standard-module* string\n +--ro percentage-of-standard-modules-having-deviation? string\n +--ro augmented-standard-module* string\n +--ro percentage-of-standard-modules-having-augments? string\n\n```\n\n```\nmodule: bbf-obbaa-onu-management\n augment /baa-network-manager:network-manager/baa-network-manager:managed-devices/baa-network-manager:device/baa-network-manager:device-management:\n +--rw onu-config-info\n +--rw vendor-name? string\n +--rw expected-serial-number? bbf-xpon-types:onu-serial-number\n +--rw expected-registration-id? bbf-xpon-types:onu-registration-id\n +--rw xpon-technology? identityref\n +--rw planned-onu-management-mode? identityref\n +--rw expected-attachment-points\n | +--rw list-type? enumeration\n | +--rw expected-attachment-point* [name]\n | +--rw name string\n | +--rw olt-name -> /baa-network-manager:network-manager/managed-devices/device/name\n | +--rw channel-partition-name? string\n | +--rw planned-onu-management-mode-in-this-olt? identityref\n +--rw vomci-onu-management\n +--rw use-vomci-management? boolean\n +--rw onu-management-chain-selection? bbf-vomcit:onu-management-chain-selection\n +--rw vomci-function? bbf-yang:string-ascii64\n +--rw onu-management-chain* [nf-type nf-name]\n | +--rw nf-type bbf-vomcit:vomci-entity-type\n | +--rw nf-name bbf-yang:string-ascii64\n +--rw network-function-links\n +--rw network-function-link* [name]\n +--rw name string\n +--rw termination-point-a\n | +--rw function-name string\n | +--rw local-endpoint-name string\n +--rw termination-point-b\n +--rw function-name string\n +--rw local-endpoint-name string\n augment /baa-network-manager:network-manager/baa-network-manager:managed-devices/baa-network-manager:device/baa-network-manager:device-management/baa-network-manager:device-state:\n +--ro onu-state-info\n +--ro onu-state identityref\n +--ro determined-onu-management-mode? identityref\n +--ro detected-serial-number? bbf-xpon-types:onu-serial-number\n +--ro detected-registration-id? bbf-xpon-types:onu-registration-id\n +--ro vendor-id? string\n +--ro equipment-id? string\n +--ro attachment-point\n | +--ro olt-name string\n | +--ro channel-termination-name string\n | +--ro onu-id? bbf-xpon-types:onu-id\n | +--ro v-ani-name? string\n | +--ro olt-local-onu-name? string\n +--ro software-images\n | +--ro software-image* [id]\n | +--ro id uint8\n | +--ro version? string\n | +--ro is-committed boolean\n | +--ro is-active boolean\n | +--ro is-valid boolean\n | +--ro product-code? string\n | +--ro hash? string\n +--ro voltmf-msg-data\n +--ro in-messages? bbf-yang:performance-counter64\n +--ro out-messages? bbf-yang:performance-counter64\n +--ro messages-errors? bbf-yang:performance-counter64\n notifications:\n +---n onu-authentication-report-notification\n +--ro onu-authentication-status identityref\n +--ro olt-name string\n +--ro channel-termination-name string\n +--ro onu-id? bbf-xpon-types:onu-id\n +--ro detected-serial-number? bbf-xpon-types:onu-serial-number\n +--ro detected-registration-id? bbf-xpon-types:onu-registration-id\n +--ro v-ani-name? string\n +--ro olt-local-onu-name? string\n +--ro onu-name? string\n\n```\n\n### Standard ONU Adapter\n\nThe management of an ONU utilizes the Device Adapter concept within OB-BAA and the OB-BAA distribution provides an ONU standard adapter called bbf-onu-standard that can be found in the distribution's /resources/models/standard-adapters directory. The standard ONU adapter has below properties:\n\n- adapterType: ONU\n- adapterModel: standard\n- vendor: BBF\n- version: 1.0\n \n\n### ONU Creation\n\nONU's can be created within the BAA layer either before an ONU is detected (pre-provisioned) by an OLT or once an ONU has been detected by an OLT. When the ONU has been pre-provisioned within the BAA layer, the ONU device is created and persisted in the BAA layer's datastore. Additionally, the vOMCI function and vOMCI Proxy that are part of the ONU's management chain also notified with Create-ONU RPC requests about the ONU that is created in the BAA layer.\n\nWhenever the OLT notifies the BAA layer that the OLT has detected an ONU, the OLT sends an ONU state change notification that the BAA layer uses to determine if the change of ONU state is because the OLT has detected an ONU attachment. If the BAA layer has determined that the ONU attachment has been detected but the BAA layer doesn't have the ONU device configured in the BAA layer's datastore, the ONU is treated as an orphaned or unknown ONU. Once the ONU has been created within the BAA layer with match of the ONU identification properties and the authentication of the ONU succeeds, a set-onu-communication Action Request is forwarded to vOMCI Proxy and vOMCI function that is part of the ONU management chain.\n\n**Info:** Release 5.0 introduces new options for ONU authentication. Pleaser refer to the ONU Authentication page for mored details. In this section, it is assumed that ONU authentication is performed by the OLT and that the ONU created in the BAA layer is managed trough vOMCI. When an ONU name is not included in the notifications sent by the OLT, the matching of the ONU identification properties is made through parameters such as the attachment point, the Serial Number and the Registration ID.\n\n#### ONU creation with the management chain specified by SDN M&C\n\nIn this release, the ONU management chain configuration is expected to be configured by an external management entity. The external management entity will send the ONU management chain details with the create-onu netconf request. In a future release, the BAA layer will be able to support the determination of the ONU management chain.\n\nThe following is an example of the Create ONU request that contains the ONU's management chain:\n\n```\n onuA\n ONU\n 1.1\n BBF\n standard\n mediated-session\n vomci\n ABCD12345678\n baa-onu-types:use-vomci\n allow-any\n OLT1-CPart_1\n OLT1\n CG_1.CPart_1\n bbf-xpon-types:gpon\n vomci-vendor-1\n vomci-function\n vomci-vendor-1\n onu-management-proxy\n proxy-1\n olt\n OLT1\n vOMCI-proxy\n vomci-vendor-1\n vOMCi-grpc-1\n proxy-1\n proxy-grpc-1\n proxy-OLT\n proxy-1\n proxy-grpc-2\n OLT1\n olt-grpc-2\n\n```\n\n#### Registration for OLT notifications (onu-state-change notifications)\n\nWhen an ONU's attachment state changes toward an OLT, the OLT transmits onu-state-change notifications through its Northbound management system to subscribed management entities including the BAA layer where the vOLTMF uses these state change notifications to determine if the ONU has been considered \"detected\" or \"undetected\".\n\nThe following is an example of an onu-state-change notification:\n\n```\n 2019-07-25T05:53:36+00:00\n ABCD12345678\n 1\n CT_1\n onu-present-and-unexpected\n 2019-07-25T05:53:36+00:00\n\n```\n\nIn order to receive the onu-state-change notification, the BAA layer's ONUNotificationListener registers with DeviceNotificationListenerService for deviceNotifications using the ONUNotificationListener's deviceNotificationReceived() callback method. Upon reception of the notification, the ONUNotificationListener performs some validation on the notification and forwards the notification onto the vOLTMF using the VOLTManagementImpl's ONUNotificationProcess() method for further processing by the vOLTMF.\n\n**Info:** The ONUNotificationListener is one of the entities that registers to receive ONU state change notifications, other listeners of device notifications also receive these ONU state change notifications for their purposes such as forwarding the notification to the Access SDN M&C.\n\n##### ONU state change notification mapping to detect and undetect events\n\nThe ONU detect and undetect events are mapped to one or more of the ONU state change notifications received by the ONUNotificationListener.\n\nThe table below maps the ONU state change notifications to the ONU DETECT or UNDETECT event:\n\n| onu-state | Event |\n| --- | --- |\n| onu-present | detect |\n| onu-present-and-unexpected | detect |\n| onu-present-and-on-intended-channel-termination | detect |\n| onu-present-and-in-wavelength-discovery | detect |\n| onu-present-and-discovery-tune-failed | detect |\n| onu-present-and-no-v-ani-known-and-o5-failed | detect |\n| onu-present-and-no-v-ani-known-and-o5-failed-no-onu-id | detect |\n| onu-present-and-no-v-ani-known-and-o5-failed-undefined | detect |\n| onu-present-and-v-ani-known-and-o5-failed | detect |\n| onu-present-and-v-ani-known-and-o5-failed-no-onu-id | detect |\n| onu-present-and-v-ani-known-and-o5-failed-undefined | detect |\n| onu-present-and-no-v-ani-known-and-in-o5 | detect |\n| onu-present-and-no-v-ani-known-and-unclaimed | detect |\n| onu-present-and-v-ani-known-but-intended-ct-unknown | detect |\n| onu-present-and-emergency-stopped | undetect |\n| onu-not-present | undetect |\n| onu-not-present-with-v-ani | undetect |\n| onu-not-present-without-v-ani | undetect |\n\n#### ONU detected online\n\nUpon receiving an onu-state-change notification from the OLT, the vOLTManagementFunction determines if the onu-state-change notification translates into a DETECT event as described above. If the onu-state-change notification fields such as serial-number and channel-termination matches with a preconfigured ONU in the BAA layer, the vOLTMF sends a set-onu-communication action request to the vOMCI function and vOMCI Proxy. The action includes details of the onu-name, attachment-point and north and south bound remote-endpoints.\n\nOnce the vOMCI function and vOMCI Proxy processes set-onu-communication action, the vOMCI Proxy and vOMCI function sends the response to the action. When the OK response is received from both vOMCI Function and vOMCI Proxy that comprises the ONU's managment chain, vOLTMF updates the connection status of the ONU to \"CONNECTED\". Addiitonally, vOLTMF creates a new MediatedDeviceNectonfSession and begins the process of obtaining necessary information about the ONU and then aligning the ONU by sending GET and COPY-CONFIG requests to the targeted ONU via the vOMCI function. The results of the alignment (i.e., COPY-CONFIG response) is updated in the BAA layer's datastore.\n\nOnce the ONU detect sequence is successfully completed, the onu-discovery-result notification is forwarded to the Access SDN M_C that includes information about ONU serial number, discovery status, device-info and software information.\n\n```\n 2021-07-02T14:20:08+00:00\n ABCD12345678\n successful\n\n```\n\n\n\n#### ONU detected offline\n\nUpon receiving of an onu-state-change notification from the OLT, the vOLTManagementFunction determines if the onu-state-change notification translates into an UNDETECT event as described above. When an ONU UNDETECT event occurs, the vOLTMF retrieves the necessary ONU identification information from the BAA layer's DeviceManager using the onu-state-change's serial-number and sends a set-onu-communication request to the vOMCI Proxy and vOMCI function instances that comprise the ONU's management chain. The set-onu-communication action includes information such as attachment-point, north and south bound remote-endpoints and communication availability. Upon a successful response to the action, an onu-discovery-result notification is forwarded to Access SDN M_C along with information about the ONU including the ONU's current state.\n\nThe following diagram depicts the flow when ONU goes offline:\n\n\n\n### ONU Deletion\n\nONUs in the BAA layer can be deleted regardless whether the ONU has been pre-provisioned or was discovered by the OLT. In either case, the deletion of the ONU device in the BAA layer, triggers the MediatedDeviceEventListener's onuDeviceRemoved() method that results in Delete-ONU Action request towards vOMCI Proxy and vOMCI function. If a MediatedDeviceNetconfSession has been established then the Delete-ONU request is transmitted and the session is closed after the response to the request is received.\n\n\n\n### ONU Alarm handling via vOMCI\n\nThe following picture depicts the general workflow for processing ONU alarms received through the vOMCI function. The alarms are forwarded to the SDN M&C using ietf-alarm (RFC8632) style notifications.\n\n\n\nDetails about the implemented alarms and the processing made in the vOMCI function can be found in [vOMCI - ONU alarm Handling](https://obbaa.broadband-forum.org/architecture/voltmf/onu_alarm/#onu_alarm).\n\n## vOLTMF to vOMCI Messages over MvOLTMF-vOMCI\n\nIn WT-451 Revision:27 messages conveyed on the MvOLTMF-vOMCI interface are serialized as Google Protobufs (GPB) and YANG modules are encoded in JSON. In order to support old and new message format in this release, the following strategy pattern is introduced in the vOLTMF design.\n\n### MessageFormatter\n\n\n\nVOLTManagementImpl decides the Messageformatter to be used and creates a MediatedDeviceNetconfSession with the constructor argument \"MessageFormatter\"(JSON/GPB). In the release, the JSONFormatter and GPBFormatter is added, both of which implements the MessageFormatter interface. The MediatedDeviceNetconfSession calles MessageFormmater.getFormattedRequest() to get the formatted message request. The JSONFormatter formats the message in JSON that was supported in previous releases. The GPBFormatter formats the messages in the GPB format. Both these classes implement the method getFormattedRequest() and getResponseData() which returns the corresponding formatted message and MediatedDeviceNetconfSession use this message to communicate with the vOMCI function or vOMCI Proxy.\n\n```\npublic interface MessageFormatter {\n T getFormattedRequest(AbstractNetconfRequest request, String operationType, Device onuDevice,\n AdapterManager adapterManager, ModelNodeDataStoreManager modelNodeDsm,\n SchemaRegistry schemaRegistry, NetworkWideTag networkWideTag)\n throws NetconfMessageBuilderException, MessageFormatterException;\n ResponseData getResponseData(Object responseObject) throws MessageFormatterException;\n}\n\n```\n\n### JSONFormatter\n\nIn previous releases, messages were encoded in JSON format along with NetworkWideTags. However, the formatting of the messages were taken care by MediatedDeviceNetconfSession itself. As part of this release, the functionalities are decoupled when forming the JSON message and abstracted it to the JSONFormatter. JSONFormatter implements the method getFormattedRequest() and getResponseData() to return the JSON formatted message that was supported in previous releases.\n\n### GPBFormatter\n\nThe tr451_vomci_nbi_message.proto is used to generate the corresponding Java classes. The GPBFormatter implements the method getFormattedRequest and getResponseData. Using the Java classes generated for the .proto file, it returns the formatted message.\n\nNote: For more information about converting protobufs to Java see: [Java Generated Code | Protocol Buffers | Google Developers](https://developers.google.com/protocol-buffers/docs/reference/java-generated)\n\nIn the new format the header of the message requires details such as msg_id, sender_name, recepient_name, object_type and object_name that should be populated in the NetworkWideTag before sending to the MessageFormatter.\n\nA new enum is introduced for identifying the Object type that shows the type of target for the message.\n\n```\nPublic enum ObjectType {\n ONU, VOMCI_FUNCTION, VOMCI_PROXY, VOLTMF\n }\n\n```\n\nBased on the operationType argument passed to GPBFormatter in getFormattedRequest(), the GPBFormatter populates the req_type field in the message body.\n\n| operationType | req_type |\n| --- | --- |\n| ONUConstants.ONU_GET_OPERATION | get_data |\n| ONUConstants.ONU_COPY_OPERATION | replace_config |\n| ONUConstants.ONU_EDIT_OPERATION | update_config |\n| ONUConstants.CREATE_ONU | action |\n| ONUConstants.DELETE_ONU/ ONUConstants.SET_ONU_COMMUNICATION | action |\n\nOn receiving the responses, the GPBFormatter validates following fields:\n\n| Field name | Check |\n| --- | --- |\n| recipient_name | If it is not null, verify that it is “vOLTMF”. If not log error and discard message |\n| version | |\n| object_type | If it is not null, verify that the source is either “VOMCI_FUNCTION” or “VOMCI_PROXY” or “ONU”. If not log error and discard message |\n| object_name | If not null, verify that if the object_type is “ONU”, the object name is present in the onu devices managed by BAA. Use this field value to populate onuName in ResponseData |\n\nBased on the resp_type GPBFormatter populates the operationType field in ResponseData object it returns.\n\n| resp_type | operationType |\n| --- | --- |\n| get_resp | ONUConstants.ONU_GET_OPERATION |\n| replace_config_resp | ONUConstants.ONU_COPY_OPERATION |\n| update_config_resp | ONUConstants.ONU_EDIT_OPERATION |\n| action_resp | ONUConstants.CREATE_ONU |\n| action_resp | ONUConstants.DELETE_ONU/ ONUConstants.SET_ONU_COMMUNICATION |\n\n## Sample messages on the MvOLTMF-vOMCI (processed locally by the vOMCI instance)\n\nBelow are sample GPB formatted messages sent from vOLTMF to vOMCI function and vOMCI Proxy:\n\nCreate-ONU request towards the vOMCI Function\n\n```\nMsg {\nheader {\n msg_id: \"1\"\n sender_name: \"vOLTMF\"\n recipient_name: \"vomci-vendor-1\"\n object_type: VOMCI_FUNCTION\n object_name: \"vomci-vendor-1\"\n}\nbody {\n request {\n action {\n input_data: \"{\\\"bbf-vomci-function:managed-onus\\\":{\\\"create-onu\\\":{\\\"name\\\":\\\"ont1\\\"}}}\"\n }\n }\n}\n } \n\n```\n\nCreate-ONU request towards the vOMCI Proxy\n\n```\nMsg {\nheader {\n msg_id: \"2\"\n sender_name: \"vOLTMF\"\n recipient_name: \"proxy-1\"\n object_type: VOMCI_PROXY\n object_name: \"proxy-1\"\n}\nbody {\n request {\n action {\n input_data: \"{\\\"bbf-vomci-proxy:managed-onus\\\":{\\\"create-onu\\\":{\\\"name\\\":\\\"ont1\\\"}}}\"\n }\n }\n}\n } \n\n```\n\nCreate-ONU response from the vOMCI Function\n\n```\nMsg{\nheader {\n msg_id: \"1\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: VOMCI_FUNCTION\n object_name: \"vomci-vendor-1\"\n}\nbody {\n response {\n action_resp {\n status_resp {\n status_code=0\n }\n }\n }\n}\n} \n\n```\n\nCreate-ONU response from the vOMCI Proxy\n\n```\nMsg{ header {\n msg_id: \"2\"\n sender_name: \"proxy-1\"\n recipient_name: \"vOLTMF\"\n object_type: VOMCI_PROXY\n object_name: \"proxy-1\"\n}\nbody {\n response {\n action_resp {\n status_resp {\n status_code=0\n }\n }\n }\n}\n}\n\n```\n\nSet-ONU-Communication action towards the vOMCI Function\n\n```\nMsg{\nheader {\n msg_id: \"3\"\n sender_name: \"vOLTMF\"\n recipient_name: \"vomci-vendor-1\"\n object_type: VOMCI_FUNCTION\n object_name: \"vomci-vendor-1\"\n}\nbody {\n request {\n action {\n 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-name\\\":\\\"vOLTMF_Kafka\\\",\\\"onu-communication-available\\\":true,\\\"olt-remote-endpoint-name\\\":\\\"proxy-grpc-1\\\"}}]}}\"}\n }\n}\n\n```\n\nSet-ONU-Communication action towards the vOMCI Proxy\n\n```\nMsg{\nheader { \n msg_id: \"4\"\n sender_name: \"vOLTMF\"\n recipient_name: \"proxy-1\"\n object_type: VOMCI_PROXY\n object_name: \"proxy-1\"\n}\nbody {\n request {\n action {\n input_data: \"{\\\"bbf-vomci-proxy:managed-onus\\\":{\\\"managed-onu\\\":[{\\\"name\\\":\\\"ont1\\\",\\\"set-onu-communication\\\":{\\\"onu-attachment-point\\\":{\\\"olt-name\\\":\\\"OLT1\\\", \\\"channel-termination-name\\\":\\\"CT_1\\\",\\\"onu-id\\\":1},\\\"onu-communication-available\\\":true,\\\"vomci-func-remote-endpoint-name\\\":\\\"vOMCi-grpc-1\\\",\\\"olt-remote-endpoint-name\\\":\\\"OLT1\\\"}}]}}\"}\n }\n}\n}\n\n```\n\nSet-ONU-Communication response from the vOMCI Function\n\n```\nMsg {\nheader {\n msg_id: \"3\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: VOMCI_FUNCTION\n object_name: \"vomci-vendor-1\"\n}\nbody {\n response {\n action_resp {\n status_resp {\n status_code=0\n }\n }\n }\n}\n}\n\n```\n\nSet-ONU-Communication response from the vOMCI Proxy\n\n```\nMsg {\nheader {\n msg_id: \"4\"\n sender_name: \"proxy-1\"\n recipient_name: \"vOLTMF\"\n object_type: VOMCI_PROXY\n object_name: \"proxy-1\"\n}\nbody {\n response {\n action_resp {\n status_resp {\n status_code=0\n }\n }\n }\n}\n}\n\n```\n\nDelete-ONU action towards the vOMCI Function\n\n```\nMsg {\nheader {\n msg_id: \"5\"\n sender_name: \"vOLTMF\"\n recipient_name: \"vomci-vendor-1\"\n object_type: VOMCI_FUNCTION\n object_name: \"vomci-vendor-1\"\n}\nbody {\n request {\n action {\n input_data: \"{\\\"bbf-vomci-function:managed-onus\\\":{\\\"managed-onu\\\":[{\\\"name\\\":\\\"ont1\\\",\\\"delete-onu\\\":{}}]}}\"\n }\n }\n}\n}\n\n```\n\nDelete-ONU action towards the vOMCI Proxy\n\n```\nMsg {\nheader {\n msg_id: \"6\"\n sender_name: \"vOLTMF\"\n recipient_name: \"proxy-1\"\n object_type: VOMCI_PROXY\n object_name: \"proxy-1\"\n}\nbody {\n request {\n action {\n input_data: \"{\\\"bbf-vomci-proxy:managed-onus\\\":{\\\"managed-onu\\\":[{\\\"name\\\":\\\"ont1\\\",\\\"delete-onu\\\":{}}]}}\"\n }\n }\n}\n}\n\n```\n\nDelete-ONU response from the vOMCI Function\n\n```\nMsg {\nheader {\n msg_id: \"5\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: VOMCI_FUNCTION\n object_name: \"vomci-vendor-1\"\n}\nbody {\n response {\n action_resp {\n status_resp {\n status_code=0\n }\n }\n }\n}\n}\n\n```\n\nDelete-ONU response from the vOMCI Proxy\n\n```\nMsg {\nheader {\n msg_id: \"6\"\n sender_name: \"proxy-1\"\n recipient_name: \"vOLTMF\"\n object_type: VOMCI_PROXY\n object_name: \"proxy-1\"\n}\nbody {\n response {\n action_resp {\n status_resp {\n status_code=0\n }\n }\n }\n}\n}\n\n```\n\nConfigure endpoints towards the vOMCI function\n\n```\nMsg {\n header {\n msg_id: \\\"2\\\"\n sender_name: \\\"vOLTMF\\\"\n recipient_name: \\\"vomci-vendor-1\\\"\n object_name: \\\"vomci-vendor-1\\\"\n object_type: VOMCI_FUNCTION\n}\nbody {\n request {\n update_config {\n update_config_replica: {\n delta_config: {\n\"{\n \\\"bbf-vomci-function:vomci\\\": {\n \\\"remote-network-function\\\": {\n \\\"nf-client\\\": {\n \\\"enabled\\\": true,\n \\\"nf-initiate\\\": {\n \\\"remote-endpoints\\\": {\n \\\"remote-endpoint\\\": [\n {\n \\\"name\\\": \\\"obbaa-vomci\\\",\n \\\"nf-type\\\": \\\"bbf-network-function-types:voltmf-type\\\",\n \\\"local-endpoint-name\\\": \\\"vOMCI-kfk-1\\\",\n \\\"kafka-agent\\\": {\n \\\"kafka-agent-parameters\\\": {\n \\\"client-id\\\": \\\"client-id2\\\",\n \\\"publication-parameters\\\": {\n \\\"topic\\\": [\n {\n \\\"name\\\": \\\"vomci1-response\\\",\n \\\"purpose\\\": \\\"VOMCI_RESPONSE\\\"\n },\n {\n \\\"name\\\": \\\"vomci1-notification\\\",\n \\\"purpose\\\": \\\"VOMCI_NOTIFICATION\\\"\n }\n ]\n },\n \\\"consumption-parameters\\\": {\n \\\"topic\\\": [\n {\n \\\"name\\\": \\\"vomci1-request\\\",\n \\\"purpose\\\": \\\"VOMCI_REQUEST\\\"\n }\n ]\n }\n }\n },\n \\\"access-point\\\": [\n {\n \\\"name\\\": \\\"obbaa-vomci\\\",\n \\\"kafka-agent\\\": {\n \\\"kafka-agent-transport-parameters\\\": {\n \\\"remote-address\\\": \\\"kafka-host\\\"\n }\n }\n }\n ]\n }\n ]\n }\n }\n },\n \\\"nf-server\\\": {\n \\\"enabled\\\": true,\n \\\"listen\\\": {\n \\\"listen-endpoint\\\": [\n {\n \\\"name\\\": \\\"vOMCI-grpc-1\\\",\n \\\"grpc\\\": {\n \\\"grpc-server-parameters\\\": {\n \\\"local-endpoint-name\\\": \\\"vOMCI-grpc-1\\\",\n \\\"local-address\\\": \\\"::\\\",\n \\\"local-port\\\": 8100\n }\n }\n }\n ]\n }\n }\n }\n }\n}\"\n }\n }\n }\n }\n}\n\n```\n\nConfigure endpoints towards the vOMCI Proxy\n\n```\nMsg {\n header {\n msg_id: \\\"2\\\"\n sender_name: \\\"vOLTMF\\\"\n recipient_name: \\\"proxy1\\\"\n object_name: \\\"proxy1\\\"\n object_type: VOMCI_PROXY\n}\nbody {\n request {\n update_config {\n update_config_replica: {\n delta_config: {\n\"{\n \\\"bbf-vomci-proxy:vomci\\\": {\n \\\"remote-network-function\\\": {\n \\\"nf-client\\\": {\n \\\"enabled\\\": true,\n \\\"nf-initiate\\\": {\n \\\"remote-endpoints\\\": {\n \\\"remote-endpoint\\\": [\n {\n \\\"name\\\": \\\"vOLTMF_Kafka_2\\\",\n \\\"nf-type\\\": \\\"bbf-network-function-types:voltmf-type\\\",\n \\\"local-endpoint-name\\\": \\\"proxy-kfk-1\\\",\n \\\"kafka-agent\\\": {\n \\\"kafka-agent-parameters\\\": {\n \\\"client-id\\\": \\\"client-id3\\\",\n \\\"publication-parameters\\\": {\n \\\"topic\\\": [\n {\n \\\"name\\\": \\\"vomci-proxy-request\\\",\n \\\"purpose\\\": \\\"VOMCI_RESPONSE\\\"\n },\n {\n \\\"name\\\": \\\"vomci-proxy-notification\\\",\n \\\"purpose\\\": \\\"VOMCI_NOTIFICATION\\\"\n }\n ]\n },\n \\\"consumption-parameters\\\": {\n \\\"topic\\\": [\n {\n \\\"name\\\": \\\"vomci-proxy-request\\\",\n \\\"purpose\\\": \\\"VOMCI_REQUEST\\\"\n }\n ]\n }\n }\n },\n \\\"access-point\\\": [\n {\n \\\"name\\\": \\\"vOLTMF_Kafka_2\\\",\n \\\"kafka-agent\\\": {\n \\\"kafka-agent-transport-parameters\\\": {\n \\\"remote-address\\\": \\\"kafka-host\\\",\n \\\"remote-port\\\": 9092\n }\n }\n }\n ]\n },\n {\n \\\"name\\\": \\\"vOMCI-grpc-1\\\",\n \\\"nf-type\\\": \\\"bbf-network-function-types:vomci-function-type\\\",\n \\\"local-endpoint-name\\\": \\\"proxy-grpc-2\\\",\n \\\"access-point\\\": [\n {\n \\\"name\\\": \\\"vOMCI-grpc-1\\\",\n \\\"grpc\\\": {\n \\\"grpc-transport-parameters\\\": {\n \\\"remote-address\\\": \\\"vomci-host\\\",\n \\\"remote-port\\\": 8100\n }\n }\n }\n ]\n }\n ]\n }\n }\n },\n \\\"nf-server\\\": {\n \\\"enabled\\\": true,\n \\\"listen\\\": {\n \\\"listen-endpoint\\\": [\n {\n \\\"name\\\": \\\"proxy-grpc-2\\\",\n \\\"grpc\\\": {\n \\\"grpc-server-parameters\\\": {\n \\\"local-endpoint-name\\\": \\\"proxy-grpc-2\\\",\n \\\"local-address\\\": \\\"::\\\",\n \\\"local-port\\\": 8433\n }\n }\n }\n ]\n }\n }\n }\n }\n}\"\n }\n }\n }\n }\n}\n\n```\n\n## Sample notifications on the MvOLTMF-vOMCI (sent by the vOMCI function)\n\nONU Alignment Result (aligned) Notification\n\n```\nMsg {\n header {\n msg_id: \"1\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: ONU\n object_name: \"ont1\"\n}\nbody {\n notification {\n data: \"{\\\"bbf-vomci-function:onu-alignment-status\\\":{\\\"event-time\\\": \\\"2021-06-01T15:53:36+00:00\\\",\\\"onu-name\\\": \\\"ont1\\\",\\\"alignment-status\\\": \\\"aligned\\\"}}\"\n }\n}\n}\n\n```\n\nONU Alignment Result (mis-aligned) Notification\n\n```\nMsg {\n header {\n msg_id: \"1\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: ONU\n object_name: \"ont1\"\n}\nbody {\n notification { \n data: \"{\\\"bbf-vomci-function:onu-alignment-status\\\":{\\\"event-time\\\": \\\"2021-06-01T15:53:36+00:00\\\",\\\"onu-name\\\": \\\"ont1\\\",\\\"alignment-status\\\": \\\"unaligned\"}}\"\n }\n}\n}\n\n```\n\nONU Reported Alarms via the vOMCI function\n\n```\nMsg {\n header {\n msg_id: \"1\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: ONU\n object_name: \"ont1\"\n}\nbody {\n notification { \n event_timestamp: \"2022-01-09T13:53:36+00:00\"\n data: \"{ \"ietf-alarms:alarm-notification\": {\n \"resource\": \"/ietf-interfaces:interfaces/interface[name='eth0']\",\n \"alarm-type-id\": \"bbf-alarm-types:bbf-alarm-type-id\",\n \"alarm-type-qualifier\": \"\",\n \"time\": \"2022-01-09T13:53:36+00:00\",\n \"perceived-severity\": \"major\",\n \"alarm-text\": \"example alarm\"\n }\n }\"\n }\n}\n}\n\n```\n\nONU Cleared Alarms via the vOMCI function\n\n```\nMsg {\n header {\n msg_id: \"1\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: ONU\n object_name: \"ont1\"\n}\nbody {\n notification { \n event_timestamp: \"2022-01-09T13:53:36+00:00\"\n data: \"{ \"ietf-alarms:alarm-notification\": {\n \"resource\": \"/ietf-interfaces:interfaces/interface[name='eth0']\",\n \"alarm-type-id\": \"bbf-alarm-types:bbf-alarm-type-id\",\n \"alarm-type-qualifier\": \"\",\n \"time\": \"2022-01-09T13:54:36+00:00\",\n \"perceived-severity\": \"cleared\",\n \"alarm-text\": \"example alarm\"\n }\n }\"\n }\n}\n}\n\n```\n\n## Sample messages on the MvOLTMF-vOMCI (translated and forwarded to the ONU)\n\n### Replace-Config\n\nWhen vOLTMF receives onu-alignment result notification from the vOMCI function with alignment-status as \"misaligned\", the vOLTMF tries to align the ONU by sending replace-config request towards the vOMCI function. For an ONU created with standard onu adapter 1.0 below is the sample replace-config request and response:\n\nreplace-config request towards the vOMCI function:\n\n```\nMsg {\n header {\n msg_id: \"2\"\n sender_name: \"vOLTMF\"\n recipient_name: \"vomci-vendor-1\"\n object_type: ONU\n object_name: \"ont1\"\n}\nbody {\n request {\n replace_config {\n 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\\\":{}}\"\n }\n }\n}\n}\n\n```\n\nreplace-config response from a vOMCI function:\n\n```\nMsg {\n header {\n msg_id: \"2\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: ONU\n object_name: \"ont1\"\n}\nbody {\n response {\n replace_config_resp {\n status_resp{\n status_code=0\n }\n }\n }\n}\n}\n\n```\n\n### Get-Data\n\nInformation about an ONU can be retrieved by sending a get-data request towards the vOMCI function. This request contains a list of filters which specify which parts of the ONU data model need to be retrieved. For an ONU created with the standard onu adapter 1.0 below is the sample get-data request and response:\n\nget-data request towards the vOMCI function:\n\n```\nMsg {\n header {\n msg_id: \"3\"\n sender_name: \"vOLTMF\"\n recipient_name: \"vomci-vendor-1\"\n object_name: \"ont1\"\n }\n body {\n request {\n get_data {\n filter: \"{\n \\\"ietf-hardware:hardware\\\": {\n \\\"component\\\": [\n {\n \\\"name\\\": \\\"ont1\\\",\n \\\"bbf-software-management:software\\\": {}\n }\n ]\n }\n }\"\n }\n }\n }\n}\n\n```\n\nget-data response from the vOMCI function:\n\n```\nMsg {\n header {\n msg_id: \"3\"\n sender_name: \"vomci-vendor-1\"\n recipient_name: \"vOLTMF\"\n object_type: ONU\n object_name: \"ont1\"\n }\n body {\n response {\n get_resp {\n data: \"{\n \\\"ietf-hardware:hardware\\\": {\n \\\"component\\\": [\n {\n \\\"name\\\": \\\"ont1\\\",\n \\\"bbf-software-management:software\\\": {\n \\\"software\\\": [\n {\n \\\"name\\\": \\\"model1-software\\\",\n \\\"revisions\\\": {\n \\\"revision\\\": [\n {\n \\\"id\\\": 1,\n \\\"alias\": \\\"model1-software-rev1\\\",\n \\\"state\": \\\"in-use\\\",\n \\\"version\\\": \\\"1.0.0\\\",\n \\\"product-code\\\": \\\"pcode\\\",\n \\\"hash\\\": \\\"123456789\\\",\n \\\"is-valid\": true,\n \\\"is-active\": true,\n \\\"is-committed\": true\n },\n {\n \\\"id\\\": 2,\n \\\"alias\\\": \\\"model1-software-rev2\\\",\n \\\"state\": \\\"available\\\",\n \\\"version\\\": \\\"2.0.0\\\",\n \\\"product-code\\\": \\\"pcode\\\",\n \\\"hash\\\": \\\"134323233\\\",\n \\\"is-valid\\\": true,\n \\\"is-active\\\": false,\n \\\"is-committed\\\": false\n }\n ]\n }\n }\n ]\n }\n }\n ]\n }\n }\"\n }\n }\n }\n}\n\n```","schema":"https://schema.getpostman.com/json/collection/v2.0.0/collection.json","isPublicCollection":false,"owner":"11528456","team":1088250,"collectionId":"c6920b23-dcab-4b53-aa71-8f657d9e3447","publishedId":"2s93RQTZtk","public":true,"publicUrl":"https://bbf.etisoftware.com","privateUrl":"https://go.postman.co/documentation/11528456-c6920b23-dcab-4b53-aa71-8f657d9e3447","customColor":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"},"documentationLayout":"classic-double-column","customisation":{"metaTags":[{"name":"description","value":""},{"name":"title","value":""}],"appearance":{"default":"light","themes":[{"name":"dark","logo":null,"colors":{"top-bar":"212121","right-sidebar":"303030","highlight":"FF6C37"}},{"name":"light","logo":null,"colors":{"top-bar":"FFFFFF","right-sidebar":"303030","highlight":"FF6C37"}}]}},"version":"8.10.1","publishDate":"2023-07-22T13:02:16.000Z","activeVersionTag":"latest","documentationTheme":"light","metaTags":{"title":"","description":""},"logos":{"logoLight":null,"logoDark":null}},"statusCode":200},"environments":[{"name":"ETI-Environment","id":"ccd84c46-e859-40f6-be77-828ec604591a","owner":"11528456","values":[{"key":"token","value":"","enabled":true},{"key":"baseUrl","value":"triad60.dev.etisoftware.com","enabled":true,"type":"default"},{"key":"instance","value":"eti-demo-maxicom","enabled":true,"type":"default"}],"published":true}],"user":{"authenticated":false,"permissions":{"publish":false}},"run":{"button":{"js":"https://run.pstmn.io/button.js","css":"https://run.pstmn.io/button.css"}},"web":"https://www.getpostman.com/","team":{"logo":"https://res.cloudinary.com/postman/image/upload/t_team_logo_pubdoc/v1/team/52de83af874f462001674ddb9bdc1bfca2ae7a02c72a76650e1d6907bc6253c0","favicon":"https://etisoftware.com/favicon.ico"},"isEnvFetchError":false,"languages":"[{\"key\":\"csharp\",\"label\":\"C#\",\"variant\":\"HttpClient\"},{\"key\":\"csharp\",\"label\":\"C#\",\"variant\":\"RestSharp\"},{\"key\":\"curl\",\"label\":\"cURL\",\"variant\":\"cURL\"},{\"key\":\"dart\",\"label\":\"Dart\",\"variant\":\"http\"},{\"key\":\"go\",\"label\":\"Go\",\"variant\":\"Native\"},{\"key\":\"http\",\"label\":\"HTTP\",\"variant\":\"HTTP\"},{\"key\":\"java\",\"label\":\"Java\",\"variant\":\"OkHttp\"},{\"key\":\"java\",\"label\":\"Java\",\"variant\":\"Unirest\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"Fetch\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"jQuery\"},{\"key\":\"javascript\",\"label\":\"JavaScript\",\"variant\":\"XHR\"},{\"key\":\"c\",\"label\":\"C\",\"variant\":\"libcurl\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Axios\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Native\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Request\"},{\"key\":\"nodejs\",\"label\":\"NodeJs\",\"variant\":\"Unirest\"},{\"key\":\"objective-c\",\"label\":\"Objective-C\",\"variant\":\"NSURLSession\"},{\"key\":\"ocaml\",\"label\":\"OCaml\",\"variant\":\"Cohttp\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"cURL\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"Guzzle\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"HTTP_Request2\"},{\"key\":\"php\",\"label\":\"PHP\",\"variant\":\"pecl_http\"},{\"key\":\"powershell\",\"label\":\"PowerShell\",\"variant\":\"RestMethod\"},{\"key\":\"python\",\"label\":\"Python\",\"variant\":\"http.client\"},{\"key\":\"python\",\"label\":\"Python\",\"variant\":\"Requests\"},{\"key\":\"r\",\"label\":\"R\",\"variant\":\"httr\"},{\"key\":\"r\",\"label\":\"R\",\"variant\":\"RCurl\"},{\"key\":\"ruby\",\"label\":\"Ruby\",\"variant\":\"Net::HTTP\"},{\"key\":\"shell\",\"label\":\"Shell\",\"variant\":\"Httpie\"},{\"key\":\"shell\",\"label\":\"Shell\",\"variant\":\"wget\"},{\"key\":\"swift\",\"label\":\"Swift\",\"variant\":\"URLSession\"}]","languageSettings":[{"key":"csharp","label":"C#","variant":"HttpClient"},{"key":"csharp","label":"C#","variant":"RestSharp"},{"key":"curl","label":"cURL","variant":"cURL"},{"key":"dart","label":"Dart","variant":"http"},{"key":"go","label":"Go","variant":"Native"},{"key":"http","label":"HTTP","variant":"HTTP"},{"key":"java","label":"Java","variant":"OkHttp"},{"key":"java","label":"Java","variant":"Unirest"},{"key":"javascript","label":"JavaScript","variant":"Fetch"},{"key":"javascript","label":"JavaScript","variant":"jQuery"},{"key":"javascript","label":"JavaScript","variant":"XHR"},{"key":"c","label":"C","variant":"libcurl"},{"key":"nodejs","label":"NodeJs","variant":"Axios"},{"key":"nodejs","label":"NodeJs","variant":"Native"},{"key":"nodejs","label":"NodeJs","variant":"Request"},{"key":"nodejs","label":"NodeJs","variant":"Unirest"},{"key":"objective-c","label":"Objective-C","variant":"NSURLSession"},{"key":"ocaml","label":"OCaml","variant":"Cohttp"},{"key":"php","label":"PHP","variant":"cURL"},{"key":"php","label":"PHP","variant":"Guzzle"},{"key":"php","label":"PHP","variant":"HTTP_Request2"},{"key":"php","label":"PHP","variant":"pecl_http"},{"key":"powershell","label":"PowerShell","variant":"RestMethod"},{"key":"python","label":"Python","variant":"http.client"},{"key":"python","label":"Python","variant":"Requests"},{"key":"r","label":"R","variant":"httr"},{"key":"r","label":"R","variant":"RCurl"},{"key":"ruby","label":"Ruby","variant":"Net::HTTP"},{"key":"shell","label":"Shell","variant":"Httpie"},{"key":"shell","label":"Shell","variant":"wget"},{"key":"swift","label":"Swift","variant":"URLSession"}],"languageOptions":[{"label":"C# - HttpClient","value":"csharp - HttpClient - C#"},{"label":"C# - RestSharp","value":"csharp - RestSharp - C#"},{"label":"cURL - cURL","value":"curl - cURL - cURL"},{"label":"Dart - http","value":"dart - http - Dart"},{"label":"Go - Native","value":"go - Native - Go"},{"label":"HTTP - HTTP","value":"http - HTTP - HTTP"},{"label":"Java - OkHttp","value":"java - OkHttp - Java"},{"label":"Java - Unirest","value":"java - Unirest - Java"},{"label":"JavaScript - Fetch","value":"javascript - Fetch - JavaScript"},{"label":"JavaScript - jQuery","value":"javascript - jQuery - JavaScript"},{"label":"JavaScript - XHR","value":"javascript - XHR - JavaScript"},{"label":"C - libcurl","value":"c - libcurl - C"},{"label":"NodeJs - Axios","value":"nodejs - Axios - NodeJs"},{"label":"NodeJs - Native","value":"nodejs - Native - NodeJs"},{"label":"NodeJs - Request","value":"nodejs - Request - NodeJs"},{"label":"NodeJs - Unirest","value":"nodejs - Unirest - NodeJs"},{"label":"Objective-C - NSURLSession","value":"objective-c - NSURLSession - Objective-C"},{"label":"OCaml - Cohttp","value":"ocaml - Cohttp - OCaml"},{"label":"PHP - cURL","value":"php - cURL - PHP"},{"label":"PHP - Guzzle","value":"php - Guzzle - PHP"},{"label":"PHP - HTTP_Request2","value":"php - HTTP_Request2 - PHP"},{"label":"PHP - pecl_http","value":"php - pecl_http - PHP"},{"label":"PowerShell - RestMethod","value":"powershell - RestMethod - PowerShell"},{"label":"Python - http.client","value":"python - http.client - Python"},{"label":"Python - Requests","value":"python - Requests - Python"},{"label":"R - httr","value":"r - httr - R"},{"label":"R - RCurl","value":"r - RCurl - R"},{"label":"Ruby - Net::HTTP","value":"ruby - Net::HTTP - Ruby"},{"label":"Shell - Httpie","value":"shell - Httpie - Shell"},{"label":"Shell - wget","value":"shell - wget - Shell"},{"label":"Swift - URLSession","value":"swift - URLSession - Swift"}],"layoutOptions":[{"value":"classic-single-column","label":"Single Column"},{"value":"classic-double-column","label":"Double Column"}],"versionOptions":[],"environmentOptions":[{"value":"0","label":"No Environment"},{"label":"ETI-Environment","value":"11528456-ccd84c46-e859-40f6-be77-828ec604591a"}],"canonicalUrl":"https://bbf.etisoftware.com/view/metadata/2s93RQTZtk"}