Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Overview

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

Info

This is the hottest topic regarding our actual work. The space will change on a daily basis.

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

First FTTH implementation was finished at Dec 2019 and is included in release 2.5.0

Development Progress. Feel free to follow us on github.

Drawio
bordertrue
viewerToolbartrue
fitWindowfalse
diagramNameprogress
simpleViewerfalse
width400
diagramWidth401
revision23

Definitions

ProtocolUsageProvisioning of
TR-69protocol for remote management of customer-premises equipment (CPEs)CPEs only!
PPPoEThe Point-to-Point Protocol over Ethernet (PPPoE) is a network protocol for encapsulating PPP frames inside Ethernet frames. (wikipedia)speed provisioning and monitoring for any device (DSL, GPON, AE, ..) of used bandwidths

Naming Conventions

shortcutusage
AEActive Ethernet

OLT

ONU

Optical Line Terminal

Optical Network Unit


DSLAMDSL Head End


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

Drawio
bordertrue
viewerToolbartrue
fitWindowfalse
diagramNamepppoe-dia
simpleViewerfalse
width600
diagramWidth721
revision6

Explanation: 1 to 4 see Dial-in Workflow


Workflow Discussion for Multiple BRAS

Ole Ernst + Torsten SchmidtRobert 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)


The work

now NMS PRIME comes into play. For a clean implementation we need to focus on:


Implementation StepsDescriptionGithubAssignedstate

1. Access Technology Provisioning Workflow

Design thoughts..

DONE

2. FreeRADIUS implementation

Connecting NMS PRIME with FreeRADIUS server.#684NMS Prime TeamTODO

3. TR-69 implementation

Implementing a free and open source TR-69 server into NMS PRIME#686External?TODO

4. Monitoring

Monitoring of special devices values, like temperature, optical levels, ...

TODO