Frame Switching

Chapter 8. High Speed Packet Networking

8.1 Frame Switching

Frame switching describes a very common generic network interfacing

technique. Many "X.25 networks" on the market offer an "SOLC PAD" function which is capable of switching data from an SOLC link in one part of the network to another SOLC link somewhere else in the network.42 The term "Frame Switching" does not describe any standardised protocol or interface at all.

The frame switching technique is not new. Nor is it a "high speed" technology.

Understanding frame switching is, however, important to understanding the genesis of Frame Relay.

Consider two machines communicating over a point-to-point SOLC43 link.

EJ

^A

S_D_L_C_L i_n_k ____ . - __

EJox B

frame -.-.

In the diagram when Box A needs to send something to Box B header and trailer information specific to the link control protocol is appended to the ends of the block to be sent. This block of data is called a "frame".

In a network situation, inside the frame there will typically be a network header on the front of the user data.

* * * * * *

*

EJ

^{A ~} :- - - - -: +-fram\ EJox B

frame

-.-.* *

* *

* * * * * *

If we want to place a network between Boxes A and B as illustrated above, then there are many alternatives. Typically in the front of the user data message there will be a set of network protocol headers. We could:

1. Terminate the link control protocol (from Box A's perspective make the network "look like" box B) and then use the network protocol headers to

42 The IBM X.25Net product can perform this function.

43 In principle, the link protocol used doesn't matter at all. Frame switching interfaces exist for many different types of link control such as BSC and LAPB as well as SDLC.

© Copyright IBM Corp. 1992 143

route the data to its destination. The problem with this is that the network needs to understand the network headers in the data. This is often a complex problem since there are many different network protocols in existence.

2. Take whatever is sent by Box A, put our own network headers onto the front, route it through the intermediate network and then send it on to Box B.

This is very simple to do and satisfies many requirements but:

• Link control protocols have very short time-outs, which can be lengthened but are a problem if the network delay is irregular.

• Many link controls (especially SOLe) rely for their operation on regular polling. Sending polls across the network (and receiving the responses) can cause significant additional network overhead.

• The network addresses of the communicating boxes must be

prespecified to the network and must be fixed. The address in the link control headerM can be used to identify different destinations, but this ability is very limited. polling and error recovery are handled locally and do not pass through the network.

Frame switching is like alternative 2 above, but the polling function is handled locally at each end of the network. Only data and control messages are

forwarded through the network. The details of how this works vary from one \ implementation to another. A number of characteristics should be noted:

• The link control from the user to the network is terminated in the nearest

• Many implementations of this kind allow the end user boxes to initialise their communications at different times. This precludes those boxes from

exchanging their characteristics using XID (eXchange IDentification) protocols. It is this characteristic which prevents many networks from correctly handling SNA PU 2.1 nodes. These nodes rely on XID type 3 to tell each other their characteristics and will not function correctly unless the

44 in SOLe one can address up to 255 secondary "boxes" but the control end of the link has no address - it is specified by context.

(

~

frame switching network understands the XID protocols and properly synchronises the initialisation.

• Since the line control is terminated by the nearest network node when a frame is sent to the network it is acknowledged immediately on receipt. If that frame is subsequently lost by the network (through a node failure, for example) the end "boxes" will "think" that the frame has been received by the destination when it really has not.⁴⁵ This is no problem for SNA (or OSI) since link control is not relied upon for network level acknowledgements (that's what layered architecture is all about). However, it is disruptive since if a frame is lost there is no recovery and connections (sessions) running above the link layer must be terminated and restarted.

Some older devices (predominantly SSC) actually use line control level acknowledgements to signal correct receipt of the data to the user application. (There are SSC versions of frame switching available in the marketplace.) These older devices will not function correctly over a frame switching system because data can be lost without being detected.

• There is another problem with link level switching systems (this also applies to LAN bridges and routers). The network loses the ability to distinguish between different types of traffic based on priority.

For example, an SDLC link may carry many SNA sessions all at different priorities. At any point in time the link may be carrying highly critical interactive traffic or batch traffic (or a mixture). The network has no way of knowing so it must treat all traffic as a single priority.

The consequence of this is that the network is unable to load its intermediate links or nodes to utilisations much above 60% at the peak (with average utilisations of perhaps 20% to 30%). In contrast, if the network is able to distinguish between data flows based on priority, then resources can be utilised up to 60% (peak) for interactive traffic only and the remaining capacity may be used for non-critical batch traffic. (SNA networks operate this way.)

The" net" of the above is that networks that switch frames are much less efficient in their use of link bandwidth (and node cycles) than networks (like SNA) that are able to recognise priorities.

45 Contrast this with the later description of Frame Relay. In Frame Relay the link control operates across the network and thus can be used to recover from network losses of data.

Chapter 8. High Speed Packet Networking

145