frame relay FECN, BECN the reason

[sarahr202]

Hi everybody

   I understand how we can use FECN, BECN bit to let sending router knows it has to slow down.

This is from my book:

R1--------FR1-------FR2---------R2

R1 is sending data to R2 . FR1 receives a frame from R1. FR1 notices the congestion on its link connected to FR2. FR1 sets the BECN bit.

and sends the frame on its way to R2.

Fr1 receives a frame going to R1, Fr1 sets the FECN bit.

I understand the logic of setting FECN bit so R1 can be informed about the congestion and therefore slows down..

I do not understand why FR1 has to set BECN bit, FR1 could simply set FECN bit in frames going to R1.

Why do we have to set BECN bit?  If the purpose is to R2 knows ( the receiver) that the particular frame has experienced congestion, then how does it help R2? There is nothing R2 can do about it . If the whole purpose is to let sender knows about congestion so it can slow down, that purpose can be achieved by using only FECN without the need of having BECN bit.

I appreciate your help.

Thanks and have a great week

[Giuseppe Larosa · Accepted solution]

Hello Sarah,

>>There is nothing R2 can do about it

R2 can set BECN on frames going to remote DTE R1.

congestion can be experienced in one direction only (likely) and the return path may be different not going through the same FR switch in the FR cloud. (yes this is possible if I remember  correctly)

From this the presence of both FECN and BECN bits in the FR frame header

Hope to help

Giuseppe

[Peter Paluch · Accepted solution]

Hello Sarah and Giuseppe,

My two cents...

The FECN and BECN are used to express in which direction a congestion occured. The FECN bit is set on the frames flowing in the direction in which the congestion occurs, while the BECN is set in the opposite direction of the congestion. Now, as you have correctly noticed, the FECN bit is actually an information for the receiver, not for the sender of the traffic that actually contributes to the congestion, so setting the FECN bit may appear futile.

Perhaps not First of all, even the receiver of the traffic may actually do something to alleviate the congestion. Think TCP: if the receiver shrinks the receive window, it forces the sender to send data more slowly. If the endpoint is directly connected to a FR VC, it may indeed react to FECN bit set by reducing the TCP rwnd. There may be also other feedback mechanisms in place that signal to the sender that it should slow down that may be triggered by the arrival of a frame with FECN set. In general, it may be helpful for a receiver to know that the traffic towards it is experiencing congestion so that it can be prepared for the inevitable consequences - increased jitter, packet losses, delays, etc. What the receiver is going to do with this information is up to its own intelligence.

Second, the router at the end of a VC that receives frames with FECN set may perform a so-called FECN-to-BECN reflection by sending LMI end-to-end Keepalive messages with BECN set, thereby indicating to the sender that a congestion is occuring.

So the difference between the FECN and BECN has its merit because both receiver and sender should be informed that congestion is occuring, but the reaction of each of these two endpoints is different to the information. If the information about congestion did not contain the notion of the direction in which the congestion occurs, it may be difficult to react appropriately.

Giuseppe, I am not sure if asymmetric paths through the Frame Relay cloud are in agreement with correct Frame Relay operation. While they can be configured this way, I do have a feeling that it is not correct. It's just a feeling, I do not have any technical argument to support my claim so please feel more than welcome to correct me here...

Best regards,

Peter

[Joseph W. Doherty · Accepted solution]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Peter Paluch wrote:
Second, the router at the end of a VC that receives frames with FECN set may perform a so-called FECN-to-BECN reflection by sending LMI end-to-end Keepalive messages with BECN set, thereby indicating to the sender that a congestion is occuring.

It's been years since I've worked with FR circuits, but what Peter wrote, I recall, is what I had to do for the sending router (i.e. my edge router with link to FR cloud) to "know" there was congestion.  I.e. I had to have destination router (i.e. my other side edge router with link to FR cloud) reflect FECNs into BECNs.  With this, I was able to dynamically shape the traffic from the source.  When the reflected FECNs were seen as BECNs, the shaper would slow.  If the reflected BECNs stopped appearing, the shaper would start to ramp up its transmission rate.

[Giuseppe Larosa · Accepted solution]

Hello Peter,

Frame Relay as ATM makes a distinction between User to Network interface UNI where LMI is spoken between the DTE and the DCE and Network to Network Interface with different protocols and conventions used in UNI or NNI.

The details of NNI implementation are hidden to DTE devices on UNI interfaces.

So also the fact that the paths can be asymmetrical is hidden to DTE Devices.

I have had some small experience in configuring ATM switches and FR switches and I remember some of them had PVC configured as unidirectional paths exactly as an MPLS LSP is ( examples ATM Fore or Cisco MGX / IGX).

With BECN implementing FECN reflection FR had a true flow control mechanism as noted by Joseph:

the sender would slow down quickly the amount of traffic sent during a Tc interval if in the previous TC interval a BECN is received.

The amount of traffic sent during a Tc interval is slowly increased if in the last N Tc intervals no BECN have been received.

The keyword was something adaptive shaping or shape adaptive-becn ( the command syntax was changed over time)

Hope to help

Giuseppe

[sarahr202]

Hi to all my old friends ( I don't mean  you guys are old)

I understand  that how FECN and BECN bit can help alleviate the congestion in FR cloud. And these bits are part of frame relay PDU.

Second, the router at the end of a VC that receives frames with FECN set may perform a so-called FECN-to-BECN reflection by sending LMI end-to-end Keepalive messages with BECN set, thereby indicating to the sender that a congestion is occuring

But I am a little confused about LMI and FECN and BECN bit.

,

LMI runs between DTE( our edge router) and DCE( Frame relay switch). 

Its job is to performs connections maintenance between dce and dte and informs dte about dlcis.

That means LMI messages flow between DTE and DCE. So how can a receiving router can send LMI end to end with BECN set to sender?

thanks and have a great week

[Joseph W. Doherty · Accepted solution]

Disclaimer

The   Author of this posting offers the information contained within this   posting without consideration and with the reader's understanding that   there's no implied or expressed suitability or fitness for any purpose.   Information provided is for informational purposes only and should not   be construed as rendering professional advice of any kind. Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In   no event shall Author be liable for any damages whatsoever (including,   without limitation, damages for loss of use, data or profit) arising  out  of the use or inability to use the posting's information even if  Author  has been advised of the possibility of such damage.

Posting

Second, the router at the end of a VC that receives frames with FECN set may perform a so-called FECN-to-BECN reflection by sending LMI end-to-end Keepalive messages with BECN set, thereby indicating to the sender that a congestion is occuring
But I am a little confused about LMI and FECN and BECN bit.
, 
LMI runs between DTE( our edge router) and DCE( Frame relay switch).  
Its job is to performs connections maintenance between dce and dte and informs dte about dlcis.
That means LMI messages flow between DTE and DCE. So how can a receiving router can send LMI end to end with BECN set to sender?

Don't quote me, but I thought FECN to BECN reflection "piggy-backed" on FR frames going back to the source (the other end of the VC).  Which if it did, would work fairly well with TCP, as it could piggy back on the ACKs.

I recall I never saw BECNs unless I configured FECN to BECN reflection on my DTE FR router.  However, don't know if that was an overall FR restriction or just the what my FR vendors supported.

[Peter Paluch · Accepted solution]

Hello Sarah,

I have to apologize - I have made a mistake here. Although Cisco does have its proprietary extension to LMI they call Frame Relay End-to-End Keepalive which is described here:

http://www.cisco.com/en/US/docs/ios/12_0t/12_0t5/feature/guide/FRKeep.html

this one is not used to as the messages carrying the BECN bit set, contrary to what I wrote earlier. I apologize about that. Instead, Cisco uses Q.922 TEST RESPONSE messages artificially generated when a FECN-carrying frame is received, and these TEST RESPONSE messages will be set the BECN bit.

http://www.cisco.com/en/US/docs/ios/12_2/qos/command/reference/qrfcmd9.html#wp1103558

Best regards,

Peter

[Joseph W. Doherty · Accepted solution]

Disclaimer

The    Author of this posting offers the information contained within this    posting without consideration and with the reader's understanding that    there's no implied or expressed suitability or fitness for any  purpose.   Information provided is for informational purposes only and  should not   be construed as rendering professional advice of any kind.  Usage of  this  posting's information is solely at reader's own risk.

Liability Disclaimer

In    no event shall Author be liable for any damages whatsoever  (including,   without limitation, damages for loss of use, data or  profit) arising  out  of the use or inability to use the posting's  information even if  Author  has been advised of the possibility of such  damage.

Posting

Peter thanks for looking up what the reflection does.  It makes sense as it wouldn't require "normal" return flow traffic to reflect the FECNs.

[Raju Sekharan · Accepted solution]

Hi

FECN is set in the forward direection. So in your case, FECN is set to packets going from FR1 towards R2

BECN is set in the backward direction. So in your case it is send towards R1

in short, FECN is send to receiver and BECN to source

If the destination Frame Relay node receives a Frame Relay frame with the FECN bit set, the node can indicate the congestion condition to upper layer protocols that can implement receiver-side flow control

If the destination Frame Relay node receives a Frame Relay frame with the BECN bit set, the node can indicate the congestion condition to upper layer protocols that can implement sender-side flow control

Both of FECN and BECN are facilities provided by Frame-realy to inform the upper layer protocols about congestion

Also your frame-relay show outputs can show if you are receving BECN and FECN which will help us to know about congestion and it's direction

Thanks

Raju