cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
2473
Views
54
Helpful
17
Replies

FrameRelay Explicit Congestion Notification & traffic shapping

xine xine
Level 1
Level 1

Hi !

I'm currently prepare my CCNP, ONT 642-845 certification Exam.

I have question about the Frame Relay Explicit Congestion Notification (BECN and FECN).

I had provide a small visio plan to make my question more easier to explain.... (see attached files)

My understanding about BECN & FECN notification is this :

If PC1 is sending data to PC4 through router 1 to 4. When data pass through congestion 128K link Router2 will generate BECN and send this to Router1 also Router2 generate FECN and send it to Router4 to notify the upper layer protocol they will expected some delay to received data from PC1. When Router1 received BECN, Router1 start to shape his interface to slowdown communication to PC4. But, Router4 have not to change anything in is shaping configuration.

Now if I'm correct with this everything is good to me. What is not clear to is the last sentence in the following text :

"Frame Relay traffic shaping controls Frame Relay traffic only and can be applied to a Frame Relay subinterface or Frame Relay DLCI. Whereas Frame relay traffic shaping supports Frame Relay fragmentation and interleaving (FRF.12), class-based traffic shaping does not. On the other hand, both class-based traffic shaping and Frame Relay traffic shaping interact with and support Frame Relay network congestion signals such as BECN and forward explicit congestion notification (FECN). A router that is receiving BECNs shapes its outgoing Frame Relay traffic to a lower rate. If it receives FECNs, even if it has no traffic for the other end, it sends test frames with the BECN bit set to inform the other end to slow down."

copy paste form : CCNP ONT Official Exam Certification Guide

Author : Amir S. Ranjbar, CCIE No. 8669

First Printing: May 2007

Page : 167

"If it receives FECNs, even if it has no traffic for the other end, it sends test frames with the BECN bit set to inform the other end to slow down."

I'm understand when Router4 received the FECN, router4 will send BECN to some others....

To which one exactly ?

After this exchange of BECN FECN, how should I expected to know where is the congested link ?

Is also Router4 send FECN, when this stop ?

I don't understand why router4 send BECN to someone else....

can somebody help me ?

Thanks a lot !

P.S.: Please excuse me for my English, I'm a French peoples.

1 Accepted Solution

Accepted Solutions

Joseph, Xine

Just to let you know got an e-mail back from Dan Bruhn, NetPro moderator -

"Hi Jon,

We had a code change last week that was causing these problems. We rolled back the code change so they should be resolved. If you're still seeing issues please let me know. Thanks again for passing these issues along.

Cheers,

Dan"

Jon

View solution in original post

17 Replies 17

Jon Marshall
Hall of Fame
Hall of Fame

"P.S.: Please excuse me for my English, I'm a French peoples" - can't see anything wrong with your English at all. I am English and i make more spelling mistakes than you on a good day :-)

Anyway, a word of warning. Frame relay is not my strongest subject at all but the way i understand it is that the FECN bit is set by Frame relay switches and not routers (unless your router is acting as a frame switch !).

So if the link between R1 (router 1) and R2 (router 2) is congested the frame switch will set the FECN bit for traffic going to R2.

When R2 receives frames with the FECN bit set it then sets the BECN bit and sends frames back to R1 so that R1 knows it has to adjust it's traffic rate.

At no time does R2 send a FECN to R4. It doesn't need to because it is only congested on that link.

Again it is important to understand that it is the frame switch that sets the FECN and not the router itself.

Jon

Joseph W. Doherty
Hall of Fame
Hall of Fame

I was unable to view either of your attachments, so I'm unable to reference them. I assume R1 and R4 are the frame-relay end-points and R2 and R3 are interior frame-relay hops (which are logically frame-relay switches, not routers).

If my assumption about your topology is correct, R4 would "reflect" FECNs received from R1 back to R1 using BECNs. This could be done by tagging frames already going to R1, or according to your documentation, using special test frames (if there is no other traffic going to R1).

You don't know where the congested link is, just that there is congestion between R1 and R4. (There may be only one frame-relay switch between R1 and R4, two [as in your diagram?], or lots of frame-relay switches.)

I'm unsure whether FECN to BECN reflection is automatic or whether is requires some additional configuration on the router. (I suspect the latter.)

Once R1 sees BECNs it can adjust its outgoing tranmission rate using a shaper that understands BECNs. One that does, slows the outbound transmission rate, and keeps it slowed until the BECNs stop (R4 to R1 BECNs will stop when R1 to R4 FECNs stop). Once the BECNs stop, such shapers will try to allow the transmission rate to increase up to the maximum allowed. If more BECNs are seen, the cycle of the shaper adjusting its transmission speed, is continued. (I.e. BECNs, slow; no BECNs, speed up.)

BTW: Shaper configuration does require manual configuration.

Joseph

"I assume R1 and R4 are the frame-relay end-points and R2 and R3 are interior frame-relay hops (which are logically frame-relay switches, not routers)."

I think that's the issue. I think each router is acting as L3 router and not as a frame-relay switch but i could be wrong. If R2 & R3 are frame-relay switches then i agree with what you say. But from the .pdf it looks like they aren't.

Jon

Jon, unable to comment on your comment. Note my post begins with "I was unable to load either of your attachments", although perhaps it would be clearer if I wrote unable to "view" either.

[edit]

Revised original post.

[edit2]

Finally able to view the PDF.

That's much different from what I assumed!!!

In a network as shown, BECN/FECN would only be between R1:R2, R2:R3, R3:R4. The BECN/FECN is L2, it would not span the routers, L3. [edit3] Which is pretty much what your wrote, Jon.

Joseph

"Note my post begins with "I was unable to load either of your attachments", although perhaps it would be clearer if I wrote unable to "view" either."

I did read that but i just assumed with your perseverance you would eventually manage to view it :-)

Jon

Jon, my perseverance sometimes shows, eh? (You should see the flat part of my forehead, too much butting against brick walls.)

In this case, I would have let it go since I both stated not seeing the diagram and what my assumptions of the network were, but after your follow-up, I had to see the diagram. Surprisely it was simple. My browser wouldn't open the PDF directly (thought this used to work - recent java update broke this?), but if I saved the PDF, I could then open it. (The alternative would have been to install a Visio viewer.)

Seeing the diagram helped much (surprise). It especially helped with the references to PC2 and PC4.

PS:

For the original poster, ECN is a L3 end-to-end method for congestion notification. In theory, ECN could allow PC1 to know there was congestion to PC4, although it wouldn't know where along the path. I think router's could set ECN if they saw interface congestion, but don't recall there being any support for reflecting FECN/BECN into ECN.

Microsoft's CTCP, I believe, can detect congestion by carefully watching RTT timers. This too wouldn't know where along the path it was happening.

" My browser wouldn't open the PDF directly (thought this used to work - recent java update broke this?), but if I saved the PDF, I could then open it"

Funny you should say that actually because i have exactly the same problem. Until about 2 weeks ago i used to be able to open files directly but now i have to save every single one to may hard drive and open them.

Incidentally also getting a lot of "Warning: Page Expired" broswer settings when i click the back button. Started happening the same time.

Could be something to do with NetPro site or browsers i guess but i haven't conciously updated anything.

Jon

I only updated my Java the other day, but don't often open PDFs via my browser (except this site). So the two might be unrelated.

As to the page expired, yea! In fact just typed a lengthy post and got the Apache error when I went to post (signon expired, I believe). Used to be able to go back and and clip my prior post. Now lost, argh!

I recall mention on the maintenance topic, or some such, Cisco was making some changes. Related? Maybe we should post this stuff to those topics.

PS:

To original poster, sorry for wandering off topic.

Yes, apologies to the OP for going slightly off topic.

"Used to be able to go back and and clip my prior post. Now lost, argh!"

I feel your pain !, this has happened to me recently so i have got into the habit of copying before i even try and post. Most annoying symptom is going to type an answer then clicking on poster's name to find out who you are talking to, go back and you get Page Expired.

So where are these maintenance topics you are referring to ?. It wouldn't hurt to let them know.

I had in mind: Idea Center - NetPro Ideas

Hi !

You are to know each others....

I have also the same issue since I had start to used this site to post my question for ma preparation of Exam certification or office related question.... For this reason I used in Windows MS WordPad to write my message and use copy/paste function to post what I had wrote... Before I working like this.... because I'm a French it's make longer time for my to create my message than you... each time the 30minutes alowed expired befored I used post buttom....

Thanks a lot Jon for you comment about my English !!

Jon, in your first post you saied it's a switch is set BECN/FECN bit in frame.... in his text the author does'nt speak about any FrameRelay switch but only router..... But what is more confusde for me is this :

"So if the link between R1 (router 1) and R2 (router 2) is congested the frame switch will set the FECN bit for traffic going to R2.

When R2 receives frames with the FECN bit set it then sets the BECN bit and sends frames back to R1 so that R1 knows it has to adjust it's traffic rate.

"

If I understanding both of you, if the sending device (switch or router) just before the congestion is generate FECN bit set ?

If R1 know the link is congested, (it send a FECN) why is simply not start to shape is't interface, why it wait to received BECN to start to slowdown communication ?

Joseph, if my diagram was like was you suppsed R2 and R3 only layer 2 Frame Relay switches, why the notfication was passed from R1 to R4 ? If I understanding you if the link R1 and R2 is congested if maybe not between frame relay switch R2 & R3.... why R2 and R3 relayed FECN bit to R4 ?

Last thing, in your post Joseph, you saied : "I think router's could set ECN if they saw interface congestion, but don't recall there being any support for reflecting FECN/BECN into ECN." I was under the impression ECN is only the name of this process... not also another field in the frame to flag if FECN or BECN was set during L3 conversation, if I can call this like this.., while the frame cross the FrameRelay link between last 2 routers....

Thanks to both of you to help me....

Hi,

a couple of general remarks:

Frame Relay (FR) switches like the Cisco IGX can be configured how to handle congestion and FECN/BECN. One option is not to send FECN/BECN to customer FR routers. This choice allows the SP to hide congestions in his network from the customer. Most SPs were overbooking their network, which means there will be congestion, if every customer sends at CIR. Not every SP would like to admit that ... I have seen overbooking by a onsiderable factor, e.g. customer buys 128k CIR and the SP reserves 16k in his network. Note: not every FR SP does this.

Another option in a FR switch is to send FECN/BECN in a congestion case. What is congestion? Really it is defined by a certain threshold in the interface queues of the FR switches. So if a inetrface queue for a certain PVC class in a FR switch is filling up above a certain level the frames in the queue would get the FECN bit set. To speed up the feedback process ("Please slow down dear sender or I have to drop your frames!") one could also send a BECN in the opposite direction to the routers contributing to congestion. So the FR SP would not rely on the customer equipment doing FECN to BECN reflection.

The general idea of informing about congestion was also introduced in L3 by using two bits in the TOS byte of the IP header. This was called ECN and is defined in RFC 3168 (The Addition of Explicit Congestion Notification (ECN) to IP).

It can be configured, if WRED is used, to not drop an IP packet in the random drop range but mark ECN instead. There is, however, no FECN/BECN to ECN bit reflection as far as I know because ECN is independent of L2 transport.

The router receiving the ECN bit in IP is supposed to reduce TCP window size the same way as if the packet was dropped by WRED. Reducing the window size is reducing TCP throughput.

Regards,

Martin

Hi !

I defenitly not make the link with ECN bit in the IP packet.... this make sence to me in the post from Joseph.

In the organisation I was previously work, I think the service provider was overbooking the network like you explain... We was paid for 128k link and received a service like 56K link or 33,6K link.... But I don't know anything about the BECN/FECN bit I was'nt knowing FrameRelay, and I was'nt have acces to the router at this time.

But what is still not clear to me is about what I had post just before :

"Jon, in your first post you saied it's a switch is set BECN/FECN bit in frame.... in his text the author does'nt speak about any FrameRelay switch but only router..... But what is more confusde for me is this :

"So if the link between R1 (router 1) and R2 (router 2) is congested the frame switch will set the FECN bit for traffic going to R2.

When R2 receives frames with the FECN bit set it then sets the BECN bit and sends frames back to R1 so that R1 knows it has to adjust it's traffic rate.

"

If I understanding both of you, if the sending device (switch or router) just before the congestion is generate FECN bit set ?

If R1 know the link is congested, (it send a FECN) why is simply not start to shape is't interface, why it wait to received BECN to start to slowdown communication ?

Joseph, if my diagram was like was you suppsed R2 and R3 only layer 2 Frame Relay switches, why the notfication was passed from R1 to R4 ? If I understanding you if the link R1 and R2 is congested if maybe not between frame relay switch R2 & R3.... why R2 and R3 relayed FECN bit to R4 ?

"

thanks a lot !

"If R1 know the link is congested, (it send a FECN) why is simply not start to shape is't interface, why it wait to received BECN to start to slowdown communication ? "

That is the key point though. R1 does not send the FECN because it doesn't know the frame-relay network is congested. R1 only realises that congestion is happening when it receives packets from R2 with the BECN bit set.

And R2 only knows there is congestion happening when it receives packets with the FECN bit set. Now these packets are being sent to R2 from R1 but R1 did not set the FECN bit in them when it sent the packets. It was the frame-relay switch that set the FECN bit before forwarding the packet onto R2.

So FECN bit is set by frame-relay switch & BECN bit is set by the receiving router.

Obviously in your diagram only there are no frame-relay switches shown but there would be at least one frame-relay switch between R1 & R2.

Jon

Getting Started

Find answers to your questions by entering keywords or phrases in the Search bar above. New here? Use these resources to familiarize yourself with the community:

Innovations in Cisco Full Stack Observability - A new webinar from Cisco