Options
Frame relay congestion control...
rjbarlow
Member Posts: 411
in CCNA & CCENT
Hi all,
someone know what is the content of a frame with the bit FECN and BECN set to 1 in the F.R. header respectively over a connection Frame Realy?
Try to explain better what I would to say:
If the FECN field bit is set to 1 by the switch F.R., the DTE notified of congestion is the DESTINATION router. Then I guess that the frame has been carried to the destination and not dropped in its way.
If the BECN field bit is set to 1 by the switch F.R, the DTE notified of congestion is the SOURCE router. Then I guess in this case the frame come back to the source from the attached F.R. switch.
Are these considerations right?
routerA
switch F.R.1
switch F.R.2
.routerB
someone know what is the content of a frame with the bit FECN and BECN set to 1 in the F.R. header respectively over a connection Frame Realy?
Try to explain better what I would to say:
If the FECN field bit is set to 1 by the switch F.R., the DTE notified of congestion is the DESTINATION router. Then I guess that the frame has been carried to the destination and not dropped in its way.
If the BECN field bit is set to 1 by the switch F.R, the DTE notified of congestion is the SOURCE router. Then I guess in this case the frame come back to the source from the attached F.R. switch.
Are these considerations right?
routerA
switch F.R.1
switch F.R.2
.routerB
Comments
-
Options
dtlokee
Member Posts: 2,378 ■■■■□□□□□□
rjbarlow wrote:Hi all,
someone know what is the content of a frame with the bit FECN and BECN set to 1 in the F.R. header respectively over a connection Frame Realy?
Try to explain better what I would to say:
If the FECN field bit is set to 1 by the switch F.R., the DTE notified of congestion is the DESTINATION router. Then I guess that the frame has been carried to the destination and not dropped in its way.
If the BECN field bit is set to 1 by the switch F.R, the DTE notified of congestion is the SOURCE router. Then I guess in this case the frame come back to the source from the attached F.R. switch.
Are these considerations right?
routerA
switch F.R.1
switch F.R.2
.routerB
Yes that's basically the idea. The BECN and FECN bits are not sent in new frames by the frame switches, they are set in the traffic going between the DTE endpoints. BECN can also be set on return traffic by the router that receives a FECN on a PVC.
One problem with FECNs is that if the frame exceedes the CIR and is marked DE, it will be dropped when there is congestion, therefore no FECN is bit can be set.The only easy day was yesterday! -
Options
Netstudent
Member Posts: 1,693 ■■■□□□□□□□
Okay I am kinda confused about this as well.
FECN Alerts Destination
BECN Alerts Source
So frame1 leaves routerA and is destined for RouterB and experiences congestion in the opposite direction that it is traversing. The return data is experiencing congestion on its way back to the source.
The switch will set the BECN bit to 1 on Frame1 as it goes to RouterB?
OR
The switch will set the BECN bit on another frame that is already on its way back to the source RouterA?
I'm confused on how BECN is supposed to alert the source when the frame is going in the opposite direction of the source and opposite direction of the congested data flow.There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1! -
Optionsdtlokee
Member Posts: 2,378 ■■■■□□□□□□
Netstudent wrote:Okay I am kinda confused about this as well.
FECN Alerts Destination
BECN Alerts Source
So frame1 leaves routerA and is destined for RouterB and experiences congestion in the opposite direction that it is traversing. The return data is experiencing congestion on its way back to the source.
The switch will set the BECN bit to 1 on Frame1 as it goes to RouterB?
OR
The switch will set the BECN bit on another frame that is already on its way back to the source RouterA?
I'm confused on how BECN is supposed to alert the source when the frame is going in the opposite direction of the source and opposite direction of the congested data flow.
Remember that Frame Relay is connection oriented, that is the switch knows of the flow between endpoints due to the PVC (traffic on a PVC can be distinguished from other traffic on the same link by the DLCIs). BECN is sent back to the source on any frames belonging to the PVC flowing that direction on the PVC that experienced congestion.The only easy day was yesterday! -
OptionsNetstudent
Member Posts: 1,693 ■■■□□□□□□□
Okay I get it as much as I possibly could without actually seeing it occur.
"BECN is sent back to the source on any frames belonging to the PVC flowing that direction on the PVC that experienced congestion."
So then this would tell the source that data is being congested on it's way back to the source?There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1! -
Optionsdtlokee
Member Posts: 2,378 ■■■■□□□□□□
It would tell the source the frames are going to experience congestion on the way to the destination. This can be used by the source to adapt it's transmission rate down to the CIR so no frames are marked DE.The only easy day was yesterday!
-
OptionsNetstudent
Member Posts: 1,693 ■■■□□□□□□□
hmm this has been what confused me from the beginning. So I guess I don't fully get it.
Okay Lets try this again, and tell me whats wrong with my logic here.
A frame leaves RouterA and then on its way to ROuterB, it experiences congestion. When it experiences this congestion on a frame-relay switch, the frame switch is going to set the BECN bit to 1 on a frame that is already on it's way back to the source within the same PVC.
This will tell RouterA that there is congestion on the path to routerB.
Rjbarlow, I'm not trying to hijack your post but coincidentally I have the same issues with congestion control.There is no place like 127.0.0.1 BUT 209.62.5.3 is my 127.0.0.1 away from 127.0.0.1! -
Optionsdtlokee
Member Posts: 2,378 ■■■■□□□□□□
Netstudent wrote:hmm this has been what confused me from the beginning. So I guess I don't fully get it.
Okay Lets try this again, and tell me whats wrong with my logic here.
A frame leaves RouterA and then on its way to ROuterB, it experiences congestion. When it experiences this congestion on a frame-relay switch, the frame switch is going to set the BECN bit to 1 on a frame that is already on it's way back to the source within the same PVC.
This will tell RouterA that there is congestion on the path to routerB.
Rjbarlow, I'm not trying to hijack your post but coincidentally I have the same issues with congestion control.
That is the idea.The only easy day was yesterday! -
Optionsrjbarlow
Member Posts: 411
I think this topic is a little obscure:Netstudent wrote:hmm this has been what confused me from the beginning. So I guess I don't fully get it.
Okay Lets try this again, and tell me whats wrong with my logic here.
A frame leaves RouterA and then on its way to ROuterB, it experiences congestion. When it experiences this congestion on a frame-relay switch, the frame switch is going to set the BECN bit to 1 on a frame that is already on it's way back to the source within the same PVC.
This will tell RouterA that there is congestion on the path to routerB.
Rjbarlow, I'm not trying to hijack your post but coincidentally I have the same issues with congestion control.
I read that switches can set BECN and FECN bit to 1 (not at the same time obviously), if You look at page 546 of the Sybex 5th Ed. book that is said, but also routers can set this bit.
For example in the posted scenario, with routerA that sends frames to routerB and contextually network congested occur;
a F.R. switch in the path can set the FECN bit to 1, thus routerB is receiving these frames with the FECN bit set to 1 and consequently, when routerB must send its frame to routerA, on those it sets the BECN bit to 1 so routerA is alerted.
