- Bronze, 100 points or more
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?
Let say we have a frame relay network with three frame relay switches.
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 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.
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.
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.