REIJS@SURFNET.NL (05/23/91)
1 Introduction
Charing bandwidth is one of the main principles of network
protocols. This can e.g. be done by means of time multiplexing
(TDM) equipment and by means of packet switching (e.g. X.25, CLNP
or DoD-IP). Within the framework of ISDN, CCITT has defined a
level two protocol named Frame Relay, which is a light weight
packet switching protocol. It has the connection oriented features
(PVC's, accounting) of X.25, but it has e.g. high throughput, low
end-to-end delay and no error correction.
Frame Relay is part of CCITT I.122, but up until now it is still
not a stable recommendation.
To speed the implementation, some 20 suppliers made an agreement
to make products, which will follow a defacto standard [1]. Both
network provision and CPE (Customer Premises Equipment)
implementations will be produced (see chapter 4).
Because of the above characteristics, Frame Relay is a possible
protocol to be used within a European backbone. The following
sections will elaborate the possibilities of using Frame Relay in
such a backbone.
2 Technology
Frame Relay is belonging in the family of packet switching
protocols. And like X.25 or DoD-IP it is also based on frames with
a variable length (these protocols are called frame relaying
technics).
2.1 The protocol
It is a DTE-DCE interface level 2 protocol with a V.35 physical
interface. Up until now it is only defined for T1/E1 (1.5/2 Mbps),
but in future T3/E3 (45/34 Mbps) will be included in the standard.
The defacto standard [1] is only based on permanent logical links
(comparable with PVC's in X.25, Permanent Virtual Circuits).
Within CCITT one is busy expanding the standard to switched
logical links (Frame Relay 2).
Like in X.25, a permanent logical link gets on both sides of the
connection a (different) number, which are called DLCI's (Data
Link Connection Identifier). Just like the LCN (logical Channel
Number) in X.25, the DLCI has only local significance.
Figure 1 gives an impression of the frame format.
2.2 The service
Frame Relay is a level two service, it includes the following
features:
- variable frame length (the standard talks about a minimum
allowable frame length of 262 octets, but at this moment the
smallest implemented maximum frame length is 4000 octets).
- maximum number of permanent logical links is 910
- no error recovery
- frames arrive in the correct order
- predefined permanent logical links are addressable by means of
DLCI
- low end-to-end delay (appr. 2 msec per node)
- high throughput (because of light weight protocol)
- no congestion control (must be preformed by DTE).
Optional services (so not mandatory):
- global addressing
- multicast capability (for the connection less world this
options will be very important for Address Resolution
Protocols [ARP]).
- flow control
2.3 Weaknesses of protocol
Besides the advantages of Frame Relay, it also has some
disadvantages. The following are the most important:
- the flow control must be handled by the DTE's. If these are
not able to do something, packets are lost in the Frame Relay
network (level 3 or 4 protocols will handle this loss).
- it is not clearly known how a Frame Relay network will handle
congestion. And related to this: priority, use of discard
facilities, rerouting
- it is not yet know what performance information will be
available from the Frame Relay network.
2.4 Management facilities
Additional to the data link service, Frame Relay also has some
management functions incorporated. These features are not yet
incorporate in the CCITT standard. The defacto standard has the
following properties:
- the implementation of the management protocol is analog to
Q.931
- it is DTE-DCE protocol
- the DTE gets notifications on the change of DLCI's
- the network is able to monitor the link between the DTE and
DCE.
An optional LMI-feature is asynchronous DLCI status updates.
3 The status of the standards
3.1 Frame Relay
The formal standardization is being undertaken by CCITT and ANSI.
CCITT defines the basic Frame Relay service in I.122. It defines
two services:
- Frame Relay 1
permanent logical links
- Frame Relay 2
switched logical links
The service is using the LAPD multiplexer method (Q.921) and it
uses the out of band signaling of Q.931 (including management
functions [LMI]).
The defacto standard [1] is based on Frame Relay 1 and the LMI
message format is based on Q.931. All mentioned standards are
still not stable. The expected arrival of a first draft of the
Frame Relay 2 will be end 1991.
Some remarks on naming of standard (Q.xxx and I.xxx belong to
CCITT and T1.xxx belong to ANSI):
I.441 is identical to Q.921
T1.602 is equivalent to Q.921
I.451 is identical to Q.931
T1.607 and T1.608 are equivalent to Q.931
T1.606 is equivalent to I.122
3.2 Layers below Frame Relay
At this moment suppliers have there own proprietary protocols
below Frame Relay. Most protocols are cell relaying technics
(frames with fixed lengths).
In future Frame Relay will be transported by cell relaying
protocols like ATM or DQDB.
3.3 Levels above Frame Relay
There are not yet stable standards for supporting X.25, CLNS or
DoD-IP over Frame Relay.
In the Internet world people are busy making a RFC for DoD-IP over
Frame Relay. The ongoing discussion can be followed through the
list: IPLPDN@nri.reston.va.us (IP over Large Public Data
Networks).
No firm dates can be given when these protocols are stable.
4 Product availability
Some 22 supplier did sign an agreement which said that they would
implement Frame Relay (based on [1]). The suppliers can be divided
in CPE and network equipment suppliers. De speed of the interfaces
range from 256 kbps to 2 Mbps. It is expected that at the end of
this year the products will be able to support 2 Mbps.
The dates of the availability of products has been gathered in the
period of Jan. up and including April 1991. In case not enough
information is gotten, one sees question marks.
4.1 Frame Relay networks
The following suppliers agreed on making Frame Relay network
equipment (between brackets: date available, product name): AT&T
(now, IACS), Hughes Networks (Q2/91, IPN), Newbridge (???,
3600/3645), Northern Telecom (Q4/91, DPN100), StrataCom (now,
IPX), Timeplex (Q4/91, LINK), US Sprint (now, TP7900).
4.2 Levels below Frame Relay
Only proprietary cell relaying technics exists (e.g. StrataCom).
4.3 Frame Relay CPE
The following suppliers have agreed on making Frame Relay CPE: ACC
(???, ACS4100), Cisco (now, AGS), Digital (???, ???), IBM (???,
3745), Netrix (???, ???), Timeplex (???, TIME/LAN), VitaLink (???,
???) and Wellfleet (???, ???).
5 Conclusions
The overall conclusions are:
- Frame Relay is still in the process of standardization
- It is not yet feasible to make a European wide multiprotocol
backbone, based on Frame Relay. If in the very near future
products will be stable and tested, it could be used for a
production multiprotocol backbone.
- Frame Relay offers a service which could be very well used in
multiprotocol backbone, because it could deliver a common
protocol for X.25, CLNP and DoD-IP.
5.1 Future study subjects for multiprotocol backbone based on
Frame Relay
The following aspects must be studied:
- What impact does the lack of congestion control have on an
operational service? What additional features must be
available within the Frame Relay protocol.
- How important is it to have stable standards for
routing/bridging X.25, CLNP or DoD-IP over Frame Relay?
- Because Frame Relay is only an interface standard, there are
not yet interworking standards between Frame Relay networks.
What problems will result from this lack?
- Why are there no European suppliers for Frame Relay equipment?
6 Documents
[1] Frame Relay specification with extensions, doc. nr.
001-208966, 1990, Digital, Northern Telecom, StrataCom.
[2] Broadband networks, McQuillan, J.M., Data communications
international, June 1990, pp 62-74
[3] Frame Relay white paper, Button, B., StrataCom, May 1990.
[4] The Frame Relay solution, US Sprint, Telenotes Vol. 1, Nr. 2,
Sept. 1990.
[5] Frame Relay networks: not as simple as they seem, Opderbeck,
H., Data communications international, Dec. 1990, pp 89-91.
[6] Review of backbone technologies, Heinanen, J., RARE High speed
symposium, Jan. 17, 1991.
[7] I.122, Framework for providing additional packet mode bearer
services, Melbourne, Nov. 1988.
[8] Q.921, ISDN user-network interface - Data link layer
specification, Melbourne, Nov. 1988.
[9] Q.931, ISDN user-network interface - Layer 3 specification for
basic call control, Melborne, Nov. 1988.