SEBA: SDN Enabled Broadband Access

Phase I - Study

Title

• SEBA - SDN Enabled Broadband Access

Objective

• SDN-Enabled Broadband Access (SEBA) is an Exemplar Platform being built by the ONF and CORD community.

Concepts

• SEBA is a lightweight platform based on a variant of R-CORD. It supports a multitude of virtualized access technologies at the edge of the carrier network, including PON, G.Fast, and eventually DOCSIS and more. SEBA supports both residential access and wireless backhaul and is optimized such that traffic can run ‘fastpath’ straight through to the backbone without requiring VNF processing on a server.
• Is integrated with Kubernetes, prepared for use in high speed and operationalized with FCAPS and OSS Integration.
• This project intends to anticipate a big trend that is to bring the features of SDN to access broadband.

Features

• Integration with:
  • VOLTHA (Virtual OLT Hardware Abstraction): An open source project to create a hardware abstraction for broadband access equipment. It supports the principle of multi-vendor, disaggregated, “any broadband access as a service” for the Central Office. VOLTHA currently provides a common, vendor agnostic, GPON control and management system, for a set of white-box and vendor-specific PON hardware devices. With the upcoming introduction of access Technology Profiles, VOLTHA will support other access technologies like EPON, NG-PON2 and G.Fast as well. On its northbound interface, VOLTHA abstracts the PON network to appear as a programmable Ethernet switch to an SDN controller. On its southbound side, VOLTHA communicates with PON hardware devices using vendor-specific protocols through OLT and ONU adapters.
  • ONOS: The only SDN controller platform that supports the transition from legacy “brown field” networks to SDN “green field” networks. This enables exciting new capabilities, and disruptive deployment and operational cost points for network operators. ONOS is the only open source controller providing:
    • Scalability
    • High performance
    • Resiliency
    • Legacy device support
    • Next-generation device support
  • TRELLIS: Is the leading open-source SDN based, multi-purpose L2/L3 spine-leaf switching fabric for data-center (DC) networking. Leveraging the ONOS Controller, Trellis creates a non-blocking fabric for data centers using white box switching hardware and open source software. Unlike traditional networking approaches, the fabric itself does not run a control protocol (such as BGP, OSPF or RSTP). Instead, all the intelligence is moved into applications running on the clustered ONOS controller. In this way the fabric switches can be simplified, the entire fabric can be optimized by leveraging a holistic view of all activity, and new features and functionality can be deployed without upgrading the switches.

Oriented Study

Write here, the study plane and the references.

Phase II - Teaching

Content

• GPON - GigaBit Passive Optical Networks
• SDN - Software Defined Networking

Presentation

• Arquivo:SDA - Apresentação GPON - Raoni - v2.pdf
• Arquivo:Presentation SDN SDA NFV.pdf

Metodology

Describe the metodologies.

Phase III - Example of Business Case

Business Case

    Descrever um exemplo de negócio que permita avaliar a solução comercialmente

Lei do Bem

• Projeto possui algum elemento tecnologicamente novo ou inovador?

Elemento tecnologicamente novo ou inovador pode ser entendimento como o avanço tecnológico pretendido pelo projeto, ou a hipótese que está sendo testada

• Projeto possui barreira ou desafio tecnológico superável?

Barreira ou desafio tecnológico superável pode ser entendido como aquilo que dificulta o atingimento do avanço tecnológico pretendido, ou dificulta a comprovação da hipótese

• Projeto utiliza metodologia/método para superação da barreira ou desafio tecnológico?

Metodologia/método para superação da barreira ou desafio tecnológico pode ser entendido como aqueles atividades que foram realizadas para superação da barreira ou do desafio tecnológico existente no projeto

• Projeto é desenvolvido em parceira com alguma instituição acadêmica, ICT ou startup?

Se sim, o desenvolvimento tecnológico é executado por associado ou por alguma empresa terceira? qual o nome da empresa? 
Anexar cópia do contrato

Phase IV - Prototype oriented to the business

Scope

To install, configure, learn and to aplly techniques to implement the SEBA platform

Product Backlog

Describe the requisites

PoC

Proof of Concept

Technical Details

• The SEBA project delivers a set of software components specified in the high-level architecture, including but not necessarily limited to NEM/Edge Cloud Orchestrator, SDN controller, Access Node (AN) driver, Aggregation & Service Edge (ASG) driver.
• The hardware from vendors may also include embedded software for controlling, monitoring and abstracting low level functions of the hardware, including BIOS, firmware, board support drivers and board management controllers (BMCs).

SEBA Service Layer

• BNG
  • The BNG (Broadband Network Gateway) is a key component in fixed broadband access networks. It resides at the demarcation point between the access network (usually based on L2 tunnels) and the routed IP/MPLS network. The BNG provides per-subscriber services and is the highest-tier network element that has the full per-subscriber context. Beyond this point, traffic can be correlated to a subscriber using the IP address, but the complete view is gone. The functional requirements on BNG types are described by the Broadband Forum (BBF, TR-178 and related documents). The core functions of a BNG at the access side and towards the core, but not limited to, are:
    • Aggregation of L2 access tunnels / VLANs / MPLS PWs
    • Termination of network attachment (PPPoE or IPoE tunnels), authentication, (dynamic) policy enforcement, AAA client
    • Tunnel switching and termination (e.g., L2TP LAC)
    • Traffic filtering and shaping
    • Lawful interception
    • Anti-Spoofing
    • Split horizon rules
    • Per-subscriber OAM (e.g. using keepalives)
    • Accounting
  • The BNG also acts as a router as it is part of the IP core network of the service provider. This covers, amongst others, the following functions:
    • Routing protocols (IGPs, EGPs)
    • MPLS control and user planes
  • The BNG directly interfaces with Policy control systems and AAA services.
  • In SEBA, there are multiple ways to deal with the required BNG functionality:
    • a) Serve an external BNG. In this case, SEBA acts as smart aggregation network
    • b) Embed the BNG as part of the POD, either as PNF or VNF
    • c) Decompose the BNG into Service Edge (SE) and Router and deploy as PNF or VNF with the PNF possibly being embedded in the AN or ASG. While the first two options basically represent state-of-the art thinking and keep existing centralized functionality in closed systems, option
    • c) goes beyond.

• Network Edge Mediator (NEM)
  • The Network Edge Mediator (NEM) serves as the mediation layer between the edge/access system and the service provider backend and global automation frameworks. NEM will provide the interfaces and components to support FCAPS functionalities required by the service provider for managing the access network components and broadband service subscribers the SEBA POD is designed to offer and support. A variety of operator OSS/BSS and global orchestration frameworks can be integrated northbound for specific deployment needs.

• SEBA NBI Client
  • The SEBA NorthBound Interface (NBI) Client provides an application layer for management interfaces between the Carrier Automation Platform and NEM. The SEBA NBI client is tightly coupled with the Carrier Automation Platform and so is specific to the Service Provider.

• SDN Control
  • SDN comes with three major capabilities:
    • A means to take control functions out of a dedicated box and centralize them and create applications for such purposes
    • A means to dynamically program data paths through the network
    • A means to directly program packet processing on a chipset The first two play a key role when steering subscriber traffic. The last one enables programming user plane packet processing for a service edge onto programmable silicon. When looking at a customer / CPE attachment process, there are two major stages
    • Stage 1: Device Attachment and Recognition
    • Stage 2: Subscriber Session Establishment

• Aggregation and Service Gateway (ASG)
  • Aggregation and Service Gateway (ASG) devices (switches) support Layer 2 or Layer 3 network aggregation, switching, and routing of data plane, control plane and management network connectivity within the POD as well as to external data networks, and supports Service Edge/BNG capabilities. There may be one or more ASG devices, and setups as switching fabric, depending upon the implementation.

• AN Driver
  • The AN Driver shall be a collection of loosely coupled services which provide an abstract interface from the SDN controller to target device hardware. Different AN drivers can support many technology types such as PON, XGSPON, NG-PON2, Gfast, or DOCSIS.

• ASG Driver
  • The ASG Driver provides the management and control functions for the ASG devices. Functions for user plane aggregation include create, delete, update and retrieve L2 or L3 connections between access ports and uplink ports, and to monitor these connections. Functions for management control plane connectivity include (as applicable) to create, delete, update and retrieve management and control paths between ASG devices and compute servers, between certain ANs and compute servers, and from ASG devices to external BNGs or routers.

• Access Nodes (AN)
  • The Access Nodes will be a specific implementation the broadband access technology, such as PON technology. Vendors can produce AN boxes providing drivers to interface the required adapter. White box ANs based on industry standard chipsets are used. Drivers provide a bridge between ONF TS-100: SDN Enabled Broadband Access (SEBA) hardware supplied SDKs (software development kits) and the required adapter.

• Profiles
  • A Technology Profile (TP) helps to define a subscriber service. It contains AN specific parameters specific to a technology such as GPON, XGS-PON, NGPON2, EPON, future PON technologies, DOCSIS, Fixed Wireless, Ethernet, xDSL etc. Thus, the profile is specific to the technology. A device adapter interprets the technology profile. Multiple technology profiles can be defined for a specified technology type. These profiles define the service level characteristics. A residential service could use a weighted 4 queue model while a business service could require a strict priority 8 queue model.

• Access Technology - PON
  • SEBA is expected to support various kinds of PON-related technology (e.g. GPON, XGS-PON, EPON, Gfast etc..) and physical devices. In this architecture, these PON specific features and devices (i.e. OLT/ONUs) are abstracted by AN Driver into a pseudo-Ethernet switch whose ports ONF TS-100: SDN Enabled Broadband Access (SEBA) correspond to ONU-UNIs and OLT-NNIs. This abstraction provides operators with various options to deploy PONs that have different equipment structures while managing them in a common SDN architecture. For instance, it is possible to use the both types of OLT: Box-type OLT (refer to Figure 1, “High Level Target Architecture”) and pluggable module-type OLT (refer to Figure 4). In the latter case, the control messages sent from AN Driver to OLT go through ASG, while the messages are directly sent to OLT in the former case. It is also possible to run a TC (Time Critical) functions (e.g. DBA (Dynamic Bandwidth Allocation) function) apart from hardware (refer to Figure (right) instead of running these functions inside the hardware (refer to Figure (left)). In any case, the PON-specific features are managed under AN Driver.

Options for PON-OLT architecture

(Left) Single H/W-type PON-OLT architecture. (Right) Functional decomposition-type PON-OLT architecture.|

SEBA POD Management

• Areas of management
  • POD Management
  • OLT Management
  • ONT Management
  • Profile Management
  • Service Provisioning
  • Status Reporting
  • Alarm Management
  • Performance Monitoring

• POD Management
  • Manage hardware life cycle for common hardware components, fabric, compute
  • Provide inventory information for common hardware component
  • Life cycle manage software components
  • Download and manage software upgrades for SEBA, NEM, ONOS, ONOS Apps, and VOLTHA components
  • Provide support for add-on components to be managed (Local OSAM, Legacy Management Driver, Local Adapter e.g.)
  • Monitor common hardware resources
  • Provide detail views on CPU utilization, component states, POD status, Container status

• OLT Management
  • Managing subscriber services in the POD
  • Assign a descriptive identifier (CLLI e.g.) to the abstract OLT
  • Retrieve OLT hardware inventory information
  • Manage OLT software and upgrades
  • Reset OLT hardware
  • Backup and Restore Configuration information (OLT, ONT, Subscriber) for the OLT
  • Delete OLT
  • Run OLT hardware diagnostics
  • Retrieve inventory information for SFP devices plugged into OLT ports
  • Provide a summary Health status for the OLT

• ONT Management
  • Assign ONT to specific OLT port and assigned ONT number via serial number
  • Map upstream ONT identifications (OLT CLLI ONT port) to dynamic VOLTHA assignments
  • Retrieve ONT hardware inventory information
  • Manage ONT software and upgrade
  • Reset ONT hardware
  • Manage associated ONT database configurations
  • Delete ONT hardware
  • Run available ONT diagnostics and retrieve result
  • Retrieve inventory information for SFP device plugged into the ONT
  • Disable the ONT
  • Manage the ONT UNI port
  • Reset ONT UNI
  • Disable ONT UNI

• Service Type Management
  • Create a new service type
    • Name – Identifier of the service type, i.e. Residential Service, Business Service
  • Service Type provide a link between service ordering and VOLTHA specific implementation details
  • Allows Northbound systems to be independent of VOLTHA implementation details such as Technology Type and Table ID
  • Defined externally per operator as required by service details
  • Retrieve Service Types

• Technology Profile Management
  • Create a new or configure an existing technology profile
    • New Profile ID or Existing Profile ID
      • Technology Type–i.e. XGS, G.fast, ...
      • Data Block of key value pair
    • Service Type (optional)
      • This command could change the selected profile for existing service by mapping a new profile ID to an existing service type. The result must be the push of the new profile information to the subscribers.
      • Technology profiles without a service type set will not be usable from the service APIs
  • Retrieve Technology Profiles
    • Technology Type

• Speed Profile Management
  • Create a new or configure an existing speed profile
    • Name
    • Technology Type
    • Direction (Upstream or Downstream)
    • Data Block of key value pairs
      • PON adapter types would specify the specific metering parameters required to provide the required service
      • Future technology types
  • Retrieve Speed Profiles
    • Technology Type

Researchers

• Ana Paula Fernandes
• Aymen Ghannouchi
• Bruno Rodrigues Rabelo Resende
• Luiz Cláudio Theodoro
• Raoni Exaltação Masson
• Willian Santos Silva