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: - The heartbeat mechanism, which verifies
that a VC is operational
- The multicast
mechanism
- The flow control
- The ability to
give DLCIs global significance
- The VC status
mechanism
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: -
Cisco – The original LMI extensions
-
Ansi – Corresponding to the ANSI standard T1.617 Annex
D
- q933a – Corresponding to the ITU standard
Q933 Annex A
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: - A one byte IE identifier
- An IE length field
- One or more bytes
containing actual data that typically includes the status of a
DLCI
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