Thread Links Date Links
Thread Prev Thread Next Thread Index Date Prev Date Next Date Index

[802.3_SPEP2P] Half-duplex issues in MAC Merge: Clause 99 MAC Merge verification function

Dear all,

In addition to the potential issues with the Clause 99 state diagrams I sent a few moments ago, I also wanted to note what seems to be a more fundamental half-duplex issue with MAC Merge, just in case there is ever an effort in the future to support this. It relates to the Clause 99 MAC Merge verification function. I apologise if this has already been addressed, or if it has been decided to not support the verification function in half-duplex operations, but I don't recall this being discussed, and couldn't find anything in the archive about this.

As described in subclause 99.4.3 'Verifying preemption operation', the verification function checks that the link can support the preemption capability. If the preemption capability is enabled but has not been verified, the MAC Merge sublayer transmits a verify mPacket and waits for the reception of a respond mPacket to confirm that the remote station supports the preemption capability.

The first issue is that these verify and respond mPackets are not transmitted by the MAC. Instead, they are transmitted by the verification function within the MAC Merge sublayer and are injected in to the transmit path by the Transmit Processing function (see Figure 99-3 'MAC Merge sublayer Functional Block Diagram'). Specifically, these packets are generated by the TX_V and TX_R functions (see 99.4.7.4 'Functions') called by the TX_VERIFY and TX_RESPOND states in the Transmit Processing state diagram (see Figure 99-5). As an example, the TX_V function is specified to produce '576 rPLS_DATA.requests to send a verify mPacket'.

The problem with this is that the TX_VERIFY and TX_RESPOND states are simply entered into after a minimum of a IPG time after the end of the previous transmission, and then the verify or respond mPacket is just sent. While a verify or respond mPacket is being sent, an attempt to transmit by the MAC is not serviced until an IPG time after of the transmission of the verify or respond mPacket. This results in correct operation for a full-duplex link. It, however, could result is incorrect operation for a half-duplex link as transmission of the verify and respond mPackets do not obey the CSMA/CD protocol, even with the changes that were proposed to support half-duplex operation.

As an example, since transmission of a verify or respond mPacket isn't based on carrier sense, a late collision could be generated. Now this could be addressed by changing the state diagrams to require carrier sense before a verify or respond mPacket transmission, but that won't address the need for back-off and retry should a collision happen during the transmission of a verify or respond mPacket.

The second issue is that the verify and respond mPackets are based on a full-duplex point-to-point link. As a result, they do not support addressing, and the preemption capability is enabled and disabled for all transmissions. As a result, when an end station on a half-duplex mixing segment sends a verify mPacket, if just one other station on that half-duplex mixing segment replies with a respond mPacket, it will be considered confirmation to that end station that it can now enable the preemption capability. And once enabled, all transmissions are preemptable, even though only one other end station on the half-duplex mixing segment responded it is preemption capable.

Best regards,
  David

________________________________________________________________________
To unsubscribe from the STDS-802-3-SPEP2P list, click the following link: https://listserv.ieee.org/cgi-bin/wa?SUBED1=STDS-802-3-SPEP2P&A=1