| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Let’s make time to discuss this on the call tonight. I think there are some significant implications if there is no OAM sublayer in the OLT’s PON stack. --kan-- -- Kevin A. Noll Sr. Director, Systems Architecture Tibit Communications kevin.noll@xxxxxxxxxxxx From: Glen Kramer <glen.kramer@xxxxxxxxxxxx> Kevin, See inline, please. -Glen From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Hmm…. Now that I re-read that statement, it is confusing. The intent of the statement is to convey that the OAM-based ONU management functionality that would traditionally be in the OLT is being moved to an external entity (a general purpose server, probably). [GK: ] It is fine if the OAM client and OAM sublayer is moved together from an ONU-facing OLT port to a remote server. But I don’t think OAM client and OAM sublayer can be separated and
still be compliant with and retain all the functionality per C57 in 802.3. The specifics of where the client resides or how it is split is what I am trying to figure out in the context of D0.6. I think there must be some lightweight version of the OAM client in the OLT, but if it’s there, then how does the OAMPDU get to it from the UMT SL? I don’t think the OLT’s OAM sublayer (on the PON side) can
be removed or else the OLT loses key functions (loopback) that should not be moved to an external location. [GK: ] I think we all agree that we cannot change anything about OAM operation. It is defined in 802.3, and we are not chartered to re-write it or to define any alternatives. (In a proprietary
implementation, vendors can do whatever they want, but this is not something that needs or should be discussed here.) Per 802.3, there is no possibility to split an OAM client among two different devices or to separate a client from the underlying OAM sublayer. I also wonder if the OAM sublayer needs to exist in the “Manager” side. For the purposes of OAM over UMT to manage the ONUs, I don’t think it needs to be there. [GK: ] OAM sublayer needs to be adjacent to OAM client. They cannot be separated.
Lastly, is my depiction of the tunnel correct (terminating at the UMT sublayer on the PON side of the OLT)? [GK: ] Yes, the tunnel entrance and exit points are correct. The OLT doesn’t need to have OAM sublayer and OAM client facing the ONU. These blocks won’t receive any responses from the ONU.
All the OAMPDUs that ONU sends will enter a tunnel before they reach OAM sublayer, so OAM client in the OLT will never be able to complete the OAM discovery with the ONU. Instead, the OAM client in the ONU Manger will complete the OAM discovery with the ONU. --kan-- -- Kevin A. Noll Sr. Director, Systems Architecture Tibit Communications From: Glen Kramer <glen.kramer@xxxxxxxxxxxx> Kevin, I can try later today or tomorrow. Can you describe what this sentence means: “OLT’s OAM Client is disaggregated and moved to the ONU Manager”? Does it mean the client is split in several pieces, or that it is separated from OAM sublayer, or that the client and OAM sublayer are simply moved together to the ONU Manager? -Glen From: Kevin Noll [mailto:kevin.noll@xxxxxxxxxxxx]
Glen, Please refer to the attached PPT. Could you answer the questions contained in the slides and adjust the diagrams to help us understand how this should work? --kan-- -- Kevin A. Noll Sr. Director, Systems Architecture Tibit Communications 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 |