BLOG

VEIP vs EthUni - unified provisioning

VEIP vs EthUni - unified provisioning

Modern FTTH networks are build not only to sell own services, but also - or maybe above all - for wholesale services.
 
There are 2 groups/kinds of terminals that can terminate FTTH Network (terminate = have PON port on board).
 
  1. SFU (Single Family Unit) - simple L2 device with Ethernet port. This port can be 1GBaseT, 2.5GBaseT or 10GBaseT - multigig. All depends on particular hardware. This is the most popular type of device when service is delivered to a service provider, that delivers own router for subscriber. So we have 2 box solution.
  2. HGU (Home Gateway Unit) - devices that includes router, wifi and additional voice and ethernet ports.
From OLT/OMCI perspective default versions of provisioning are:
 
  1. for SFU - PPtP - VLAN service is delivered to LAN port (EthernetUNI), and provisioning utilises pure OMCI communication. Our endpoint is called EthUNI.
  2. for HGU - all services are created on subsrcriber's router. To simplify this logic - let's say that this is a linux host connected via LAN card to ethernet switch.
    But, all of that happens within same silicon chipset, there is no dedicated external port, only internal link (on silicon).
    Our endpoint is called VEIP (Virtual Ethernet Interface Point).
  3. Well, there is also an option for so called Hybrid Mode (SFU and HGU in same time) - but this is less popular in large scale solutions, rather for smaller ISPs. It is very flexible, but makes provisioning more complex.
For large telco networks - the simpler, the better.
 

Is it possible to unify it? To use same provisioning method for SFU and HGU?

  1. HGU as SFU. Router from OMCI perspective can present itself, as device with 1x LAN port only device. As simple SFU.
    To get it - a OMCI stack in ONT must be modified. Long story short - we inform OLT that we do have "physical" ethernet interface. Internally - we redirect all traffic forwarded to that "physical" ethernet port - to same endpoint, as used when we are VEIP device.
    Simple? Yes, and it works.
    Disadvantages? HGU firmware should have predefined WAN at least for TR069 service, and predefined TR069 parameters.
    This can be done by proper firmware preparation. Dedicated firmware can be uploaded via OMCI.
  2. SFU as HGU.
Lets go back to our SFU vs HGU - from OLT perspective it is large difference - we have to use different profiles for SFUs and HGUs.
 

Examples of profiles from DASAN OLT

Regular SFU EthUni provisioning:
!
traffic-profile LEOX_ETHUNI_VLAN11 create
mgmt-mode uni eth 1 omci
tcont 1
gemport 1/1
dba-profile DBA
mapper 1
gemport count 1
bridge 1
ani mapper 1
uni eth 1
extended-vlan-tagging-operation VEIP_TAGGED_11
apply
!
 
VEIP Emulated on SFU provisioning:
!
traffic-profile LEOX_VEIP_EMULATION create
tcont 1
gemport 1/1
dba-profile DBA
mapper 1
gemport count 1
bridge 1
ani mapper 1
uni virtual-eth 1
extended-vlan-tagging-operation VEIP_TAGGED_11
apply
!
 
Additional VLAN handling related information:
!
extended-vlan-tagging-operation VEIP_TAGGED_11 create
downstream-mode enable
single-tagged-frame 1
filter inner vid 11 cos any tpid any
treat remove single
treat inner vid 11 cos copy-inner tpid copy-inner
apply
!
 
As you can see - ME171 - Extended Vlan Tagging Operations profile used in both case is exactly same.
 

Examples of profiles from Nokia OLT

Regular SFU EthUni provisioning:
 
sw-ver-act is V4.4.1L18rc7 - this is regular firmware version
 nokia_regular_sfu_ethuni
 typ:isadmin># info configure equipment ont interface 1/1/4/2/1
 configure equipment ont
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 echo "equipment"
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 interface 1/1/4/2/1 sw-ver-pland disabled
 sernum LEOX:A2100480
 subslocid WILDCARD
 fec-up disable
 sw-dnload-version disabled
 enable-aes enable
 log-auth-pwd plain:******
 planned-us-rate nominal-line-rate
 admin-state up
 exit
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 typ:isadmin># info configure equipment ont slot 1/1/4/2/1/1
 configure equipment ont
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 echo "equipment"
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 slot 1/1/4/2/1/1 planned-card-type ethernet plndnumdataports 1 plndnumvoiceports 0
 exit
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 typ:isadmin># info configure bridge port 1/1/4/2/1/1/1
 configure bridge
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 echo "bridge"
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 port 1/1/4/2/1/1/1
 max-unicast-mac 5
 vlan-id 3100
 exit
 exit
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 typ:isadmin>#
 
VEIP Emulated on SFU provisioning:
 
sw-ver-act is V4.4.1L18rc7V - this V at the end stands for VEIP emulating firmware version.
 
nokia_veip_emulation
 
Number of slots - in this case is 2. In NOKIA we still have to keep slot number 1 (ethernet type) to enable ethernet port, that by default is disabled.
This is possible to be modified in firmware to be always enabled, but we do not recommend it, as you would loose up/down steering option. However, if just a LAN port flap is needed, this could be done via remote ONT reboot.
LAN port flapping may help to recover DHCP client in RGU (Residental Gateway Unit - customer's router with ethernet WAN) - for that kind of situation, we have a very interesting feature, that will be described in other blog chapter.
 
 typ:isadmin># info configure equipment ont interface 1/1/4/2/1
 configure equipment ont
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 echo "equipment"
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 interface 1/1/4/2/1 sw-ver-pland disabled
 sernum LEOX:A2100480
 subslocid WILDCARD
 fec-up disable
 sw-dnload-version disabled
 enable-aes enable
 log-auth-pwd plain:******
 planned-us-rate nominal-line-rate
 admin-state up
 exit
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 typ:isadmin># info configure equipment ont slot 1/1/4/2/1/14
 configure equipment ont
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 echo "equipment"
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 slot 1/1/4/2/1/14 planned-card-type veip plndnumdataports 1 plndnumvoiceports 0
 exit
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 typ:isadmin># info configure equipment ont slot 1/1/4/2/1/1
 configure equipment ont
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 echo "equipment"
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 slot 1/1/4/2/1/1 planned-card-type ethernet plndnumdataports 1 plndnumvoiceports 0
 exit
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 typ:isadmin># info configure bridge port 1/1/4/2/1/14/1
 configure bridge
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 echo "bridge"
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 port 1/1/4/2/1/14/1
 max-unicast-mac 5
 vlan-id 3100
 exit
 exit
 #------------------------------------------------------------------------------------------------------------------------------------------------------
 typ:isadmin>#
 
So, in both cases - we simplify OLT configuration to only one type of profile, no matter what kind of device is used.
Reverse situation is also possible - HGU may pretend to be SFU, which also seems to be quite commonly used solution.
 
free_consultation
 
Enjoyed this article? Have any questions? Don't hesitate to reach us - contact@leolabs.pl
 
Equipment used for tests:
  • LEOX LXT-010G-D ONT with 2 firmware images with different features;
  • DASAN V5824G OLT;
  • NOKIA ISAM7360 with FWLT-C card;
  • Live telco core network of leon.pl (switching/BNG etc);
  • Dedicated small linux box to simulate RGU.