cisco ccna industrial

cisco ccna industrial.25.2.4 Congestion ControlIn the previous subsection, the impact that the various traffic parameters of the VC have on the way traffic enters the operator's network was described. Once the traffic enters the operator network, these parameters do not affect their transport through the operator network to the remote site. Of course, this poses a problem for the operator network: what to do if the operator network becomes congested and frames need to be dropped? It would be nice if the operator could tell the Frame Relay DTE that congestion has occurred before it starts dropping frames, and have them slow down the VC. As mentioned earlier, Frame Relay does not provide a retransmission mechanism; if a frame is dropped due to a frame check sequence (FCS) error or congestion, the source device that created the frame will be responsible for retransmitting it.To deal with this problem, Frame Relay provides a standard mechanism that can be used to inform and accommodate congestion problems in the Frame Relay operator's network. The Frame Relay frame header contains two fields for indicating congestion: the FECN and BECN, whose usage is illustrated in Figure 25.8. Router A sends information to the carrier network, and congestion occurs on the carrier network. When congestion occurs on the path through which the VC passes, the operator sets the FECN bit in its frame header for frames destined for Router B. After these frames arrive at Router B, the router discovers that the FECN bit in its frame header is set, so it sends a Frame Relay frame in the VC in the opposite direction and sets the BECN bit in its frame header. To speed up the congestion notification process, some vendors' carrier switches generate a BECN frame and send it in the VC in the opposite direction to the source device to indicate that congestion has occurred. Router A receives the BECN frame to reduce the data rate of the VC.Figure 25.8 FECN and BECNA major drawback of the FECN/BECN congestion notification method is that it is not a very efficient way to control traffic. For example, an operator may set its FECN bit as the frame travels to the target device to indicate that congestion has occurred; but by the time the target device sends a BECN frame to the source device, the congestion may have disappeared. When the source device receives the BECN frame, it starts to slow down the transmission speed, but by then it is no longer congested. In addition, there is no way to tell the source or target device the level of congestion; without any feedback on how much to reduce, the source device may reduce the VC data rate too much or too little. With these issues in mind, many companies have turned to ATM. ATM also supports flow control, but its implementation is much more sophisticated than Frame Relay, allowing VCs to adapt to congestion in real time.Exam Points FECN is used to indicate that a frame has encountered congestion on its way from the source device to the destination device; the destination device uses BECN to tell the source device that congestion has occurred on its way from the source device to the destination device.Authentication Target 25.03Chapter 25 Frame Relay 69125.3 Configuring Frame RelayThe remainder of this chapter describes the various ways to configure Frame Relay on a router. As with other WAN encapsulations such as PPP and HDLC, Frame Relay is configured on the serial interface.