Frame Relay Benefits: Frame Relay is specifically designed for bursty LAN applications. it supports a wide range of traffic pattern and topology model, and can consolidate previously separate network into one-network solution.
|Frame Relay||FR’s predecessor|
|Require only one FR local physical link||dedicated physical p2p link for per type of data per peer|
|High BW utilization & Low Subscriber fee||BW waste & Expensive rent cost|
|Single Integrated network for all Application||each physical WAN link for each type of data|
|High scalability and low-cost and easy topology manipulation||high cost for meshed topology and adding new remote site|
Aggregating all logical connections into one physical link: highly scalable and changeable with low cost as the connections FR provided are logical, .
customer pays for shared BW in FR Cloud rather than dedicated BW.
Besides, instead of deploying different local WAN physical links for different types of data, one local FR physical link are shared by all applications which make FR network an Integrated network for all kinds of data. For higher BW requirements, FR can easily be upgraded to T1, E1, Full T3 (45 Mbps) or higher.
High BW Efficiency
X.25 packet switched networks typically allocated a fixed bandwidth through the network for each X.25 access, regardless of the current load. This resource allocation approach, while apt for applications that require guaranteed quality of service, is inefficient for applications that are highly dynamic in their load characteristics or which would benefit from a more dynamic resource allocation. Frame Relay networks can dynamically allocate bandwidth at both the physical and logical channel level.
For most services, the network provides a permanent virtual circuit (PVC), which means that the customer sees a continuous, dedicated connection (between access device and SP FR switch) without having to pay for a full-time leased line, while the service-provider figures out the route each frame travels to its destination and can charge based on usage.
Frame Relay Overview
Frame Relay Origination
Frame Relay is a stripped down version of X.25 (oldest packet-switched service with data rate up to 2 Mbps). Unlike X.25, who is designed for low data rate transmission on high error-rate transmission facilities and provides hop-by-hop error correction and orderly delivery, Frame Relay is created for high throughput and approximately error-free network. It only provides built-in congestion control and discard lot of overhead used for reliable transmission, and offloads the error correction and orderly delivery to the higher level.
Frame Relay Data Rate
Frame Relay can run on fractional T-1 or full T-carrier system carriers (outside the Americas, E1 or full E-carrier). Frame Relay complements and provides a mid-range service between basic rate ISDN, which offers bandwidth at 128 kbit/s, and Asynchronous Transfer Mode (ATM), which operates in somewhat similar fashion to Frame Relay but at speeds from 155.520 Mbit/s to 622.080 Mbit/s.
Frame Relay Packet Data Unit
Frame-relay frame structure essentially mirrors almost exactly that defined for LAP-D. However, there is no control field in FR PDU.
Each FR PDU consists of below sections:
Flag Field (octet 1): used to perform high-level data link synchronization which indicates the beginning and end of the frame.
Address Field (octet 2 – 3, 4 or 5): comprise DLCI to identify VC and congestion control bits which include FECN, BECN, DE. FECN bit notifies the receiver of the congestion while the BECN notifies the sender.
Information Field:A system parameter defines the maximum number of data bytes that a host can pack into a frame. Hosts may negotiate the actual maximum frame length at call set-up time. The standard specifies the maximum value as at least 262 octets, so that any type of networks can support that, while FR recommends maximum frame length to be at least 1600 octets to avoid segmentation and reassembling at the end of end users.
Frame Check Sequence (FCS) Field: CRC check to see if the frame is erred and need to be discarded.
Frame Relay Congestion Control
congestion control in FR network consists of following elements:
Admission Control: The network decides whether to accept a new connection request, based on the relation of the requested traffic descriptor and the network’s residual capacity. The traffic descriptor consists of a set of parameters communicated to the switching nodes at call set-up time or at service-subscription time, and which characterizes the connection’s statistical properties. The traffic descriptor consists of three elements:
1. Committed Information Rate (CIR): The average rate (in bit/s) at which the network guarantees to transfer information units over a measurement interval T. This T interval is defined as: T = Bc/CIR.
2. Committed Burst Size (BC): The maximum number of information units transmittable during the interval T.
3. Excess Burst Size (BE): The maximum number of uncommitted information units (in bits) that the network will attempt to carry during the interval.
Once the network has established a connection, the edge node of the Frame Relay network must monitor the connection’s traffic flow to ensure that the actual usage of network resources does not exceed this specification. Frame Relay defines some restrictions on the user’s information rate. It allows the network to enforce the end user’s information rate and discard information when the subscribed access rate is exceeded. Explicit congestion notification is proposed as the congestion avoidance policy.
PVC & SVC
PVC: basically a predefined layer 2 path through a service provider network that sort of “emulates” a point-to-point leased line for the customer.
Considering Frame Relay Switching from SP’s perspective
In Frame Relay Cloud, each FR switch will be manually configured with switch path which are actually the static mapping between input interface & input DLCI and output interface & output DLCI. Besides, those kind of mappings should be configured for both way. In that sense, it is quite clear that Frame Relay network is purely a layer 2 network in which only layer 2 address is required for switching and no IP address is needed.
Consider Frame Relay Switching from customer’s perspective
For Frame Relay Access Router (DTE) who is connected to a Frame Relay Switch through a Virtual Channel identified by specific DLCI, it should know which IP addresses are reachable through that specific DLCI. Therefore, DTE routers need a mapping between reachable remote IP addresses and local DLCIs. And this can be done in two ways: Static and Dynamic.
Static: The static method typically involves the frame-relay interface-dlci command or the frame-relay map command depending on exactly what is going on.
Dynamic: The dynamic method is where inverse-ARP has a part to play. Essentially what happens is that an inverse-ARP request is sent out through a particular DLCI from the originating router saying “I have IP address x”. Since the receiving router will receive that request on its own local DLCI, it now knows which remote IP address is reachable through the local DLCI the request was received on. The receiving router than sends an inverse-ARP reply that contains his IP address. Now at the originating router we also have a mapping between local DLCI and a reachable remote IP address.
Reference URL: http://astorinonetworks.com/2011/06/15/understanding-frame-relay-inverse-arp/
Enable and Disable Frame Relay Inverse ARP
An interface is by default a “multipoint” interface so, frame-relay inverse-arp is on (for point-to-point, there is no Inverse ARP).
When will Inverse ARP be sent out:
1. For physical interface: IF you have an IP address on the interface, the router will send an Inverse-ARP request out every single DLCI associated with the interface. If you have no other sub-interfaces with DLCIs assigned via frame-relay interface-dlci or frame-relay map commands this means ALL of them!
2. For Multipoint Subinterfaces: By default no inverse-ARP requests will be sent UNLESS you utilize the frame-relay interface-dlci command, and you have an IP address on the interface. If you put this command on your subinterface for one or more DLCIs, inverse ARPs will indeed be sent for those DLCIs.
Disable Inverse-ARP by static DLCI / IP mapping: When you configure Static mapping for a DLCI on FR multipoint interface, it will automatically disable the Inverse-ARP for specific DLCI while the other DLCIs on that multipoint interface still have Inverse-ARP on. However, you will see both static and dynamic mappings for that specific DLCI from the output of command “show frame-relay map”, because the old dynamic mapping inserted by Inverse-ARP will be deleted only after reloading the router.
Disable Inverse-ARP on per-interface base: issuing the no frame-relay inverse-arp interface command.
Disable Inverse-ARP on per-DLCI base: issuing the no frame-relay inverse-arp ip command
Note that: Disable Inverse-ARP sending will not disable responding to Inverse-ARP received which should be disabled by interface command “no arp frame-relay”.
Reference URL: http://www.cisco.com/en/US/tech/tk713/tk237/technologies_tech_note09186a008014f8a7.shtml#back https://supportforums.cisco.com/message/110813#110813
Local Management Interface
Local Management Interface (LMI) is a signaling standard used between routers and frame relay switches.Information about keepalives, global addressing, IP Multicast and the status of virtual circuits is commonly exchanged using LMI. The routers learn the data-link connection identifiers (DLCIs) they need to use from the Frame Relay switch via LMI updates. The routers then send Inverse ARP for the remote IP address and create a mapping of local DLCIs and their associated remote IP addresses.
There are three standards for LMI:
ANSI / ITU-T Q.933 (using DLCI 0 for signaling, DLCI 16~992 for Data),
Cisco (using DLCI 1023 for Signaling, DLCI 16~1007 for Data).
(DLCI has 10 bits for addressing).
By default, the Local Management Interface (LMI)-type defaults to “cisco” LMI.
(config-if)# frame-relay lmi-type ansi/cisco/q933a
Configuring Frame Relay
1. configure IP address and encapsulation type on interface or Per-DLCI basis
(config-if)#ip address 172.16.10.1 255.255.255.0
(config-if)#encapsulation frame-relay [cisco/ieft]
2. configure LMI type
(config-if)#frame-relay lmi-type <cisco/ansi/q933a>
3. configure Frame Relay mapping
—- Static mapping
(config-if)#no frame-relay inverse-arp (disable Inverse-ARP)
(config-if)#no arp frame-relay (enable Inverse-ARP for specific protocol-DLCI pairs)
(config-if)#frame-relay map <protocol> <protocol-address> <dlci-number> [broadcast] [cisco/ietf] //static mapping configuration automatically disables Dynamic Inverse ARP.
—- Automatic Mapping using Inverse-ARP by default
Why Sub-interface is introduced in Frame Relay network
Sub-interface makes partially meshed Frame Relay network possible, as it indirectly enables split-horizon to solve below 2 issues in partially meshed FR network, and finally make most protocols which require split-horizon fully supported on partially meshed FR network.
Without sub-interface, split-horizon on a single physical interface is not supported, thus mapping a single DLCI to several destination does not make sense. That is why each DLCI can only be mapped to one destination (IP Address), and so does on the SP’s FR switch.
- Most protocols assume transitivity on a logical network; that is, if station A can talk to station B, and station B can talk to station C, then station A should be able to talk to station C directly. Transitivity is true on LANs, but not on Frame Relay networks unless A is directly connected to C (impossible, as this is a partially meshed FR network) or split-horizon is enabled on FR interface (packet is received and forwarded out in the same interface using a different DLCI).
- Plus, certain protocols, such as AppleTalk and transparent bridging, cannot be supported on partially meshed networks because they require “split horizon”.
- With FR sub-interfaces, a single physical interface is treated as multiple virtual interfaces. Packets received on one virtual interface can now be forwarded out another virtual interface, even if they are configured on the same physical interface.
How Frame Relay handle multicast & broadcast
When a router needs to send a broadcast or multicast over Frame Relay, the router must actually send a copy of the packet over each PVC instead, because the Frame Relay network does not have the ability to replicate the broadcast or multicast packet. Routers do send the multicast OSPF Hellos for any PVCs listed in frame-relay interface-dlci commands, and for any DLCIs listed in frame-relay map commands if the broadcast keyword was included. Otherwise, multicast or broadcast packets are not replicated.
Alternatively, some OSPF network types tell a router to not attempt automatic discovery of neighbors. In such a case, the router should be configured with the neighbor x.x.x.x OSPF router subcommand. This command overcomes the issue with neighbor discovery.
FR interface types from perspective of OSPF
- Point-to-Multipoint FR Interface (P2M): It is a collection of point-to-point links between various devices on a segment and normally takes 2 forms with Sub-interface configured or not. (Split-horizon could be supported on this P2M interface when sub-interfaces are introduced). By default, OSPF treats P2M FR interface as NBMA network type where routers do not proactively send out OSPF Hello and broadcast & multicast is not natively supported. However, P2M interface can provide broadcast & multicast support to discover OSPF neighbors when frame-relay map ip x.x.x.x xxx broadcast or ip ospf network broadcast is manually configured. Alternatively, you can also manually designate OSPF neighbor using command “neighbor x.x.x.x”.
- Point-to-Point FR Interface (P2P): it natively support broadcast & multicast this OSPF neighborhood discovery is automatically supported.