FEw question about frame relay header(lapf),FECN,BECN bits

Answered Question
Aug 22nd, 2009
User Badges:
  • Bronze, 100 points or more

Hi every body.


I have few questions:


Which organization has defined LAPF header?


Please consider the following case.


R1---FRsw1---FRSW2----FRsw3-R2


FR stands for frame relay switch in the above fig.


R1 and R2 are connected by frame relay network.


Let say R1 sends sends a frame, to R2

FRsw1 receives the frame and notices frame has experienced congestion,so frsw1 sets the FECN bit.


FRsw2 receives the frame and forwards it to frsw3 which eventually delivers it to R2.

R2 notices the FECN and concludes this frame has experienced the congestion on its way.


Now what purposes it serves to let R2 knows the frame has experienced some congestion by setting FECN bit?



===========================


Now R2 sends the frame to R1


Which switch will set the BECN bit? the switch(frsw1) which has intially set the FECN bit or any switch in the path to R1?


Thanks a lot and have a nice weekend



Correct Answer by Giuseppe Larosa about 7 years 9 months ago

Hello Sarah,

have a good weekend you too.


I think the designers had in mind a scenario where each upper layer protocol is mapped to a different PVC /DLCI.


Later the need for multiprotocol over the same DLCI rised as a way to achieve more scalability.


Frame relay specification says that all the PVC descriptions have to be carried in a single full status LMI message.

This caused a strict limit to the max number of DLCIs that can be used on a single UNI interface given an encapsulation, an LMI type and an MTU on the interface.

So the need to reuse the same DLCI for multiple protocols was felt and the standard updated.


Hope to help

Giuseppe


Correct Answer by Giuseppe Larosa about 7 years 9 months ago

Hello Sarah,

too many questions :)

so forgive me if I will miss someone


a) Which organization has defined LAPF header?

The very first were some companies including Cisco itself. So we have enc frame-relay cisco|ietf.


Originally the standard was defined by the frame relay forum also the author of the different FRF agreements.

RFC 1490 (now obsolete) defined multiprotocol over Frame relay with the introduction of a protocol type field for upper layer protocol carried in the frame

see

http://www.faqs.org/rfcs/rfc1490.html



FRF was then merged to ATM forum

the new forum at the end has been merged to the MPLS forum

Now, it should be called the broadband forum and should include also the DSL forum.


look at

http://www.broadband-forum.org/


b)

in your scenario:


Now what purposes it serves to let R2 knows the frame has experienced some congestion by setting FECN bit?


Frame Relay definition allows remote DTE R2 or any switch in the middle to set the BECN on frames traveling in the opposite direction to the direction that experienced congestion.

So FECN can be set only by a switch but BECN can be set by a router or a switch


R1 on receiving BECN can react to this by slowing down its transmission rate (shaping to a lower rate).

On successive receiving of BECN the speed is halfed down to the mincir. (minimum rate).

The router will increase again the rate after some Tc intervals with no BECNs received but using a slower increase rate.


This is called adaptive shaping using BECN.

There is also a proprietary mechanism called foresight that can be used if the FR switches are cisco (old stratacom) with cisco routers as DTE.


Hope to help

Giuseppe




  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (2 ratings)
Loading.
Correct Answer
Giuseppe Larosa Sat, 08/22/2009 - 11:01
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Sarah,

too many questions :)

so forgive me if I will miss someone


a) Which organization has defined LAPF header?

The very first were some companies including Cisco itself. So we have enc frame-relay cisco|ietf.


Originally the standard was defined by the frame relay forum also the author of the different FRF agreements.

RFC 1490 (now obsolete) defined multiprotocol over Frame relay with the introduction of a protocol type field for upper layer protocol carried in the frame

see

http://www.faqs.org/rfcs/rfc1490.html



FRF was then merged to ATM forum

the new forum at the end has been merged to the MPLS forum

Now, it should be called the broadband forum and should include also the DSL forum.


look at

http://www.broadband-forum.org/


b)

in your scenario:


Now what purposes it serves to let R2 knows the frame has experienced some congestion by setting FECN bit?


Frame Relay definition allows remote DTE R2 or any switch in the middle to set the BECN on frames traveling in the opposite direction to the direction that experienced congestion.

So FECN can be set only by a switch but BECN can be set by a router or a switch


R1 on receiving BECN can react to this by slowing down its transmission rate (shaping to a lower rate).

On successive receiving of BECN the speed is halfed down to the mincir. (minimum rate).

The router will increase again the rate after some Tc intervals with no BECNs received but using a slower increase rate.


This is called adaptive shaping using BECN.

There is also a proprietary mechanism called foresight that can be used if the FR switches are cisco (old stratacom) with cisco routers as DTE.


Hope to help

Giuseppe




sarahr202 Sat, 08/22/2009 - 11:12
User Badges:
  • Bronze, 100 points or more

Thanks Giuseppe.


The book says original lapf header did not have prtocol type feild. Cisco annd some companies banded(-:) together and came with cisco header inserted between lapf header and data feild.


So i was just thinking which organisation was behind original lapf with a poor foresight that not to include type feild.


Thanks and have a good weekend.

Correct Answer
Giuseppe Larosa Sat, 08/22/2009 - 11:25
User Badges:
  • Super Silver, 17500 points or more
  • Hall of Fame,

    Founding Member

Hello Sarah,

have a good weekend you too.


I think the designers had in mind a scenario where each upper layer protocol is mapped to a different PVC /DLCI.


Later the need for multiprotocol over the same DLCI rised as a way to achieve more scalability.


Frame relay specification says that all the PVC descriptions have to be carried in a single full status LMI message.

This caused a strict limit to the max number of DLCIs that can be used on a single UNI interface given an encapsulation, an LMI type and an MTU on the interface.

So the need to reuse the same DLCI for multiple protocols was felt and the standard updated.


Hope to help

Giuseppe


sarahr202 Sat, 08/22/2009 - 12:42
User Badges:
  • Bronze, 100 points or more

I got few more questions but they are not related subject.

Actions

This Discussion