| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Pat, It is very hard for me to follow the suggested changes for “aMACMergeStatusRx” and “aMACMergeStatusTx” – I would very much appreciate writeup in the attached document and not just comments – these are very hard to follow. As far as “oMACMergeFrameMfcsErrorCount” – if the carried MFCS does not match the calculated MFCS, that does not necessarily mean it is CRC – it can be just bit error in a fragment and assembling such a frame is pointless. Seems that if we just rely on matching MFCS to indicate whether it is a fragment or not, we can have a situation where we have an error in MFCS, merge layer assumes it is the end of the frame and then we push incomplete MAC frame to MAC. This would generate errors, decreasing link reliability. I am not OK dropping ”oMACMergeFragCountOutOfOrderRx”. For debug purposes, it is better to have more data to see what kind of link problems we have, rather than just have one bin that says something went wrong. I can make all changes needed to “oMACMergeFragCountRx and oMACMergeFragCountTx” – I just need to have more to work on. Please suggest specific text changes – that would make discussion simpler. Thanks I think the description of “aMACMergeHoldCOunt” is clear – “A count of times MM_CTL.request(HOLD) primitive was asserted, interrupting transmission of a preemptable MAC frame”, i.e., we count only times it is asserted during a transmission of preemptable frame. Other assertions would not be counted. Marek From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx] Resending with the subject modified to reflect the email contents. From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx] Thank you for making a good start on adding MACMerge managed objects. My comments: IEEE 802.3 uses a<attribute name>, not o<attribute name> for attributes. This may need to be discussed at the meeting: Since we decided that the express and premptable MACs each appear in management as regular MACs, do we need something to indicate which premptable MAC is associated with the express MAC? Or is that handled by just indicating it in an entity relationship diagram? Should we add MAC Merge to 30.3 or do a separate figure for it? For oMACMergeStatusRx, If you support MAC Merge, the MAC Merge sublayer is always enabled including the receive processing function. The status that would be useful to report is whether SMDs other than 0xD5 have been received. (That means that the link partner has enabled preemption transmission and there is nothing in the way that has interfered with receiving the non-SFD SMD values.) For oMACMergeStatusTx, I prefer the suggestion we got from someone at the meeting (Peter Jones?) of enabled and active instead of enabling and enabled – enabled means that preemption has been enabled but it isn’t yet operational and active means that preemption has been enabled and verified so that it is operational. Also, I think Tx should be separated into a writable attribute used to configure enabling/disabling MACMerge and a read only attribute used to indicate state. States could be disabled, verifying and active. We may not need oMACMergeFrameMfcsErrorCount. My view of it is that the MAC Merge sublayer checks whether the last 4 bytes match the computed Mfcs for the fragment. If they don’t match, it assumes the last 4 bytes contain a CRC and this is the end of the frame. The MAC then checks the frame CRC and it counts the error if there is a CRC error. oMACMergeFragCountOutOfOrderRx – we already count reassembly errors. Do we need to also count this specific type of reassembly error? I’d suggest dropping this counter. oMACMergeFragCountRx and oMACMergeFragCountTx – express frames, whole premptable frames and fragments are all mframes. It is unclear from the description whether the intent is to count mframes or only mframes containing fragments. We can know the number of frames transmitted and received from the MAC statistics. How about replacing these with counts of non-initial fragments transmitted and received which will indicate how often preemption is occurring? oMACMergeHoldCount – MM_CTL.request(HOLD) can be received without interrupting a premptable MAC frame. I.e. the HOLD came when there was no frame in progress so there was no preemption but there may be premptable frames that would have been started that are held off by it. I think we should just count how many times the primitive was asserted without regard to whether it caused a preemption. From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] Alon, Thank you for the comments. I acted on items 1, 2, and 3, and provide updated document. Item 4 is a bit unclear, since I am not really sure how we can measure reliably indicated times. It is not clear also what purpose these would serve. I would suggest that we discuss these at the next meeting, and then add them to the draft Regards From: Alon Regev [mailto:aregev@xxxxxxxxxxx] Here is my quick feedback on both the clause 30 attributes (as well as some aspects of the current draft): 1. In Beijing (March Plenary) it was decided to use auto-negotiation according to http://www.ieee802.org/3/br/public/2014-03%20Beijing%20CN/8023-IET-TF-1403_Barrass_Negotiation_r1.pdf . I wasn't in the Beijing meeting, but as I interpret this, preemption can be enabled separately in each direction (all IET capable link partners need to be able to Rx IET frames, but Tx can be enabled separately in each direction). I think this implies that we need a separate oMACMergeStatusRx and oMACMergeStatusTx. Here is my proposal a. oMACMergeStatusRx should have one of the following values i. no capabilities tlv received – Additional Ethernet Capabilities TLV has not yet been received from the Link Partner since the Link went up. This is most likely due to the partner not supporting preempting. ii. disabled – Received Additional Ethernet Capablities TLV indicating that link partner does not have MACMerge Tx enabled iii. enabling – Received Additional Ethernet Capablities TLV indicating that link partner has MACMerge Tx Enabled, but preemption operation has not been verified yet iv. enabled – Preemption operation has been verified b. oMACMergeStatusTx should have the following values i. disabled – MAC Merge Tx is disabled. ii. no capabilities tlv received – Additional Ethernet Capabilities TLV has not yet been received from the Link Partner since the Link went up. This is most likely due to the partner not supporting preempting. iii. enabling – MAC Merge Tx function is in the process of being enabled iv. enabled – Preemption operation has been verified and the MAC Merge Tx function is enabled c. oMACMergeStatusRx should only support GET operations d. oMACMergeStatusTx should support GET and SET. 2. I think we need a counter for “aMacMergeMFCSErrorsRx” to count the number of fragments rejected due to an invalid MFCS. 3. Should we have a counter for “aMacMergeSMDErrorsRx” to count fragments/frames rejected due to an unrecognized SMD value? 4. I think we should have some statistics that measure timing values. Here are my proposals: a. oMACMergeHoldTimeTx – Total amount of time the Hold signal has been active (you can divide this by oMACMergeHoldCount to get the average amount of each hold) since preemption was enabled b. oMACMergeNoHoldTimeTx – Total amount of time the Hold signal has been inactive since preemption was enabled c. oMACMergePMacHoldNoEMacFrameTimeTx –Total time when pMAC frames were available, but not transmitted due to MM_CTL.request = HOLD when no frames are available from the eMAC. Regards, Alon Regev Senior Director Ixia Phone: 1-818-983-2438 Fax: 1-818-981-1805 Email: aregev@xxxxxxxxxxx -----Original Message----- Any comments on these? I'd like to know which direction to move forward ... Regards Marek Hajduczenia, PhD Network Architect, Principal Engineer Bright House Networks Office +1-813-295-5644 Cell +1-813-465-0669 -----Original Message----- From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] Sent: July 18, 2014 5:43 PM To: 'Pat Thaler'; 'Peter Jones (petejone)' Cc: 'STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx' Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego Pat et al., Attached please find the first draft of Clause 30 attributes. It would be very helpful if any proposed changes be included as tracked in this document, including any specific comments on any issues with proposed definitions. On the flight back I thought about counters and one simple way to avoid having to repeat all definitions of all MAC, MAC Control, and OAM counters would be to add into oMACMergeEntity pointers to merged MAC, OAM, MAC Control and other sublayers that are merged. That would allow software to identify specific MAC instance (for example) and poll respective counters. I prefer that approach personally much more than repeating pages and pages of counters and attributes with no clear need at all. Note that management software will need to be updated anyway, since oMACMergeEntity will be different and have different capabilities than a typical oMACEntity, hence I do not believe the argument of reuse of software is valid. Regards Marek -----Original Message----- From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] Sent: July 17, 2014 11:13 PM To: 'Pat Thaler'; 'Peter Jones (petejone)' Cc: 'STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx' Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego Pat, Looking at the model in Clause 30, that would require essential a major overhaul of the model shown in Figure 30-3. Note that multiple MAC instances are already allowed (one-to-many between oAggregator and oMACEntity) so I was thinking about adding oMACMerge with multiple-to-one relationship relative to oMACEntity. We *could* replicate all counters from oMACEntity (30.3.1) and then indicate that when oMACMerge is present, these counters represent the sum of respective counters from associated oMACEntity entries. Down the road, that will force a specific implementation of MACMerge in EPON, though, where each instance of express and non-express MAC would have to be bound to a separate instance of MAC Merge sublayer. I am not saying it is a bad thing, just making an observation. Here are the specific attributes that I am thinking of adding to oMACMerge, irrespective of whether we replicate oMACEntity and oMACControlEntity counters and attributes within oMACMerge. Please comment oMACMergeID (sublayer instance id) oMACMergeSupport (indicating whether MACMerge is supported on the DTE) oMACMergeStatus (indicating enabled / active, I do not see a difference between them ... ) oMACMergeFrameAssErrorCount (number of frames with reassembly errors) oMACMergeFrameAssOkCount (number of frames with correct reassembly - combined with oMACMergeFrameAssErrorCount will give us total number of reassembly events, or fragmented frames) oMACMergeFragCountRx (number of received fragments - any interest?) oMACMergeFragCountOutOfOrderRx (number of received fragments out of order) oMACMergeFragCountTx (number of transmitted fragments - any interest?) oMACMergeHoldCount (number of times MM_CTL.request(HOLD) was asserted) oMACMergeFrameExpressCountTx (number of express frames transmitted) oMACMergeFrameExpressCountRx (number of express frames received) Anything else? I am not sure what other error conditions we can really have here ... Once Clause 30 model is clear, preparing SNMP objects based on these definitions should be a breeze Marek -----Original Message----- From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx] Sent: July 17, 2014 5:27 PM To: Marek Hajduczenia; 'Peter Jones (petejone)' Cc: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego What we need to cover in management: How to deal with having two MACs - this was discussed during the meeting with 802.1 TSN. For compatibility, to allow management to look at the MAC parameters and treat them the same as for other ports, there should be one set of combined MAC parameters (i.e. any counters report the sum of events for the two MACs). Also MAC Control. For separate objects for the two MACs, may be okay to just count frames sent and received by each MAC, rather than duplicating all the objects such as error counters. In that case, perhaps these counters could be in MAC Merge rather than in the MAC. Also need for MAC Merge, objects for: Preemption supported, Preemption enabled, Preemption active, Received frames with reassembly errors Perhaps also Counter for MM_CTL.request(HOLD) was received (see what was done for PAUSE or PFC) Counter for number of times that preemption of a frame occurred (or number of continuation mFrames sent because that is the same thing) Same for continuation mFrames received That's all I can think of at the moment. Regards, Pat -----Original Message----- From: Marek Hajduczenia [mailto:marek.hajduczenia@xxxxxxxxx] Sent: Thursday, July 17, 2014 10:40 AM To: 'Peter Jones (petejone)' Cc: Pat Thaler; STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego Hi Peter, I "kind of" volunteered for that, given that I was working with Howard on 802.3.1 on similar topics already. Once Pat sends me the list of parameters that we need to cover, I will start working on Clause 30 objects, and then translate that into 802.3.1 SNMP parameters - potentially, with your help if you are willing to put some time into that. I am sure we can get at least the initial version worked out between the two of us and then post for a broader review in the next version of the draft Regards Marek -----Original Message----- From: Peter Jones (petejone) [mailto:petejone@xxxxxxxxx] Sent: July 17, 2014 1:31 PM To: Marek Hajduczenia Cc: Pat Thaler; STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx Subject: RE: [IEEE 802.3br IET] Agenda and presentations for San Diego Marek, Did you volunteer (or get volunteered) to work on the "Managed objects" item? I'm interested in helping with this, but as part of full disclosure, I'm not very familiar with how 802.3 does the "Clause 30" management dance (but I have lots of SNMP experience). Cheers Peter _______________________________________________ Peter Jones Cisco Systems Principal Engineer 3600 Cisco Way ENG Switching Software San Jose, CA, 95134 USA Tel: +1 408 525 6952 Fax: +1 408 527 4698 Email: petejone at cisco.com Twitter: @petergjones _______________________________________________ -----Original Message----- From: Pat Thaler [mailto:pthaler@xxxxxxxxxxxx] Sent: Monday, July 07, 2014 2:27 PM To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx Subject: Re: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego Dear colleagues, As editor, I'd like to mention the remaining areas where additional technical input would help with completing the draft: - Managed objects - while the SNMP object definitions will be done when 802.3.1 is revised, we still need to add an object class and objects to Clause 30 for the new capability/sublayer and to 79.4 for the TLV. - Preemption verification - How to verify that preemption isn't disrupted by a silent device on the link (e.g. media converter, non-802.1Q compliant switch) that replaces the SMD with an SFD still needs some fleshing out (99.4.2). - Delay constraints - I've put a first cut at delay constraints in the draft (99.4.8). Feedback on whether those are reasonable for implementations to meet is needed. (I also noticed a cut and paste typo on that subclause - the 4th paragraph (not counting Editor's notes) "is held" should be "is not held" (page 30 line 5). Regards, Pat Thaler -----Original Message----- From: Winkel, Ludwig [mailto:ludwig.winkel@xxxxxxxxxxx] Sent: Monday, July 07, 2014 12:32 PM To: STDS-802-3-DMLT@xxxxxxxxxxxxxxxxx Subject: [802.3_DMLT] [IEEE 802.3br IET] Agenda and presentations for San Diego Dear colleagues, Please go to the 802.3br web site to see the Agenda and presentations for San Diego meeting. Besides the intended work on the draft, there is also a task on a liaison letter to ITU. Both documents are in the private area (protected). Mit freundlichen Gruessen / With best regards, Ludwig Winkel Chair of the IEEE P802.3br Task Force Siemens AG , I IA SC FC Oestliche Rheinbrueckenstr. 50 76187 Karlsruhe, Germany Tel.: +49 721 595-6098 Mobile: +49 172 6132658 mailto:ludwig.winkel@xxxxxxxxxxx Siemens Aktiengesellschaft: Chairman of the Supervisory Board: Gerhard Cromme; Managing Board: Joe Kaeser, Chairman, President and Chief Executive Officer; Roland Busch, Klaus Helmrich, Hermann Requardt, Siegfried Russwurm, Ralf P. Thomas; Registered offices: Berlin and Munich, Germany; Commercial registries: Berlin Charlottenburg, HRB 12300, Munich, HRB 6684; WEEE-Reg.-No. DE 23691322 |
Attachment:
oMACMerge R003.docx
Description: application/vnd.openxmlformats-officedocument.wordprocessingml.document