Arkin,
This is a good question. I’ll offer my explanation, but I also invite Kevin to comment on this if he sees it differently.
When we discussed the UMT layering diagram in earlier calls, we focused mainly on how to allow a device to simultaneously process native OAMPDUs and OAM over UMTPDUs. This is still the main use case.
In the follow-up discussion in Salt Lake City, Kevin offered an additional requirement that a new UMT capable device should also be manageable by OMCI over UMTPDUs. So, we tried to enhance the layering diagram to also allow this use case.
However, I do not think that the 1904.2 should go into any specific details for the protocols it carries. In the main body of the standard, we should have a generic layering diagram with labels “Protocol-specific Interface” and “protocol-specific client”. Maybe we will decide to add annexes for some specific protocols. Below is the layering diagram as it would appear in the main body of the standard.
<image004.png>
One key point that I feel is not well understood is that “other non-OAM clients” is a very broad category and needs to be further subdivided into “Non-OAM Ethernet-based clients” and “Non-Ethernet-based clients”. The OMCI is a non-Ethernet-based client.
The UMT sublayer is transparent to all Ethernet-based clients. It achieves this transparency by converting UMTPDUs into native protocol xPDUs before passing the data to these protocol-specific clients. For all the Ethernet-based protocols, this conversion is very simple. All UMT needs to do is to (possibly) replace the DA and replace or remove the opcode. In other word, it converts UMTPDU Ethernet frames into another kind of Ethernet frames. Existing OAM sublayer is designed to handle all these Ethernet frames (OAM and non-OAM).
But for the non-Ethernet protocols, this conversion doesn’t work, as these protocols don’t use Ethernet frames. In such use cases, the UMT sublayer should simply remove the UMT header and pass the payload up to a protocol-specific client using protocol-specific indication and request primitives.
To be honest, I am a bit confused about the purpose of the UMT (may be this is due to lack of background on my side due to missing the earlier meetings).
Are we mentioning the GPON as a specific use-case example of "Other non-OAM clients" or is that the only client that can directly interact with UMT?
If it is the only one, I am more confused about the activity because it seems that the UMT is now required to deal with "OMCI_requests" (per the picture) which is a very specific functional extension designed for GPON in the 1904.
If not, then I am also curious to learn the other examples that will use both the OAM client and/or directly interact with UMT sublayer. In those cases which messages will be used to directly interact with UMT since the picture refers to such direct messages as "OMCI_requests" and "OMCI_indication".
Best Regards
Arkin
On 6/10/2019 8:42 AM, Marek Hajduczenia wrote:
The one question I do have – why do we even have to show OMCI? There are many other clients which may (or may not) be supported. Do we have now to show all of them?
Rather than show OMCI, I’d recommend showing just “Other non-OAM clients” instead to cover them all with a single drawing
Marek
All,
In Salt Lake City, Kevin and I discussed the UMT layering diagram some more. The focus was on how to support the C57 loopback, while a device may be receiving both native OAMPDUs and OAM over UMTPDUs.
Another challenge was the desire to support OMCI, which also can be in two forms: OMCI over OAMPDUs (per ITU-T G.988) or OMCI directly over UMTPDUs.
Kevin and I believe the following layering diagram solves all these issues.
<image001.png>
These diagram is somewhat similar to what I presented on the last conference call, but it has the UMT layer extended to allow native OMCI interface to OMCI client.
You may want to look again at the presentation from the call, which explains how UMT layer operates.
-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
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