NOTE - for simplicity - the core (transit) switches within the cloud are not shown.  The two switches shown are "edge switches" or "access switches".

All public Frame Relay networks use proprietary core switch technology, and they all use small "sub-frames".  This makes the core architecture have a similar advantage to ATM - fixed cell sizes - or in the case of FR, fixed sub-frame sizes.  This allows the core switches (transit switches) to transfer sub-frames at high speed, since they do no have to work with SAR (Segmentation And Reassembly), as the edge switches do.  The size of the frames varies greatly, but the size of of the sub-frames is fixed.  Each vendor has their own, proprietary size for the subframes.  For example, Alcatel (now out of the FR switch business) used sub-frames of 132 bytes.    

Frames and Edge Switches - note the two types of frames . . . "Frames" and "subFrames".  The Frames are mostly all the same size, but sice they are typically embedding IP packets, the last frame for each packet varies in size.  For example, if an IP packet is 10000 bytes and the frame size is 4096 bytes, then the first two frames would be full size, and the third frame would only be 10000 - (4096+4096) = 1808 bytes.  Any time a switch has to deal with changing sizes, it requires much more CPU overhead.  But since the edge switch is only servicing a relatively small number of PVC's the extra processing does not present a problem.  

SubFrames and Transit Switches (Core Switches) - the inner, core switches (transit switches), have to deal with thousands of PVC's !!  To be able to handle that volume, the design calls for all frames to be the same size, and to be small (a similar concept to ATM's tiny 53-byte cells).  The vendors use differing sizes of subframes - Nortel, for example, uses 132 bytes.  This way, all the transit switches can be built for speed, and can rely on the fact that every subframe that arrives will be exactly 132 bytes.  Now all the switch has to do is switch subframes . . . no policing of the customer's router and making sure it adheres to it's contractual frame rate and asking it how big the frames will be . . . no scaling up and down to work with the many differing size incoming frames . . . it is now dedicated solely to switching.

In essence the network is "standard Frame Relay" outside of the cloud and "proprietary, non-standard" Frame Relay inside the cloud.  The Frame Relay standards actually only deal with the access portion, and leave the transit up to the manufacturer - but all manufacturer's of FR edge switches must adhere to the Q.922A and Annex A standards !!!

see also  http://www.alliancedatacom.com/frame-relay-tutorials.asp (Frame Relay Tutorials)

Overview of Frame Relay

This topic is so complex - that the details cause most to lose sight of the basic operation.  Thousands have contributed to countless papers, as the standards have been formed, perfected, changed, and added to.  What has resulted is a large number of 2-inch thick three-ring binders.  We will discuss only the most important details  -  leaving any further investigation up to the reader, much of which is available at the Frame Relay Forum website - particularly in the FRF standards . . . FRF.1.2 through FRF.19  -  in addition, they have a good basic tutorial on the FR-Forum site.

The first public frame relay service offering appeared in North America during 1992 from companies such as US Sprint, AT&T, BT North America, Wiltel and Compuserve. See also the  "Frame Relay Forum" (www.frforum.com).

Frame Relay gave the long-distance carriers a method of connecting LAN's on an "as needed" basis, instead of the 24x7 connectivity provided by private lines.  Finally, the carriers had a way of sharing their backbone - which meant they could support a huge number of customers.   

X.25 - "Packet" - Layer 3 Precursor to Frame Relay  -  X.25, called "packet services" was the basis for Frame.  The methodology was simple - it took streams of data from one site, and broke them up into discrete blocks of data (called  packets) and then statistically multiplexed them over a transmission path.  The path is called a VC (Virtual Connection), because the packets pass through switches along the way and are not sent along one dedicated line.  Therefore, it is a path, or circuit in that it follows a predetermined route, but it is virtual in that the path is a combination of segments along the way.  The VC typically includes several switches  -  it is set up, used for data transmission, torn down.  

X.25 overcame poor quality transmission lines by providing error detection and correction each step of the way (at each switch - and there can be many switches along a VC).  This is called "store and forward" . . . the data was received, stored briefly while error detection and correction was performed, and then forwarded to the next switch along the path.  The earlier switches were rather slow - but the time it took to store before forwarding was so great that it only allowed a transmission rate maximum of one DS0, or 64kbps.

Frame Relay - "Fast Packet"  - Layer 2 service - the name is a misnomer, since Frame Relay used "frames" instead of packets.  This technology was a godsend, as it became available just in time for all the bandwidth-hungry customers who were limited by the 64k maximum.  Companies were desperate for bandwidth, and FR increased it by 2,400% !!!  As the need for speed increased, the quality of transmission lines fortunately has also improved greatly, with the advent of nationwide fiber-optic backbones as well as improved LEC quality for the "last mile".  Frame Relay increased the speed of X.25 from DS0 (64k) to DS1 (1536k).  DS1 is composed of 24-DS0's.  

The key was to allow packets to traverse the entire path, with error detection (and when an error is detected, the frame is discarded), but no error correction  -  which meant no laborious store and forward.  This forces the endpoints to add capability for retransmission, and since end-to-end retransmission is now a mandatory feature - the frames have to be numbered in sequence so that they can be reassembled in the correct order.

The Q.922A (Q.922 Annex A) Frame -  the Frame Relay standards define a frame format under Annex D, called Q.922A   This standard denotes that the frame is variable in length - although it does not specify a specific length.  Most providers use generic lengths of either 2048 or 4096 bytes.  The Q.922A frame occurs in the UNI (User-to-Network Interface), between the customer's router or FRAD (Frame Relay Access Device) and the edge switch of the carrier's FR cloud.  Within the cloud, a proprietary format is used.  For now, assume the Q.922 frames are 4096 in length, until the end of the transmission - and then whatever was left over would be transmitted in a smaller frame.  For example, if a user sent a file of 9140 byes, then two 4096-byte frames would be sent followed by one frame of 948 bytes (9140 = 4096 + 4096 + 948).  

The Q.922A standard had to stay, since it allowed frame relay access device hardware manufacturers to design their interface.  However, the Frame Relay "cloud" used proprietary devices and technologies.  Each manufacturer designed their own methodologies.  In fact, in all those countless diagrams where you see "FR" written in the center of the cloud  -  it is actually not FR, but a proprietary means of tranporting the actual FR (The customer's Q.922A frame) from one access edge switch to the far end edge switch.  All the hardware vendors followed suit and began using small, fixed-size "subframes" to transport the data across the backbone.  This required fragmentation to occur in the first edge switch and defragmentation in the last  -  but this process, although somewhat of a slowdown, was faster than having to deal with large Q.922A frames of varying size.

The Proprietary Sub-Frames - research revealed that the deciphering of the beginning and end of units of data took up a majority of the processing time.  It was also determined that the Q.922A standard frame (which was either 2048 or 4096 bytes) required more processing than tiny chunks of data.  

Seizing this concept, manufacturers such as Nortel and Alcatel, began manufacturing two classes of Frame Relay switches . . . Edge and Core.  For the edge switches, the processing was intensive . . . they had to be able to fragment, reassemble, and also perform Layer 2 switching for the frames.  

For the core switches (the internal switches of the cloud) - they used the "KFC" theory, that if you only have to do one thing - it will be done right.  Core switches must sustain massive traffic loads, and as such, cannot be bothered with assembling and disassembling frames (fragmenting/defragmenting).  Therefore is was decided that the edge switches would create small fixed-size cells (Alcatel uses 132 bytes).  This meant that the core switches knew exactly where each sub-frame begins and ends.  No extra processing needed.  Therefore they could act as a dedicated traffic cop, and switch at extremely high speeds.