Upload
others
View
7
Download
0
Embed Size (px)
Citation preview
Richard Tse, Microchip Technology
Mar 3, 2020
Teleconference
IEEE 1914 NGFI
IEEE 1914.3a RoE – D1.1 Comment Resolution, Day 2
Outline
• Comment 52 and 53 (again)
• Comment
• Proposed Change
• Discussion
• Comment 24
• Comment 35, 41, and 57
• Comment 104
• Comment 105
• Comment 145
• Rogue
• Rogue
Comments 52 and 53: Comments
• The PCS processed all zeros and PCS processed repeating error control characters do not guarantee 8B/10B codeword alignment, if continued over an extended duration, because of a lack of comma characters in the stream. A K28.1 comma character should be inserted occasionally if this replacement pattern is continued (e.g. after every 2048 consecutrivecodewords of the replacement pattern, for 8B/10B encoded datastreams). K28.1 is used instead of K28.5 to differentiate it from CPRI's K28.5.
• The injection of K28.1 characters periodically during extended assertions of PCS processed replacement patterns should be described in subclause 7.3.7, along with the replacement patterns, instead of in this subclause.
Comments 52 and 53: Proposed Change
• Add statement after NOTE 5 to indicate this behaviour for this replacement pattern scenario.
• Remove this paragraph and, instead, describe the periodic injection of K28.1 characters during extended assertions of PCS processed replacement patterns in subclause 7.3.7.
Comments 52 and 53: Discussion (1/2)
• From last teleconference:
• OK with insertion of 10B comma characters that don’t coincide with CPRI Hyperframe boundary intervals so as to inadvertently cause frame alignment
• Some repeated 8B/10B patterns cause SERDES problems (e.g. CJPAT, found in IEEE 802.3 Annex 48A)
• Problems result from switching between repeating 10B patterns with low transition density to 10B patterns with high transition density and vice-versa
• Repeating of PCS-coded all-zeros pattern or PCS-coded error pattern (/V/) might cause this problem
Comments 52 and 53: Discussion (2/2)
• Options brought up so far to avoid CJPAT problem:
• Self-synchronous scrambling of the all zeros pattern (between periodic insertions of a comma character)
• Loses meaning of all zeros if receiving end does not have self-synchronous descrambler, which will be the case
• Example self-synchronous scrambler is G(x) = 1 + x39 + x58, which is used for 64B/66B PCS in IEEE 802.3
• Already-defined /C1/C2/ ordered set sequence for “GE link fault”
• Loses meaning of all-zeros
• C1 = /K28.5/D21.5/D0.0/D0.0/
• C2 = /K28.5/D2.2/D0.0/D0.0/
• K28.5 has low transition density switching
• D0.0 has medium transition density switching
• D2.2 has high transition density switching
• D21.5 has high transition density switching
• /I/ followed by /Dx.y/ and/or /V/
• Loses meaning of all-zeros
• Need mix of transition densities
Comment 24: Comment
• Now that the management model will be added to this standard, the corresponding statement should be placed back in the Scope of this standard.
Comment 24: Proposed Change
• Add "A management model for this protocol is defined" to the end of the paragraph
Comment 24: Discussion
• Added sentence is the same as that from the scope in P1914.3a’s PAR
Comment 35, 41, 57: Comment (1/3)
• Comment #35 on subclause 11.2, Table 24 Mapper PM Counter Value Parameters:
• PM counters for early and late RoE control packets should be available. Some RoE control packets (e.g. Ctrl_AxC) might need to be aligned with CPRI basic frames.Since not all control packets are timing sensitive, we need a set of parameters to enable/disable the early/late timing check for the ones that might be (Ctrl_AxC, VSD, slow-C&M).
Comment 35, 41, 57: Comment (2/3)
• Comment #41 on subclause 12.3 RoE de-mapper defect events:
• Defects for early and late RoE control packets should be available. Some RoE control packets (e.g. Ctrl_AxC) might need to be aligned with CPRI basic frames.Since not all control packets are timing sensitive, we need a set of parameters to enable/disable the early/late timing check for the ones that might be (Ctrl_AxC, VSD, slow-C&M).
Comment 35, 41, 57: Comment (3/3)
• Comment #57 on subclause 12.8 RoE de-mapper consequential actions for defects
• Consequential for early and late RoE control packets should be available. Some RoE control packets (e.g. Ctrl_AxC) might need to be aligned with CPRI basic frames.Since not all control packets are timing sensitive, we need a set of parameters to enable/disable the early/late timing check for the ones that might be (Ctrl_AxC, VSD, slow-C&M).
Comment 35, 41, 57: Proposed Change (1/3)
• Comment #35:
• Add .rx_early_ctrl_pkt_cnt and .rx_late_ctrl_pkt_cnt to the list of PM counters iin Table 25.
• Add parameters for Ctrl_AxC, VSD, and slow C&M control packets to enable the PM counters and indications for early/late events.
Comment 35, 41, 57: Proposed Change (2/3)
• Comment #41:
• Add .early_ctrl_pkt and .late_ctrl_pkt to the list of defects in Table 27.
• Add parameters for Ctrl_AxC, VSD, and slow C&M control packets to enable the PM counters and indications for early/late events.
Comment 35, 41, 57: Proposed Change (3/3)
• Comment #57:
• Add consequential actions for early and late RoEcontrol packets in Table 32. These packets should be discarded (discard_msg) and PM counters for these events should be incremented (pm_cnt).
• Add parameters for Ctrl_AxC, VSD, and slow C&M control packets to enable the PM counters and indications for early/late events.
Comment 35, 41, 57: Discussion
• CPRI control channels are proprietary so we don’t know whether they are timing sensitive or not. P1914.3a should allow both timing sensitive and timing insensitive usage.
Comment 104: Comment
• Subclause 5.5.2 Subtype (subType) field
• In the 3rd and 4th rows below the headings of Table 3, the "Function" has been renamed to clarify that "structure-aware" applies to "CPRI" on the 4th row, but not on the 3rd row. This is inconsistent and doesn't fix the inconsistency that existed before the change. Further it changes terminology that is already standardized.
Comment 104: Proposed Change
• Not specified
Comment 104: Discussion
• Structure-agnostic is not dedicated to just CPRI. It can be used to carry any bit stream.• IEEE-1914.3-2018 has a NOTE on structure-agnostic modes that says the term CPRI
(or CPRI-like) is used even if the protocol being mapped/demapped is not CPRI
• CPRI is used alongside structure-aware to clarify that it is only used for CPRI
• During investigation on this comment, it was found that the subTypevalue for RoE CPRI structure-aware frequency domain data subtype is missing
• subType = 5 should be used
Comment 105: Comment
• Subclause 5.5.5.2 Sequence number (seqNum) field
• Unclear what "special associations" means.
Comment 105: Proposed Change
• Be more specific and remove this terminology if not absolutely needed.
Comment 105: Discussion
Change from:
• The sequence number field is used to identify the order of successive packets. Components of the sequence number field can be used to identify special associations for the data contained in the RoE packet, like CPRI hyperframe numbers (HFN) and Node B frame numbers (BFN), and/or to fragment large messages.
To
• The sequence number field is used to identify the order of successive packets. Components of the sequence number field can be used to identify associations with radio events for the data contained in the RoE packet, like CPRI hyperframenumbers (HFN) and Node B frame numbers (BFN), and/or to fragment large messages
Rogue Comment #2: Comment
• This comment is a result of a limitation in IEEE 1914.3-2018 that was highlighted by the tf3_2002_dada_autoneg_extendedheader_1.pdf
contribution
• Edit clause 8.2.2 of 1914.3-2018 to restate the use of control packets for structure agnostic mappings. RoE control packets are not needed to transfer any radio control data (as per structure aware mappings), but they can be used for RoE control plane purposes (timing control, delay measurement, configure and read parameters, etc).
Rogue Comment #2: Proposed Change
• As per comment
Rogue Comment #2: Discussion
• Change from:
• Since the structure-agnostic RoE mapper encapsulates the entire data stream (with or without line coding), there are no associated control packets for the structure-agnostic RoE mapper. Any control or management information embedded in the data stream is not interpreted by the RoE mapper but is passed through as binary data.
to
• Since the structure-agnostic RoE mapper encapsulates the entire data stream (with or without line coding), there are no associated control packets for the structure-agnostic RoE mapper RoEcontrol packets are not needed to transfer any radio control data (as per structure aware mappings). Any control or management information embedded in the data stream is not interpreted by the RoE mapper but is passed through as binary data. However, RoE control packets can be used for RoE control plane purposes (e.g., timing control, delay measurement, configuration, reading of RoE parameters).
Rogue Comment #3: Comment
• Subclause 8.3.9 Handling of other Ctrl_ AxC and vendor-specific words, Table 15
• cwSel in Table 15 of IEEE 1914.3-2018 should be a 4-bit field, not a 3-bit field
• This is an error in 1914.3-2018
Rogue Comment #3: Proposed Change
• Fix the width of the .cwSel parameter
Rogue Comment #3: Discussion
• The description of .cwSel and its relationship to the CPRI Xsparameter indicates it is 4-bits, not 3.