Kevin,
(referencing the two figures shown in this reflector post: https://www.ieee1904.org/2/email/msg00289.html)
>> After looking at this again, and starting to write text around one of these figures, it seems that the second figure is easier to
>> explain simply from the point of view that the mechanism to share the MAC address is obvious vs. the first figure we would
>> need to explain the magic involved in sharing the MAC address... or just leave it unexplained (not my preference).
In the second figure, there is only a single MAC instance, so in the receive direction there is no MAC address sharing. However, in the transmit direction, the OAMPDU.request primitive includes the source_address parameter. When any of the multiple OAM entities generates an OAMPDU, it should insert the single common MAC address. So, in the second figure, OAM entities all share the same MAC address.
In the first figure, each OAM entity sits on top of its own MAC instance, and these MAC instances all share the same MAC address. This is how the 802.3 solved this exact problem (see the highlighted text).
I suggest we discuss these two approaches on the next socialization call.
-Glen
From: Lists <lists@xxxxxxxxxxxxxxx>
Sent: Monday, February 01, 2021 11:52 AM
To: Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx>
Cc: stds-1904-2-tf@xxxxxxxxxxxxxxxxx
Subject: Re: Contribution for Annex 8A example of remote EPON management
After looking at this again, and starting to write text around one of these figures, it seems that the second figure is easier to explain simply from the point of view that the mechanism to share the MAC address is obvious vs. the first figure we would need to explain the magic involved in sharing the MAC address... or just leave it unexplained (not my preference).
Thoughts?
Sent from my mobile device
On Jan 21, 2021, at 9:12 PM, Glen Kramer <000006d1020766de-dmarc-request@xxxxxxxxxxxxxxxxx> wrote:
Kevin and all,
I have spent some time working on figures for the “optimized” manager use case.
This use case is very similar to the classical or non-optimized remote EPON management, with the only exception is that a single MAC address is used at the Manager, instead of a unique MAC address per each ONU and OLT in the classical use case.
In both use cases, everything except the Manager operates exactly the same, so I don’t think it makes sense to repeat the same description or figures. The optimized use case only needs to focus on the architecture of the Manager.
There are two ways to architect Manager for the optimized case. One way is to specify multiple MAC instances, all sharing the same MAC address. This is very similar to PON-facing port on the OLT, where we have a MAC per LLID, but only a single MAC address. This architecture is shown in the following figure:
<image002.png>
The other way to represent Manager’s architecture is to use a single MAC instance and a shim sublayer above MAC that does the source-based forwarding. This is shown in the following figure.
<image006.png>
Both types of the Manager architectures have identical externally-observable behavior, except probably the statistic counters attached to each MAC instance.
I am not sure if the use case description should only include one the above architectures or both. Let’s discuss.
-Glen
From: Glen Kramer <glen.kramer@xxxxxxxxxxxx>
Sent: Tuesday, January 19, 2021 10:18 AM
To: 'STDS-1904-2-TF@xxxxxxxxxxxxxxxxx' <STDS-1904-2-TF@xxxxxxxxxxxxxxxxx>
Subject: Contribution for Annex 8A example of remote EPON management
Hi all,
On the last socialization call, we have discussed the figure showing the remote management of EPON using VLC.
Attached is the a complete example of this use case, with all the description of tunnels and rule contents. This text is supposed to be included as a new subclause at the end of annex 8A.
Please, take a look and let me know if anything needs fixing or additional explanations. FYI, the comment submission deadline is tomorrow EoD.
Thank you,
-Glen
To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1
To unsubscribe from the STDS-1904-2-TF list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-1904-2-TF&A=1