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

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

This <strong>to</strong>pology is limited <strong>to</strong> <strong>the</strong> capabilities provided by <strong>the</strong> OSI-RM Layer 3 pro<strong>to</strong>col<br />

used <strong>to</strong> provide delivery, and it is commonly used as a cost savings dodge. With this<br />

configuration, you only need <strong>to</strong> have <strong>the</strong> multipoint host contract for a large<br />

bandwidth Frame Relay connection, and <strong>the</strong> single PVC sites can contract for just a<br />

percentage of <strong>the</strong> supportable bandwidth of <strong>the</strong> multipoint site.<br />

Frame Relay Congestion Control<br />

This latter approach works well because Frame Relay supports congestion control<br />

mechanisms. These mechanisms are known as forward and backward explicit<br />

congestion notification (FECN and BECN). To enable FECN or BECN, a notification bit<br />

is set in <strong>the</strong> Frame Relay frame address field. BECN is used by DTEs <strong>to</strong> indicate<br />

congestion problems. If a BECN bit is enabled on a received frame, <strong>the</strong> receiving<br />

DTE reduces CFR for <strong>the</strong> interface. If consecutive BECN messages are received, <strong>the</strong><br />

CFR is reduced fur<strong>the</strong>r. When <strong>the</strong> host begins <strong>to</strong> receive, BECN "clears" messages;<br />

<strong>the</strong> DTE can begin <strong>to</strong> increase its CRF. FECN messages are implemented by <strong>the</strong><br />

DCEs <strong>to</strong> indicate <strong>to</strong> <strong>the</strong> destination DTE that <strong>the</strong> frame encountered congestion over<br />

its delivery path through <strong>the</strong> Frame Relay <strong>network</strong>.<br />

If <strong>the</strong> BECN and FECN mechanisms are not adequate <strong>to</strong> accommodate <strong>network</strong><br />

congestion in <strong>the</strong> Frame Relay cloud, <strong>the</strong> DCE will implement fur<strong>the</strong>r congestion<br />

recovery by discarding frames based on <strong>the</strong> Discard Eligibility (DE). A DE setting of<br />

1 indicates <strong>the</strong> frame can be discarded in times of congestion. A setting of 0<br />

indicates that <strong>the</strong> frame should be spared unless <strong>the</strong>re is no alternative. The DE can<br />

be set by <strong>the</strong> DTE based on <strong>the</strong> type of traffic contained in <strong>the</strong> frame or depending<br />

on <strong>the</strong> DTE's CFR. If <strong>the</strong> DTE is in excess of its standard usage CFR, <strong>the</strong> frames will<br />

be tagged with a DE of 1.<br />

The Frame Relay Frame Format<br />

The standard Frame Relay frame has five fields, described in <strong>the</strong> following list. In<br />

addition <strong>to</strong> <strong>the</strong> standard frame, an LMI Frame Relay frame is used when <strong>the</strong> LMI<br />

extensions are enabled. The standard Frame Relay frame is illustrated in Figure<br />

5.16 and described in <strong>the</strong> following bulleted list.<br />

Figure 5.16. The standard Frame Relay frame format.

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

Saved successfully!

Ooh no, something went wrong!