Hi Vishal,
I apologize for not being clear.
We have to look quite deep at the physical layer of Ethernet to understand how two interconnected network cards recognize they are interconnected and can start exchanging frames.
When 10BaseT Ethernet was being standardized, IEEE needed to invent a mechanism that allowed a network card (furthermore called as NIC) and the opposite device, be it a hub, a switch or another NIC, to find out they are connected together. Older versions of Ethernet (10Base5, 10Base2) did not incorporate this functionality. Without it, a hub or a switch would not know if a station is connected to its particular port, and conversely, a NIC would not be able to tell you that it is successfully connected to another device on the other end of the cable run.
So IEEE came up with idea of so-called Link Pulses, or simply LPs, that are sent from every 10BaseT port each 16ms (+- 8ms) if no frames are being sent at the same time. An LP is not a frame itself, it's just a pulse placed on the transmit pair of wires. As a result, the NIC was either sending frames, or if there were no frames to be sent, LPs were sent each 16ms. If a NIC was continuously receiving frames or LPs (with proper interframe and LP spacing, of course) it knew it was successfully connected to another device. If no LPs and no frames were received over a certain period of time, a NIC declared a link-down status and considered the port to be disconnected.
With 100BaseTX Ethernet, things are similar but more complex. The concept of link pulses is retained but in addition, the IEEE needed to provide negotiation capabilities so that if you interconnect 100BaseTX and 10BaseT cards, you can reliably detect not only that there is a device connected on the other end but also what speed and duplex it supports. So the idea of link pulses was extended - instead of sending a single pulse each 16ms that just declares "I am up", 100BaseTX cards send a series (a burst) of pulses each 16ms that actually form a codeword indicating the supported speeds and duplexes, declaring "I am up and these are my supported speeds and duplexes". Naturally, these pulses must occur in faster succession in order to fit into the allotted time, therefore, they have been renamed into Fast Link Pulses, or FLPs, and retroactively, the former Link Pulses from 10BaseT were renamed to Normal Link Pulses, or NLPs, to distinguish them from FLPs introduced in 100BaseTX. The FLPs are the basis for Ethernet autonegotiation capabilities we commonly use nowadays. Recall, neither NLPs nor FLPs are frames.
That is not all, however. In 100BaseTX, data are not sent as simple bytes. Instead, each byte (8-bit value) is first split into a 4-bit nibble and subsequently, this 4-bit nibble is assigned a new 5-bit codeword, or a symbol, according to a fixed translation table. The 100BaseTX then transmits these 5-bit symbols. This coding is called 4B5B in literature (although the 'B' should really be lowercase). On the receiving NIC, the 5-bit symbols are received, translated back to their 4-bit nibble counterparts, the bytes are recombined from the nibbles and voila - you have your original data back. This coding is done for two purposes: first, the 4B5B translation is carefully chosen so that it avoids long runs of bits of identical value which can pose problems in the resulting signal transmission, and second, the 5-bit symbol alphabet gives you additional 16 symbols that do not map back to any 4-bit data nibble and that can be used as special commands.
One of these special commands is an IDLE symbol. This IDLE symbol is being sent from a 100BaseTX NIC whenever there is no frame to be sent. In fact, a 100BaseTX NIC is continuously sending 5-bit symbols - either symbols that correspond to data in a frame being transmitted, or other special symbols, or in the absence of any other information to be sent, the IDLE symbols. A 100BaseTX NIC is never silent. This also means that FLPs are not sent anymore after a 100BaseTX card has negotiated 100Mbps operation because there is no silent period to send them in. In 100BaseTX, the FLPs are used during link initialization and autonegotiation, and after 100Mbps operation has been negotiated, the card stops sending FLPs and starts sending IDLE symbols or other symbols as required, but it is not going to be silent anymore at any moment.
But this is still not all. The FCC bureau was concerned about possible electromagnetic interference emanating from a cable run caused even by the 5-bit symbols as appearing on the cable. The 4B5B code makes sure that each 4-bit data nibble is transcribed into a 5-bit symbol that has at least a single transition between a binary 1 or 0, but it is not immune against situation where identical symbols are sent repeatedly. For example, the IDLE symbol is, in binary, 11111. During periods when there are no data to be sent, a NIC would continuously transmit this sequence of bits that would result in periodic pattern of voltages appearing on the cable, causing interference in a quite specific frequency band. Therefore, the 100BaseTX NIC performs yet another operation - a so-called scrambling whereby the flow of 5-bit symbols is XOR-ed with a pseudorandom sequence of bits obtained by a pseudorandom number generator built into the NIC (technically, it is a self-synchronizing linear feedback shift register). This XOR-ing of 5-bit symbols by a pseudorandom sequence results into the output flow of bits also having a pseudorandom property, thereby removing any regular or periodic patterns and spreading out the resulting electromagnetic spectrum. Also, the XOR operation has another nice property - XOR-ing a bit twice with the same value yields the original bit back. This means that if the scrambled stream of bits is XOR-ed again by the same pseudorandom sequence that was used to scramble it, you get the original 5-bit symbols back, as the pseudorandom sequence will eliminate itself in the XOR operation. This operation is called descrambling.
There is one hidden gotcha in this scrambling operation - if pseudorandom number generators are used, how is it guaranteed that they generate identical stream of bits so that data can be correctly descrambled at the receiving side? The answer lies in the IDLE symbols again. After a NIC has negotiated 100Mbps operation with its neighbor, it must synchronize the pseudorandom number generators. It does this by listening to the data being received and adjusting its pseudorandom number generator until the descrambled stream starts producing IDLE symbols that are being sent from the other side. The other side does the same - it listens to us sending IDLE symbols and adjusts its own pseudorandom number generator until it is able to recognize IDLE symbols.
Only now I can explain my points from the original post:
in the case of 10Mbps Ethernet, one of the ports will miss the NLP pulses and thus keep a port reported as down
This means that if a TP cable is broken so that it can carry data only in a single direction, the NIC in the opposite direction will stop receiving not only frames but also NLP pulses from the other party and declare the link disconnected. This avoids the loop because if a link is declared down, the port is not transmitting frames.
in the case of 100Mbps Ethernet, one of the ports will initially lose synchronization with the other party (the IDLE symbols will cease to be received) and subsequently it will miss the FLP pulses, thereby not being able to perform autonegoation with the other side, keeping the port down
This means that if a TP cable is broken so that it can carry data only in a single direction, the NIC in the opposite direction will stop receiving frames and IDLE symbols from the other NIC and lose synchronization in its pseudorandom number generator. This will result in link loss event, and the NIC will try to reestablish the link by listening to FLPs from the other party that will never come because the link is broken. Again, the port will be declared down and will not be allowed to send any data frames.
in the case of 1Gbps and faster Ethernets, all 8 wires are used in both directions simultaneously so a physical unidirectional condition can not be created at all
The TP cabling has its limits on the maximum frequencies it can carry. 1Gbps and faster Ethernet transmission even in a single direction requires using 8 wires in parallel because otherwise, on a smaller count of wires, the signal would either need to change more rapidly or to have more states, neither of which is feasible with respect to analog transmission properties of TP cabling. And because we want to use full duplex, we need to use all 8 wires in a TP cable simultaneously in both directions. This is accomplished using Digital Signal Processors, or DSPs, that allow you to numerically subtract the signal you have put on the wires from the signal that is currently present on the wires, yielding the signal that was put on the wires by the opposite device.
However, if all 8 wires are used for bidirectional transmission simultaneously, there is - by its very definition - no unidirectional state possible. If you break a single wire, on 1Gbps and higher, both directions will be impaired. Therefore, discussing the unidirectional link for 1Gbps and faster Ethernet technologies on TP is basically not relevant.
Does this help? I know this is a complicated topic related to physical layer operations that most networkers somehow don't like to know about, but in this case, this is really necessary to understand if a unidirectional link condition can be created on TP cabling at all.
Please feel welcome to ask further. I can understand that this topic needs more clarification that I've been able to put here at the moment.
Best regards,
Peter
