printable format  e-mail to a friend comment on article More Q & A Video Killed the Data Stream Distance Training with IS-IS Theory, Reality and Total T-1 Bandwidth 'Area 257' De-Classified Follow That Packet! Back-to-Back Connections and ADSL Split-Scope DHCP Servers VRRP Implementation Q & A Archive

My question is regarding the BECN and FECN in Frame Relay networks.

Here is a simple visual:

MainOfficeRouter(DTE) ------T1------ (DCE)FR switch nearest
MainOffice---------------- CLOUD-------------FR switch nearest
BranchOffice (DCE)-------Frac-T1-------(DTE)BranchOfficeRouter

I think my understanding of a BECN and FECN is all right, to some degree, but I'm still skeptical regarding who potentially can set the FECN/BECN in the Frame Relay header. Let's assume that the MainOffice has much more bandwidth at its access link compared to the link connecting the BranchOffice. The MainOffice now has the potential to send at a much faster rate and therefore could cause congestion at the FR switch nearest the BranchOffice. I believe this to be true because the MainOffice can send traffic into the FR cloud at a rate of over 1Mbps. A bottleneck could exist at the FR switch nearest the BranchOffice because it cannot put bits onto the wire as fast as it's receiving through the cloud from MainOffice (due to bandwidth constraints of BranchOffice access link). I wouldn't expect congestion to occur within the FR cloud in the provider's network because I would think they have ample bandwidth in the core infrastructure. My understanding is that the potential for congestion usually occurs at the point in which you have dissimilar rates (the edges of diagram).

So traffic gets congested going from the MainOffice to the BranchOffice. Since the BranchOffice FR switch is seeing the congestion first hand, it sets the FECN bit in packets it sends to the BranchOffice. So when the Branchoffice Router has to reply (i.e. TCP ACKs) in the opposite direction back to the MainOffice, a BECN is set to alert the MainOffice to "back off" (BECN is set by DCE as long as congestion still exists). Now, can that BECN be set by the BranchOffice itself, or is it the responsibility of the DCE device only? My understanding is that the reply will make its way back to the BranchOffice FR switch and the BECN will be set by the Switch not the BranchOffice Router. All other switches within the cloud will simply pass it along until the BranchOffice data reaches the MainOffice.

The MainOffice can now react pending it has Traffic shaping enabled to respond to BECNs. Would it be valid to say that we should set the MainOffice traffic shaping parameters to react to BECN? What effect would it have to have traffic shaping configured at either office to react to BECNS/FECN? I have a feeling that if you allow the BranchOffice to react to FECN packets, then it could tag packets as BECNs vs. the FRswitch doing it. The reason I think that a router (DTE) has the capability to tag ECNs is because the "show frame-relay pvc" command shows counters for both in and out for FECN and BECN packets. I would think that as a DTE device, the router will only see Inbound FECNs or BECNs. I'm puzzled regarding the "out" counter. Is that for configurations when using a router as a FR switch?

Thanks in advance,
-- Ted

Answer:

Ted,

ECNs are definitely one of those fun areas, and often a confusing area all around! Starting at the beginning, though, is always a good place to go.

-- advertisement (story continued below) --

FECN (Forward Explicit Congestion Notification) and BECN (Backward Explicit Congestion Notification) were designed as functions of the frame-relay network itself. This means that the frame switches were supposed to actually do the generation of this information based on error levels seen.

You are correct that a service provider's network SHOULD have enough bandwidth to really not see any congestion (heck, that's the SP's entire QoS design right there -- no congestion, no problems!). But sometimes, stuff happens.

The FECN is designed to follow the traffic being sent along a PVC and indicate to the receiving device that traffic may be delayed in its arrival. The BECN is designed to go back toward the source side of the PVC and indicate that the transmission rate should be backed off of.

In the "play nice with others" realm of networking, ECNs are routinely ignored unless you specifically configure your routers to pay attention to them. Go figure. So that's the design concept from the Service Provider's network point of view as they have the ability to generate frames with ECN information or tag frames passing through.

So what about today? First, SP networks have become more festive in their designs. Rarely will we see a "real" frame-relay network any longer (at least, end-to-end frame-relay). Mostly, frame-relay exists at the SP edge only. Inside the SP network, we will likely run MPLS, or at least re-encapsulate to a new IP packet. So we lose all of the internal functionality that was attempted to bring into frame-relay once upon a time.

Your next question about who has the bottleneck? Or who throttles whom? When we start to go through the information, what you'll notice is that in much older router code, it really did come just from the network itself. But today, we at least have evolved to the idea, as you note, that even though the Service Provider network is running smoothly, one or more of your company's sites are dying from overload! Any device has the capability of flagging one of the ECN bits inside a frame-relay frame header. There's one FECN bit and one BECN bit, so it's either on or off.

Now, the catch: While it's quite cool that any device COULD flag the other side and warn them of impending dropped frames (generally a bad idea), nobody generates an empty frame in order to do this. There is no concept of a "Hold Please" frame. So data actually needs to be sent back, and the ECN can "piggy-back" or be carried along with data flowing.

In the event of many UDP streams, there is no need for notification or acknowledgment, and therefore there may not be any return traffic in order to ask the other side to please slow down.

Our concerns with ECN bits in the frame-relay headers generally have to do with configuring traffic shaping. The numbers we come up with for traffic shaping rarely have anything to do with the service provider's information because, like you pointed out, the problem usually isn't there, (or if it is, look at a new provider) So the target numbers for traffic shaping are most dependent on what our topology looks like, and making sure that the hub of a hub/spoke network can't flood any spokes. Likewise, we make sure that all spokes collectively can't flood the hub. Both result in drops and both indicate problems.

As far as your "out" markings go, that's generally when your device has errors receiving information and when some data goes back out, the BECN will be set.

For some more information, check out:

• http://www.protocols.com/pbook/frame.htm
• http://tinyurl.com/gu42r
• http://tinyurl.com/6gy46

Cheers,
-- Scott

back to question

Scott Morris, quadruple CCIE, JNCIE and all-around uber-geek, can often be seen traveling around the world consulting and delivering CCIE training. He recently accepted a new Senior CCIE Instructor position with Internetwork Expert! For more information on him check out http://www.uber-geek.net or for CCIE training check out http://www.internetworkexpert.com. You can contact Scott via editor@tcpmag.com. You can contact Scott about "Configuring BECN/FECN Frame Relay Traffic " at editor@tcpmag.com.