Exibir código-fonte para SEBA: SDN Enabled Broadband Access

= Phase I - Study  =

<br> 

== Title  ==

* SEBA - SDN Enabled Broadband Access

<br> 

== Objective  ==

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

<br> 

== Concepts  ==

<br> 

* 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.
<br> 

== Features  ==

<br> 
 
* 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.
<br>

== Oriented Study  ==

<br> 

 Write here, the study plane and the references.
<br>

= Phase II - Teaching  =

<br> 

== Content  ==
 
* GPON - GigaBit Passive Optical Networks
* SDN - Software Defined Networking
<br> 

== Presentation  ==

* [[Arquivo:SDA - Apresentação GPON - Raoni - v2.pdf]]
* [[Arquivo:Presentation SDN_SDA_NFV.pdf]]

<br>

== Metodology ==
<br>

 Describe the metodologies.
<br>

= Phase III - Example of Business Case<br>  =

<br> 

== Benefits to the owner  ==



<br> 

<br>

== Benefits to the user  ==


<br>

== Drivers  ==

<br><br>

== Business Models  ==

== Business Case  ==

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

<br>

== Lei do Bem ==
<br>

* 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
<br>

* 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
<br>

* 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
<br>

* 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
<br>

= Phase IV - Prototype oriented to the business  =

<br> 

== Scope  ==
<br> 

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

<br>

== Product Backlog  ==

<br> 

 Describe the requisites
<br>

== Technical Details  ==
<br> 
* 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 ===
<br>


[[Arquivo:SEBA-Architecture.png|center|600px]] 


* 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.
<br>

* 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.
<br>

* 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.
<br>

* 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
<br>

* 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.
<br>

* 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.
<br>

* 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.
<br>

* 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.
<br>

* 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.
<br>

* 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
[[Arquivo:SEBA-PON.png|center|600px]]
 (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 
<br> 

* 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
<br>

* 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


* Service Management
** Create a new or configure an existing service
*** Abstract OLT Name (CLLI) (as configured with OLT management)
**** This is used to identify specific VOLTHA device IDs and the adapter to be used
**** Pre-provisioning of services will be allowed thus dynamic OLT may not be assigned at time of service order
*** Slot
*** OLT Port
*** ONT Number (as configured with ONT management)
**** This is used to tie the northbound ONT numbering to the dynamic numbering of the VOLTHA
**** Pre-provisioning of services will be allowed thus dynamic ONT may not be assigned at time of service order
*** ONT Port
*** SVLAN
*** CVLAN
** Create a new or configure an existing service
*** Service Type
**** Service type plus technology type will specify technology profile to select
*** Downstream Speed Profile
**** Speed profile plus technology type will specify meters or additional configuration
*** Upstream Speed Profile
**** Speed profile plus technology type will specify meters or additional configuration
** Retrieve Subscriber Services
** Under consideration
** Authentication String format (optional)
**** Format of identification string to be applied to upstream authentication messages (i.e. RADIUS)
*** DHCP option 82 port identifier format (optional)
<br>

== PoC  ==

<br> 

* Resources (Equipment)
** Flex POD1 which has one OLT/4ONUs(need to update this  POD to have only one fabric switch to which OLT and BNG is connected to)
** Other PODs that do not have OLT/ONUs - Flex -ONF POD, QCT POD1
** Request for one more OLT so that QA can test more scenarios
** Test setup (at Flex Labs) used by ONF QA is shown below 
<br>

* Configuring SiaB:
** The default configuration of SiaB incorporates an emulated OLT/ONU provided by Ponsim and an emulated AGG switch provided by Mininet. 
** Mininet is also configured with a host that stands in as the BNG and runs a DHCP server. 
** The Ponsim setup installs a single OLT, ONU, and RG.
** The RG is able to authenticate itself via 802.1x, run dhclient to get an IP address from the DHCP server in Mininet, and finally ping the BNG
<br>

* Interface SiaB:
** Subscriber authentication
** Show Workflow driver service instances
*** 	Authentication sate
***	Backend Status
***	Dhcp state
***	ONU state
** Run DHCP cliente
<br>

* Results:
** SiaB is a real SEBA pod with virtual hardware
** Good on-rampo for the community
*** About half the questions os Slack are in contect os SiaB
*** SiaB is doubling SEBAś popularitu
** Comunity contributions to SiaB
*** USe real openflow switch + server instedad of mininet
*** supoprt for multimpes ONUs / RGs 
<br>

* Links:
** https://guide.opencord.org/profiles/seba/siab.html
** https://blog.zufardhiyaulhaq.com/seba-tutorial/
** https://www.youtube.com/watch?v=8MpH9YkXmxQ


<br>

== Tests Worksheet ==

* Workflow high-level
:: 1. ONT discovered bottom-up
:: 2. If ONT serial number is not allowed or unknown (i.e it has NOT been provisioned by OSS), disable the ONT; generate an event to external OSS that an ONT has been discovered but not yet provisioned. If the ONU’s physical location does not match the location specified for the ONU by the OSS, disable the ONT and generate an event to external OSS that an ONT with valid serial number has been discovered but at the wrong location.
:: 3. When OSS provisions the ONT, re-enable it & program 802.1x flow - UNI port(s) will be UP
:: 4. Note that RG authentication and DHCP cannot proceed here without subscriber/ service-binding provisioning by external OSS. Assume subscriber provisioning happens from external OSS
:: 5. 802.1x EAPOL message comes from RG, and ONOS AAA app adds options and sends to radius server. Options are pulled from Sadis/NEM  - NASPortId is a required here
:: 6. If RG authentication fails, allow it to keep trying (in the future consider redirection to captive / self-help portal). DHCP should not succeed since RG authentication has failed
:: 7. If RG authentication succeeds, ONOS AAA app notifies via an event on the kafka bus that authentication has succeeded
:: 8. NEM can listen for the event, and trigger the programming of the data plane in both AGG switch and the PON for the subscriber’s C and S vlan info and the DHCP trap flows. DHCP process can start
:: 9. DHCP L2 relay -> add option 82, learn public IP address, forward via dataplane to external DHCP server
:: 10. If RG is disconnected from UNI port, force authentication again (even if subscriber/service-binding has been provisioned by OSS). Upon reconnection  to UNI port, RG must re-authenticate before DHCP/other-traffic can flow on the provisioned VLANs.
<br>

* Based on AT&T:
** With ONUs in the `whitelist` (with couple ONUs in the list) 
*** API to push ONU whitelist?
*** With a matching ONU in the whitelist  and validate that the  ONU is shown as `enabled`
*** With a discovered ONU that is not contained in the whitelist or the slot/pon-port information is incorrect for the ONU device.  
*** A discovered ONU which has been disabled, can be re-enabled by addition to whitelist
*** An enabled ONU can be disabled by removal from whitelist
*** If an ONU is added to the whitelist (and has service), then removed, then added back its service recovers
** Pre-provisioning of a subscriber into NEM
*** SubscriberID, S-Tag & C-Tag, NASportId, circuitId, subscriber description
*** Without discovered ONU
*** With discovered but invalid ONU
*** With valid ONU
*** With 2 ONUs on the same OLT with different S-Tag
** RG authentication after the ONU gets into enabled state
*** Send EAPOL message from the subscriber
*** RG authentication fails if subscriber has not been provisioned
*** RG authentication passes if subscriber has been provisioned
*** RG continues to attempt authentication
** Agg switch and NEM-AGG triggers
*** Crossconnect-service can add BNG mapping to S-VLAN [Low]
*** Crossconnect-service can add BNG mapping to ‘any’ vlan
*** After subscriber is provisioned
*** After multiple-subscribers on same OLT are provisioned with same S-VLAN, there is only 1 cross-connect in AGG switch
*** That after multiple-subscribers on same OLT are provisioned with different S-VLAN, there are multiple cross-connects in AGG switch
*** After multiple-subscribers on different OLTs are provisioned with different S-VLAN, there are corresponding cross-connects in AGG switch
*** After a subscriber is removed, the crossconnect exists if there are other subscribers with the same S-VLAN
*** After all the subscribers with the same S-VLAN are removed, then the cross-connect is also removed
*** Special crossconnects can be created - eg vlan 409
** DHCP: 
*** DHCP fails if RG has not been authenticated
*** DHCP succeeds if RG has been authenticated
** Dataplane Failure Scenarios (needs to be fleshed out)
*** Reboot RG, ONU, OLT and Fabric Switch (Leaf attached to OLT)
*** Bring down UNI port and back up (unplug ONU LAN port and plug it back), equivalent to disconnect RG from ONU and reconnect it
*** Bring down ONU fiber and back up (unplug ONU fiber and plug it back)
*** Bring down PON port and back up (unplug PON fiber and plug it back)
*** Bring down NNI port and back up (unplug uplink cable and plug it back)
** Control plane failure scenarios
*** VOLTHA, ONOS and NEM reboots
** Alarm generations?  
** Verification steps in  existing testcases  for `onos-fabric` `onos-voltha` whenever configurations are pushed into XOS.  - LOW
** More test scenarios for subscriber `status` changes
** Soak and Stability Tests
*** Provision subscribers and leave the POD to run for couple weeks(atleast two weeks to start with) and perform tests to validate the stability of the containers. 
*** Soak test

= Schedule  =

<br>

[[Arquivo:P&D SDA - Cronograma.pdf]]

= History  =

<br> 

<br>

= Researchers  =
* Ana Paula Fernandes
* Aymen Ghannouchi
* Bruno Rodrigues Rabelo Resende
* Luiz Cláudio Theodoro
* Pedro Henrique Quintino Garcia
* Raoni Exaltação Masson
* Willian Santos Silva
<br>