setting the Discard Eligibility (DE) bit in the address field. The switch maintains a bit counter for each VC. An incoming frame is marked DE if it puts the counter over Bc. An incoming frame is discarded if it pushes the counter over Bc + Be. At the end of each Tc seconds the counter is reduced by Bc. The counter may not be negative, so idle time cannot be saved up. Frames arriving at a switch are queued or buffered prior to forwarding. As in any queuing system, it is possible that there will be an excessive buildup of frames at a switch. This causes delays. Delays lead to unnecessary retransmissions that occur when higher-level protocols receive no acknowledgment within a set time. In severe cases this can cause a serious drop in network throughput. To avoid this problem, frame relay switches incorporate a policy of dropping frames from a queue to keep the queues short. Frames with their DE bit set will be dropped first. When a switch sees its queue increasing, it tries to reduce the flow of frames to it. It does this by notifying DTEs of the problem by setting the Explicit Congestion Notification (ECN) bits in the frame address field. The Forward ECN (FECN) bit is set on every frame that the switch receives on the congested link. The Backward ECN (BECN) bit is set on every frame that the switch places onto the congested link. DTEs receiving frames with the ECN bits set are expected to try to reduce the flow of frames until the congestion clears. If the congestion occurs on an internal trunk, DTEs may receive notification even though they are not the cause of the congestion. The DE, FECN and BECN bits are part of the address field in the LAPF frame.
Content 5.1 Frame Relay Concepts 5.1.5 Frame Relay address mapping and topology When more than two sites are to be connected, consideration must be given to the topology of the connections between them. Frame Relay is unlikely to be cost-effective when only two sites are interconnected with a point-to-point connection. Frame Relay is more cost-effective where multiple sites must be interconnected. WANs are often interconnected as a star topology. A central site hosts the primary services and is connected to each of the remote sites needing access to the services. In this hub and spoke topology the location of the hub is chosen to give the lowest leased line cost. When implementing a star topology with Frame Relay, each remote site has an access link to the frame relay cloud with a single VC. The hub has an access link with multiple VCs, one for each remote site. Because Frame Relay tariffs are not distance related, the hub does not need to be in the geographical center of the network. A full mesh topology is chosen when services to be accessed are geographically dispersed and highly reliable access to them is required. With full mesh, every site is connected to every other site. Unlike with leased line interconnections, this can be achieved in Frame Relay without additional hardware. It is necessary to configure additional VCs on the existing links to upgrade from star to full mesh topology. Multiple VCs on an access link will generally make better use of Frame Relay than single VCs. This is because they take advantage of the built-in statistical multiplexing. For large networks, full mesh topology is seldom affordable. This is because the number of links required for a full mesh topology grows at almost the square of the number of sites. While there is no equipment issue for Frame Relay, there is a limit of less than 1000 VCs per link. In practice, the limit will be less than that, and larger networks will generally be partial mesh topology. With partial mesh, there are more interconnections than required for a star arrangement, but not as many as for a full mesh. The actual pattern is very dependant on the data flow requirements. In any Frame Relay topology, when a single interface is used to interconnect multiple sites, there may be reachability issues. This is due to the nonbroadcast multiaccess (NBMA) nature of Frame Relay. Split horizon is a technique used by routing protocols to prevent routing loops. Split horizon does not allow routing updates to be sent out the same interface that was the source of the route information. This can cause problems with routing updates in a Frame Relay environment where multiple PVCs are on a single physical interface. Whatever the underlying topology of the physical network, a mapping is needed in each FRAD or router between a data link layer Frame Relay address and a network layer address, such as an IP address. Essentially, the router needs to know what networks are reachable beyond a particular interface. The same problem exists if an ordinary leased line is connected to an interface. The difference is that the remote end of a leased line is connected directly to a single router. Frames from the DTE travel down a leased line as far as a network switch, where they may fan out to as many as 1000 routers. The DLCI for each VC must be associated with the network address of its remote router. This information can be configured manually by using map commands. It can also be configured automatically, taking LMI status information and sending a Reverse Address Resolution Protocol (RARP) message on each VC identified. This process is described in more detail in a separate section. Web Links Configuring Dynamic and Static Mapping for Multipoint Subinterfaces http://www.cisco.com/warp/public/ 125/ 17.html#17-A
Content 5.1 Frame Relay Concepts 5.1.6 Frame Relay LMI Frame Relay was designed to provide packet-switched data transfer with minimal end-to-end delays. Anything that might contribute to delays was omitted. When vendors came to implement Frame Relay as a separate technology rather than as one component of ISDN, they decided that there was a need for DTEs to dynamically acquire information about the status of the network. This feature was omitted in the original design. The extensions for this status transfer are called the Local Management Interface (LMI). The 10-bit DLCI field allows VC identifiers 0 through 1023. The LMI extensions reserve some of these identifiers. This reduces the number of permitted VCs. LMI messages are exchanged between the DTE and DCE using these reserved DLCIs. The LMI extensions include the following: There are several LMI types, each of which is incompatible with the others. The LMI type configured on the router must match the type used by the service provider. Three types of LMIs are supported by Cisco routers: LMI messages are carried in a variant of LAPF frames. This variant includes four extra fields in the header so that they will be compatible with the LAPD frames used in ISDN. The address field carries one of the reserved DLCIs. Following this are the control, protocol discriminator, and call reference fields that do not change. The fourth field indicates the LMI message type. There are one or more information elements (IE) that follow the header. Each IE consists of the following: Status messages help verify the integrity of logical and physical links. This information is critical in a routing environment because routing protocols make decisions based on link integrity. Interactive Media Activity Drag and Drop: LMI Message Format When the student has completed this activity, the student will be able to correctly order the fields in a LMI message frame. Web Links Frame Relay http://www.tele.sunyit.edu/ internetworking/ 55149.htm