Frame Relay Notes – DE, FECN, and BECN

  • All are part of the frame relay congestion management suite.
  • Frame relay switches monitor links for CIR or oversubscription congestion on links.
    • If the VC has a CIR of 256k, the switch knows there is congestion if the customer is sending more than 256k down that VC.
  • Discard Eligible
    • Flag in the LAPF header
    • Marks a frame as eligible to be dropped in case of congestion
    • Marked via the MQC
  • Forward Explicit Congestion Notification
    • Flag in the LAPF header
    • Set by the switch when the frame is about to enter a link with congestion on a VC
      • Congestion in one direction
      • FECNs are set when the frame is going into the congestion.
    • Receiving router can see that there was congestion on the way.
    • FECNs can be used to activate adaptive shaping via FRTS.
    • Plain English:  If Router B receives a frame with the FECN flag set, that means that there is congestion on the path from Router A to this Router B, and that Router B should expect delays.
  • Backward Explicit Congestion Notification
    • Flag in the LAPF header
    • Set by the switch when a frame has just left the link with congestion
      • Congestion is the opposite direction.
      • BECNs are set when the frame has just left a link that has congestion on it.
    • Notifies the original sending router that there is congestion along that VC.
    • Plain English:  If Router A receives a frame with the BECN flag set, that means that there is congestion from Router A towards Router B and that the sending host should calm down a little bit.

http://www.sinclair.org.au/keith/networking/frame_relay.html

Corrections requested.

Aaron Conaway

I shake my head around sometimes and see what falls out. That's what lands on these pages.

More Posts

Follow Me:
Twitter

2 comments for “Frame Relay Notes – DE, FECN, and BECN

  1. monfasem
    June 23, 2011 at 3:06 pm

    FECN : its a fwd msg so received by sender.
    BECN : Bwd msg so received by destenation .
    Corrections requested 😉

  2. Alex S
    June 23, 2011 at 6:11 pm

    BECN: as traffic goes through FR cloud from R1 to R2 and switch experiences congestion, it sets BECN bit to 1 on traffic returning back to R1 (ie. ACKs, replies). Or it can generate Q.922 test frame with BECN bit set to 1 itself and inform offending routers they need to slow down. If R1 is configured to react to BECN bits, it cuts traffic down by 25% (or 50%?) up to a value set as mincir. You need to set “shape adaptive ” in your QoS profile in order for router to react on BECN bits.

    FECN: If there is no returning traffic from R2 to R1, ie. constant udp stream R1->R2 obly, FR switch experiencing congestion sets FECN bit to 1 and forwards the frame to R2. R2 receives FECN’d frame amd generates Q.922 test frame back to router R1. FR switch experiencing congestion sets BECN bit on that test frame to 1 – because routers slow down only when they receive BECN’d frame. You need to configure “shape fecn-adapt” in your QoS profile in order for router to listen to FECN’d frames and send Q.922 frames back.

    That’s how I understood it when studying QoS, hope it’s correct 🙂

Leave a Reply

Your email address will not be published. Required fields are marked *