09.12.2012 Views

Understanding the network.pdf - Back to Home

Understanding the network.pdf - Back to Home

Understanding the network.pdf - Back to Home

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

PPP Framing<br />

There are three HDLC frame variations used by PPP <strong>to</strong> transmit ULP data. The type<br />

of transmission frame employed is determined by kind of transport connection<br />

being used for transmission. These variations are defined in RFC 1662.<br />

For asynchronous transport using modems, AHDLC framing is used. AHDLC framing<br />

is implemented in software as part of <strong>the</strong> PPP interface driver. It makes use of a<br />

defined frame delimiter character for marking <strong>the</strong> beginning and end of AHDLC<br />

frames. It also employs an escape character <strong>to</strong> indicate <strong>to</strong> <strong>the</strong> receiver how <strong>to</strong><br />

interpret <strong>the</strong> next octet value. In order for <strong>the</strong> escape characters <strong>to</strong> be interpreted<br />

properly with certain octet values, <strong>the</strong> link transport must support 8-bit values,<br />

o<strong>the</strong>rwise <strong>the</strong> data will be misinterpreted. These character combinations are never<br />

used <strong>to</strong> represent user data. AHDLC also utilizes some type of in-band or<br />

out-of-band flow control mechanism, but that is left up <strong>to</strong> <strong>the</strong> actual hardware and<br />

software implementation. AHDLC's processing of <strong>the</strong> datastream on a per octet<br />

basis does add some additional overhead <strong>to</strong> <strong>the</strong> data handling process.<br />

For synchronous transport over dedicated DS-X leased lines or ISDN, bitsynchronous<br />

HDLC (BHDLC) framing is used. BHDLC is ideal for transport<br />

implementations where framing is accomplished by <strong>the</strong> hardware interface. Where<br />

AHDLC uses special escape characters for structuring <strong>the</strong> user data, BHDLC instead<br />

uses bit stuffing techniques <strong>to</strong> present <strong>the</strong> user data in interpretable form. Also like<br />

AHDLC, an end-of-frame marker is employed <strong>to</strong> indicate <strong>the</strong> end and beginning of a<br />

new frame (01111110). To ensure that <strong>the</strong> end-of-frame marker and user data are<br />

not mistaken, bit stuffing is used after any sequence of five consecutive ones. If<br />

after five consecutive ones <strong>the</strong> next bit is a zero, <strong>the</strong> zero is a stuffing bit and should<br />

be ignored. If a one is <strong>the</strong> next bit, <strong>the</strong> octet is complete. By using bit stuffing, <strong>the</strong><br />

octet boundaries are no longer valid, so <strong>the</strong> entire bitstream must be interpreted <strong>to</strong><br />

transport <strong>the</strong> data correctly. Hence <strong>the</strong> name, bit-synchronous. BHDLC's<br />

bit-synchronous transmission mechanism is also more efficient than AHDLC<br />

because it allows <strong>the</strong> datastream <strong>to</strong> be processed on a per packet basis instead of a<br />

per octet basis.<br />

The last variation is octet-synchronous HDLC. This variation is rarely used except for<br />

SONET and SDH applications. Octet-synchronous uses <strong>the</strong> same start/end delimiter<br />

and escape character that AHDLC uses, <strong>the</strong> difference being in <strong>the</strong> handling of <strong>the</strong><br />

escape characters. Octet-synchronous HDLC was originally developed for ISDN<br />

transport applications. It was never implemented, though, as BHDLC is more<br />

efficient for ISDN transport applications.<br />

Regardless of <strong>the</strong> framing variation, <strong>the</strong> PPP frame format is essentially <strong>the</strong> same for<br />

each transmission variation, as illustrated in Figure 5.22.

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!