FTTH implementation

Overview

This is the coding guideline for FTTH + DSL + WiFi implementation in NMS Prime.

The problem

TR-69 is a provisioning protocol for CPE's only. This implies there is no standardised way of how to set Modem speed rates (e.g. Downstream/Upstream rate 100MBit/s to 10MBit/s). Many operator address this by using a quick-and-dirty method of manually setting internet speeds at the OLT directly via CLI. The next logical step is easy but also dirty: using the CRM to somehow "connect via telnet or SSH and push the required speed rates via CLI (or better SNMP)". This will work but it comes at a high price, imagine:

disadvantages for setting the modem speed via CLI:

1. Every network architecture (GPON, Active Ethernet, DSL, WiFi) requires a different provisioning implementation
2. vendor specific CLI commands (or SNMP MIBs) makes life hard for a generic implementation approach – switching OLT vendor will cause pain!
3. ONU –> OLT port mapping required
   support team needs knowledge of FTTH connection circuits (ineffective/bad workflow!)
4. potential config race conditions / hazards
   Assume you are connected via SSH towards your OLT, while the provisionig system pushes also config changes via telnet/SSH. This could lead to race conditions, especially while saving configs.

Progress

Development Progress. Feel free to follow us on github.

Definitions

Naming Conventions

The solution:

The solution is PPPoE with the following architecture

1. OLT / AE / DSLAM serves all Modems with a default profile of maximum speed, e.g. 1GBit/s down and upstream
2. a BRAS / BNG router with PPPoE is used for traffic shaping and bandwidth monitoring
3. customer devices require to use PPPoE protocol for dial-in
4. Switches can be configured to only allow forwarding of PPPoE traffic

Dial-in Workflow

1. PPPoE connection establishment
2. PPPoE server forwards user/psw to RADIUS server
3. RADIUS server checks credentials and looks-up RADIUS attributes of customer in database
4. Establish PPPoE tunnel

5. / 6. / 8. / 9. Accounting related (optional for bandwidth monitoring)

Architecture

Explanation: 1 to 4 see Dial-in Workflow

Workflow Discussion for Multiple BRAS

Ole Ernst + Torsten Schmidt + Robert Worschitz (Unlicensed)on 28.5.19

Considerations on

• BRAS routing aggregation(s)
• Dynamic IP update: RADIUS –> DDNS
  Robert Worschitz (Unlicensed) : solution for core routing is OSPF (also working with 1M devices)
  OSPF will also solve BRAS outages (this is not working for route aggregation)