Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

RE: [1904.4 TF] comment against 802.3ca to fix the ONU re-registration issue

Here is how I understand the possible use cases related to ONU registration

1) NORMAL DISCOVERY (AKA Discovery and Registration) is a two-step process:
	- Discovery step includes exchange of DISCOVERY and REGISTER_REQ messages
	- Registration step includes exchange of REGISTER + GATE and REGISTER_ACK
messages.

2) DIRECT DISCOVERY is similar to Normal discovery and is also a two-step
process. But the first step sends DISCOVERY MPCPDU with ONU’s MAC address.
This use case avoids contention during the discovery window, but it assumes
that ONU’s MAC address is known to the OLT.

3) DIRECT REGISTRATION is used when the OLT has prior knowledge about the
ONU. That knowledge must include all the parameters that REGISTER_REQ would
normally carry (MAC addr, Pending envelopes, laser on/off times) and also
the derived parameters that OLT usually obtains during the discovery step:
RTT and RSSI group for that ONU. The Direct Registration process only
includes the exchange of REGISTER + GATE and REGISTER_ACK messages.  Since
the ONU is unregistered (does not have a PLID assigned) the REGISTER is
transmitted on DISC_PLID with unicast MAC DA.

4) RE-REGISTRATION use case allows OLT to update various parameters in a
registered ONU that were originally set during Normal Discovery, Direct
Discovery, or Direct Registration. For example OLT/NMS may decide that it
needs to change the PLID or MLID assigned to the ONU, or change the
durations or Sync Periods  Sp1Length, Sp2Length, Sp3Length.  In this use
case, REGISTER MPCPDU with Flag=ACK is sent to a registered ONU on the ONU’s
specific PLID. The re-registration process can also be used to check the
MPCP protocol health (in addition to GATE/REPORT exchange). While GATEs and
REPORTs are typically handled by HW, REGISTER and REGISTER_ACK may be
handled by SW.

5) DEREGISTRATION is used to deregister an ONU. In this use case, REGISTER
MPCPDU with Flag=NACK is sent to a registered ONU on the ONU’s specific
PLID.


The cases 1, 2, 3, and 5 are already supported by the existing .3ca spec.
Case #4 is described in 802.3ca text (as I showed on slide 2) and it is
supported by the ONU Registration state diagram (as I showed on slide 4).
But the OLT Registration state diagram had a bug and didn’t allow sending
REGISTER with Flag=ACK. That’s what I propose we fix.  Note that this
problem is a technical error to be fixed. It is not an attempt to add a new
feature.

Glen

From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>
Sent: Thursday, August 26, 2021 6:56 PM
To: STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: [1904.4 TF] comment against 802.3ca to fix the ONU
re-registration issue

JC,

As Glen mentioned on the call, there are cases where the registration
parameters of the ONU might need to be changed. There is no need for the ONU
to go through a full blown registration, since the ONU is already known
(distance, MAC address, etc.) so we can push the device to go into an
accelerated re-registration process saving on time and bandwidth.

Marek

From: mailto:stds-1904-4-tf@xxxxxxxx <mailto:stds-1904-4-tf@xxxxxxxx> On
Behalf Of Jean-Christophe Marion
Sent: Thursday, August 26, 2021 7:12 PM
To: Glen Kramer <mailto:000006d1020766de-dmarc-request@xxxxxxxx>
Cc: mailto:STDS-1904-4-TF@xxxxxxxxxxxxxxxxx
Subject: Re: comment against 802.3ca to fix the ONU re-registration issue

Hi Ed,

Yes, I would like to discuss it further. I was a little confused yesterday
and still today about the use case. I thought that the re-register use case
is to support the directed discovery. But it seems that we just want to
re-register a link that was already registered. And I am confused about why
we would do that.

Thanks,

Jc



On Aug 26, 2021, at 5:35 PM, Glen Kramer
<mailto:000006d1020766de-dmarc-request@xxxxxxxx> wrote:

Dear colleagues,

The 802.3 maintenance TF chair just announced a series of calls to resolve
comments against 802.3 D2.0. They already have a large number of comments,
including 10 post-deadline comments.  I would like to submit our comment
fairly soon, as they consider the post-deadline comments in FIFO order.

Please take another look at the following presentation that we discussed
yesterday and let me know whether you (a) agree and support this solution,
or (b) can offer an improved solution.
https://www.ieee1904.org/4/meeting_archive/2021/08/tf4_2108_kramer_12.pdf

I would like to attach this presentation as a comment supplement to better
illustrate to 802.3 maintenance TF the problem and the solution. And to
emphasize that this material was reviewed and vetted by many people, I would
like to include all names as co-authors of this presentation.  Please, let
me know if it is ok to include your name on the first slide. If you don’t
feel like you understand this material enough or feel uncomfortable with
being listed for any reason whatsoever, it is no problem, but please let me
know either way, so I don’t continue waiting. I would like to submit the
comment the first half of next week.

If anyone would like to discuss this more, let me know and I will be happy
to schedule a webex call.

Thank you,
Glen


From: Adam Healey <mailto:0000074ad040f574-dmarc-request@xxxxxxxx>
Sent: Thursday, August 26, 2021 4:32 PM
To: mailto:STDS-802-3-MAINT@xxxxxxxxxxxxxxxxx
Subject: [STDS-802-3-MAINT] IEEE P802.3 (IEEE 802.3dc) revision D2.0 comment
resolution meeting series

Colleagues,

I am announcing a series of teleconference meetings for the resolution of
comments received against the IEEE P802.3 (IEEE 802.3dc) initial Working
Group ballot.
• Tuesday 7 September 2021 from 10 am to 1 pm EDT (14:00-17:00 UTC)
• Monday 20 September 2021 from 10 am to 1 pm EDT (14:00-17:00 UTC)
• Thursday 23 September 2021 from 10 am to 1 pm EDT (14:00-17:00 UTC)
• Monday 27 September 2021 from 10 am to 1 pm EDT (14:00-17:00 UTC)
The teleconference coordinates may be found on the IEEE 802.3
https://www.ieee802.org/3/calendar.html. Note that motions may be considered
at these meetings.

Please review the IEEE-SA patent, copyright, and participation policies
<http://ieee802.org/3/policies.html> prior to the meeting.

Meetings have been provisioned based on a rough guess of the time needed to
complete comment resolution. Meetings will be cancelled if they are not
needed. However, there is not enough time to add more meetings while keeping
to the target project schedule. As a result, I will allow the 27 September
meeting to run as long as needed to complete comment resolution.

Comment reports will be posted following the announcement of the ballot
results. I will provide more information about the comment resolution
process and the expected order of consideration as we approach the 7
September meeting.

Thanks,
--Adam

________________________________________
To unsubscribe from the STDS-802-3-MAINT list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-MAINT&A=1
________________________________________
To unsubscribe from the STDS-1904-4-TF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1

________________________________________
To unsubscribe from the STDS-1904-4-TF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1
________________________________________
To unsubscribe from the STDS-1904-4-TF list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1

________________________________________________________________________
To unsubscribe from the STDS-1904-4-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-4-TF&A=1

Attachment: smime.p7s
Description: S/MIME Cryptographic Signature