Basic knowledge of Access Network: learning notes on FECN forward congestion Identification

Many may not have a special understanding of the FECN forward congestion mark. Here we mainly analyze the basic knowledge of the FECN forward congestion mark. The Frame Relay Service provides transparent and non-confirmed transmission of frames. The received user data will be forwarded as data, except when the address and FCS field are changed. When the frame relay network is facing congestion, it may notify the user of the congestion, and assume that the user will take comfortable actions to reduce the congestion, or just drop this frame.

In terms of network control, FR adopts a simple Congestion Notification mechanism to reduce system overhead, instead of an explicit control mechanism based on each virtual circuit. This is mainly because FR is usually running on a relatively stable network medium. Therefore, you can submit the traffic control function to the upper-layer protocol without affecting data integrity. The Congestion Notification Mechanism adopted by FR is composed of two parts: Forward congestion mark FECN) and Backward Congestion mark BECN)

Both the FECN forward congestion mark and BECN are controlled by bits in the FR frame header. In addition to the FECN and BECN bits, the FR frame also provides a discarded indicator DE to identify non-important data that can be discarded when network congestion occurs. The FECN mechanism is enabled when the DTE device sends data to the FR network. If the network is congested, DCE devices, such as switches, will automatically set the frame's FECN bit to 1. When a data frame reaches the destination to receive a DTE device, you can check whether the frame has experienced network congestion during transmission by analyzing the address domain containing the FECN bit already set to 1. The DTE device located in the receiver transmits the received information to the high-level protocol for further processing. Start the traffic control mechanism or ignore the notification information from the front-end of FECN to the congestion flag according to different situations. When FECN-bit FR frame reverse transmission is set, the DCE device sets the BECN bit based on network conditions to notify the receiver whether the data frame is subject to network congestion during transmission. The DTE device transmits the above information to the upper-layer protocol for processing, and starts the traffic control mechanism or ignores the BECN-bit information according to different situations.

Congestion Control mainly applies two mechanisms: congestion avoidance and congestion recovery. To avoid congestion, the network sends a clear notification to the user by setting BECN and FECN in the user data frame when the network is congested. If the user effectively reduces the traffic of the outbound network at this time, to ease the congestion. The network uses the FECN forward congestion identifier and the BECN two bits to notify the terminal site of congestion. When the frame flow direction in the network is congested in the same direction, the FECN bits are reset; when the opposite direction of the frame flow in the network is congested, reset the BECN bit. This will lead to a situation where when the transmission is unidirectional on a specific virtual circuit, only the receiver is notified of congestion, and it may be caused by the sender. Congestion recovery is caused when the user's device cannot effectively respond to BEDN/FECN, resulting in more serious network congestion. At this time, the network will first discard the user frame where the DE bit is set; if the congestion still cannot Be mitigated, The Be data or even Bc data will Be discarded.

The FECN and BECN congestion indicators are generally set only by the network, and are generally set in the case of moderate congestion, so the network can still transmit frames, and the user end can be dropped only when severe congestion occurs. You can use the DE bit in the address field to set the frame priority. The network will discard the frame with the DE bit first, but the standard does not limit the network to discard only the frame with the DE bit set, just assume that, however, it is not emphasized that the end site will reduce its own information transmission rate after detecting network congestion.

The above describes the in-band congestion control mode. However, the in-band congestion signaling designed in the frame relay standard limits the correct response to congestion and prevents the realization of more advanced congestion control modes. Because the in-band Frame Relay congestion control mode depends on the settings of the FECN forward congestion identifier bits in the data sent to the destination, and the request sender slows down. But in fact, the end-to-end flow control process may not have this restriction, so the ITU-T has developed another optional signaling mechanism, that is, cllm1_lidate Link Layer Management, strengthen Link Layer Management ).

CLLM occupies an independent DLCI, that is, out-of-band, which allows the network to transmit control messages to the user end. The CLLM message contains a list of DLCI messages that may cause congestion. You want to restrict the data transmission of the specified DLCI to reduce the congestion of the terminal site. For frames with two-byte address fields, the CLLM message uses the DLCI 1007 format. For frames with three-byte or four-byte address fields, CLLM sends the C/r field in the lapf xid frame format, set 1 to indicate a response. The frame relay network may send Explicit Congestion Control messages on a dedicated DLCI, reporting congestion using out-of-band signaling. In addition to the frames sent from the remote terminal site and the LMILocal Management Interface and local Management Interface sent over the network) messages, the terminal site may also receive CLLM messages from the network to report congestion. It is also possible that the bits in the frame address field use in-band signaling to report congestion. In this way, the terminal site will not receive any other frames except the remote frames and LMS messages. When the network is congested, the network can either set FECN/BECN bits in the user's data DLCI, or use CLLM messages at the same time.