Printed on 25 July 2016 at 1:25:48 PM. IEEE , D1.0, Approved Comments (all comments)

Transcription

1 Printed on 25 July 2016 at 1:25:48 PM #1 Type: E TF: TF3 Clause: FM Page: 8 Line: 15 Commenter: Marek Hajduczenia / Charter Communications Something went wrong with TOC entry seems to be overlapping with 4.1 entry Please regenerate TOC and make sure that PDF corresponds to clean Word document. P9. Yes. ToC generation is broken. Will double check next time. #2 Type: T TF: TF3 Clause: 1.1 Page: 12 Line: 4 Commenter: Marek Hajduczenia / Charter Communications "This document defines the encapsulation and mapping of radio protocols to be fronthauled over Ethernet" this is the first time the term "fronthaul" is used in the document and there is no definition of such term. Change to "This document defines the encapsulation and mapping of radio protocols to be transported over Ethernet" Consider also adding a statement in the lines of "The transport of packetized radio signal over Ethernet is referred to in this standard as fronthaul." to explain what it is... P13.. #3 Type: E TF: TF3 Clause: 1.1 Page: 12 Line: 9 Commenter: Marek Hajduczenia / Charter Communications Is "802.1CM" and should be "IEEE Std 802.1" with reference to proper standard version there are multiple instances of this problem Please also make sure that reference to 802.1CM is properly expanded. P13. Move to bibliography as shown in 17.2 of IEEE style guide in this case IEEE Std 802.1CM. Same is true for 802.1TSN URL. Only CPRI is a normative reference section 2 of IEEE style guide. #4 Type: T TF: TF3 Clause: 1.1 Page: 12 Line: 9 Commenter: Marek Hajduczenia / Charter Communications Unnecessary: "Alternative transparent mechanisms are 10 also permitted in conjunction with or in lieu of 802.1CM profile." already stated clearly in two last sentences Strike the offending text P13. agreed. #5 Type: E TF: TF3 Clause: 1.1 Page: 12 Line: 13 Commenter: Marek Hajduczenia / Charter Communications Typos: "tehnology" Please check the draft to make sure there are NO typos present P13.. MS Word does not behave well on this document spelling check does not work. #6 Type: T TF: TF3 Clause: 1.1 Page: 12 Line: 11 Commenter: Marek Hajduczenia / Charter Communications Comment Status: Resolved Response Status: Reject Commenter Satisfaction: None Category: It is unclear what the purpose of discussion on implementation of ROE in the Scope statement for the standard is Remove lines Consider removing line 17 as well it is repetition of the statement in lines 79 anyway. Lines 1116 could be placed where RoE is discussed as an architecture P13. Newcomers to the TF found the text and position of it useful. #7 Type: E TF: TF3 Clause: 1.2 Page: 12 Line: 19 Commenter: Marek Hajduczenia / Charter Communications "describe the exact header" unnecessary qualirifcation "exact" clearly, once you define the format, it will be exact Remove the "exact" adjective P13. #8 Type: E TF: TF3 Clause: 1.2 Page: 12 Line: 19 Commenter: Marek Hajduczenia / Charter Communications Seems like sentence got broken in the middle: "encapsulations required to; 20 transport any newly defined fronthaul protocol" Change to "encapsulations required to transport any newly defined fronthaul protocol" P13. Paragraphs below should be bullet points. #9 Type: E TF: TF3 Clause: 1.2 Page: 12 Line: 20 Commenter: Marek Hajduczenia / Charter Communications Open brackets, with no matching closing one: "(i.e. the native RoE encapsulation" Please make sure there is a matching bracket somewhere around in the sentence P13. Accept #10 Type: E TF: TF3 Clause: 1.2 Page: 12 Line: 23 Commenter: Marek Hajduczenia / Charter Communications Formatting gone wrong: lines 2326 are intended to be bulleted P13. Yes, it looks like the list bullets are missing. #11 Type: E TF: TF3 Clause: 1.2 Page: 12 Line: 21 Commenter: Marek Hajduczenia / Charter Communications Unnecessary reference to bulleted list: "used to transport other existing fronthaul protocols in a ways described in the next two bullet points" Change to: "used to transport other existing fronthaul protocols as follows:" P13.. Page 1 of 11

2 Printed on 25 July 2016 at 1:25:48 PM #12 Type: E TF: TF3 Clause: 1.2 Page: 12 Line: 23 Commenter: Marek Hajduczenia / Charter Communications "bit transparent" is a compound adjective and should be hyphenized Change to "bittransparent" globally The same applies to "structureagnostic" OK #13 Type: T TF: TF3 Clause: 1.2 Page: 12 Line: 23 Commenter: Marek Hajduczenia / Charter Communications For a reader of the purpose statement, it is not clear what the difference between lines 2324 and then 2526 is. Either remove reference to these (they are not needed to understand the scope of the document either way) or explain better what the difference between two options is P13. Add (structure aware) to 2526 #14 Type: E TF: TF3 Clause: 1.2 Page: 12 Line: 20 Commenter: Marek Hajduczenia / Charter Communications "i.e." is always followed by "," Make sure all instances of "i.e." are followed by "," OK #15 Type: ER TF: TF3 Clause: 1.2 Page: 12 Line: 27 Commenter: Marek Hajduczenia / Charter Communications No content in 1.3 Either add content, or remove the subclause altogether P13. Will remove #16 Type: ER TF: TF3 Clause: 2 Page: 13 Line: 6 Commenter: Marek Hajduczenia / Charter Communications No references provided Please expand on the references, as needed P14. #17 Type: E TF: TF3 Clause: 3.2 Page: 14 Line: 14 Commenter: Marek Hajduczenia / Charter Communications "Fields are shown in bold type" rather "field names" Change to "Field names are shown in bold typeface." P15. #18 Type: E TF: TF3 Clause: 3.2 Page: 14 Line: 13 Commenter: Marek Hajduczenia / Charter Communications Minor editorial fixes in the statement: "Within this document Parameters are in bold type and prefixed with a period, for example.seqnumpmax" Change to "Within this document, names of parameters are shown in bold typeface and prefixed with a period, for example,.seqnumpmax" P15. OK #19 Type: ER TF: TF3 Clause: 3.1 Page: 14 Line: 5 Commenter: Marek Hajduczenia / Charter Communications Wrong formatting for individual terms and definitions. Please use the approved template P15. Will format as per IEEE style guide 3.1 #20 Type: TR TF: TF3 Clause: 3.1 Page: 14 Line: 5 Commenter: Marek Hajduczenia / Charter Communications Terms and definitions have to be selfstanding and fully comprehensible when extractef from the document and placed into the IEEE Standards Disctionaty Online for anybody to use. As they are, they are meaningless outside of this document, for example, "Field" is a very common word, and it is used in here in the meaning of "RoE field" rather than just "field". Also, it is not clear why it needs to be specified at all. A quick search in the dictionary shows already entries for mappers, flows, fields, and parameters, which are also common terms. Suggest to have the terms either removed, or create definitions which are RoE specific, e.g., change a generic "flow" to "RoE flow". Accept, prepend these terms with RoE in 3.1. Add text hereafter refered to as e.g. flow #21 Type: ER TF: TF3 Clause: 3.3 Page: 14 Line: 16 Commenter: Marek Hajduczenia / Charter Communications Wrong formatting for individual acronyms and abbreviations. Please use the approved template Note also that "Endpoint" is neither an acronym or abbrevation. Same for Jitter P15. Will format as per IEEE style guide 3.1 & 3.2. Will move lines for jitter and endpoint to section 3.1 of the std Page 2 of 11

3 Printed on 25 July 2016 at 1:25:48 PM #22 Type: TR TF: TF3 Clause: 3.4 Page: 15 Line: 3 Commenter: Marek Hajduczenia / Charter Communications Comment Status: Incomplet Response Status: Reject Commenter Satisfaction: None Category: No DUT in "All RoE packets shall use the EtherType value shown in Table 1." packets are NOT a testable entity under any means the RoE source endpoint (if you have such a concept, or whatever the transmitter is called) should be used instead We do not understand the comment #23 Type: ER TF: TF3 Clause: 3.4 Page: 15 Line: 4 Commenter: Marek Hajduczenia / Charter Communications Wrong format of Table / Figure numbering for captions Should be "ClauseNumber" instead. Please apply the template P16. Accept #24 Type: T TF: TF3 Clause: 3.4 Page: 15 Line: 4 Commenter: Marek Hajduczenia / Charter Communications The purpose of "(*)" in Table 1 is not explained Please add a footnote with text, or whatever the purpose of this reference point is P16. (there used to be a comment to this effect) #25 Type: ER TF: TF3 Clause: 3.5 Page: 15 Line: 6 Commenter: Marek Hajduczenia / Charter Communications Comment Status: Resolved Response Status: Reject Commenter Satisfaction: None Category: I see zero value in demonstrating endianess of byte ordering, apart from refercing whether big or small endian representation is used. Replace lines 6 14 with the followign text: "For Ethernet packets, this document uses bigendian byte ordering representation." There are several references that could be used to explain this concept better, without creating additional explanation of what ednianess is... P like this. #26 Type: T TF: TF3 Clause: 3.5 Page: 15 Line: 11 Commenter: Marek Hajduczenia / Charter Communications The purpose of lines 1112 in the context of "Bit, octet ordering and numerical presentation" is lost on me Remove lines 1112 there is no need for this explanation at this point. You do not need to justify everything that is used in the document P16. Accept #27 Type: E TF: TF3 Clause: 3.5 Page: 15 Line: 15 Commenter: Marek Hajduczenia / Charter Communications Comment Status: Resolved Response Status: Reject Commenter Satisfaction: None Category: For decimal, binary, and hex representations, consider reusing balloted text from IEEE Std , and 3.5.8, which is much more complete and comprehensive. For decimal representation, there is really no need for any additional statements. P16. We dont see any value at this time. #28 Type: TR TF: TF3 Clause: 4 Page: 16 Line: 1 Commenter: Marek Hajduczenia / Charter Communications The document jumps right into specification of packet formats, without really showing what the overal network architecture is, even though it is mentioned in line 3: "overall RoE architecture", without really showing up anywhere Suggest to change title of Clause 4 to "Radio over Ethernet (RoE)" and then include the followign outline: 4.1 Radio over Ethernet (RoE) Architecture 4.2 RoE Traffic Types 4.3 RoE Functional Elements 4.4 RoE Frame Format Rename section headings as proposed #29 Type: ER TF: TF3 Clause: 2 Page: 14 Line: 6 Commenter: Jouni Korhonen / Broadcom Limited The references are not in proper format. Example: IEEE Std 802TM2014, IEEE Standard for Local and Metropolitan Area Networks: Overview and Architecture. Accept. #30 Type: ER TF: TF3 Clause: 2 Page: 14 Line: 8 Commenter: Jouni Korhonen / Broadcom Limited 802.1TSN is not a single specification. Either remove 802.1TSN from normative references or replace it with the specification(s) that is needed. Accept. Move to bibliography as URL #31 Type: ER TF: TF3 Clause: 3.1 Page: 15 Line: 11 Commenter: Jouni Korhonen / Broadcom Limited Acronyms should be expanded on the first use. Here OAM and PDU are seen for the first time. "Operations and Management (OAM) Type Length Value (TLV)/PDU" Move 3.3 to 3.1 Page 3 of 11

4 Printed on 25 July 2016 at 1:25:48 PM #32 Type: ER TF: TF3 Clause: 3.5 Page: 16 Line: 11 Commenter: Jouni Korhonen / Broadcom Limited The text in lines 1112 seems misplaced. I do not understand how the CPRI bit ordering disscussion belongs here. Suggest removing lines 1112 or expanding the discussion more. See comment 78 Change text from 'The CPRI specification defines a different ordering scheme. Translation from one scheme to the other is performed, as required, by (de)mappers' to 'For structure aware and native mappers, I,Q samples are transported without their bits interleaved.' #33 Type: E TF: TF3 Clause: 4 Page: 17 Line: 4 Commenter: Jouni Korhonen / Broadcom Limited "RoE enabled architecture" in not really defined in this specification. Suggest removing the reference to "architecture". Change 'architecture' to 'network' #34 Type: E TF: TF3 Clause: 4.1 Page: 17 Line: 7 Commenter: Jouni Korhonen / Broadcom Limited Acronym LCs for timing control is confusing. Suggest renaming Timing Control to LCt Ok #35 Type: E TF: TF3 Clause: 4.1 Page: 17 Line: 8 Commenter: Jouni Korhonen / Broadcom Limited Acronym LCt for control packets is confusing. Suggest renaming Control Packet to LCc ok #36 Type: ER TF: TF3 Clause: 4.1 Page: 17 Line: 12 Commenter: Jouni Korhonen / Broadcom Limited A RoE node can lso be a passthru. The text states that later though in a different sentence. Also RoE endpoint has two different used format with or without hyphen. Suggest rewroting the paragraph between lines 11 to 15. All the needed text is there but deserves a bit reordering to make it read better. Change to; This document uses terms node and RoE node meaning a RoE capable networking node that is either an originator,reciever or passthrough node of RoE communication. Global search replace endpoint to endpoint #37 Type: E TF: TF3 Clause: Page: 19 Line: 23 Commenter: Jouni Korhonen / Broadcom Limited Missing '.' Add the missing full stop. ok #38 Type: ER TF: TF3 Clause: Page: 21 Line: 2 Commenter: Jouni Korhonen / Broadcom Limited Containers are not discussed earlier and therefore the sentence starting "If containers.." appears misplaced. Either containers need to be described to some extent in here or a reference needs to be given. Add container definition to clause 3.1 #39 Type: ER TF: TF3 Clause: 4.2 Page: 21 Line: 8 Commenter: Jouni Korhonen / Broadcom Limited Ethernet is written wrong. Change "ehternet" to "Ethernet". ok #40 Type: E TF: TF3 Clause: 4.3 Page: 21 Line: 20 Commenter: Jouni Korhonen / Broadcom Limited Typo Change "bit" to "bits". ok #41 Type: E TF: TF3 Clause: Page: 22 Line: 0 Commenter: Jouni Korhonen / Broadcom Limited Missing '.' Add the missing full stop. Change table text to 'Reserved for future sub types.' on P22. P21 Table 2 needs full stop on each row. Page 4 of 11

5 Printed on 25 July 2016 at 1:25:48 PM #42 Type: TR TF: TF3 Clause: Page: 22 Line: 11 Commenter: Jouni Korhonen / Broadcom Limited It is not clear why the Ethernet header "shall not" contain any length field. Propbably it is meant to say here "Ethernet header will not contain any length information"... #43 Type: TR TF: TF3 Clause: Page: 22 Line: 17 Commenter: Jouni Korhonen / Broadcom Limited This paragraph should also state that the sequence number and the time stamp are per RoE flow. This is nor clearly stated anywhere in the document. Add a sentence saying the orderinginfo is per each RoE flow and they are independent. Change to 'Ordering information is assigned to each flow and is presented in one of two methods, a seqnum or timestamp' #44 Type: ER TF: TF3 Clause: Page: 24 Line: 20 Commenter: Jouni Korhonen / Broadcom Limited References given to the same section where the text is. Remove the reference to and reword the sentence accordingly. Remove sentence. #45 Type: TR TF: TF3 Clause: Page: 24 Line: 2 Commenter: Jouni Korhonen / Broadcom Limited The timestamp should contain an explicit indication bit of the "start of frame' (SoF). The SoF refers to e.g., CPRI hyperframe or LTE 10ms radio frame. The synchronization of the 2 bit sequence number and the presentation time to the SoF in a data path is complex unless we have an explicit indication when a specific RoE packet contain payload that is to be scheduled at the SoF boundary to the radio. This obviously has implications like the location of the payload that contains "SoF data" has to be placed as first octets in the RoE payload. An example could be a CPRI hyperframe boundary and the basic frame that contains the first control word would have to be the first payload data in the RoE payload field. Add explicit Start of Frame bit into the timestamp format. Suggestion to reduce the timestamp accuracy from 1/64ns to 1/32ns, and then use format 1:2:24:5, where the '1' bit is the SoF bit. See presentation tf3_1606_korhonen_sof_1.pdf for further information. Will add text consistant with page 11 of tf3_1606_korhonen_sof_2.pdf Add 'SoF is a indication of a frame boundary. When the SoF bit is set to 1, this indicates the start of the payload contained within the packet is the start of the frame. For example, a radio frame boundary.' Add 'orderinfo applies to the start of the payload' Add to strucrure aware mapper clause 'SoF indicates a radio frame boundary' #46 Type: TR TF: TF3 Clause: 6.5 Page: 26 Line: 23 Commenter: Jouni Korhonen / Broadcom Limited Supported 256 Ethernet links should be 255. RoE has maximum 255 available flowids to be used. My understanding is that we cannot go beyond 255 for any resource that can somehow be mapped to concurrent RoE flows. change 256 to #47 Type: TR TF: TF3 Clause: 6.5 Page: 26 Line: 27 Commenter: Jouni Korhonen / Broadcom Limited I would assume the compression in RoE is not a feature of the Ethernet link. It rather is a feature of the RoE payload traffic and would be very specific to that transported payload. Remove Ethernet link level compression. Remove compression and encryption parameters from ethernet and cpri link parameters. #48 Type: TR TF: TF3 Clause: 6.7 Page: 28 Line: 0 Commenter: Jouni Korhonen / Broadcom Limited In Table 7 stating "Structure Agnostic" is means basic frames does not make the mapper agnostic. This should reworded to be agnostic to CPRI. Something like "transported radio framing protocol units such as Basic Frames in a case of CPRI". When merging tunneling and agnostic mappers,.lenpack units are in Octets #49 Type: TR TF: TF3 Clause: 6.8 Page: 29 Line: 0 Commenter: Jouni Korhonen / Broadcom Limited In Table 8 stating "Structure Agnostic" is means basic frames does not make the mapper agnostic. This should reworded to be agnostic to CPRI. Something like "transported radio framing protocol units such as Basic Frames in a case of CPRI". When merging tunneling and agnostic mappers,.lenpack units are in Octets #50 Type: TR TF: TF3 Clause: 7.1 Page: 30 Line: 7 Commenter: Jouni Korhonen / Broadcom Limited Tunneling mapper is more or less equivalent to the agnostic mapper (assuming the agnostic mapper is also changed accordingly to be not specific to CPRI as expected). The real difference is that the tunneling mapper does not remove the 8B/10B line coding, which the Structure Agnostic mapper does. Suggest removing the entire Section 7.1. We will simplify the standard by merging these mappers. Section 7.1 will be absorbed into 7.2 We will add parameters to indicate; a) Whether line coding should be removed/added for RoE encapsulated payloads b) The encoded line rate in bps Page 5 of 11

6 #51 Type: TR TF: TF3 Clause: 7.2 Page: 31 Line: 14 Commenter: Jouni Korhonen / Broadcom Limited The current text is CPRI specific, which by PAR is not corrent. Remove CPRI specific references. We will simplify the standard by merging these mappers. Section 7.1 will be absorbed into 7.2 #52 Type: TR TF: TF3 Clause: 7.2 Page: 31 Line: 22 Commenter: Jouni Korhonen / Broadcom Limited Comment Status: Withdraw Response Status: None Commenter Satisfaction: None Category: One RoE packet may contain multiple transported radio framing protocol "framing units" (CPRI basic frame as an example). While incrementing the sequence number by 1 for each sent RoE packet is fine but that might be different is other use cases. The sequence number increment should be flexible regarding that fact, which the sequence number description in subclause already allows. Add a sentence or a statement that other than CPRI mappers may use different increment values for the pcounter. Alternatively move the CPRIspecific part of the text of this subclause (and reworded) into subclause ************** Comment withdrawn on , at 11:37 #53 Type: ER TF: TF3 Clause: Page: 31 Line: 30 Commenter: Jouni Korhonen / Broadcom Limited The agnostic mapper description shall not be CPRI specific. Remove the CPRI from subclause header. We will simplify the standard by merging these mappers. Section 7.1 will be absorbed into 7.2 #54 Type: ER TF: TF3 Clause: Page: 32 Line: 28 Commenter: Jouni Korhonen / Broadcom Limited Flow ID 0 is wrong in this context. RoE has reserved NIL flowid for this purpose. Change "0" to NIL flowid #55 Type: TR TF: TF3 Clause: Page: 32 Line: 38 Commenter: Jouni Korhonen / Broadcom Limited The modulo logic is turned off when the.module is set to 0. The text says the same "effect" is achieved by setting the modulo to 1 and index to 0. While it is true but misleading in a sense that the latter does not turn off the logic just produces the same outcome. There should be only one way of doing this. Delete "(the same effect is also achieved by setting the.modulo to 1 and.index to 0)". #56 Type: E TF: TF3 Clause: Page: 33 Line: 5 Commenter: Jouni Korhonen / Broadcom Limited Typo remove unnecessary "." OK #57 Type: E TF: TF3 Clause: Page: 33 Line: 6 Commenter: Jouni Korhonen / Broadcom Limited In Table 9 there is typo in.modulo description. Change "turns of" to "turns off". #58 Type: ER TF: TF3 Clause: Page: 34 Line: 1 Commenter: Jouni Korhonen / Broadcom Limited Missing reference to Figure? Add a reference to Figure 12? Accept #59 Type: ER TF: TF3 Clause: Page: 34 Line: 15 Commenter: Jouni Korhonen / Broadcom Limited Missing shall Change "The following information is supported" to "The following information shall be supported". Add parameters to clause 6.6 c) Protocol version at location Z.2.0 i.e., control word 2. d) HDLC bit rate at location Z.66.0 i.e., control word 66. e) L1 signaling at location Z i.e., control word 130. f) Ethernet pointer at location Z i.e., control word 194. Add text to to say that these get populated. Page 6 of 11

7 #60 Type: TR TF: TF3 Clause: Page: 34 Line: 31 Commenter: Jouni Korhonen / Broadcom Limited Wrong figure reference. Change "Figure X" to "Figure 13". #61 Type: E TF: TF3 Clause: Page: 35 Line: 12 Commenter: Jouni Korhonen / Broadcom Limited Extra ".". Remove extra "." from the mapperid example. #62 Type: E TF: TF3 Clause: Page: 36 Line: 29 Commenter: Jouni Korhonen / Broadcom Limited Typo. Change "dif" to "If". #63 Type: E TF: TF3 Clause: Page: 37 Line: 2 Commenter: Jouni Korhonen / Broadcom Limited Typo. Change "collected. to the" to "collected. The". #64 Type: E TF: TF3 Clause: Page: 37 Line: 4 Commenter: Jouni Korhonen / Broadcom Limited Typo. Change "the.hfnmodulo" to ".hfnmodulo". #65 Type: E TF: TF3 Clause: Page: 37 Line: 23 Commenter: Jouni Korhonen / Broadcom Limited Comment Status: Withdraw Response Status: None Commenter Satisfaction: None Category: Incorrect number range for cwnum. For the.cwnum in Table 13 it is stated valid range is 0 to 63. However, subclause page 36 line 26 states the valid range is 1 to 64. Correct Table 13 accordingly i.e., the valid range to 164. At the same time bits needed for the range changes from 6 to 7. ************** Comment withdrawn on , at 16:00 There are a few errors here #66 Type: E TF: TF3 Clause: Page: 38 Line: 17 Commenter: Jouni Korhonen / Broadcom Limited Remove explicit number assignments for the flowid. Delete "( b)"., it is already stated. #67 Type: TR TF: TF3 Clause: Page: 39 Line: 11 Commenter: Jouni Korhonen / Broadcom Limited Current text prohibits 1 to many communication usiong control packets. Remove text "between two RoE endpoints" Change to 'The packet payload carries a single flow or a group of flows between RoE nodes' also applies to 7.5 #68 Type: T TF: TF3 Clause: Page: 39 Line: 15 Commenter: Jouni Korhonen / Broadcom Limited Text missing. Needs some writeup. I would say here also that the flowid in this case defines which control word mapper/container is in use. Numbering incorrect. Will add 'Editor's Comment To be defined at a later date.' #69 Type: ER TF: TF3 Clause: Page: 39 Line: 16 Commenter: Jouni Korhonen / Broadcom Limited Text missing. Add description. Numbering incorrect. Will add 'Editor's Comment To be defined at a later date.' #70 Type: TR TF: TF3 Clause: Page: 39 Line: 19 Commenter: Jouni Korhonen / Broadcom Limited I has not been stated anywhere what format the "targettimestamp" is. Add a short description and point to RoE timestamp format in subclause Change to 'The timing packet is a control packet which contains both the seqnum and timestamp field. targettimestamp contains the orderinfo as a timestamp and targetseqnum contains the associated orderinfo in seqnum format as defined in ' Page 7 of 11

8 #71 Type: E TF: TF3 Clause: 7.5 Page: 40 Line: 4 Commenter: Jouni Korhonen / Broadcom Limited Wrong reference. Change "subclause 4.2" to "subclause 4.3". #72 Type: E TF: TF3 Clause: Page: 40 Line: 7 Commenter: Jouni Korhonen / Broadcom Limited Text missing. Add description. Will add 'Editor's Comment To be defined at a later date.' #73 Type: E TF: TF3 Clause: Page: 40 Line: 8 Commenter: Jouni Korhonen / Broadcom Limited Text missing. Add description. Will add 'Editor's Comment To be defined at a later date.' #74 Type: ER TF: TF3 Clause: Page: 40 Line: 12 Commenter: Jouni Korhonen / Broadcom Limited Comment Status: Withdraw Response Status: None Commenter Satisfaction: None Category: This subclause does not state that the payload field format shown in Figure 17 applies to native RoE data flows and structure aware mappers. And also for the case when the payload is samples. Add description. ************** Comment withdrawn on , at 16:07 #75 Type: TR TF: TF3 Clause: Page: 24 Line: 2 Commenter: Jouni Korhonen / Broadcom Limited The current timestamp does not handle "past timestamps" at all. Add support for "acceptable timestamp window", which would allow detecting late packets and past timestamps within the "acceptable timestamp window" limits. See the attached presentation tf3_1606_pastts_1.pdf for further information. Editor will add text consistant with tf3_1606_korhonen_pastts_1.pdf page 13. The new variable is a parameter named accepttimewindow and is associated with all mappers and is a 29bit value which reflects the integer and fractional ns of the timestamp. A recieved packet with a timestamp minus currenttime which is either negative or greater than the accepttimewindow consitutes an error condition, where currenttime is the current time truncated to a similar 29bit value. #76 Type: ER TF: TF3 Clause: 2 Page: 14 Line: 6 Commenter: Bomin Li / bli use the full name of the standards use the full name of the standards. #77 Type: ER TF: TF3 Clause: 3.5 Page: 16 Line: 9 Commenter: Bomin Li / bli Comment Status: Resolved Response Status: Reject Commenter Satisfaction: None Category: should the bit ordering by aligned with ieee802.3? refer to figure 31, bit 0 corresponds to LSB No desire to change it at this point. Action item (JK) to draw out entire packet example with populated fields for an appendix. #78 Type: ER TF: TF3 Clause: 3.5 Page: 16 Line: 13 Commenter: Bomin Li / bli should the bit ordering by aligned with CPRI sepecification? refer to CPRI specification v7.0 page 20, subclause , bit 0 corresponds to LSB Change text from 'The CPRI specification defines a different ordering scheme. Translation from one scheme to the other is performed, as required, by (de)mappers' to 'For structure aware and native mappers, I,Q samples are transported without their bits interleaved.' #79 Type: ER TF: TF3 Clause: 4.1 Page: 17 Line: 7 Commenter: Bomin Li / bli LCs appears for the first time, spell completely spell completely and add abbreviation #80 Type: ER TF: TF3 Clause: 4.1 Page: 17 Line: 8 Commenter: Bomin Li / bli LCT appears for the first time, spell completely spell completely and add abbreviation Page 8 of 11

9 #81 Type: ER TF: TF3 Clause: 4.1 Page: 17 Line: 9 Commenter: Bomin Li / bli LCD appears for the first time, spell completely spell completely and add abbreviation #82 Type: TR TF: TF3 Clause: Page: 19 Line: 15 Commenter: Bomin Li / bli BER should be 10^12 BER should be 10^12 #83 Type: ER TF: TF3 Clause: Page: 20 Line: 1 Commenter: Bomin Li / bli in figure 6, some arrows have the wrong direction change the direction of the arrows to/from demappers. In addition, srcid and destid ranges are reversed. #84 Type: ER TF: TF3 Clause: Page: 20 Line: 1 Commenter: Bomin Li / bli in figure 6, for CPRI Ports,.cpriID is 0, 1,... N, not 0,0,...n change.cpriid for the second port, from 0 to 1 #85 Type: TR TF: TF3 Clause: Page: 22 Line: 12 Commenter: Bomin Li / bli structure agonostic mapper does not separate control data and sample data. descibe functionalities for different mappers P20. Change to 'Structure aware and native mappers separate control data and sample data into different streams.' #86 Type: ER TF: TF3 Clause: Page: 22 Line: 17 Commenter: Bomin Li / bli first time reader may get lost how to control the use of seqnum or timestamp? indicate that it is controlled by the parameter and refer to the parameter in chapter 6 Add line 'The orderinfo type used for a given flow is determined by a parameter. This parameter is described in Table 7. This parameter shall be maintained throughout the lifetime of the flow.' #87 Type: TR TF: TF3 Clause: Page: 22 Line: 23 Commenter: Bomin Li / bli should it be 0 < pcounter length <= 32 or 0 <= p < 32? change to 0 < pcounter length <= 32 or 0 <= p < 32 Change to a. 0 <= p < 32 //Note we need to adjust seqnum usage in timestamp #88 Type: TR TF: TF3 Clause: Page: 22 Line: 24 Commenter: Bomin Li / bli should it be 0 <= qcounter length < 32 or 0 <= q < p1? change to 0 <= qcounter length < 32 or 0 <= q < p1 Change to b. 0 <= q <= p (if q=p then the qcounter is not present) Also 'The field from p up to and including 31 is the pcounter field and the field from q to p1 is the qcounter field.' #89 Type: TR TF: TF3 Clause: Page: 22 Line: 25 Commenter: Bomin Li / bli should it be 0 < qcounter length + pcounter length <= 32 or nothing? change to 0 < qcounter length + pcounter length <= 32 or remove it remove c) #90 Type: TR TF: TF3 Clause: Page: 30 Line: 22 Commenter: Bomin Li / bli the number of octets in the packet is defined by the parameter change the description that the number of octects is defined by the parameter Change 'The length field in the common header (see 4.2.4) defines the number of octets in the packet.' to 'The parameter.lenpack defines the number of octets which are encapsulated in the RoE payload. This is reflected in the length field in the common header.' Page 9 of 11

10 #91 Type: ER TF: TF3 Clause: 7.4 Page: 38 Line: 7 Commenter: Bomin Li / bli does not fit into this chapter move to chapter becomes 8 (7.5 becomes 7.4) #92 Type: ER TF: TF3 Clause: All Page: All Line: Commenter: Brian Torley / Xilnx The subsection numbers to not align with the subsection headings #93 Type: TR TF: TF3 Clause: Page: 30 Line: 25 Commenter: Brian Torley / Xilnx The first sequence number would be more logical to be 0x0000 rather than 0x0001, as the wrap around value includes 0x0000 agreed change to 'The first sequence number in the stream shall be 0x0000' #94 Type: TR TF: TF3 Clause: Page: 31 Line: Commenter: Brian Torley / Xilnx This section does not sate the first sequence number. It should to be consistent with section Is it 0 or 1? Change to 'The sequence number starts from 0 and is used to reflect the framing of the source data' #95 Type: TR TF: TF3 Clause: Page: 32 Line: 30 Commenter: Brian Torley / Xilnx I am unclear if.lencontainer includes the number of bits in.lenskip. I don't think it does but to be explicit add "Note:.lenContainer does not include the number of bits in.lenskip).. It would be good to add this text.lencontainer does not include the number of bits in.lenskip #96 Type: ER TF: TF3 Clause: Page: 32 Line: 31 Commenter: Brian Torley / Xilnx Change "per each" to "per" #97 Type: TR TF: TF3 Clause: 1.1 Page: 13 Line: 15 Commenter: Brian Torley / Xilnx Change "decapsulate" to "deencapsulate", as decapsulate does not have the same meaning. (Also change in other locations where "decapsulation" is used) #98 Type: ER TF: TF3 Clause: 3.4 Page: 14 Line: 4 Commenter: Brian Torley / Xilnx Table 1 has (*) in one box, but there is no definition what the (*) means or refers to. P16.. Will add to footer. #99 Type: ER TF: TF3 Clause: 4.1 Page: 17 Line: 7 Commenter: Brian Torley / Xilnx LCs/LCt/LCd is missing from section 3.3 (Acronyms and abbreviations). Will explicitly describe. #100 Type: ER TF: TF3 Clause: Page: 20 Line: 9 Commenter: Brian Torley / Xilnx Change Header from "(de)mappers"to "Mappers/DeMappers" OK. Same is true for (de)packetizer #101 Type: TR TF: TF3 Clause: Figure 6 Page: 20 Line: 2 Commenter: Brian Torley / Xilnx The mappers and demappers have both got arrows pointing upwards towards the Ethernet Links. This is confusing as the demapper should be pointing downwards, away from the Ethernet Links. Accept Page 10 of 11

11 #102 Type: TR TF: TF3 Clause: Page: 21 Line: 4 Commenter: Glen Kramer / Broadcom Many "requirements" throughout the draft are vague and/or not testable: RoE parameters are communicated during link establishment and define how the RoE node shall operate. The payload data shall be comprised of the binary stream of tunneled bits without interpretation. The use of sequence number shall be consistent with the corresponding data flow. The control process shall extract the control words for the Fast C&M channel and create an appropriate Ethernet packet out of the extracted Ethernet packet data (e.g., discarding SSD, ESD,IDLE bit sequences and line coding). dif there are multiple containers the areas they define shall not overlap each other. The RoE control packet opcode specification shall describe the exact sequence number handling. The behavior of the control process shall be defined by each mapper that makes use of the control data. There is also a number of deprecated word "will" in the text. Use the reserved words according to IEEE style manual: === The word *shall* indicates mandatory requirements strictly to be followed in order to conform to the standard and from which no deviation is permitted (*shal*l equals *is required to*). Note that the use of the word *must* is deprecated and shall not be used when stating mandatory requirements; must is used only to describe unavoidable situations. The use of the word *will* is deprecated and shall not be used when stating mandatory requirements; will is only used in statements of fact. The word *should* indicates that among several possibilities, one is recommended as particularly suitable without mentioning or excluding others; or that a certain course of action is preferred but not necessarily required (*should* equals *is recommended that*). The word *may* is used to indicate a course of action permissible within the limits of the standard (*may* equals *is permitted to*). ==== Use simple present tense in places of general description, i.e., "define how the RoE node shall operate." ==> "define how the RoE node operates". Need to go through each case. Page 11 of 11