ONU Device Disable/enable Discussion

[Shaun Missett]

Starting a thread for discussion of the ONU Device Discussion

Previous Notes:

• device management disable/(re) enable/delete (Nick)
• further discussion required regarding disable/enable/delete approach
• is this order-dependent? if so, how to enforce?
• need further definition of "disable"/expected behavior for admin-down? (see also existing JIRA VOL-482 with comments/notes)

G.988 Description of disable/enable ONU behaviour

A.1.6 Administrative state considerations
The administrative state attribute has two values: 0 (unlock) and 1 (lock).
In the state model of [ITU T X.731], administrative state represents the intention of management to allow (unlock) or deny (lock) the functionality of a managed entity. Administrative lock must not inhibit management access to the managed entity. Though specified by neither [ITU T X.731] nor [ITU T X.733], a common side effect of administrative lock is to suppress notifications from the locked entity and any dependent entities. This avoids unnecessary alarms during maintenance and repair, or when a resource is not in use. The OMCI conforms to this convention.
The need for continuing management access implies that, regardless of the administrative state, an ONU must maintain its presence on the PON, and it may also have to provide local craft access, for example, to enter registration information.
Subject to continuing management access, it is suggested that the ONU itself, any separable circuit packs, and all ports should power down as much as possible when the administrative state is locked. It is further suggested that the default value for administrative state be locked. This reduces power consumption in cases such as pre-installation of ONUs and unsubscribed or unused ports.
Operators may have additional requirements that override power-down or that override the suggested lock default.
NOTE – When an ITU-T G.987 ONU enters initial state, as defined in [ITU-T G.987.3], it may set administrative lock on the ONU-G managed entity, thereby preventing all user traffic from flowing until the OLT unlocks the ONU-G. Although this is optional behaviour on the part of the ONU, the OLT is advised to check the state of this attribute when bringing an ONU into service.

Question:

Do we start out from the position that the ONU should implement the behaviour described in G.988?

Where an ONU does not meet this we should initiate a bug fix.

  

[Matt Jeanneret]

I agree we should stick with the G.988 definition.  The question was really about should the OLT (BAL drivers specifically) be told to take any action in addition to the OMCI disable(s).  Its not much work to have the handler consider the stored voltha admin state before either proceeding through the mib sync/mib download/uni enable or re-lock on onu reboot.  

Some onu ive seen on a mib reset locks itself, while others dont.   And others still on an ONU-G lock will lock the PPTP/UNI ports, but others dont.  So my only point is the handler will explicitly lock it all.

-matt

-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%2BYfzecj%2BGFvGOwXjYssAF_V9N7ZskSc9_0e2C%3DveEfiurN_%2Bw%40mail.gmail.com.
For more options, visit https://groups.google.com/a/opencord.org/d/optout.

[Matt Jeanneret]

Also, I think the key point also (for Nick and I) is:

Administrative lock must not inhibit management access to the managed entity

Which (to me) says BAL is not told to cut off communications.   While walking to lunch Nick agreed, so i think we are good.   As long as an onu reboot doesn't inadvertently restore service.

-matt

[Chip Boling]

I think we are good as well. On a reboot of the ONU (due to power outage or reboot command), when the ONU comes back up, the MIB Sync state machine should detect the condition where the ONU sets any of the administrative locks to unlocked (when they were previously locked).   There is a delay where this point will be enforced, but as any MEs for flows have to be restored as well, it can easily be handled by making sure that ONU_G and UNI_G MEs are restored to the proper state first during the resynchronization process.

   - Chip

[Shaun Missett]

Ok - I think we are agreed on the approach - any other points to discuss around this?

Thanks

Shaun

[Shaun Missett]

I think we can consider this issue closed also.

Thanks

Shaun