Proposal - Device Management in VOLTHA

[gcgiri...@gmail.com]

Hello All,

Attached is the proposal for device management in voltha. I haven't really mentioned the fine grained details of the implementation. Request your feedback if you see something is not right in this initial proposal and needs a change/enhanced. We can as well discuss the same in the forthcoming TST meetings.

Thanks & Regards,

Girish

[GS Ying]

Not to be picky - Is OLT enable/disable the same as PON port enable/disable?  I hope not.  Then we need to add PON port enable/disable.

Thanks

Shawn

--
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-discuss+unsubscribe@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/2ac3ee91-9c4a-474b-bf9f-3fb66b086683%40opencord.org.
For more options, visit https://groups.google.com/a/opencord.org/d/optout.

[GS Ying]

Girish - the page mentioned the architecture changes in order to support the device manager.  are ALL the blue blocks need to be changed?  I don't think any block is new.  

Thanks

Shawn

[Amit Ghosh]

Hi Shawn,

Yes the OLT enable/disable is for the entire device and not the specific PON ports. I think the enable/disable for the individual PON ports should be covered in the PON Configuration epic.

I created an user story VOL-204:Provide support for enabling/disabling the PON ports of an OLT in PON Configration Epic for the same.

Regards,

Amit Ghosh

On Saturday, June 10, 2017 at 3:36:10 AM UTC+5:30, GS Ying wrote:

Not to be picky - Is OLT enable/disable the same as PON port enable/disable?  I hope not.  Then we need to add PON port enable/disable.

Thanks

Shawn

On Fri, Jun 9, 2017 at 10:51 AM, <gcgiri...@gmail.com> wrote:

Hello All,

Attached is the proposal for device management in voltha. I haven't really mentioned the fine grained details of the implementation. Request your feedback if you see something is not right in this initial proposal and needs a change/enhanced. We can as well discuss the same in the forthcoming TST meetings.

Thanks & Regards,

Girish

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

[Amit Ghosh]

Hi Shawn,

Yes we are not proposing any new modules specifically for the Device Management scope that we have. Yes we are proposing changes in the existing blue blocks.

Regards,

Amit Ghosh

On Saturday, June 10, 2017 at 3:43:08 AM UTC+5:30, GS Ying wrote:

Girish - the page mentioned the architecture changes in order to support the device manager.  are ALL the blue blocks need to be changed?  I don't think any block is new.  

Thanks

Shawn

On Fri, Jun 9, 2017 at 3:06 PM, GS Ying <syin...@gmail.com> wrote:

Not to be picky - Is OLT enable/disable the same as PON port enable/disable?  I hope not.  Then we need to add PON port enable/disable.

Thanks

Shawn

On Fri, Jun 9, 2017 at 10:51 AM, <gcgiri...@gmail.com> wrote:

Hello All,

Attached is the proposal for device management in voltha. I haven't really mentioned the fine grained details of the implementation. Request your feedback if you see something is not right in this initial proposal and needs a change/enhanced. We can as well discuss the same in the forthcoming TST meetings.

Thanks & Regards,

Girish

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

[Chip Boling]

For software management, our OLT is a collection of microservices and we currently support a single 'big-bang' release install, but have the capability to do individual installs and patches.

With respect to inventory capabilities, we may want the ability to report multiple versions of software per device.  A few of the initial items to track for any running images might be:

• Service/Component/Patch Name -  To list what service it provides on the device
• Running Version string - Non-empty but most likely vendor specific
  
• Hash / security validation string - Empty/null if not available
• Install date & time- Empty/null if not available
• Image type (running, candidate, startup) - Default type is running if not provided by device

Some devices may be able to store multiple versions of a component, but probably reporting only the latest version (running) and perhaps what version will be running on reboot (startup) would be enough for an initial release.

     - Chip

[L Fang]

Hi Amit/Girish:

A few questions on the proposal:

1.  "Disable ONU" API currently sends ofp.OFPPR_DELETE event to ONOS, and ONOS sets the port to "disabled".  

      When "Enable ONU" API is called, ONOS sets the port to "enabled" and immediately puts ONU into service mode rather than start fresh from EAPOL authentication.  

      Question: how to address this issue in the proposal?

2. If Disable ONU/Enable ONU APIs' current behaviors are correct, then what do we expect "Delete ONU" and "Delete ONT" APIs to do? 

    Currently those two APIs are pretty much just deleting the device objects from VOLTHA database. Shall we expect them to provoke ONOS to re-authenticate ONT subscriber?

3. Shall we consider elevating the ONT port/interface configuration to VOLTHA adapter and expose it to NBI APIs?

Thanks!

Lydia

[Girish Gowdru]

Hi Chip,

Agree to you inputs.

The API to retrieve the SW version on the device will be designed to include the items you mention.

 

Regards,

Girish

--

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/a0339960-eeef-48ee-bfec-a3b3fdf569ae%40opencord.org.

[Amit Ghosh]

Hi Lydia,

Please find my comments inline.

Thanks,

Amit Ghosh

On Monday, June 12, 2017 at 11:44:03 PM UTC+5:30, L Fang wrote:

Hi Amit/Girish:

A few questions on the proposal:

1.  "Disable ONU" API currently sends ofp.OFPPR_DELETE event to ONOS, and ONOS sets the port to "disabled".  

      When "Enable ONU" API is called, ONOS sets the port to "enabled" and immediately puts ONU into service mode rather than start fresh from EAPOL authentication.  

      Question: how to address this issue in the proposal?

         [AG] : My understanding is that "Disable ONU" should not send OFPPR_DELETE, rather it should send MODIFY in case the ONU is already enabled, else do nothing. ONOS OLT app on seeing this modify would remove the filtering rules. When "Enable ONU" is done, it should again send MODIFY is the ONU is in disabled state, else do nothing. ONOS OLT app on seeing this modify would add the filtering rules. 

2. If Disable ONU/Enable ONU APIs' current behaviors are correct, then what do we expect "Delete ONU" and "Delete ONT" APIs to do? 

    Currently those two APIs are pretty much just deleting the device objects from VOLTHA database. Shall we expect them to provoke ONOS to re-authenticate ONT subscriber?

    [AG]: On "Delete ONU", the logical port in voltha should be removed as well as OFPPR_DELETE should be sent to ONOS.

 

 

3. Shall we consider elevating the ONT port/interface configuration to VOLTHA adapter and expose it to NBI APIs?

[AG]: Not sure I understand this, which parameters configuration are we talking about here.

[L Fang]

Hi Amit,

Thanks for your reply!

Currently when we disable ONU, the adapter will remove the UNI port from logical device. As a result, the OFPPR_DELETE message is triggered. Similarly when ONU is enable, the UNI port is added to logical device.

If this is not correct, what do we expect adapter to do when enable/disable device? In logical_device_agent.py, only POST_ADD and POST_REMOVE trigger send_port_change_event.

Thanks,

Lydia

[Girish Gowdru]

Hi Lydia,

When the ONU is disabled, the adapter should not remove the port. It should instead update the port, i.e., call adapter_agent.update_logical_port instead of adapter_agent.delete_logical_port.

 

The adapter_agent.update_logical_port function updates the /logical_devices/{}/ports and this invokes the callback _port_updated in logical_device_agent.py. FYI, the _port_updated function is registered in _port_added function at the time of port creation.  Please look into _port_added for more details where it sends a port_status OF message.

 

Regards,

Girish

 

From: L Fang [mailto:lfan...@gmail.com]
Sent: Wednesday, June 14, 2017 4:42 AM
To: VOLTHA Discuss <voltha-...@opencord.org>
Cc: gcgiri...@gmail.com
Subject: [voltha-discuss] Re: Proposal - Device Management in VOLTHA

 

Hi Amit,

--

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/7bd9f6d5-02cc-4f76-bab6-8ffd6a23e166%40opencord.org.

[L Fang]

Hi Girish,

Thanks for your reply!

In the ponsim_onu.py, it calls self.adapter_agent.delete_logical_port when disabling an ONU. On the same note, in ponsim_olt.py, it calls self.adapter_agent.delete_logical_device when disabling an OLT. So if this is not an expected behavior, the option would be:

- for disabling ONU,  setting port.ofp_port.config = OFPPC_PORT_DOWN or OFPPC_NO_RECV?

- also what to do when disabling OLT?

Regards,

Lydia

To post to this group, send email to voltha...@opencord.org.

[Girish Gowdru]

Hi Lydia,

For disabling the ONU the port.ofp_port.state should be set to OFPPS_LINK_DOWN. Once the ONU is re-enabled, the port.ofp_port.state should be set back to OFPPS_LIVE. The port.ofp_port.config field is usually modified by controller and the switch ideally shouldn’t be modifying it.

 

When the OLT is disabled, the existing behavior in the ponsim_olt adapter seems right to me. This means at the voltha side => the device is disabled, logical device deleted, child devices disabled, all references for the device removed and all ports disabled. At the ONOS end => the entire logical device appears as down.

[X-MARK PATTON]

Is there any state diagrams or sequence diagrams available for the ONT and OLT use cases?

 

Mark

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/SN2PR0801MB637BCE4389396F3A59476CCEEC00%40SN2PR0801MB637.namprd08.prod.outlook.com.

[L Fang]

Hi Girish,

In current behavior of ponsim_olt.py, when enable/disable an ONU, the device admin_state is set  to AdminState.DISABLED/ENABLED, it seems to me that it is more appropriately to map this to port.ofp_port.config rather than port.ofp_port.state.

The other question is more relate to ONOS' behavior in response of logical device deletion in VOLTHA, considering the following scenario:

When a subscriber associated with an ONT is already authenticated, and then the OLT is disabled including all ONTs associated with it. When the OLT and ONTs are enabled again, what do we expect ONOS to do?

Will ONOS start from authenticating the ONT again? or just resume from the state before OLT/ONT are disabled?

Thanks

Lydia

[Steve Crooks]

Regarding the ONU Self Test, I think this should be generalized to self-test within the existing infrastructure. The IAdapterInterface should provide a self_test interface and if it's not targeting the OLT right now that's fine - that OLT adapter(s) can simply return 'Not Implemented'.

Regards,

Steve

[NaveenBabu Venkateshappa]

Hi Girish, Lydia 

When We bring down the ONU (hardware reset) we see VOLTHA deletes the port and respective information of that port and in ONOS it shows as port disabled. 

So when ONU device is not available then what will be the event which OLT should be sending to VOLTHA? 

I believe the question is how do we differentiate ONU disabled and ONU deleted events to be handled. 

I believe OLT firmware should provide different events on ONU down and ONU port disabled? 

W.r.t port.ofp_port.state which will be modified based on the OLT events which will be propagated to OF agents as I read from OF state description (I shared on e mail regarding that with you, couldn't fetch it now)

Let me know if it's other way.

Regards,

Naveen

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/SN2PR0801MB637BCE4389396F3A59476CCEEC00%40SN2PR0801MB637.namprd08.prod.outlook.com.

[Amit Ghosh]

Hi Lydia,

Regarding your questions "When a subscriber associated with an ONT is already authenticated, and then the OLT is disabled including all ONTs associated with it. When the OLT and ONTs are enabled again, what do we expect ONOS to do?

Will ONOS start from authenticating the ONT again? or just resume from the state before OLT/ONT are disabled?"

When the port is disabled, ONOS removes the flows and when it is enabled it adds the flows back again. 

The AAA application which is the authenticator waits for EAPOL messages from the RG and acts accordingly. The authentication is always started by the RG. 

After enabling again, ONOS will bring back the flows to the state they were before.

One condition under which the RG would initiate a new authentication is if it sees that it's link with the ONU goes down and come back up again.

Regards,

Amit Ghosh

[gcgiris...@gmail.com]

Agreed Steve and thanks for the feedback.

All,

Based on all the comments received until now, I have updated the proposal. We will go ahead with the implementation based on the this latest proposal attached.

Regards,

Girish

[Kora, Sireesha (Nokia - US/Raleigh)]

Girish,

    I looked through the latest proposal and I do not see any references to ONU’s entities and its management. For e.g,  how the ONT’s slots and ports will be managed. When is this planned to be incorporated on the proposal? There are requirements in the POC3 to manage ONU’s entities.

 

Thanks

Sireesha

 

From: gcgiris...@gmail.com [mailto:gcgiris...@gmail.com]
Sent: Friday, June 16, 2017 5:24 AM
To: VOLTHA Discuss <voltha-...@opencord.org>
Cc: gcgiri...@gmail.com
Subject: [voltha-discuss] Re: Proposal - Device Management in VOLTHA

 

Agreed Steve and thanks for the feedback.

--

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/333ecb2f-5fe2-4555-95fd-f09c0b49a582%40opencord.org.

[Girish Gowdru]

Hi Sireesha,

I think the items you are referring to fall under Chassis Management (correct me if I am wrong) and is not being addressed as part of the proposal shared. It will need to be addressed separately, may be after the we have addressed the items in the current proposal.

 

Regards,

Girish

To view this discussion on the web visit https://groups.google.com/a/opencord.org/d/msgid/voltha-discuss/DB4PR07MB0704914CBBF9A3D23C9DE600FCC10%40DB4PR07MB0704.eurprd07.prod.outlook.com.

[Amit Ghosh]

Hi Sireesha,

Thanks for the feedback, maybe am confusing things from Test Strategy Document. Can you please point me to the Sections in the document which talks about the management of the ONU's entities, specifically the ports?

Thanks,

Amit Ghosh

[L Fang]

Thanks Amit! That answered my question.

Lydia

[Kora, Sireesha (Nokia - US/Raleigh)]

Amit,

    Sorry I missed this question.

 

As mentioned before in on one of the threads, the entities listed in red oval (in the below picture) need to be supported(at least the minimum set) for configuration of ONU slots and ports etc. This falls under Device Management  which is a gap.

 

The AT&T POC-III requirements H3 as priority listed for the following requirement(as e.g.). This would need the ONU device management to manage ont-card and port(ethernet UNI). In the current code, since there is no support for this, the ont-card and port numbers are inferred from the name of vEnet(temporary stop-gap work-around).  Let me know if you have any further questions!

 

• Ethernet Interface (UNI) – link configuration (i.e. 1000BTFULLDPLX), link admin state (UP/DOWN)

H

H1

 

Thanks!

 

From: Amit Ghosh [mailto:ghos...@gmail.com]

Sent: Friday, June 16, 2017 9:14 AM
To: VOLTHA Discuss <voltha-...@opencord.org>

--
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/e90e19b5-125e-4200-9a69-7a39a5833c24%40opencord.org.