RBFS REST APIs
This document contains all the information about RBFS REST API services, their purposes and how to use these APIs. This documentation goes hand-in-hand with the RBFS OpenAPI document which provides information about all RBFS REST API endpoints. It is recommended to refer to this document in conjunction with the RBFS OpenAPI document.
Introduction to RBFS REST APIs
RBFS REST APIs allow customers and partners to programmatically access information from the RBFS software components. RBFS REST APIs enable users to manage and automate many of their tasks by accessing and consuming the RBFS data simply and securely.
RBFS REST API architecture supports containerized deployments with a centralized configuration and management. It also enables the configuration and management of distinct daemons and services.
RBFS APIs adhere to the Representational State Transfer (REST) principles and allow consumers to securely connect to the RBFS device, obtain information (read) and run actions or operations to apply changes. RBFS REST APIs use JavaScript Object Notation (JSON) for the exchange of information. The OpenAPI Specification format, which is a broadly accepted industry standard for describing REST APIs, is used to describe, consume, and visualize RBFS REST APIs.
Understanding RBFS APIs
RBFS, a disaggregated Broadband Network Gateway, provides many APIs to make all communications possible with various RBFS software components, the host operating system (ONL), and the hardware platform. RBFS consists of several independent microservices including the API Gateway daemon (ApiGwD) and Control daemon (CtrlD). Both of these microservices, known as daemons, play crucial roles in managing RBFS instances.
API gateway functions only if management plane security is enabled. All API requests from external clients are routed to the API Gateway. After successful authentication by the API Gateway, these requests are forwarded to the Control daemon. CtrlD, which is aware of the state and port information of all daemons that reside in the RBFS container, can forward requests to the respective daemons.
| If security is disabled, API Gateway does not function and, then CtrlD becomes the first entry point for external requests. |
The illustration presents how the RBFS REST APIs communication happens with various underlying software components. RBFS microservices, which perform various functions, are containerized in an open Linux container. RBFS APIs are generally categorized into Public Management APIs and Internal APIs. Public Management APIs include CtrlD API, RESTCONF API, and Operational state API. These APIs are used for managing and automating many of the network administration tasks.
| The use of internal APIs such Brick Daemon APIs and BDS APIs are not supported. |
The illustration also presents the API Gateway daemon (ApiGwD) and Control daemon (CtrlD), which are deployed on the host operating system (open network Linux) along with the RBFS container. The API Gateway acts as an entry point that provides a secure channel for all REST APIs by authenticating all requests. After successful authentication by the API Gateway, CtrlD (Control Daemon) passes all the requests to the respective daemons (that reside in the RBFS container) which are responsible for performing certain tasks.
RBFS APIs
CtrlD API: CtrlD runs on the host OS (ONL) and acts as a proxy to the other APIs including high-level APIs for the RBFS configurations. The CtrlD API, implemented by the CtrlD, performs various tasks such as starting the container and rebooting the device. In case of a software upgrade, this API is used to trigger the upgrade.
API Gateway: You can deploy the API Gateway Daemon (ApiGwD) on the host OS (that is ONL) to secure the RBFS management plane. The API Gateway authenticates all API requests using JSON web tokens. The API Gateway Daemon acts as the TLS endpoint for the hardware platform and it converts external access token into an internal RtBrick token /SEC/. Finally, it forwards the requests to the CtrlD.
The API Gateway also enforces an API throttler that provides a mechanism called API throttle quotas to protect the RBFS system resources from being exhausted with too many requests by a single client system that uses the RBFS APIs very extensively.
Operational State APIs: The Operational State API, provided by the Operational State Daemon (opsd), allows accessing system states such as routing protocol states, interface states, subscriber states and resource utilization. The Operational State Daemon takes care of examining the operational state of a switch and runs actions to diagnose and troubleshoot the problems. The operational state is ephemeral and state data is lost when the switch reboots.
RESTCONF APIs: With RESTCONF, you can manage all the configurations in RBFS.
Prometheus APIs: Prometheus APIs help to retrieve metrics from various RBFS components for visibility.
| RFC and draft compliance mentioned in the document are partial except as specified. |