Back to the roots: it all started with SDLC

My recent post about problems with old modems has generated a lot of comments with some very useful ideas, but nobody addressed the question “why was a long string of ones not a problem?”, so let's start there. Almost all WAN synchronous protocols in use today are descendants of venerable SDLC invented by IBM more than 30 years ago. SDLC was later extended to support connectionless and balanced modes, resulting in HDLC. PPP is just an extension of HDLC, adding support for negotiations and standard layer-3 protocol demultiplexing. In SDLC, IBM also solved the frame delimiting and associated escape character problem inherent in previous protocols like BSC (DLE was used in BSC) by introducing bit stuffing: a zero would be inserted after five consecutive ones (and silently removed by the receiver) to differentiate the regular data stream from framing (six consecutive ones) and abort (more than six consecutive ones) sequences. Thus, the HDLC (or PPP) data stream can never contain more than six consecutive ones and the long sequences of ones never cause synchronization loss.

IBM obviously also had problems with bad modems and solved it with the NRZI encoding that was part of SDLC standard (and a major pain in the good old days when the appliques on the old Cisco routers did not support it and we've been trying hard to penetrate IBM accounts). You can still configure NRZI encoding on most routers' serial links (it might depend on the actual hardware platform) with the nrzi-encoding interface configuration command (you had to do it with jumpers in the AGS+). Incidentally, changing interface encoding to NRZI was really helpful when you had to break things in the preparation for the troubleshooting part of the original CCIE lab).

Enough theory, let's summarize the proposed solutions:

  • The nrzi-encoding (if available) is the best one, as it reliably solves the problem, is transparent and does not incur additional overhead.
  • Compression or encryption are OK, but they result in significant CPU overhead (unless you have hardware encryption/compression modules) and might (at least in theory) still produce a long sequence of zeroes, although with a very low probability. IPSec also introduces overhead due to additional IPSec headers.
  • LFI (effectively multilink PPP over a single link) is also a good solution, as the PPP framing and MLPPP headers break the long sequences of zeroes (you might have to fine-tune the fragment size with ppp multilink fragment size configuration command), but it introduces overhead on the WAN link.
  • IP fragmentation would work, but would be quite bandwidth-consuming. If the fragmentation would be performed by the router, the overhead would be 20 bytes per fragment (IP header), if the sending host performs the fragmentation, the overhead is 40 bytes per fragment for TCP sessions. For example, if we reduce the IP MTU size to 256 bytes, the TCP session overhead is over 18% (and we were scoffing at the ATM designers that made us live with 10% overhead).
There were also a few suggestions that would not work very well:
  • The invert data command would only help if the modem has problems with long strings of zeroes, not with long strings of the same value.
  • The tunnel key command just sets a 4-byte field in the GRE header but does not affect the encapsulated data at all.

3 comments:

  1. For the record the original NP-2T Two-Port Serial module for the old Cisco 4000 series routers also need to change hardware jumpers if you want to enable NRZI. Starting with the NP-4T module Cisco began to support software-selectable NRZI control from the IOS CLI. Also, the older Cisco 3000 series routers only supported NRZ only; there was no NRZI support until the 3104 and 3204 models were released.

    I like the LFI solution because in most cases if we are doing VoIP LFI would be required anyway for circuit speed that is below 768K. For circuit speed like fractional DS3 or full DS3 we can enable scrambling to overcome the long string of zeros.

    ReplyDelete
  2. That was a good one, I completely forgot about bit stuffing. :)

    Note that Wikipedia NRZI article you refer to gives an example where transition happens on 1s, which wouldn't help. SDLC's NRZI has transition on 0s.

    ReplyDelete
  3. Hello there I am so delighted I found your blog page, I really found you by mistake, while I was researching for something else,
    Regardless I am here now and would just like to say many thanks for a remarkable post and a all round enjoyable blog
    I don’t have time to go through it all at the moment but I have bookmarked it and also included your RSS feeds, so when I have time I will be back to
    read more, Please do keep up the excellent work.
    industrial training indore

    ReplyDelete

You don't have to log in to post a comment, but please do provide your real name/URL. Anonymous comments might get deleted.

Ivan Pepelnjak, CCIE#1354, is the chief technology advisor for NIL Data Communications. He has been designing and implementing large-scale data communications networks as well as teaching and writing books about advanced technologies since 1990. See his full profile, contact him or follow @ioshints on Twitter.