Please Whitelist This Site? I know everyone hates ads. But please understand that I am providing premium content for free that takes hundreds of hours of time to research and write. I don't want to go to a pay-only model like some sites, but when more and more people block ads, I end up working for free. And I have a family to support, just like you. :) If you like The TCP/IP Guide, please consider the download version. It's priced very economically and you can read all of it in a convenient format without ads. If you want to use this site for free, I'd be grateful if you could add the site to the whitelist for Adblock. To do so, just open the Adblock menu and select "Disable on tcpipguide.com". Or go to the Tools menu and select "Adblock Plus Preferences...". Then click "Add Filter..." at the bottom, and add this string: "@@||tcpipguide.com^$document". Then just click OK. Thanks for your understanding! Sincerely, Charles Kozierok Author and Publisher, The TCP/IP Guide

NOTE: Using software to mass-download the site degrades the server and is prohibited. If you want to read The TCP/IP Guide offline, please consider licensing it. Thank you.

The TCP/IP Guide  9  TCP/IP Lower-Layer (Interface, Internet and Transport) Protocols (OSI Layers 2, 3 and 4)       9  TCP/IP Network Interface Layer (OSI Data Link Layer) Protocols            9  TCP/IP Serial Line Internet Protocol (SLIP) and Point-to-Point Protocol (PPP)

SLIP and PPP Overview and Role In TCP/IP 1 2 3 Point-to-Point Protocol (PPP)

SLIP Basic Data Framing Method and General Operation

Here's how SLIP framing works. An IP datagram is passed down to SLIP, which breaks it into bytes and sends them one at a time over the link. After the last byte of the datagram, a special byte value is sent that tells the receiving device that the datagram has ended. This is called the SLIP END character, and has a byte value of 192 decimal (C0 hexadecimal, 11000000 binary). And that's basically it: take the whole datagram, send it one byte at a time, and then send the byte 192 to delimit the end of the datagram.

A minor enhancement to this basic operation is to precede the datagram by an END character as well. The benefit of this is that it clearly separates the start of the datagram from anything that preceded it. To see why this might be needed, suppose at a particular time we have only one datagram to send, datagram #1. So, we send #1, and then send the END character to delimit it. Now, suppose there is a pause before the next datagram shows up. During that time we aren't transmitting, but if there is line noise, the other device might pick up spurious bytes here and there. If we later receive datagram #2 and just start sending it, the receiving device might think the noise bytes were part of datagram #2.

Starting datagram #2 off with an END character tells the recipient that anything received between this END character and the previous one is a separate datagram. If that's just noise, then this “noise datagram” is just gibberish that will be rejected at the IP layer. Meanwhile, it doesn't corrupt the real datagram we wish to send. If no noise occurred on the line between datagrams then the recipient will just see the END at the start of datagram #2 right after the one at the end of #1, and will ignore the “null datagram” between the two.

There is only one other issue SLIP deals with. If the END character is 192 decimal, what happens if the byte value 192 appears in the datagram itself? Transmitting it “as is” would fool the recipient into thinking the datagram ended prematurely. To avoid this, a special Escape character (ESC) is defined, which has a decimal value of 219 (DB in hex, 11011011 in binary). The term “escape” means that this symbol conveys the meaning “this byte and the next one have a special meaning”. When a value of 192 appears in the datagram, the sending device replaces it by the ESC character (219 decimal) followed by the value 220 decimal. Thus, a single “192” becomes “219 220” (or “DB DC” in hexadecimal). The recipient translates back from “219 220” to “192”.

This leaves one final problem: what happens if the escape character itself is in the original datagram? That is, what if there's a byte value of 219 in the IP datagram to be sent? This is handled by a similar substitution: instead of “219” we put “219 221”.

So in summary, this is basically everything SLIP does:

• Break an IP datagram into bytes.
  
  
• Send the END character (value “192”) after the last byte of the datagram; in better implementations, send the END character before the first byte as well.
  
  
• If any byte to be sent in the datagram is “192”, replace it with “219 220”.
  
  
• If any byte to be sent is “219”, replace it with “219 221”.

Figure 22 shows an example of how SLIP works, including the escaping of special characters, using a mock IP datagram.

Figure 22: Operation of the Serial Line Internet Protocol (SLIP)

IP datagrams are passed down to the SLIP software at layer two (a simplified one with only five bytes is shown here). There, they are framed by surrounding them with END characters (hexadecimal value C0h, shown in orange). Special characters with hexadecimal values DBh and C0h are replaced by two-byte sequences. Note that the presence of the bracketing END characters forces the receiving device to see the noise byte (03h, in red) as a separate IP datagram, rather than part of either of the real ones. It will be rejected when passed up to the IP layer.

SLIP and PPP Overview and Role In TCP/IP 1 2 3 Point-to-Point Protocol (PPP)

If you find The TCP/IP Guide useful, please consider making a small Paypal donation to help the site, using one of the buttons below. You can also donate a custom amount using the far right button (not less than $1 please, or PayPal gets most/all of your money!) In lieu of a larger donation, you may wish to consider purchasing a download license of The TCP/IP Guide. Thanks for your support! Donate $2 Donate $5 Donate $10 Donate $20 Donate $30 Donate: $

---

Home - Table Of Contents - Contact Us

The TCP/IP Guide (http://www.TCPIPGuide.com)
Version 3.0 - Version Date: September 20, 2005

© Copyright 2001-2005 Charles M. Kozierok. All Rights Reserved.
Not responsible for any loss resulting from the use of this site.