In data networking and transmission, 64b/66b is a line code that transforms 64-bit data to 66-bit line code to provide enough state changes to allow reasonable clock recovery and facilitate alignment of the data stream at the receiver.
The overhead of the 64b/66b encoding is 3.125%, which is considerably less than the more common 8b/10b encoding scheme which has a 25% overhead. At the time 64b/66b was deployed, it allowed 10Gb Ethernet to be transmitted with the same lasers used by SONET OC-192, rather than requiring 12.5 Gbit/s lasers, which were not expected to become available for several years.
As the scheme name suggests, 64 bits of data are transmitted as a 66-bit entity.
The 66 bit entity is made by prefixing one of two possible two-bit 'preambles' to the 64 bits to be transmitted.
- If the preamble is '01', the 64 bits are entirely data
- If the preamble is '10', an eight-bit type field follows, plus 56 bits of control information and/or data
- The preambles '00' and '11' are not used, and generate an error if seen.
The use of the '01' and '10' preambles guarantees a bit transition every 66 bits, which means that a continuous stream of 0s or 1s cannot be valid data. It also allows easier clock/timer synchronization, as a transition must be seen every 66 bits.
The complete payload (consisting of either 64 data bits, or 56 data bits + type byte) are then scrambled using a self-synchronous scrambler function, with the intention of ensuring that a relatively even distribution of 1s and 0s are normally found in the transmitted data. The intention is not to encrypt the data, but to give the transmitted data useful engineering properties. The scrambler does not provide an absolute guarantee that output data will never have a long run-length of 0s or all 1s or other undesirable properties, but instead allows strong statistical bounds to be put on the probability of such events. Practical designs will choose system parameters such that a bit-error due to long run-lengths is vanishingly unlikely. This method is different from the codebook based approach of 8B/10B encoding.
The encoding and scrambling are normally done entirely in hardware, the scrambling using a linear feedback shift register. Upper layers of the software stack need not be aware that the link layer is using this code.
Properties and application
64b/66b's design goals are clock recovery, stream alignment, DC balance, transition density and run length. Unlike 8b/10b which guarantees strict bounds on DC balance, transition density and run length, 64b/66b provides statistical bounds on these properties. Although it is theoretically possible for a specific data pattern to align with the scrambler state and produce a long run of 65 zeroes or 65 ones, the probability of such an event is equal to flipping an unbalanced coin and having it come up in the same state 65 times in a row. At 10 Gigabits per second, the expected time for a 64 bit run-length to occur is 265/109 seconds, or about once every 58 years. Most clock recovery circuits designed for SONET OC-192 and 64b/66b are specified to tolerate an 80bit run length. Such a run cannot occur in 64b/66b because transitions are guaranteed at 66 bit intervals.
An earlier scrambler used in Packet over SONET/SDH (RFC 1619, 1994) had a short polynomial with only 7 bits of internal state which allowed a malicious attacker to create a Denial-of-service attack by transmitting patterns in all 27-1 states, one of which was guaranteed to desynchronize the clock recovery circuits. This vulnerability was kept secret until the scrambler length was increased to 43 bits (RFC 2615, 1999) making it impossible for a malicious attacker to jam the system with a short sequence.
64b/66b avoided this vulnerability by using a scrambling polynomial with enough random internal state (58 bits) that it was provably impossible for a dedicated attacker to force a 64 bit run-length pattern any more effectively than sending random data.
Similarly, the DC balance of 64b/66b is not absolutely bounded. However, it can be shown that the scrambler output closely approximates a sequence of random binary bits. Passing such a sequence through an AC-coupled circuit produces a "baseline wander" that follows a gaussian distribution, and the impact on the system error rate can be statistically quantified. In practice, a modest coupling capacitor value of 0.001uF in a 100 ohm system is sufficient to guarantee that a DC drift of more than 2.5% will occur less often than once per 1022 bits (about 31,700 years at 10Gbit/s). 
The main contribution of 64b/66b is the observation that the deterministic runlength and transition density of 8b/10b are not always worth a 25% code overhead, and that solid robust systems could be designed using statistically bounded methods. At some point, the real risk of a nuclear war, meteoric impact, or power supply failure dominate the reliability of both 8b/10b and 64b/66b systems.
If the DC balance of 64b/66b is not sufficient for some application (such as a requirement for using small coupling capacitors implemented on chip), the Interlaken protocol improves the DC balance further by trading off more coding bits. By using the 64b/67b encoding. 64b/67b extends 64b/66b with explicit DC balancing.
Technologies that use it
- R.C. Walker; R. Dugan (18-20). "64b/66b low-overhead coding proposal for serial links". IEEE 802.3 High Speed Study Group. pp. 11–13.
- Ibid., pages 15-16.
- Note that this is the original proposal to the IEEE, and some changes were made for the final, agreed standard. The circuit diagram for the 58 bit scrambling polynomial described in the proposal is identical to the one adopted in the standard. However, the proposal numbers the registers in reverse order such that the x58+x19+1 polynomial in the proposal is the same as the one labelled x58+x39+1 in the standard.
- PatentView/EP1133123 Software Patent: 64b/66b decoding, for packetized serial data
- ERROR CORRECTION ON 64/66 BIT ENCODED LINKS
- Introduction to 10 Gigabit 64b/66b (Clause 49)
- A reference design by Xilinx on 64b/66b encoding and scrambling
- Aurora 64B66B IP core using 64b/66b encoding
Read in another language
This page is available in 1 language