Distinguishing between ONUs in RG Mode versus Bridged Mode

[Shaun Missett]

Following up on the VOLTHA Scrum call today Oct 09, 2018:

A MIB upload may show several interface types:

PPTP

VEIP

POTS

etc

How does the ONU adapter decide how to configures the ONU - is it RG mode or not.?

Comments welcome:

Shaun

[Matt Jeanneret]

I have not seen any indication in MIB data that explicitly says an ONU is RG mode or Bridged mode.   What i have seen is UNI of one type or another (PPTP vs VEIP) existing which implies this.    The UNI instance ID is cross referenced in the PPTP, VEIP, or POTS  list to figure out which kind it is.

The logic i'm working on looks basically like this.  Currently no support for POTS UNI, but it would be added here when the time comes:

                for entity_id in uni_list:      

                    ...
                    if entity_id in pptp_list:
                        self._add_uni_port(entity_id, uni_type=UniType.PPTP)
                    elif entity_id in veip_list:
                        self._add_uni_port(entity_id, uni_type=UniType.VEIP)
                    else:
                        self.log.warn("unable-to-find-uni-in-pptp-or-veip", key=entity_id, value=uni_value)

Below is an example from an ONU with a built in RG (or RG with a built in ONU?) that uses VEIP UNI types and has no PPTP. 

Start with the list of *all* UNI ports, ME class id 264. There is no indication of what type it is in this list.   This is the "uni_list" referred to above.  The attribute  non-omci-management id gives a clue that this onu has an rg router/bridge built in:

> omci debug --dump 264
Dump UniG in MDM
  <UniG instance="1">
    <ManagedEntityId>769</ManagedEntityId>
    <Deprecated>0</Deprecated>
    <AdministrativeState>0</AdministrativeState>
    <ManagementCapability>0</ManagementCapability>
    <NonOmciManagementId>0</NonOmciManagementId>
    <RelayAgentOptions>0</RelayAgentOptions>
  </UniG>
  <UniG instance="2">
    <ManagedEntityId>770</ManagedEntityId>
    <Deprecated>0</Deprecated>
    <AdministrativeState>0</AdministrativeState>
    <ManagementCapability>0</ManagementCapability>
    <NonOmciManagementId>0</NonOmciManagementId>
    <RelayAgentOptions>0</RelayAgentOptions>
  </UniG>
  <UniG instance="3">
    <ManagedEntityId>1025</ManagedEntityId>
    <Deprecated>0</Deprecated>
    <AdministrativeState>0</AdministrativeState>
    <ManagementCapability>0</ManagementCapability>
    <NonOmciManagementId>1025</NonOmciManagementId>
    <RelayAgentOptions>0</RelayAgentOptions>
  </UniG>
</DslCpeConfig>

From there for each entity id above check which type of uni it is by finding the matching entity id for the supported types.    Check for PPTP UNI, ME class 11:

 

> omci debug --dump 11
Dump PptpEthernetUni in MDM
</DslCpeConfig>

Which in this case there are none.   In every other onu we have developed/tested against, this list would map to the 4 or 5 LAN ports on the ONU.   In this case the LAN ports are *not* UNI ports, so the list is empty.

Then check for VEIP UNI, ME class 329.  This is the new work:

 > omci debug --dump 329
Dump VirtualEthernetInterfacePoint in MDM
  <VirtualEthernetInterfacePoint instance="1">
    <ManagedEntityId>1025</ManagedEntityId>
    <AdministrativeState>0</AdministrativeState>
    <OperationalState>0</OperationalState>
    <InterDomainName>00</InterDomainName>
    <TcpUdpPointer>65535</TcpUdpPointer>
    <IanaAssignedPort>65535</IanaAssignedPort>
  </VirtualEthernetInterfacePoint>
</DslCpeConfig>

Which in this case there is one.   This is the UNI that is then used for bridge port construction, extended vlan config, etc.  

For completeness below are the other two, which are POTS UNI, class id 53:

> omci debug --dump 53
Dump PptpPotsUni in MDM
  <PptpPotsUni instance="1">
    <ManagedEntityId>769</ManagedEntityId>
    <AdministrativeState>0</AdministrativeState>
    <InterworkingTpPointer>0</InterworkingTpPointer>
    <AlarmReportingControl>FALSE</AlarmReportingControl>
    <AlarmReportingControlInterval>0</AlarmReportingControlInterval>
    <Impedance>0</Impedance>
    <TransmissionPath>0</TransmissionPath>
    <RxGain>0</RxGain>
    <TxGain>0</TxGain>
    <OperationalState>1</OperationalState>
    <HookState>0</HookState>
    <PotsHoldoverTime>0</PotsHoldoverTime>
    <NominalFeedVoltage>0</NominalFeedVoltage>
    <LossOfSoftswitch>0</LossOfSoftswitch>
  </PptpPotsUni>
  <PptpPotsUni instance="2">
    <ManagedEntityId>770</ManagedEntityId>
    <AdministrativeState>0</AdministrativeState>
    <InterworkingTpPointer>0</InterworkingTpPointer>
    <AlarmReportingControl>FALSE</AlarmReportingControl>
    <AlarmReportingControlInterval>0</AlarmReportingControlInterval>
    <Impedance>0</Impedance>
    <TransmissionPath>0</TransmissionPath>
    <RxGain>0</RxGain>
    <TxGain>0</TxGain>
    <OperationalState>1</OperationalState>
    <HookState>0</HookState>
    <PotsHoldoverTime>0</PotsHoldoverTime>
    <NominalFeedVoltage>0</NominalFeedVoltage>
    <LossOfSoftswitch>0</LossOfSoftswitch>
  </PptpPotsUni>
</DslCpeConfig>

-matt

--
You received this message because you are subscribed to the Google Groups "VOLTHA Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to voltha-discus...@opencord.org.
To post to this group, send email to voltha-...@opencord.org.
Visit this group at https://groups.google.com/a/opencord.org/group/voltha-discuss/.
To view this discussion on the web visit https://groups.google.com/a/opencord.org/d/msgid/voltha-discuss/CA%2BYfzecO1WuA6iCZ8btWMrehvyN3CshzL6buce9LbwQitrbSog%40mail.gmail.com.
For more options, visit https://groups.google.com/a/opencord.org/d/optout.

[Shaun Missett]

Thanks Matt,

Makes sense to me.

Shaun

[Matevz Langus]

Hi,

Iskratel ONUs can work in mixed mode, for example 2 Ethernet ports in PPTP mode, 2 in RG mode. We never thought anybody would use this, but there are such deployments in the field.

Regards,

Matevz Langus

To view this discussion on the web visit https://groups.google.com/a/opencord.org/d/msgid/voltha-discuss/CA%2BYfzefsmfkOVNwG4%3DCOSA_uqXK3oh0hVE-eo9aXirHgaYbz8w%40mail.gmail.com.

[Shaun Missett]

Thanks Matevz,

If we use profiles for ONU’s the ability to control UNI RG group membership may be a candidate attribute. There seem to be a few attributes which cannot be derived from the ONU MIB Sync’d MEs themselves.

Shaun