| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Marek,  The attached contributions look good to me. Below are a few points of additional feedback.  1)     I am not sure both of the comments below have anything to do with the action item #13. 2)     It would be good to mention somewhere in clause 12 that OAM discovery only takes place once per ONU device and it uses primary MLID for that. 3)     It is conceivable that as time passes, both OLT and ONUs will support multiple OAM versions. And it is also conceivable that an ONU may have a version newer than what the OLT supports. Without a version negotiation, how will the OLT and ONU agree on what version to use? This item is just an invitation to discussion.  Also here are several questions related to item #13. Mostly, these are points that we need to discuss either on the reflector or on consensus call.  1)     Do we want one compound attribute to query multiple different capabilities, or we use separate attribute for each capability? 2)     We already have Channel Control Protocol and CCPDU Query message in 802.3ca that allows us to query ONUâ??s channel support capabilities. Do we duplicate this functionality in Extended OAM, or just use CCPDUs for that? I see pros and cons for both methods. 3)      For fragmentation support, we may need to know more than just a Boolean. Fragmentation requires dedicated memory and control logic per each fragmentable LLID. But ONU may not need or may not be able to provide that resource for every LLID. Also, do we need to support jumbo frame fragmentation for every LLID? This would require 10K buffer per LLID, which may be a huge waste of resources. So, I am thinking the capability query response would need to tell how much fragmentation memory it has in total, how many fragmentable LLIDs it can support (only matters for bidirectional LLIDs). This RO attribute would be under the ONU context. We probably will have to specify an additional attribute to provision fragmentation buffer size per LLID. This has to be a RW attribute to provision (W) and to query (R ) the fragmentation buffer size under the context of LLID. Glen  From: Marek Hajduczenia <mxhajduczenia@xxxxxxxxx>  Dear colleagues,  I started working on Action Item #13 and went through the cleanup of Clause 12 and Clause 13, resulting in the two following comments and attached contributions. Â
 Apart from editorial and small technical changes (e.g., remove any references to profile, since we do not do profiles anymore in 1904.4), the largest change I wanted to signal was in Table 13-5 (Information TLV), which contains the eOAM version information. I suggest we use 0x30, which is backward compatible with 1904.1 versions used for Package A, and signals a new version block. I do not expect a lot of revisions to 1904.1, but we still have more than 10 possible minor revisions available. I believe it is plenty.  Now, Action Item #13 calls also for new ONU capability discovery Â
 covering fragmentation, multiple channels, etc. Rather than cram them into the Information TLV, I suggest we create a new capability TLV under 0xDB branch, and create entries for following capabilities:  -         Support for downstream fragmentation (Boolean) -         Support for upstream fragmentation (Boolean) -         Number of downstream channels supported (int, 1 byte) -         Number of upstream channels supported (int, 1 byte)  These 4 entries exhaust the capabilities I can think of and that are not otherwise covered elsewhere. To follow up, we might want to allow for fragmentation to be disabled (R/W) in downstream and upstream directions, but I am struggling to find a reason to change the number of channels supported.  Are there any other capabilities we should be reporting for the ONU that are specific to 803.3ca systems?  Thank you  Marek 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