| Thread Links | Date Links | ||||
|---|---|---|---|---|---|
| Thread Prev | Thread Next | Thread Index | Date Prev | Date Next | Date Index |
Dear Colleagues, Unfortunately, I won't be able to attend tomorrow's IEEE P802.3dt Task Force meeting. I therefore wanted to provide a few thoughts regarding D1.0 comment #13. I would like to clarify that while the MAC checks the FCS, I believe the MA_DATA.indication primitive still passes a frame with an FCS error to the MAC Client, but with reception_status parameter set to frameCheckError (see below for further information). Further, in such a situation, I believe the packet_metadata parameter of the associated EMS_PM.indication primitive, derived from the preamble/SFD metadata, may or may not contain an error itself. As a result, while I support improving the wording, I don't believe the current wording is incorrect. As I understand it, the current IEEE P802.3dt objectives <https://www.ieee802.org/3/dt/projdoc/objectives_ems_261026.pdf> limit support for both per-packet and packet-independent metadata services to PHYs where FEC protects the entire data stream and uncorrectable RS-FEC codeword errors result in an FCS error. As a result, the absence of an FCS error can be used to indicate that the preamble/SFD metadata is error-free (to the level of protection provided by the FEC). That said, the presence of an FCS error does not necessarily indicate that the preamble/SFD metadata contains an error, since the error could have occurred elsewhere in the frame. The preamble/SFD metadata could therefore still be used if a mechanism were provided to independently detect errors in that metadata. I can think of two existing IEEE 802.3 examples of such error-detection mechanisms. Clause 99 MAC Merge uses the preamble/SFD fields to signal the mPacket format (99.3.3, 'Start mPacket Delimiter') and the fragment count (99.3.4, 'frag_count'), with the permitted values selected to have a Hamming distance of four. Clause 65 point-to-point emulation uses octets 3 to 7 of the preamble to indicate which MACs on the point-to-multipoint medium may receive the packet using a 'Logical Link ID' (LLID). A CRC-8 is used to protect the 'start of LLID delimiter' (SLD) and LLID values (see 65.1.3.2, 'Transmit'). Since we are defining a generic per-packet metadata service, it seems reasonable to allow a protocol that uses the preamble/SFD metadata in the presence of an FCS error if, for example, it provides error protection of the information it uses in the preamble/SFD metadata. Based on this, perhaps the text in question can be changed to read 'The data conveyed by EMS_PM.indication might be in error if the MAC indicates an error in the associated packet. The EMS client may nevertheless use the data if the protocol provides a means to determine that the data conveyed by EMS_PM.indication is valid.'. I'm sure this can be improved. Best regards, David MAC receive operation and ReceiveStatus --------------------------------------- The MA_DATA.indication primitive defined in subclause 2.3.2 of Clause 2 'Media Access Control (MAC) service specification' includes the reception_status parameter which can take the values receiveDisabled, receiveOK, frameTooLong, frameCheckError, lengthError, or alignmentError (see subclause 4A.2.7.1) as follows. The MA_DATA.indication message is generated by Figure 4A-4, 'MAC client receive interface state diagram'. On entry to the WAIT_FOR_RECEIVE state, the ReceiveFrame function is called. The ReceiveFrame function does not complete until a frame has been received. The ReceiveFrame returns the value ReceiveStatus and passes the individual frame fields back to its caller (see subclause 4A.2.9). If enabled, ReceiveFrame calls ReceiveLinkMgmt to receive the next frame, and then calls ReceiveDataDecap to return the frame's fields if the frame's address indicates that it should do so. ReceiveDataDecap sets ReceiveStatus to frameTooLong if the frame exceeds the maximum size. Otherwise, a correct FCS results in receiveOK, or lengthError if dribble bits are also present. An incorrect FCS results in frameCheckError, or alignmentError if dribble bits are also present. This is illustrated in Figure 4A-2b 'Control flow summary'. Note: Dribble bits can only occur where the MAU/PHY and AUI/xMII permit a received frame to terminate other than on an octet boundary. The ReceiveFrame function then completes, returns the ReceiveStatus value as the function result, and passes back the individual frame fields. As a result, the state diagram transitions to the PASS_TO_CLIENT state, issuing an MA_DATA.indication message to the MAC Client using the supplied individual frame fields and mapping ReceiveStatus to the reception_status parameter. The state diagram then immediately transitions back to the WAIT_FOR_RECEIVE state, calling the ReceiveFrame function to prepare for the next packet. As a result, a MA_DATA.indication message is issued to the MAC Client when an FCS error occurs. I have captured this in the attached simulation. If the frame check sequence parameter is missing from the MA_DATA.request message, the MAC will generate the FCS on transmission. I have therefore set the frame check sequence parameter to an incorrect value on the second transmission to create the FCS error. As shown, this results in an MA_DATA.indication message with reception_state set to frameCheckError. ________________________________________________________________________ To unsubscribe from the STDS-802-3-EMS list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-EMS&A=1
Attachment:
fcs_error.pdf
Description: fcs_error.pdf