frame relay encapsulation options

Answered Question
Aug 27th, 2009

Hi every body.

I have few question.

1)When it comes to comand " frame-relay encapsulation, the options are cisco and ietf.

ITu did include rfc 1409/2427 in doc q.933 annex e. But i did not see any option for itu in the above command.

Does it mean vendors such as cisco did not implement the standard by ITU( doc q.933 annex e) in their products?

2)

Let say we have a frame relay network with three frame relay switches.

r1-Frsw1--frsw2--frsw3-r2

Traffic flow from r1->r2

Frsw1 receives a packet and sets the fecn bit because packet has suffered some congestion.Next frsw2 receives the packet and notices the packet has suffered some congestion and tries to set the fecn bit, but fecn

bit is already set by frsw1. what would happen now?

3)Now the reverse traffic 1.e from r1<---r2

frsw3 recives the packet and set becn bit, next frsw2 receives the packet and tries to set becn bit, but it is already set by frsw3. what would happen now?

Thanks and have a good day.

I have this problem too.
0 votes
Correct Answer by Peter Paluch about 7 years 3 months ago

Hi Sarah,

I think that the book wanted to say that the "show frame lmi" command will display information only about Frame Relay serial interfaces, not about other serial interfaces that are currently running HDLC or PPP. The authors did not mean to exclude the IETF FR interfaces, they just wrote it a little vaguely.

Best regards,

Peter

Correct Answer by Peter Paluch about 7 years 3 months ago

Hello Sarah,

You are heartily welcome.

As to your question: pay attention not to confuse the frame format (Cisco or IETF) with the type of particular LMI messaging (Cisco, ANSI or Q933a). You can have any combination of a frame format and LMI type. Even with "encapsulation frame-relay ietf", you can have Cisco, ANSI or Q933a LMI and that depends on the Frame Relay switch you are connected to.

The frame format and LMI types are independent of each other. The frame format defines how should a particular payload be identified in a frame. The LMI can be viewed simply as a particular type of messages transported inside of a frame whose format has been defined earlier.

Best regards,

Peter

Correct Answer by Peter Paluch about 7 years 3 months ago

Hello Sarah,

1.) I am not quite sure. However, the Q.933 no longer contains the Annex E. It has been moved to X.36 Annex D. In any case, the IETF encapsulation specifications were available to every vendor since their publication as RFC so I would think that pretty much everybody just grabbed the RFC and implemented it. The question is whether the ITU specified yet another and different form of multiprotocol encapsulation on a single VC, or it just took the RFC and codified it in their own recommendation without substantial changes. It the ITU just grabbed the RFC without making changes to it then there's basically nothing new to implement.

2.) The FECN bit was set by FRSW1 and will remain set after the frame passes the FRSW2. As a matter of fact, once a FECN is set, it remains set until the frame reaches the destination router.

3.) The same as in previous question - once a BECN is set it will remain set until the frame reaches the destination.

Best regards,

Peter

  • 1
  • 2
  • 3
  • 4
  • 5
Overall Rating: 5 (3 ratings)
Loading.
Correct Answer
Peter Paluch Thu, 08/27/2009 - 08:02

Hello Sarah,

1.) I am not quite sure. However, the Q.933 no longer contains the Annex E. It has been moved to X.36 Annex D. In any case, the IETF encapsulation specifications were available to every vendor since their publication as RFC so I would think that pretty much everybody just grabbed the RFC and implemented it. The question is whether the ITU specified yet another and different form of multiprotocol encapsulation on a single VC, or it just took the RFC and codified it in their own recommendation without substantial changes. It the ITU just grabbed the RFC without making changes to it then there's basically nothing new to implement.

2.) The FECN bit was set by FRSW1 and will remain set after the frame passes the FRSW2. As a matter of fact, once a FECN is set, it remains set until the frame reaches the destination router.

3.) The same as in previous question - once a BECN is set it will remain set until the frame reaches the destination.

Best regards,

Peter

sarahr202 Thu, 08/27/2009 - 11:55

Hi Peter.

Thanks a lot for answering my questions.

I have one more question.

My book says the command " show frame-relay lmi" lists output forinterfaces that have been configured with " encapsulation frame-relay ".

My question is if the int is configured with" encapsulation frame-relay ietf" , then the command " show frame-relay lmi" won't list any thing?

Thanks a lot.

Correct Answer
Peter Paluch Thu, 08/27/2009 - 12:21

Hello Sarah,

You are heartily welcome.

As to your question: pay attention not to confuse the frame format (Cisco or IETF) with the type of particular LMI messaging (Cisco, ANSI or Q933a). You can have any combination of a frame format and LMI type. Even with "encapsulation frame-relay ietf", you can have Cisco, ANSI or Q933a LMI and that depends on the Frame Relay switch you are connected to.

The frame format and LMI types are independent of each other. The frame format defines how should a particular payload be identified in a frame. The LMI can be viewed simply as a particular type of messages transported inside of a frame whose format has been defined earlier.

Best regards,

Peter

sarahr202 Thu, 08/27/2009 - 13:57

Thanks Peter.

I was confounded by book statement:

That " show frame-relay lmi only lists the output for those interfaces which are configured with " encapsulation frame-relay " command."

I was wondering what if the int in configured with " encapsulation frame-relay ietf" , will the command" show frame-relay lmi" not show any thing for such interface.

Thanks and you have a good day.

Correct Answer
Peter Paluch Thu, 08/27/2009 - 14:08

Hi Sarah,

I think that the book wanted to say that the "show frame lmi" command will display information only about Frame Relay serial interfaces, not about other serial interfaces that are currently running HDLC or PPP. The authors did not mean to exclude the IETF FR interfaces, they just wrote it a little vaguely.

Best regards,

Peter

Actions

This Discussion