Introduction

This document covers the design approach followed for RDK Broadband containerization. It is evident that RDKB uses ccsp architecture which has several components,
each defined with specific roll. Communication between ccsp components is carried over by message bus, which is enhanced version of d-bus

On the understanding of above mentioned RDKB Architecture, containerization approached is based on LGI framework  which meets following major requirements

• It must be possible to run all RDK components inside containers; no components should need to run in the host except for the init process and any processes that start containers.
• It must be possible to run all RDK components (including open source components) as an unprivileged user within a container.
• It must be possible to define and configure containers at build time; there is no requirement to create and configure containers at run time
• As much as possible, container configurations and related data (e.g. UIDs, GIDs, and container network configuration) should be created automatically by tooling.
• Container security and resource usage (e.g. firewall rules and container cgroup settings) should be defined by tooling where possible.
• The mechanism for launching containers must be agnostic to the type of init system used by the device (e.g. systemd, sysV init scripts, web bridge, or others).
• The root file system configuration for a set of containers should support minimizing the overall size of the device root file system, e.g. through the use of bind mounts.
• Starting and stopping a process or group of processes in a container should not require starting or stopping the entire container.

Apart from above mentioned requirements, there are more to be reported which will be considered for future development

In general, LGI based framework uses XML file, which in turn will generate a conf,launcher script, necessary rootfs internal directories,lib files and application binaries through mount bind.

LGI based XML file framework has the option to control User ID and Group ID for each container as per the requirement and same is followed. In addition it has option of secure and non-secure control parameter which meets the requirement of running a container in non-privileged mode and privileged mode respectively.

But secure mode is chosen for all the containers in proposed containers which is again meeting the requirement

Limitations

One of the main challenge or limitation in containerizing the RDKB components would be inter process communication between them (including host) after running in container

Since host and container has different rootfs, which creates dependency in using shared memory . In short shared memory created in host rootfs cannot be accessed from process running inside container and vice versa

Another limitation in lxc-container is that network interface (brlan0) cannot be created by process (gwprov_utopia) running inside container . Only host has permission to create network interface through host based process. This creates bottleneck for RDKB containerization, since it creates bridge interface (brlan0) for LAN

Design approach

On considering above described limitations and requirements, design approach for RDKB Containerization as follows

Initially, core rdkb components(ccspcr,psm and ccsppandm) are taken for containerization which constitutes for bringing up RDKB system

Apart from core rdkb components, gwprov_utopia component is responsible for interface creation and base provisioning information which is also included

On considering the limitation in lxc container which allows interface creation only under host, gwprov_utopia component is needed to run in both host and inside container

Host side gwprov_utopia is needed for creating LAN interface (brlan0), but gwprov_utopia running inside container is essential for CCSPPandM

CCSPPandM and gwprov_utopia runs in same container which is inevitable to run as separate entity considering the limitation of shared memory

Since CCSPPandM uses utopia which in turn uses shared memory through pre-defined API's. gwprov_utopia running inside CCSPPandM container will populate some of the base information in shared memory

So to avoid CCSPPandM design change in the way it is accessing shared memory for provisioning, gwprov_utopia and CCSPPandM are needed to run in same container

So to mitigate above limitations in lxc with respect RDKB Design Philosophy, gwprov_utopia ( one binary file ) is made run in host and CcspPandM container with changes based on flag

Another server client model is used for IPC between gwprov_utopia ( server - lxcserver binary as stand alone utility) in host and ccsppandm (udp socket client function in ssp_main.c) in container

The above mentioned communication is needed to update the events from CcspPandM in Container to gwprov_utopia in host. Based on the event gwprov_utopia in host will call respective service file to create LAN (brlan0) interface

lo interface is used ( using loop back address 127.0.0.1 ) for the above mentioned IPC which is mapped into CcspPandM container as well

lxc has support to map interfaces in host to container. Once interface is created in host, it is reflected in CcspPandM too which can be bring to up state based on other events from gwprov_utopia running in ccsppandm container as well

Following components are expected to run under respective container using the UID and GID settings and as secure container provided from XML file during build time 

• DBUS
• CCSPCR
• CCSPPANDM ( + gwprov_utopia )
• PSMSSP
• CCSPWIFI

D-BUS Design approach based on LGI

Since dbus uses system_bus_socket file for inter process communication between ccsp components

So when D-Bus moved into container this file cannot be accessed by other container components considering the limitation in accessing file between containers

Hence, D-Bus container is executed by creating symbolic link for system_bus_socket file in host, which is used by containers which needs d-bus communication

Design philosophy states that d-bus communication is used for IPC as native in RDKB Architecture but it has pre defined capabilities

System Diagram

Following is the flow which will bring the RDKB components running under container to up state as a system on whole

Service file for bringing RDKB components as container which is invoked by host as part of systemd .

This is similar to previous design except change in service file to call container based script files

Host: init->systemd service->gwprov_utopia+lxcserver (for IPC between CcspPandM)

Container: DBUS->CCSPCR->PSMSSP->CCSPPandM(+ gwprov_utopia)

Please refer to user manual for commands to be used for handling containers and processing application inside container

Below mentioned diagram will differentiate the RDKB system before and after containerization

RDKB System running in Host 

RDKB System running in Containers

Enhanced Support for Interface Creation

Workflow

Containers Workflow Diagram

All containers follow the same Workflow procedure.

The application and utilities inside rootfs will vary based on each container's role.