Software

The software implementation of the Access Zone is meant to provide all the required set of functional requirements for this zone. It is expected to run within the compute fabric of the A-POD and to distribute its load across the compute fabrics across multiple A-PODs within the same network domain. Moreover, it needs to have all the required capabilities to integrate and support other broadband utility zones (Market, Community) as well as emerging Mobility Technologies (vRAN).

The software stacks are meant to provide

These are required to provide proper interfaces to other zones services as extensions and integrations with their infrastructures as well as to deliver the proper level of services under the Access Zone.

The OB-BAA software architecture is based on the logical system architecture where standardized northbound interfaces are defined for management (Minf_xxx) and control (Mfc_xxx). The standardized management interface is further broken down in the BAA layer administration (Minf_net-map, Minf_eq-inv) and the device management interfaces (Minf_Lxxx). The representation of the AN is exposed through each of the interfaces using access control to restrict access to parts of the AN.

While most northbound interfaces used by OB-BAA are standardized, several interfaces (e.g., Mfc_L2-3) are used that haven’t been standardized or are in the process of standardization.

ANs interact with the BAA layer through the adapters of the SBI. These adapters can be specific a vendor’s implementation or can be generic in the sense that vendors that have the same SBI can share a default adapter for the type of device.

The requirements for the BNG Software package are primarily based in the following Technical Report from the Broadband Forum: TR-101 Issue 2 (2011) – Migration to Ethernet-Based Broadband Aggregation. Any compliant solution must provide a very high degree of compliance with such Technical Report and its list of requirements. Several of these will be explicitly mentioned in this specification for clarification; however, that does not exclude the needed compliance with the rest.

Together with TR-101, these three additional Technical Reports must be supported:

As derived from TR-101, the main access technology will be Ethernet. In particular,the Open BNG must support IEEE 802.1Q frames, and VLAN stacking (QinQ) mechanisms as per IEEE 802.1ad. It must be noted that QinQ must be supported even if the ethertype of the outer VLAN is 0x8100 instead of the standard 0x88A8.

It shall be possible to assign automatically one (or more) IP address to all subscribers in the Open BNG. These addresses may be:

The Cloud Central Office, hosting and managing the SDN functions is expected to follow TR-384 - Cloud Central Office Reference Architectural Framework and implement the proper interfaces as defined by TR-411 Definition of interfaces between CloudCO Functional Modules.

The E2E Service Orchestrator across the access zone of the utility issues a High-Speed Internet service creation request for a tenant to the Cloud Central Office Domain Orchestrator which orchestrates the establishment of appropriate network service by requesting the:

For enterprise and tower services the A-POD must implement the proper LSO Adagio internal interfaces to partcipate in the MEF LSO Reference Architecture (MEF 55) for the Community Zone. The relevant A-POD resources must be made available under Presto API's leveraging T-API (MEF-66) and Network Resource Management Information Model (MEF 59) as per the definitions in order to be orchestrated and managed by end-to-end services leveraging orchestrations in the Community Zone adminisitrative domain.

The Edge Container Fabric is expected to follow Linux Foundation’s Edge Akaraino’s Provider Access Edge blueprint is part of Akraino’s Kubernetes-Native Infrastructure family of blueprints. As such, it leverages the best-practices and tools from the Kubernetes community to declaratively manage edge computing stacks at scale and with a consistent, uniform user experience from the infrastructure up to the services and from developer environments to production environments on bare metal or on public cloud.

This blueprint targets small footprint deployments able to host NFV (in particular vOLT, vOCMI, vRAN) and MEC (e.g. AR/VR, machine learning, AI,etc.) workloads at the edge to allow for IoT, Industry 4.0 and Autonomous Vehicles (Drones, Tractors, Cars). Its key features are:

For proper management, the edge fabric must be able to be adminsitratively compatible with the Market Zone cloud and cloud-native requirements and will provide extension point and capabilities for retail service providers edge requirements in VNFs as well as emerging applications and services that will have low-latency requirements or data pre-processing needs for cloud optimizations.

For security purposes and multi-tenancy, the fabric must support existing applications and access to hardware accelerations via a P4 Runtime abstraction under the Portable NIC Architecture to avoid NIC limitations in providing a proper service processing pipeline and isolation for the various tenants from Retail Service Providers to Emerging Services Providers.

The Portable NIC Architecture (PNA) is P4 architecture that defines the structure and common capabilities for network interface controller (NIC) devices. PNA comprises two main components:

A programmable pipeline that can be used to realize a variety of different “packet paths” going between the various ports on the device (e.g., network interfaces or the host system it is attached to), and

A library of types (e.g., intrinsict and standard metadata) and P416 externs (e.g., counters, meters, and registers).

PNA is designed to model the common features of a broad class of NIC devices.

The Portable NIC Architecture (PNA) Model has four programmable P4 blocks and several fixed-function blocks, as shown in figure above. The behavior of the programmable blocks is specified using P4. The network ports, packet queues, and (optional) inline extern blocks are fixed-function blocks that can be configured by the control plane, but are not intended to be programmed using P4.

It is expected that operations and telemetry software systems will provide the right interfaces to allow for Operations and Maintenance procedures to be established by the broadband utility operator. These interfaces depend on the nature of the services in two categories.