| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
|
Hi Tom, I think we are aligned. Thanks for the review. Any specific input on these lines will be welcome, but no need to bother with “trivial” editing issues, I will ask for editorial license. Best regards, Leon From: Tom Huber (Nokia) <tom.huber@xxxxxxxxx> Hi Leon, I think we’re almost there… The text has to be clear that figure 155-5 is not just a simple deconstruction of the 1280-bit field in figure 155-4. Because the encoding of the information elements into the 1280-bit field is complicated, the intent of figure 155-5 and
the text in clauses 155.2.5.5.[1-3] is to explain the information elements of the overhead as if they are a separate, standalone frame structure; clause 155.2.5.5.4 then explains how that structure is encoded into the 1280-bit OH field shown in figure 155-4.
As such, we have to be careful not to overload the term ‘OH field’ by using it to refer to both the 1280-bit field in figure 155-4 and the elements in the frame in figure 155-5. Taking a quick search through the draft:
If we are aligned on the general principle here, I can propose more specific text changes. Regards, Tom From: Leon Bruckman <leon.bruckman@xxxxxxxxxx>
Hi Tom, Thanks for initiating this discussion and for the detailed explanation. Basically I am OK with reverting to singular, but:
Best regards, Leon From: Tom Huber (Nokia) <tom.huber@xxxxxxxxx>
Hi all, I took the item to start an email discussion about the description of the overhead field(s), pursuant to comments 103 and 182. As I noted in the call, there is some baggage that comes from FlexO that we don’t want to include in the text of 802.3cw, but it is important to understand it in order to resolve this issue, so let me try to explain that in a bit more
detail. The FlexO frame is a ~100G structure that contains 1280 bits of overhead – 480 are alignment markers, 480 are ‘extended overhead’, and 320 are ‘basic overhead’. This structure was originally designed to support inverse multiplexing of
> 100G OTN signals over 100G PHYs. To maintain compatibility between the processing, when higher speed PHYs were added to FlexO, the higher speed frame is formed by 10-bit interleaving 100G FlexO frames (each of which has all the overhead populated, so the
processing is the same whether a group of n FlexO frames is carried over n 100G PHYs or over one n00G PHY). In the context of 400GBASE-ZR (and OIF 400ZR), there is no possibility of inverse multiplexing, and thus no need to complicate the description of the frame by discussing the 100G FlexO frames and their interleaving. Instead, we just describe
the FlexO-4 frame that results from the interleaving, and illustrate that in Figure 155-4. In addition, the ‘extended overhead’ is not used in 400GBASE-ZR, and we have opted to describe it as ‘pad’. So we have a 400GBASE-ZR frame structure with 1920 (i.e,
4x480) bits for AM, 1920 bits for pad (what FlexO would call extended overhead), and 1280 bits for OH. As such, there is a single 1280-bit field called ‘OH’. That field is then subdivided into specific overhead elements (fields) in clause 155.2.5.5. So circling back now to comments 182 and 103 first – the text in question is “The 400GBASE-ZR frame contains 1280-bit OH fields.
This field is logically composed of four 320-bit structures.” The essence of both comments 103 and 182 is that there is disagreement between singular and plural forms in the two sentences. The suggested remedy in 103
is to resolve by using plural nouns in the second sentence, while 182 suggests using singular nouns in the first sentence. The proposed response from the editor is to take the proposal from 103.
Given the above explanation and content of Figure 155-4, it seems clear to me that there is only one 1280-bit field – so regardless of what was decided before, we should correct the text to refer to a single 1280-bit OH field – and therefore
we should accept comments 182 and 190, and AIP comment 103 by pointing to 182. And then from the discussion in the meeting today, part of the difficulty seems to be that the title of 155.2.5.5 is “Overhead fields, which is intended to be indicating the specific information elements that are conveyed in the 1280-bit
OH field. As such, it may be helpful to revise this title. 155.2.5.4 describes what goes into the AM and pad fields in figure 155-4; the title of 155.2.5.4 is simply “alignment markers and pad insertion”. Maybe a simple fix here is to change the title of
155.2.5.5 from “OH fields” to “OH elements and insertion”. Lastly, I would point out that subclauses 155.2.5.5.1 through 3 describe the information elements, and 155.2.5.5.4 describes how they are inserted into the OH field. That description may appear to be more complicated than one might want
it to be; this is again due to the FlexO baggage I mentioned above. The 1280-bit OH field is formed by interleaving four 320-bit fields, only one of which is used in 400GBASE-ZR (whereas OTN FlexO applications use all 4 of them). It is convenient to describe
the contents of the overhead independently of how they are mapped into the 1280-bit field, and then describe how that structure is mapped into the 1280-bit field, as this avoids polluting the description of the information elements (MFAS, STAT, JC1-JC6) with
details about which 320-bit block contains these information elements. So to summarize:
Best regards, Tom To unsubscribe from the STDS-802-3-DWDM list, click the following link:
https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1 To unsubscribe from the STDS-802-3-DWDM list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-DWDM&A=1 |