Download PDF

1. RBFS Overview

1.1. RBFS At-a-Glance

RtBrick Full Stack (RBFS) is a disaggregated and open network operating system that is presently productized and available as a Broadband Network Gateway (BNG). RBFS acts as an access point for establishing and managing subscriber sessions for broadband subscribers. It aggregates traffic from various subscriber sessions and routes the traffic to the network of the service provider.

RBFS, an access software for subscribers, establishes and maintains a connection with the Customer Premise Equipment (CPE), so that subscribers can access and use the network services from a network service provider.

RBFS runs as an Ubuntu container on the Open Network Linux operating system on white boxes which can perform Layer 2 and Layer 3 switching.

RBFS Overview

1.2. Why RBFS

RBFS' open and disaggregated architectural design fosters a faster deployment of new features and services within a short span of time and it promotes a collaborative ecosystem of hardware and other component vendors. By separating the hardware from the software, RBFS enables you to choose the white box switches of your choice without any vendor lock-in. It helps to reduce the deployment and operational costs significantly by promoting disaggregated BNG that is suitable for cloud native ecosystem.

RBFS, built on the microservices architecture, offers some key benefits compared to traditional monolithic systems. It offers greater agility and provides a higher degree of automation that reduces operational overheads. RBFS works well with the continuous integration (CI) and continuous delivery (CD) practices and tools.

1.3. Architecture and the Key Functional Components

RBFS has been designed based on microservices architecture to cater a rapidly growing broadband traffic. An RBFS container contains multiple microservices, known as daemons. These microservices are the building blocks of the RBFS ecosystem and they can communicate with each other through a centralized in-memory datastore called Brick Data Store (BDS).

RBFS Daemons

1.3.1. Brick Data Store

RBFS has a schema-driven and in-memory database called BDS (Brick Data Store). As an in-memory data store, BDS relies mainly on the main memory for storage of data that is contrary to the databases that store data on disks. BDS has architecturally been designed to enable very minimal response time by removing the time to access data stored in disks. BDS acts as a control plane and provides all required data and instructions to the daemons for their functioning.

1.3.2. Brick Daemons

RBFS microservices architecture allows decoupled daemons to serve various functionalities and services and they have their own realm of responsibilities to serve independently.

For example, the subscriber daemon (subscriberd) manages the current subscriber state and is responsible for authentication, authorization, and accounting. The ribd daemon is responsible for route selection, next hop resolution, tunnel selection and recursion. The forwarding (fibd) daemon handles packet forwarding, route NH download, VPP and PD layer programming. Daemons such as confd and ifmd take care of various configurations and interface management respectively and together they all compose a comprehensive broadband sessions.

For the routing protocols such as BGP, there are two daemons - bgp.appd and bgp.iod - available to carry out the various functions of the protocol. The bgp.iod daemon manages sending and receiving of packets and is also responsible for update, notification, and keepalive tasks. The bgp.appd daemon is responsible for the best route selection and also takes care of updating the route section information to the bgp.iod daemon.

There are daemons such as CtrlD (Controller) and ApiGwD (API Gateway) which are part of the RBFS ecosystem but they do not stay inside of the Linux container. These daemons sit in the middle (in the ONL) and manage all the communication between the client and backend services running in the container. The API Gateway (ApiGwD) daemon provides a single point access to expose services running inside of the RBFS container.

In addition to the RtBrick daemons, you can deploy some other third-party applications in the container to bring in additional capabilities to the system. For example, Prometheus is an open-source monitoring and alerting software that you can use for observability and monitoring purposes in the container.

1.4. Supported Topologies

RBFS can be deployed in a spine-leaf architecture and can also be deployed as a standalone in a single switch by consolidating all the features in one switch.

A spine-leaf architecture is a two-tier network topology that consists of two switching layers — a spine and leaf. In this topology, two layers of switches interconnect in a full mesh. The leaf layer consists of access switches which aggregate traffic and connect directly into the spine that is the core network.

The advantage of RBFS spine-leaf topology is that there is no single point of failure. This topology is easier for horizontal scaling by adding additional switches to add more capacity to handle increased traffic. This topology is useful for low latency and higher bandwidth.

A consolidated BNG architecture offers all the functionalities of a spine-leaf BNG architecture on a single bare-metal switch. However, this architecture is recommended when there is a small concentration of broadband subscribers.

1.5. Interfaces to Operate and Manage RBFS

RBFS provides a CLI and a rich set of commands that you can use to operate, configure, monitor, and manage the system and its various components. Using the RBFS CLI, you can configure static IPv4, IPv6, MPLS, and multicast routes.

In addition to the CLI, RBFS also offers industry-standard tools and utilities such as RBMS and APIs.

RBFS APIs allow to access and consume RBFS data in a simple and secure manner.

RBMS (RtBrick’s Management System) is a GUI based application that acts as a single pane of glass and allows interactions with RBFS for all operations, from provisioning and management to monitoring and debugging.

RBFS API Overview

1.6. Features and Components

1.6.1. Routing

RBFS supports all major interior gateway routing protocols (IGP) such as IS-IS and OSPF and the exterior gateway routing protocol BGP. BGP is a standard exterior gateway protocol (EGP) supported by RBFS. It is considered a “Path Vector” routing protocol and maintains a separate routing table based on shortest Autonomous system (AS) path and various other route attributes. RBFS supports Multiprotocol Label Switching (MPLS).

Protocol Independent Multicast (PIM) is a multicast routing protocol that runs over an existing unicast infrastructure. RBFS supports PIM source-specific multicast (SSM). PIM-SSM uses a subset of PIM sparse mode and IGMP to permit a client to receive multicast traffic directly from the source.

RBFS supports static routing that allows you to configure routes manually. With the IS-IS and OSPF protocols, RBFS supports segment routing where the source router decides the path to the destination and encodes the path details in the packet header as an ordered list of instructions. The next hop routers on the path just execute the instructions on the way to destination.

1.6.2. Access and Subscriber Management

RtBrick’s modular and scalable subscriber management offers the next generation access infrastructure (ng-access) that supports the protocols such as PPPoE, IPoE, L2TPv2, DHCPv4 and DHCPv6, and RADIUS. It provides subscriber authentication, access, service creation, activation, and deactivation. It collects accounting statistics for the subscriber sessions. RBFS enables you to address the challenges such as interoperability with numerous client devices from various vendors which requires a well implemented and industry-proven access protocol stack, including support for all relevant RFCs. RBFS subscriber management infrastructure provides the next generation of internet access protocols designed for carrier grade services. Support for PPPoE and IPoE

RBFS supports both Point-to-Point Protocol over Ethernet (PPPoE) and IPoE to deliver network access services to broadband subscribers.

PPPoE establishes a PPP connection over the ethernet and supports services such as data compression and encryption. In the RBFS, the pppoed daemon manages PPPoE and PPP sessions. The daemon helps to establish multi-logical PPP links to the ethernet and provides a secure authentication mechanism.

IP-over-Ethernet (IPoE) is an alternate to PPPoE to deliver network access services to broadband subscribers. IPoE does not require a client dial-in software and is easy to use when accessing the network. In RBFS, IPoE daemon (ipoed) manages IPoE services using DHCP for IPv4 and IPv6. Accounting

RBFS accounting is the process of tracking subscriber activities and network usage in a subscriber session for auditing and billing. Accounting tracks the information such as subscriber identity, the number of packets and bytes transferred from and to the network, start and stop times of the sessions and so on. The accounting keeps track of resources used by the subscriber during the sessions. This includes the session time called time accounting and the number of packets and bytes transmitted during the session called volume accounting. Support for Lawful Interception

RBFS supports Lawful Interception (LI) to allow legal authorities to obtain communications network data for analysis or evidence. LI is a technique of intercepting certain user data-streams tunnel the intercepted traffic to a mediation device with the data and only the users with appropriate credentials can access the intercepted data.

1.6.3. RBFS Hierarchical Quality of Service

Hierarchical Quality of Service (HQoS) is a mechanism that allows you to specify Quality of Service (QoS) behavior for different traffic classes. It provides a higher degree of granularity in traffic management. RBFS HQoS feature ensures that each network service gets the required network resources.

RBFS achieves this by classifying, policing, shaping, and scheduling the traffic based on service types.

1.6.4. Zero Touch Provisioning

By leveraging the Zero Touch Provisioning (ZTP) feature, you can automate many of the RBFS deployment and setup tasks. ZTP allows you to set up and configure the platforms automatically by eliminating the repetitive manual tasks in a large scale environment. This feature significantly reduces human touch points and errors prone by manual interventions and makes the deployment easier.

1.6.5. Scalability in RBFS

RBFS allows horizontal scaling to enhance system capacity. You can add additional switches to the spine and leaf layers to enhance capacity to handle increased subscriber traffic.

RBFS offers subscriber management capacity in a scale-out architecture called the Point-Of-Deployment (PoD), also known as a SEBA PoD (SDN Enabled PoD). A large-scale PoD consists of access leaf routers aggregated by a layer of spine-leaf routers in an auto-provisioned CLOS topology. The access leaf routers provide subscriber management functionality. For even greater scalability, a layer of border leaf routers can be added to the core of the network provider network to provide more connectivity.

The leaf routers can be scaled out horizontally to increase the number of subscribers supported on the PoD, providing a pay-as-you-grow model. PPPoE subscribers can be terminated on the access leaf routers or tunnelled to an LNS over L2TPv2. L2 Cross Connect (L2X) allows subscriber traffic to be tunnelled out of the PoD at Layer 2, providing connectivity.

1.6.6. Security in RBFS

In RBFS, security is integrated into the foundation of the network. RBFS implements several techniques and methods to safeguard the entire network infrastructure. RBFS has a comprehensive set of security capabilities that deploy multiple security controls to protect different areas of the system and network. Security features for RBFS Control Plane

RBFS Control Plane security feature enables filtering and rate-limiting the traffic transmitted from the forwarding plane to the control plane. RBFS uses Access Control Lists (ACL) and policers to secure the router’s control plane.

All routing protocols, management protocols, service protocols run in the control plane. The output of these protocols result in databases such as routing table, MAC table, ARP table, and so on, which eventually get programmed in the forwarding plane.

ACLs are the building blocks of the control plane security. RBFS employs fundamental mechanisms - Protocol ACLs and Route Lookup - for redirecting control plane traffic to the CPU and policers for controlling CP traffic to the CPU.

All routing protocols (BGP, OSPF, and ISIS), Management Protocols (SSH, RESTCONF, and so on), Service Protocols (RADIUS, NTP, and TACACS+), and Access Protocols (PPPoE, DHCP, L2TP, and PPP) automatically create Access Control Lists (ACLs) required to punt the protocol traffic to the CPU Control Plane.

The RBFS Control Plane Security feature adds policers to all protocol ACLs. This feature creates a set of default policers and applies them to the protocol ACLs to secure the control plane from DDoS attacks. Security features for RBFS Management Plane

RBFS provides the capability to restrict the access to the management plane only to authenticated and authorized entities. The authentication identifies the entity and the authorization validates if the entity is allowed to execute the action.

For management plane security, RBFS implements token based authentication that provides access to the management plane through APIs only to the authenticated entities.

RBFS uses JSON web token, an open standard token, that defines a compact and self-contained way for securely transmitting information between parties as a JSON object. The ApiGwD daemon validates the access token against a JSON web key set (JKWS).

1.6.7. Logging and Observability in RBFS

RBFS logging is the process of writing log messages during the execution of an event. Logging provides reports about the events in the entire RBFS ecosystem at different functional areas. You can configure logging based on different severity levels available. RBFS also allows you to send logs to third party log management servers such as Graylog where you can view and analyze the real-time data. It provides you the ability to trace out the errors of the applications in real-time.

Operational state visibility is crucial for troubleshooting, testing, monitoring, and capacity management. To enable operational visibility, it is required to collect router metrics periodically. RBFS allows ingestion of time-series data allows to send operational queries.

RBFS uses Prometheus, an open-source system monitoring and alerting tool, for monitoring and metric collection. Prometheus collects time-stamped data for events, network data, application performance, and so on. The tool allows analyzing metrics with the PromQL query language. Additionally, RBFS provides an optional alert management tool. You can use both of these tools together with its own services to integrate it into the RBFS ecosystem. Resource Monitoring

Monitoring the device and its various components is very crucial to analyze the health of devices. RBFS provides resource monitoring capabilities to the various components of the devices. RBFS has a dedicated daemon called resmond to discover and monitor the device resources. With the RBFS Resource Monitoring service, you can constantly observe the health of the system resources such as CPU, Memory, Processes, Disks, Sensor, and Optics. Port Mirroring

RBFS supports port mirroring, a monitoring technique that can be implemented on network switches. Port mirroring allows to copy and send data packets from a port to another port for monitoring purpose. Port mirroring enables network administrators to keep close watch on a device performance with a protocol analyzer on the port that has the mirrored data.

©Copyright 2022 RtBrick, Inc. All rights reserved. The information contained herein is subject to change without notice. The trademarks, logos and service marks ("Marks") displayed in this documentation are the property of RtBrick in the United States and other countries. Use of the Marks are subject to RtBrick’s Term of Use Policy, available at Use of marks belonging to other parties is for informational purposes only.