Figure 1. Examples of frame relay and ATM cell relay interworking:
a) network interworking; b) service interworking.
Frame relay has proven to be a very successful wide area networking service, and ATM is gaining momentum in the industry to become the preferred common backbone technology for supporting a wide variety of network services, including native ATM cell relay service and frame relay service. In the years ahead, ATM is poised to become the dominant networking technology. Since frame relay and cell relay services will coexist for a long time to come, it is imperative that the network and service interworking specifications be defined and implemented. This article focuses on the topic of frame relay and ATM cell relay service and network interworking. The authors provide the rationale, the standards-based methodology, the major open issues, and a likely evolution scenario for the interworking of frame relay and ATM cell relay networks and services.
The ATM Forum and the Frame Relay Forum have approved implementation
agreements for Frame Relay/ATM PVC Network Interworking and Service Interworking.
Network interworking enables FR information between FR end stations to be
transported over an ATM backbone. The FR end stations can connect to either
the ATM network or the FR network. In the former case, the FR CPE maps FR
to ATM, and is required to perform FR-specific functions in the FR service-specific
convergence sublayer (FR-SSCS) of ATM adaptation layer type 5 (AAL5) as
part of this mapping. Service interworking, on the other hand, allows FR
CPE on an FR network to interwork transparently with ATM CPE on an ATM network
without requiring that either type of CPE perform a mapping to the other's
protocol.
This article focuses on the topic of frame relay and ATM cell relay service
and network interworking, and provides the rationale, the methodology, and
the issues and problems of such interworking. First, we briefly review frame
relay and ATM cell relay services and networks followed by a presentation
of the interworking requirements of the two services at both the network
and service levels. Then we discuss some of the major open issues of FR/ATM
interworking, and their potential solutions. We then discuss how FR/ATM
interworking is likely to evolve. Finally, we conclude the article.
Frame Relay
Frame relay is a fast packet technology derived from X.25 that leverages
on the capabilities of the error-free physical transmission medium and the
ever-increasing intelligence and processing capabilities of end-user equipment.
Essentially, central to the concept of frame relay is the elimination of
much of the overhead and functions of the data link layer of the X.25 protocol,
Link Access Procedure for the B-Channel (LAP-B), and derives its name from
the packets processed at this layer, called "frames." Throughput
and delay performance is significantly enhanced because no link-layer resequencing
or error correction and retransmissions are done between nodes. When an
error is detected in a frame, it is simply discarded with the requirement
on the end stations at higher layers to enact error recovery mechanisms.
Furthermore, FR is a connection-oriented service, and the protocol defines
the interface between the user and the FR network, commonly known as the
FR interface or FR user-network interface (FRI or FR-UNI). It requires setting
up a connection, either a permanent virtual connection (PVC) or switched
virtual connection (SVC), between the two FR stations prior to establishing
a data transfer session. An important characteristic of FR is its scalability
to adjust bandwidth and performance on demand up to the access speed in
an asymmetric manner. It typically supports access speeds of 56 kb/s, N
x 64 kb/s, and 1.544/2.048 Mb/s (T1/E1). The International Telecommunications
Union (ITU) and American National Standards Institute (ANSI) have divided
the FR standards into three categories: service description, core aspects,
and signaling (Table 1 and Fig. 2).
| Category | ITU-T standards | ANSI Standards |
|---|---|---|
| Service description | I.233 | T1.606 |
| Core aspects | Q.922 Annex A | T1.618 |
| Signaling | Q.933 | T1.617 |
The origin of FR lies in the standards work done for integrated services
digital network (ISDN). ITU's I.122 provided the initial framework which
provided the standard for ISDN frame mode bearer services for packet services.
The ITU's Q.921 (Link Access Procedure for the D Channel -- LAP-D) provided
the incentive to multiplex virtual circuits (VCs) at the data link layer.
The service description documents describe the overall frame relay service
and specifications. Service attributes such as information transfer attributes,
access attributes, and general attributes are defined. Annex A of I.233
defines several performance parameters to measure frame relay, such as throughput,
transit delay, committed information rate (CIR), and other statistical and
performance parameters. The CIR describes the information transfer rate
to which the network must commit in order to support a user during a normal
data transfer session. In a PVC environment, the CIR is a provisioned parameter
negotiated between the user and the network provider. For an SVC, the SVC
is negotiated during call setup. Associated with CIR is a time interval
(Tc) during which a user can send up to the committed
amount of data (Bc) and the excess amount of data (Be).
The relationship between the parameters is as follows:
If (CIR > 0) and (Bc > 0) and (Be = 0) then Tc = Bc/CIRwhere EIR is the excess information rate.
If (CIR = 0) and (Bc = 0) and (Be > 0) then Tc = Be/access rate of the link
If (CIR > 0) and (Bc > 0) and (Be > 0) then Tc = Bc/CIR and EIR = Be/Tc
The FR frame format resembles the high-level data link control (HDLC)
frame format, which is common to other protocols such as synchronous network
architecture (SNA), X.25, and ISDN. The flag bytes at either end of the
frame delimit the frame. The two-octet frame check sequence (FCS) contains
the CRC-16 code to determine if any bit errors have occurred in transit.
The extended address (EA) bit in a header is used to extend or limit the
size of the header. The data link connection identifier (DLCI) specifies
and distinguishes separate VCs across each access link between the user
and the access node on the FR network. Thus, the DLCIs are used to multiplex
several connections. The DLCI can be 10 bits, 16 bits, or 23 bits long.
Some DLCIs are reserved for specific control or management functions. For
example, DLCI 0 is reserved for in-channel signaling; DLCI 1023 (in two-octet
header format) is reserved for in-channel layer management. The D/C bit
is called DLCI or DL-CORE control indication. It is used to indicate if
the last 6 bits of the DLCI are to be interpreted as DLCI bits or DL-CORE
bits. DL-CORE bits are used to transfer ITU-T I.233-specific information
(e.g., service attributes, performance criteria). Instead of the destination
DLCI, the source DLCI is provided in the frames on a VC. The source DLCI
is mapped to the VC which has end-to-end significance. The C/R (command/response)
bit is application-specific and is used to correlate the end-to-end messages.
A forward explicit congestion notification (FECN) bit is used by the network
to indicate congestion to the destination endpoint of the network and to
slow down the receipt of information. If set, the destination end-point
checks the incoming traffic volume; if the CIR is exceeded it may alert,
via the BECN frame, the transmitting end station. A backward explicit congestion
notification (BECN) bit is used by the network to notify the originator
of the network congestion and to invoke congestion avoidance procedures.
Use of both the FECN and BECN bits is optional, and they can be used by
either the network or the user. The network is not allowed to clear either
of the explicit congestion notification bits. The discard eligibility (DE)
bit can be set to indicate low-priority frames that can be discarded in
the event of network congestion. This bit can be set by either the user
or the network. The network considers any traffic in excess of the user's
subscribed rate as low-priority. The use of this bit is optional. Once set,
the network is not allowed to clear this bit.
A DLCI reserved for in-channel layer management, commonly referred to as
"consolidated link layer management (CLLM)," is used by the FR
node to notify the end systems about various operations, problems, status,
and so forth, independent of the user frames. A comprehensive list of CLLM
messages is defined in the core aspects of the FR standard.
Procedures for user-to-network (access) signaling for establishing and releasing
SVCs or calls are published in ITU-T Q.933 and ANSI T1.617, and include
both B-channel and D-channel frame mode connection procedures. The protocol
also defines mechanisms to notify the users of PVCs of failures and restorations.
With the impetus on interoperability, the Frame Relay Forum has revised
the above specification making it simpler and appropriate for both the UNI
and the network-network interface (NNI). This specification is published
as FRF.2. Although current FR services are predominantly PVC-based, some
of the SVC signaling procedures are used with the NNI.
With many different FR service providers with different network switches,
there is a need for them to interoperate with each other because the users
of an enterprise may be nationally or internationally distributed. Based
on ANSI's T1.617 Annex D, the Frame Relay Forum has defined a set of interconnection
standards known as the NNI. This document is published as FRF.2. Although
this document exists as a working draft in the ANSI T1S1.2 working group,
the standards committees have yet to publish it as an international standard.
The NNI defines the protocols and procedures for different carriers' networks
to interconnect with each other. Some of the principal operations of the
NNI are: notification of adding a PVC, detection of deleting a PVC, notification
of failure of UNI or NNI, notification of PVC segment availability or unavailability,
verification of links between FR nodes, and verification of FR node. These
operations take place by means of exchanging status (S) and status enquiry
(SE) messages that also contain the status information of the PVCs. Despite
implementing the NNI specifications, the two different frame relay networks
may still run into interoperability problems because of incompatible congestion
control and network management protocols and procedures. The FRF specification
also includes procedures for SVC signaling and call setup at the UNI (based
on ITU-T Q.933 and ANSI T1.617).
ATM cell relay is both a switched network technology and a bearer class
service: to avoid ambiguity, the network technology is referred to as "ATM"
and the user service as "cell relay service (CRS)." This dichotomy
is presented up front to help differentiate ATM and CRS from FR. As described
above, FR is a connection-oriented data link layer packet-switching technology
that supports the high-speed transfer of data frames from a source to a
destination point. ATM, on the other hand, is a connection-oriented packet-switching
technology that supports isochronous stream transfers, connectionless data
packet transfers, and connection-oriented data packet transfers. It is this
unique capability of ATM to support multiple higher-layer applications with
the appropriate guarantees of service for each that has led the industry
to define ATM as the multiservice switched backbone technology of choice.
Most of the requirements of an ATM switching system are captured in Bellcore
GR-1110-CORE [1]. Additional ATM protocol requirements are described in
[2p;7].
ATM switching is the result of two key forces: standards and silicon. In
the standards community (ITU, ATM Forum), a single modality for information
transfer, independent of the information content (voice, video, data), was
defined under the name "Asynchronous Transfer Mode." Interestingly,
there is no optimal data link layer protocol suited to both voice and data.
In data communications, performance is best characterized by throughput-delay.
Because most data applications are delay-insensitive, optimum performance
is achieved at the data link layer by maximizing the amount of data transmitted
during each SDU transfer. For packetized voice communications, performance
is completely measured by mean transfer delay and delay variation (jitter).
Here, optimum performance is achieved by minimizing the SDU size such that
the effects of output queuing delay in the ATM switch are negligible. In
the spirit of compromise, the ITU adopted an ATM cell payload size of 48
bytes -- the numerical average between the 32-byte cells advocated by the
voice-oriented European community and the 64-byte cells advocated by the
United States and Japan, who have a more data-centric view of ATM. Note
that the term cell implies that the data link layer packets are fixed
in length, unlike the variable-length frames used in FR.
Advancements in silicon technologies (ASICs) are the other key factors in
the development of ATM. The processing speed of dedicated ASICs opens the
possibility to process information at rates commensurate with synchronous
optical network/synchronous digital hierarchy (SONET/SDH) transmission speeds.
To achieve these speeds requires that very simple decisions are made at
each switching node; for example, to which output port should the received
cell be directed? Anything more complex than this sort of decision process
will result in the need to use software (firmware) rather than hardware
and greatly limit the switching capacity. For a point of reference, small
ATM switches available since 1993 have switching capacities of 2p;10
Gb/s. Compare this to the most advanced packet routers -- which rely on
firmware processing -- that support < 1 Gb/s. Larger central-office-based
ATM switches support 20p;80 Gb/s capacity. Aligned with the objective
of keeping the amount of processing required to a minimum is the standardization
of a 5-byte ATM cell header. Hence, an entire ATM cell spans 53 bytes; the
structure of an ATM cell is depicted in Fig. 4.
The next-hop address of an ATM cell is determined by its VPI/VCI fields
in the header. The virtual path identifier/virtual channel identifier (VPI/VCI)
fields have a hierarchical relationship; the VPI is analogous to a trunk,
which may contain any number (< 65,535) of virtual channel connections
(VCCs), each identified by a unique VCI. Because VPI/VCIs have only local
significance (i.e., they are only unique within a given connection between
ATM cell relay nodes), there is no limitation on the number of VCCs contained
within a network. The ATM cell header also contains a payload type identifier
(PTI) field that enables the switch to determine if any special handling
instructions are required. For example, voice calls that are adapted to
ATM via the ATM adaptation layer type 1 (AAL 1) may need to have their synchronous
residual time stamp (SRTS) updated at each node to ensure that the quality
of service (QoS) guarantee on delay variation is met. The PTI field also
has code points to indicate a congested network state by means of an explicit
forward congestion indication (EFCI) code point. Another important use of
the PTI field is to indicate that the cell is an operations, administration,
and management (OA&M) cell rather than an end-user (data) cell. Code
points exist to trigger the ATM nodes to perform segment-by-segment or end-to-end
loopbacks on VCCs or virtual path connections (VPCs). These ATM layer loopbacks
play an important role in ATM network performance monitoring, fault management,
and connection management. For most traffic types, however, the PTI has
significance only at the end station, where it is used to properly reassemble
the SDUs and, subsequently, higher-layer AAL data units.
Architecturally, CRS is analogous to FR service. CRS end users connect to
the ATM network via an ATM UNI. The ATM Forum has defined a number of native
CRS UNIs for the public ATM network. These include DS-1/E1, DS-3/E3, J2
at 6.3 Mb/s, OC-3c/STM-1, and OC-12c/STM-4. A wide range of UNIs have also
been defined for the private network, including 25 Mb/s unshielded twisted
pair (UTP), 51 Mb/s UTP, and 100 Mb/s multimode fiber. Additionally, because
ATM can support multiple services, several non-cell-bearing UNIs have also
been defined. These include the frame-based UNI (FUNI)1,
and DS-1 and DS-3 circuit emulation interfaces, which
carry data to the ATM switching node over existing T-carrier physical and
data link layer protocols.
The ATM Forum defines two classes of interfaces for connecting ATM nodes
within or between networks. For the public network, the B-ICI defines the
interface for carrying CRS as well as CES, FR, and switched multimegabit
data service (SMDS). For signaling, the B-ICI uses the ITU-defined Broadband
ISDN User Protocols (B-ISUP), which are broadband extensions to the narrowband
ISUP. For private networks, the private NNI (PNNI) is defined by the ATM
Forum. PNNI is geared to Internet-like network environments, and uses modified
Q.2931 signaling and an Open Shortest-Path First Interior Gateway Protocol
(OSPF)-like routing protocol.
Above the UNIs and NNIs sit the ATM service layers. Unlike FR, in which
a single class of data service is completely defined by a small set of bandwidth
parameters, ATM permits a large set of traffic parameters and related QoS
parameters to be defined for each logical connection (Fig. 5).
The traffic parameters include peak cell rate (PCR), cell delay variation
tolerance (CDVT), sustainable cell rate (SCR), maximum burst size or burst
tolerance (MBS), and minimum cell rate (MCR). The QoS parameters include
cumulative delay variance (CDV), cell transfer delay (CTD), and cell loss
ratio (CLR). There are currently two schools of thought in managing these
parameters. The ATM Forum is opting to permit these parameters to be selected
arbitrarily at connection establishment time. The burden is then placed
on the end user to intelligently select the appropriate values. The ATM
Forum is providing recommendations for appropriate values on a service-specific
basis. The ITU is tending to group parameter sets into classes of service
(e.g., ITU Class A is time-sensitive stream traffic such as voice). This
is equivalent to constant bit rate (CBR) service. Here only the PCR, CLR,
CDV, CDVT, and CTD are relevant. Furthermore, Bellcore is recommending what
the values of CTD, CLR, and CDVT should be for CBR service [8]. Hence, the
end user must only select the PCR value in the above example. Other classes
of service defined are variable bit rate (VBR), in which the end user selects
a PCR and SCR, and unspecified bit rate (UBR), in which no selections are
necessary. New service classes currently being defined include available
bit rate (ABR) and real-time VBR.
The mapping of the traffic and QoS parameters into the ATM cell layer is
accomplished through the AAL, which comprises an upper convergence sublayer
(CS) and a lower segmentation and reassembly (SAR) sublayer. The SAR function
uses information in the AAL PDU header for segmentation into the appropriate
cell mappings and the ATM cell's PTI field for reassembly into the appropriate
AAL PDU. The CS performs the service-specific mapping of upper-layer protocols
into ATM. For this purpose, there are three different AALs defined: type
1, which through the use of cell sequence numbers and a time-stamping mechanism
is optimized to support time-sensitive stream traffic (e.g., voice); type
3/4, which is optimized to carry both connectionless (e.g., SMDS) and connection-oriented
packet traffic; and type 5, which is the most streamlined and is designed
specifically for connection-oriented packet traffic (e.g., IP). For some
particular higher-layer services, the CS layer requires a service-specific
convergence sublayer (SSCS) as well as the more general common part convergence
sublayer (CPCS). As will be described in the following sections, FR service
makes use of AAL 5 and, depending on the interworking scenario, uses both
an FR-SSCS and the AAL 5 CPCS to accomplish the appropriate service mapping.
FR/ATM Network Interworking2
The FR/ATM Interworking Function (IWF) is required to support carriage
of the PVC FR service across an ATM network. The FR CPE may be on two different
carriers' FR network and/or the ATM network. Additionally, the ATM network
may be composed of different carriers' networks. The IWF conforms to ITU-T
Recommendations I.555 (FR Bearer Service Interworking) [9] and I.365.1 (FR-SSCS)
[10]. Figure 6 shows three FRS access configurations with six interconnection
possibilities [7, 11].
ITU-T Recommendation I.555 defines two network interworking scenarios
which cover all six interconnection possibilities. Scenario 1 connects two
FR networks/CPE using B-ISDN, and scenario 2 connects an FR network/CPE
with an ATM CPE using B-ISDN. The reference configuration A3p;B3 (ATM
CPE to ATM CPE) is not supported in ITU-T Recommendation I.555; therefore,
no IWF exists in the network for this configuration. The FR-SSCS constitutes
the upper part of the AAL that sits on top of the CPAAL5. Its purpose is
to emulate FR bearer service in the ATM CPE connected to an ATM network,
and to provide interworking between an ATM network and an FR network.
The IWF maps the following features between the FR service functions and
the ATM cell relay functions:
Error Detection -- The IWF uses the standard AAL5 CPCS and SAR function.
At the ATM layer the standard 53-octet cell structure is used. Error detection
for the FR-SSCS PDU is done by the CRC-32 in the AAL5 CPCS PDU.
Connection Multiplexing -- According to ITU-T Recommendation I.555, connection
multiplexing can be accomplished at the FR-SSCS sublayer using DLCIs and
at the ATM layer using VPI/VCI. In the former case, multiple FR connections
(i.e., DLCIs) are multiplexed into a single ATM VCC. At the destination
IWF, the DLCIs are read from the reassembled AAL5 SDUs and the reformatted
FR PDU carried over the FR network. This method of multiplexing is called
"many-to-one," and its implementation is optional. In the other
method, commonly referred to as "one-to-one," each FR connection
(i.e., DLCI) is mapped to a single ATM VCC. Thus, FR connections are multiplexed
at the ATM layer using VPI/VCI. Support for one-to-one mapping is mandatory
in the IWF.
Loss Priority Indication -- The FR Q.922 core frame structure defines a
DE field which corresponds to the CLP bit in the ATM cell structure. The
IWF needs to either map or transparently carry the priority indication in
the FR-SSCS PDU header. The standards define two modes of operation for
loss priority mapping in each direction. Both these modes must be supported
by the IWF and be selectable on a per-ATM connection basis.
FR-to-ATM Direction -- In both modes, the DE bit in the Q.922 Core frame
is copied unchanged into the DE bit in the FR-SSCS PDU header. In addition,
in Mode 1 the DE bit is also copied unchanged into the ATM CLP bit of every
cell generated at the SAR sublayer. However, in Mode 2 the ATM CLP bit of
every cell generated at the SAR sublayer is set to a constant value (either
0 or 1) irrespective of the content of the DE bit in the Q.922 core frame,
and the constant value is selected when the ATM connection is established.
ATM to FR Direction -- In Mode 1, if at least one ATM cell belonging to
a frame has its CLP bit set, or if the DE bit of the FR-SSCS PDU is set,
then the IWF sets the DE bit of the Q.922 core frame. In Mode 2, the CLP
bit in the ATM cells is ignored; instead, the DE bit of the FR-SSCS PDU
is copied unchanged into the Q.922 core frame DE field.
Congestion Indication -- Similar to the FECN field in the FR Q.922 core
frame and the FR-SSCS PDU (which are copied unchanged in both directions),
theATM cell structure provides an EFCI field. From FR to ATM, frame-level
FECN indication is not mapped to cell-level EFCI indication, and is always
set to 0. In the opposite direction (from ATM to FR), however, if the EFCI
bit in the last received ATM cell of a segmented frame is set, or if the
FECN bit of the received FR-SSCS PDU is set, then the IWF sets the FECN
bit of the Q.922 core frame.
At the ATM cell level there is no equivalent to the BECN field in the FR
frame format. Therefore, in the ATM-to-FR direction, there is no ATM-to-frame-level
mapping, except that the BECN field in the FR-SSCS PDU is copied unchanged
into the BECN field of the Q.922 core frame. However, in the FR-to-ATM direction,
the BECN field in the FR-SSCS PDU is set to 1 by the IWF if the BECN bit
is set to 1 in the Q.922 core frame or the EFCI bit of the last received
ATM cell of the last received segmented frame is set to 1 in the ATM-to-FR
direction. Note that the FECN of the received FR-SSCS PDU is not mapped
to the BECN of the FR-SSCS PDU in the opposite direction.
ATM and Frame Relay Forum specifications on network interworking [7, 11]
describe an optional mechanism to exit the congestion state. A timer can
be used to clear the congestion state after a preset time period if no new
congestion indication is received in the ATM-to-FR direction. If the EFCI
of the last cell of the next frame received is not set, the congestion state
is cleared; otherwise, the timer is restarted.
FR PVC Status Management -- The ATM and FR-SSCS layer management operate
independently. The FR PVC status management procedures are transparently
carried over the ATM layer via the FR-SSCS. However, link integrity information
obtained by the F5 OAM cells is conveyed to the Q.933 Annex A entity. These
procedures are described in ITU-T Recommendation Q.933 Annex A. Figure 8
illustrates the protocol stacks for FR PVC status management in the ATM
CPE and the IWF [7, 11]. In FR, DLCI = 0 is used to exchange PVC status
between IWF(s) and/or the ATM CPE emulating FR. In the ATM network, this
DLCI may be carried as a separate ATM VCC. Management of FR PVCs for FR
UNI(s) and NNI(s) in the interworked FR/ATM network remains the same as
in a pure FR network.
Traffic Characterization -- The IWF maps the FR traffic parameters to
equivalent ATM traffic parameters. The traffic can be policed in the frame
mode at the ingress to the FR network or in the IWF, or at both places.
Alternatively, the same can be done in cell mode in the IWF or at the ingress
to the ATM network in the UPC function. In a multicarrier ATM network, a
carrier may implement its own network parameter control (NPC) function at
the B-ICI interface at the traffic ingress point. The ATM Forum UNI 3.1
Specification (Appendix B) provides the guidelines to map FR traffic
parameters to ATM traffic parameters, and recommendations on using generic
cell rate algorithms (GCRAs), also known as "leaky bucket," to
characterize the FR traffic. In addition, the ATM Forum B-ICI Specification,
Version 1.1 (Appendix A) provides detailed empirical relationships between
frames and cells and the GCRA conformance parameters.
Two implementation scenarios are defined: one-to-one (one DLCI to one VCC)
mapping and many-to-one (many DLCIs to one VCC or many DLCIs to many VCCs
inside a VPC) mapping. In both cases the FR traffic can be characterized
by either a 3-GCRA or a 2-GCRA algorithm.
In the 3-GCRA algorithm, the access link rate (AR) is mapped to the PCR
of CLP = 0+1 cell stream, CIR and Bc are mapped to the
SCR and MBS of a CLP = 0 cell stream, and EIR and Be are
mapped to the SCR and MBS of a CLP = 1 cell stream. (Note that those FR
frames that have DE bit set are segmented to CLP = 1 cells). GCRA(T0
+ 1, 
) enforces the contract to the PCR of the CLP
= 0 + 1 cell stream within the CDV tolerance of whereby noncompliant
cells are dropped. GCRA(Ts0, s0
+ ) enforces the SCR of the CLP = 0 cell stream within the cumulative
tolerance of MBS and where the nonconforming cells are combined
with the CLP = 1 cell stream. The third GCRA, GCRA(Ts1,
s1 + ), enforces the SCR
of the CLP = 1 cell stream within the cumulative tolerance of MBS and where the nonconforming cells are dropped. (Note that the PCR and SCRs
should take into account the overhead due to the FR, ATM, and AAL layer
mappings).
In the 2-GCRA algorithm, there is no explicit characterization of Be
or EIR. One GCRA characterizes the CLP = 0 + 1 stream as in the 3-GCRA method,
except that the PCR is derived from either the link access rate or the sum
of CIR and EIR. The other GCRA, GCRA(Tso, *s0
+ ) enforces the SCR of the CLP = 0 cell stream within the cumulative
tolerance of MBS and where the nonconforming cells are combined
with the CLP = 1 cell stream. In other words, the rate of the CLP = 0 cell
stream cannot exceed the rate of the negotiated SCR within the delay tolerance
(derived from CIR and Bc).
The CDV tolerance, , at the UPC in the ATM UNI interface or
in the IWF includes the delay variation introduced by the IWF and the FR
network. At the B-ICI, an additional delay variation term due to the ATM
network segment between the ATM IWF and the B-ICI must be included. PCR,
CDV, SCR, and MBS can be calculated assuming a typical frame size, a mean
frame size, or a worst-case (longest frame) scenario. When the traffic is
policed for conformance at the ATM layer, it is recommended that, to avoid
unjustifiable cell drops or tagging, the worst-case values be used. Note
that when the PCR is derived from the CIR and EIR, it will be necessary
to shape the cell stream in the IWF, because in FR the frames are typically
transmitted at the AR unless the CDV tolerance in the GCRAs is set unusually
large. The ramifications of this will be discussed in the "Open Issues
of FR/ATM Interworking" section of this article.
Traffic Management and Network Performance -- Traffic management of FRS
in the IWF and the ATM network are important to increase the efficiency
and seamless interworking of the two types of networks (including multiple
carriers' ATM networks). Knowledge of FR traffic descriptors (e.g., AR,
CIR, Bc, EIR, Be, and burst duration)
enables the ATM network provider to optimally set the traffic parameters
of the ATM VPCs and engineer the overall network to provide the contracted
QoS. For example, when a large number of FR DLCIs are multiplexed in a single
virtual connection, efficiencies of statistical multiplexing can be exploited
when arriving at the ATM layer traffic descriptors. The integrity of the
FECN, BECN, and DE functions associated with the FRS must be preserved in
the IWF and across the B-ICI. When congestion occurs, the ATM network sets
the EFCI code point of the ATM cells. These should be properly translated
to the FR FECN and BECN code points in the IWFs to make them available to
end users of the FR service.
ANSI Recommendation T1.5FR has defined the network performance parameters
for FR, and these are applicable to the interworking network environment
when the service termination on both ends is frame relay.
Operations and Maintenance -- Operations and management functions at the
frame level (above the FR-SSCS) remain the same as in a traditional FR network.
However, at the AAL, performance measurements are done at both the AAL5
CPCS, and FR-SSCS sublayers. Although not monitored by the network, the
CPCS-UU code point in the CPCS PDU is used to transfer user-to-user information.
The AAL5 reassembly function in the receiver (IWF or the B-CPE) checks for
the validity of the following code points or receive conditions in the AAL5
CPCS PDU:
Service interworking occurs when an FR service user interworks with a
cell relay service user without their equipment performing service-specific
functions of the other user's service. This enables users to mix and match
FR and ATM equipment throughout their regions and build FR and ATM networks
and services independent of each other. The two networks are connected by
IWFs such that the FR equipment and ATM equipment have no knowledge of the
type of equipment at the other end (Fig. 9 [13]). Briefly stated, neither
the ATM CPE nor the IWF implements the FR-SSCF. The IWF does all of the
protocol translation in both directions.
The Frame Relay Forum and ATM Forum have specified the FR/ATM Service
Interworking Implementation Agreement when the B-ISDN service user employs
the B-ISDN Class C nonassured AAL5-based message protocol and an ATM UNI
to the network. This class of service provides some basic functions that
are similar to the FR core functions in I.233.1.
Both the B-CPE and the IWF implement null SSCS, AAL5 CPCS, and the AAL5
SAR function. Within the IWF, the SSCS provides interfaces that map the
primitives to and from the Q.922 core on one side to primitives on the AAL5
CPCS side.
Variable-Length PDU Formatting and Delimiting -- In the FR-to-ATM direction,
the FR frame is mapped into an AAL5 CPCS PDU after removing the FR frame's
flags, inserted zero bits, CRC-16, and the core frame header. Some fields
of the header (e.g., DLCI, DE, FECN, BECN, and C/R) are mapped into the
ATM cell header fields. In the ATM-to-FR direction, frame boundaries, the
number of zero bits, CRC-16, and the flags are identified by the message
(frame) delineation provided by AAL5.
Error Detection -- As in network interworking, error detection for the CPCS-SDU
is done by the CRC-32 in the AAL5 CPCS PDU.
Loss Priority Indication -- The standards define two modes of operation
for loss priority mapping in each direction. Support for the second mode
is optional, and the mode selection is configurable for each virtual connection.
FR-to-ATM Direction -- In Mode 1, the DE bit in the Q.922 core frame is
copied unchanged into the ATM CLP bit of every cell generated at the SAR
sublayer. In Mode 2, the ATM CLP bit of every cell generated at the SAR
sublayer is set to a constant value (either 0 or 1) irrespective of the
value of the DE bit and is configured at the time the service is subscribed.
ATM-to-FR Direction -- In Mode 1, if at least one ATM cell belonging to
a frame has its CLP bit set, the IWF sets the DE bit of the Q.922 core frame.
In Mode 2, the CLP bit in the ATM cells is ignored; instead, the DE bit
of the Q.922 core frame is set to a constant value (either 0 or 1) configured
at the time of service subscription.
Congestion Indication -- Forward Direction: In the FR-to-ATM direction,
two modes of operation are defined, and the IWF supports them both. Which
mode applies is configurable for each virtual connection. In Mode 1, the
FECN field in the core frame is mapped to the ATM EFCI field of every cell
generated by the SAR process of AAL5. In Mode 2 no such mapping occurs,
and the EFCI field is always set to "congestion not experienced."
However, in both modes, if congestion is experienced either in the IWF or
the ATM network, the EFCI field is set to "congestion experienced."
In the opposite direction (from ATM to FR), however, if the EFCI field in
the last received ATM cell of a segmented frame is set, the IWF sets the
FECN field of the Q.922 core frame.
Backward Direction: At the ATM cell level there is no equivalent
to the BECN field in the FR frame format. Therefore, in the ATM-to-FR direction,
the IWF always sets the BECN of the Q.922 core frame to 0; and in the FR-to-ATM
direction, the IWF ignores the BECN field.
FR Command/Response and ATM CPCS-UU Mapping -- In the ATM-to-FR direction,
the IWF maps the least significant bit (LSB) of the CPCS-UU field to the
C/R field of the Q.922 core frame. In the FR-to-ATM direction, the IWF maps
the C/R field of the received Q.922 core frame to the LSB of the CPCS-UU
field.
FR DLCI and ATM VCI/VPI Mapping -- The IWF supports one-to-one mapping between
the FR DLCIs and the ATM VPI/VCIs, and this association is made during the
PVC provisioning process.
FR/ATM PVC Management -- Two different management procedures are involved,
one for the FR side and the other one for the ATM side of the IWF (Fig.
10) [13]. The procedures for the FR side use bidirectional periodic polling
as defined in ITU-T Recommendation Q.933 Annex A, Section A.4. The higher-layer
PVC management procedures remain the same as in network interworking. On
the ATM side, the PVC management procedures are defined in the ATM Forum
UNI 3.1 Specification (Section 3.5) and B-ICI version 1.1 Specifications
(Section 6.2). These procedures make extensive use of F4/F5 OA&M cell
flows and interim local management interface (ILMI) management information
base (MIB) variable values for alarm surveillance, connectivity verification,
and VPI/VCI validity checks. Note that instead of the ILMI MIB, the B-ICI
uses F4/F5 flows. The IWF maps the service-affecting indications from one
side to the other.
FR PVC Management Procedures -- Three main procedures are defined: link
integrity verification (LIV), new/deleted FR PVCs, and active/inactive FR
PVCs.
The LIV procedure ensures the health of the link between the IWF and the
FR network whereby the IWF polls (or responds to polling requests by) the
FR network. For example, when the IWF detects a service-affecting condition,
it maps it to the ATM side and sends AIS F5 OA&M cells on all the ATM
PVCs served by that link, but not more than once per second. When such a
condition is cleared, the IWF stops sending the AIS OA&M cells.
The IWF takes no action when the FR network indicates to it that a PVC is
new or deleted.
An existing FR PVC is determined to be inactive when the FR network explicitly
indicates its status to be inactive in its full report or when the LIV procedures
determine the link between the IWF and the FR network is down. The inactive
FR PVC status results in the IWF sending AIS F5 OA&M cells onto the
corresponding ATM PVCs in the ATM network. Conversely, when the FR PVC is
active and the LIV procedures indicate the link is up, the IWF maps this
condition to the corresponding ATM PVC and stops sending the AIS F5 OA&M
cells.
ATM PVC Management Procedures -- Three main procedures are defined: added/deleted
ATM PVCs, active/inactive ATM PVCs, and remote defect indication (RDI).
When an ATM PVC is configured in the IWF and put in service, a "new"
indication is sent by the IWF to the FR network in a full status report.
Conversely, when an ATM PVC is taken out of service or deconfigured in the
IWF, a "delete" message is sent by the IWF to the FR network in
a full status report.
A fully configured in-service ATM PVC is considered in the active state
when either or both of the following is true:
Figure 11 [13] illustrates a reference diagram showing how address resolution
would work in the FR/ATM service interworking. Typically, the IWF will maintain
a mapping table. On the FR side, it will contain the port number (P1) and
the DLCI number (ee) on that port. On the ATM side, it will contain the
ATM port number (P2) and the ATM VPI/VCI number (aaa/bbb) on that port.
To support hybrid PVC/SVC implementations and/or future FR SVCs, it is recommended
that the table contain the following additional information: FR Q.933 address
in E.164 address if known (E.164a) and ATM Q.2931 address/subaddress tuple
in E.164 and/or network service access point (NSAP) format if known (E.164b).
In a hybrid PVC/SVC environment, it is possible to optionally choose between
existing PVCs and setting up new SVCs to the same ATM end-station. Note
that the IWF need not keep track of the CPE IP addresses, only convert between
the two ARP formats. The mapping table is used to fill in the corresponding
fields when translating between the FR and ATM ARP packet formats, with
the exception that when the IWF receives an ATM ARP with opcode 10 (NAK),
the ARP packet is discarded because the FR ARP does not support that opcode.
For details on the ATM and FR ARP packet formats and translation between
the two, the reader is referred to FR Forum Specification FRF.8.
The standards described above lay the foundation for ensuring interoperability
and interworking between ATM PVC and FR PVC services. Although FR SVC capabilities
have not been widely implemented, SVCs are viewed as a critical service
feature for ATM. Therefore, the overall success of FR/ATM interworking will
depend on a definition of FR/ATM SVC interworking. In addition to defining
SVC interworking, issues such as traffic engineering, traffic management,
address resolution, and network management must be resolved. Furthermore,
there are newly defined capabilities within the ATM network that may threaten
to make FR obsolete prematurely. All of these issues must be considered
prior to large scale deployment of interworked FR and ATM networks. Following
is a brief synopsis of the issues deemed most critical.
Today, FR is being offered by carriers using PVCs only, and several trials
are continuing to test SVC capability using ISDN. Although X.25 employed
SVC technology that was quite mature and stable, FR is still awaiting its
implementation, even though SVC UNI specifications were approved some time
ago [14, 15]. Because FR is defined to be "a packet bearer service"
it is relatively compatible with B-ISDN protocols. On the ATM side, the
ATM Forum has defined SVC UNI specifications (versions 3.1 and 4.0). At
the present time, there are no specifications on how FR and ATM SVC signaling
procedures would interwork in the IWF. However, the existing standards on
FR/ATM interworking on upper-layer user protocol encapsulation and ARP are
sufficient to interwork FR and ATM SVC procedures as defined in FRF.4 and
ATM Forum UNI specifications 3.1 and 4.0, with the caveat that any such
implementation may well be proprietary.
The current FR Forum and ATM Forum interworking recommendations provide
useful guidelines for mapping FR PVCs into ATM PVCs. These guidelines [7]
specify several options for mapping FR performance parameters -- CIR, user
access rate, Bc, and Be -- into VBR
ATM PVC parameters -- PCR, SCR, and MBS. The implication of these mappings
is that ATM cell-level traffic shaping occurs on a per-VCI basis on the
ATM side of the FR/ATM IWF. (Note that without shaping, the FR-sourced traffic
would enter the ATM network at the IWF's ATM interface rate, resulting in
excessively bursty flows that adversely affect the overall ATM network performance.)
Under certain circumstances, however, grouping multiple DLCI streams into
a single ATM VP and traffic shaping on the VP rather than on the constituent
VCIs may improve the utilization of the ATM network dramatically. Consider
the following example: A customer local area network (LAN) consisting of
Ethernet-attached hosts connects to a public FR switch using a DS-1 access
rate FRI. The customer would like to have connectivity to a large number
of sites (say 20) which are served from another FR node that is tied to
the first FR node via an ATM tandem node. The customer would like a best-effort
service in which traffic on any given DLCI could burst at the full access
rate. Hence, each of the 20 DLCIs may be provisioned with CIR = (1536/20)
= 76.8 kb/s, Tc = 1 s, Bc = 76.8 kb,
and a Be = (1536 p; 76.8) = 1459.2 kb. (Note that
because the application -- Ethernet -- is delay-insensitive, the CIR could
be "overbooked" by a factor of 2 to 4 without impacting the end-to-end
performance significantly (i.e., the CIR of each DLCI could be set from
153.6 to 307.2 kb). This practice of overbooking an FRI is common in public
networks for best-effort service.)
However, if the FR-PVC-to-ATM-PVC mapping guidelines are followed at the
IWF, this customer's DLCIs would result in 20 ATM VBR PVCs each with SCR
= 201 cells/s, PCR = 4011 cells/s, and MBS = 212 cells. First of all, because
we know that the traffic is sourced from Ethernet hosts, the MBS does not
need to be provisioned beyond 32 cells (1500 bytes). Second, a total PCR
allocation of 20 x 4011 cells/s = 80,220 cells/s would be provisioned through
the ATM switch from one ingress port to one egress port. This aggregate
PCR is roughly equivalent to 35 Mb/s, and we know that the customer can
never generate more than 1.536 Mb/s at any time!
A better method of DLCI-to-VPI/VCI mapping for the above example may be
to terminate all 20 VBR PVCs into a single ATM permanent VPC at the IWF,
and shape the total aggregate traffic at the VP level. In the above example,
creating a CBR VP with PCR = 4011 cells/s and then shaping the aggregate
load into the ATM switch at this rate will significantly improve the utilization
of the ATM switch. Also, by transporting the FR traffic as VPCs the OA&M
complexity (and cost) within the ATM network is greatly reduced because
individual VCCs need not be administered or managed.
Several carriers are promoting the use of VP aggregation of FR traffic and
VP-level shaping with equipment providers and within the ATM Forum. It is
hoped that an informative set of guidelines similar to those developed for
DLCI-to-VCI mapping will be developed and added to the relevant IWF standards.
As described previously, FR specifies a fairly sophisticated method of
real-time congestion management based on an upstream and downstream flow
control mechanism (FECN and BECN). The ATM Forum has specified a new congestion
flow control method for ATM networks (rate-based ABR service specified in
[16]). Neither the FR nor ATM traffic management specifications address
the issue of interworking the ATM congestion control procedures and protocols
with the existing FR mechanisms. The problem with running the two mechanisms
independently on each network is illustrated by the following example. Consider
an end station attached to an FR network sending data to an end station
attached to an ATM network via an IWF. The FR congestion control mechanism
views the IWF as the destination end station while the ATM mechanism will
view the IWF as the originating end station. In the FR mechanism, congestion
building up in the destination has no effect -- the frames have been successfully
delivered -- and, in the ATM mechanism, congestion at the source will have
no effect -- the cells are not yet congesting the network. The net result
is that congestion in the ATM network will cause traffic to back up and
be lost in the IWF. If traffic flow in the opposite direction is considered,
then the result is that congestion in the FR network will cause traffic
to back up and be lost in the IWF. Without an explicit means of interworking
the two networks' congestion control mechanisms, congestion will tend to
migrate back into the IWF, where it will lead to excessive cell and/or frame
losses. The specification of this congestion control interworking is imperative
for the long-term success of FR/ATM interworking.
The standards-defined IP address resolution for FR/ATM service interworking
was described previously. The implicit assumption in FR ARP and ATM ARP
mappings is that both frame relay and ATM make use of E.164 addresses. The
ATM Forum, however, has defined four ATM end station address (AESA) types:
E.164, and three NSAP-style (20-octet) address types including encapsulated
E.164, IDC, and DCC. There is no requirement that one type must be supported;
any AESA type may be used. The implication of this is that an IP address
may be associated with any type of AESA. Furthermore, an IP end station
sitting behind a router, hub, or other packet-routing element which supports
alternate paths into the public ATM network may have its IP address associated
with multiple AESAs of varying types. Therefore, the FR/ATM ARP mapping
process must support multiple address types and entries for any one IP address.
Currently, the implementation of this is left to the vendor, and interoperability
between vendors does not exist. As ATM and FR technologies play a bigger
role in the Internet, the issue of address resolution must be resolved to
afford interoperability between both different vendors' network equipment
and different network administrative domains.
Typically, data networks are managed through either proprietary network management interfaces or open interfaces (e.g., SNMP, CMISE, CMIP) with object databases (MIBs) specific to the technology. For example, the Internet Engineering Task Force (IETF) RFC 1604 and FRF.8 specify the Simple Network Management Protocol (SNMP) MIB for FR network elements, and the ATM Forum Network Management M4 specification details the ATM network-element-to-network-management-system Common Management Information Protocol (CMIP) interface. These technology-specific (domain) network management systems may be adequate for today's single-service data networks, but will prove ineffective in managing end-to-end service across multiple domains, such as an interworked FR and ATM infrastructure. For example, to provide an end-to-end PVC from FR to ATM would require the management system to "understand" the DLCI-to-VCI traffic mappings; presently there are no MIB objects defined to accomplish this. Other functions typically provided by the NMS as part of VCC provisioning are:
At present, the Frame Relay Forum has specified the maximum access rate
UNI to be a DS-1 rate circuit (E1 in Europe). Originally, ATM UNIs were
specified at DS-3 (E3) rates and above; therefore, bandwidth requirements
alone could dictate which technology would be used where in the network.
However, recently there has been a push in the ATM community -- driven by
a perceived market need -- to develop low-bit-rate ATM access capabilities.
The ATM Forum has specified two public carrier ATM UNIs -- the DS-1 rate
UNI and the FUNI -- which clearly overlap with existing FR service. Although
the availability of these interfaces is not directly an FR/ATM interworking
issue, it must be considered when planning the network. The relative costs
of deploying, operating, and maintaining two network technologies and interworking
must be weighed against those of a single ATM network that provides access
from 64 kb/s through 622 Mb/s. The decision will be determined in large
part by a customer's currently installed base of FR, the relative need for
the various bandwidth access rates, and the projected cost of low-bit-rate
ATM.
The DS-1 rate UNI is a full-blown ATM cell-carrying interface with functionality
equivalent to the higher-bit-rate ATM UNIs. The underlying cost of implementing
the user side of this interface is higher than a DS-1 rate FR UNI due to
the required ATM SAR processes. However, with this added cost comes the
capability to support the broad range of QoS parameters on VCCs not available
with FR technology. Hence, the DS-1 ATM UNI is not a one-for-one replacement
for a DS-1 FR UNI. If a best-effort data service is all that is required,
FR may prove to be the best choice.
The ATM FUNI, unlike the DS-1 ATM UNI, carries ATM AAL PDUs across DS-1
facilities in HDLC frames. If this sounds a lot like FR, it is. The user
side of the FUNI does not have to implement the segmentation and
reassembly of frames (AAL PDUs) to cells; this function is performed at
the network side of the FUNI (i.e., within the ATM switch interface). Therefore,
the user side is simply a software modification to existing FR interfaces
on routers, hubs, and so on. The FUNI provides the end user with DS-1 or
F-T1 rate ATM access that behaves like an FR UNI and may be implemented
at an FR UNI cost, but does not burden the network with IWF complexity or
cost. The impact that the FUNI will have on the FR market is now a matter
of speculation, but it has the potential to be significant.
The interworking of ATM and frame relay will evolve through several architectural
phases; Fig. 12 depicts three of these for a single enterprise network comprising
eight customer sites -- seven remote sites (R) and a hub site (H) -- connected
across the public network via FR (solid lines) or ATM (dashed lines) connections.
The initial phase will see ATM as a core backbone technology that offers a higher-capacity, lower-operating-cost tandem for the FR switches. Today's FR network architectures typically comprise mesh-connected FR switches with DS-1 rate interswitch trunks. As the size of these mesh networks grow and the user access bandwidth requirements increase toward DS-1, the cost of maintaining and operating the mesh interoffice facilities becomes overwhelming. Introducing ATM switches as FR switch tandems improves the situation dramatically by offering greater than DS-1 trunking (DS-3 or OC-3) between FR nodes, and by collapsing the mesh interoffice facilities to a star topology. In this architecture, ATM is simply a bridge between FR nodes or networks, and is invisible to the end user (Fig. 12a). The second phase of the ATM/FR evolution will see ATM and FR as peer networks. In this phase, the ATM nodes will support ATM service directly to the enterprise network as well as provide the backbone for the FR nodes. A single enterprise network may include both ATM and FR networks; the need for users on either technology to communicate with users on the other necessitates peer-level (service) interworking of the two protocols. An early example of this need is a corporate network comprising many DS-1 (and lower-rate) FR attached remote sites connecting to several DS-3 (and higher-rate) ATM attached corporate hub sites (Fig. 12b). In this example the need to attach the hub sites using ATM is strictly due to the aggregate load seen at these sites -- ATM is not being exploited for service features beyond those available in FR. The final phase of the ATM/FR evolution will be driven by two factors:
Standards and Forum (both ATM and Frame Relay) defined frame relay-ATM
network and service interworking has been presented at a level of detail
sufficient to expose the nuts and bolts of the specifications without delving
to the depths required for product implementation -- the reader is referred
to the standards and industry interoperability specifications themselves
for that level of detail. The intent of this article was not only to provide
the framework for FR/ATM interworking but, in so doing, to uncover open
issues and potential challenges in the specifications as they exist today.
The existing interworking standards and industry specifications lay the
foundation for a basic PVC service that spans both FR and ATM networks.
Implementations of this basic capability began showing up last year. It
is expected that interworking implementations will be deployed into public
networks carrying live traffic beginning in 1996. The open issues identified
in this article will limit the scalability and flexibility of FR/ATM interworked
networks. However, experience gained from real deployments over the next
several years will provide the insight necessary to resolve the open issues.
Frame relay is proving to be one of the most successful public data services
worldwide. ATM is poised to claim this title by the end of this century.
These network technologies, and the services that ride on them, are expected
to coexist for decades, and the market is already demanding a convergence
of these technologies and services. The Frame Relay Forum and ATM Forum
have jointly set about to address this market need by working together to
create the existing FR/ATM interworking specifications. Hopefully, this
will serve as a role model to other standards bodies and fora responsible
for other public network services that sooner or later will be required
to interwork with ATM. This will ensure interoperability among the various
networks and services.
The authors acknowledge the various standards and industry forum documents,
especially the network and service interworking specifications from the
Frame Relay Forum and ATM Forum on which certain sections of this article
are based. Readers are encouraged to review the ATM Forum, Frame Relay Forum,
ITU, IETF, Bell Communications Research (Bellcore), and ANSI documents listed
for specific details on the various topics discussed in this article.
[1] Bellcore GR-1110-CORE, "Broadband Switching System (BSS) Generic
Requirements," 1995.
[2] Bellcore GR-1111-CORE, "Broadband Access Signaling Generic Requirements,"
1995.
[3] Bellcore GR-1112-CORE, "Broadband ISDN UNI and NNI Physical Layer
Generic Criteria," 1994.
[4] Bellcore GR-1113-CORE, "ATM Adaptation Layer Protocols," 1994.
[5] ATM Forum, ATM User Network Interface (UNI) Specification Version
3.1, Englewood Cliffs, NJ: Prentice Hall, 1994.
[6] ATM Forum, ATM User Network Interface (UNI) Specification Version
4.0, 1996, to be published.
[7] ATM Forum, "BISDN Inter-Carrier Interface (B-ICI) Specification
Version 1.1," Sec. 10, 1994.
[8] Bellcore SR-3330, "PVC Cell Relay Service Core Features,"
Dec. 1995.
[9] ITU-T Rec. I.555, "Frame Relaying Bearer Service Interworking,"
Com 13 R2-E, July 1994.
[10] ITU-T Rec. I.365.1, "Frame Relaying Service Specific Convergence
Sublayer (FR-SSCS)," 1993.
[11] Frame Relay Forum, "FRF.5: Frame Relay/ATM PVC Network Interworking
Implementation Agreement," Dec. 1994.
[12] Frame Relay Forum, "FRF.3: Multiprotocol Encapsulation Implementation
Agreement," 1993.
[13] Frame Relay Forum, "FRF.8: Frame Relay/ATM PVC Service Interworking
Implementation Agreement," Apr. 1995.
[14] ITU-T Rec. Q.933, "DSS1 Signaling Specifications for Frame Mode
Basic Call Control," 1992.
[15] Frame Relay Forum, "FRF.4: Frame Relay User-to-Network SVC Implementation
Agreement," 1994.
[16] ATM Forum, "Traffic Management Specification Version 4.0,"
Apr. 1996.
[1] ITU-T Rec. I.233, "Frame Mode Bearer Services," 1992.
[2] ITU-T Rec. Q.922, "ISDN Data Link Layer Specification for Frame
Mode Bearer Services," 1992.
[3] ITU-T Rec. I.370, "Congestion Management for the ISDN Frame Relaying
Bearer Service," 1991.
[4] ITU-T Rec. I.610, "B-ISDN Operations and Maintenance Principles
and Maintenance -- Proposed Text on the Loopback Capability," 1993.
[5] ITU-T Rec. Q.2931, "B-ISDN DSS2 UNI Layer 3 Specification for Basic
Call/Connection Control," 1996.
[6] ANSI T1.617, "DSS1 Signaling Specifications for Frame Relay Bearer
Service," 1991.
[7] ANSI T1.606, "Frame Relay Bearer Service -- Architectural Framework
and Service Description," 1990.
[8] ANSI T1.618, "DSS1 -- Core Aspects of Frame Protocol for Use with
Frame Relay Bearer Service," 1991.
[9] ANSI T1 Rec. T1.5FR, "Draft Frame Relay Data Communication Service
-- User Information Transfer Network Performance Parameters," T1A1.3/93-011,
Jan.1993.
[10] Frame Relay Forum, "FRF.2: Network-to-Network Implementation Agreement,"
Aug. 1992.
[11] Frame Relay Forum, "FRF.6: Frame Relay Service Customer Network
Management Implemenation Agreement (MIB)," Mar. 1994.
[12] ATM Forum, "M4 Specifications," 1995.
[13] IETF RFC 826, "Ethernet Address Resolution Protocol.," Nov.
1982.
[14] IETF RFC 1293, "Inverse Address Resolution Protocol.," Jan.
1992.
[15] IETF RFC 1483, "Multiprotocol Encapsulation Over AAL5," 1993.
[16] IETF RFC 1490, "Multiprotocol Interconnect Over Frame Relay,"
1993.
[17] IETF RFC 1577, "Classical IP and ARP Over ATM," 1994..
[18] IETF RFC 1604, "Definitions of Managed Objects for Frame Relay
Service," 1994.
Sudhir S. Dixit [SM '94] received the B.E. degree in electrical engineering from Maulana Azad College of Technology, Bhopal University, India, the M.E. degree in electronics engineering from Birla Institute of Technology and Science, Pilani, India, the Ph.D. degree in electronics and telecommunications engineering from the University of Strathclyde, Glasgow, Scotland, and the M.B.A. degree from Florida Institute of Technology, Melbourne, Florida. Dr. Dixit is a broadband network architect at NYNEX Science and Technology, where he is responsible for the specification, design, and engineering of high-speed residential and business video and data networks, and specializes in such areas as ATM, frame relay, multimedia compression and communication, loop architectures, traffic management and control, and session, signaling, and internet protocols. Prior to joining NYNEX in 1991, he held various engineering and management positions with such companies as Standard Telecommunication Laboratories (now BNR Europe Ltd), Harris Corporation, Motorola, Wang Laboratories, and most recently GTE Laboratories, where he worked on various projects designing and developing products and services that led to work on modeling and analysis of packet-switched (ATM) networks, congestion control, video compression, document imaging, image restoration, image analysis and synthesis, data modems, expert systems for automated navigation, and VLSI design. He has attended several standards and industry fora during his career, and since 1992 he has represented NYNEX at the ATM Forum. His e-mail address is dixit@nynexst.com.1 Not to be confused with frame relay, the FUNI permits ATM AAL 5 SDUs to be transmitted to the ATM switching node over existing copper facilities at DS-1 and sub-DS-1 rates.Stuart D. Elby received a B.S. degree in optics from the Institute of Optics, University of Rochester, New York, in 1982, and M.S., M.Phil. and Ph.D. degrees in Electrical Engineering from Columbia University, New York, in 1989, 1992 and 1994, respectively. His dissertation addressed distributed ATM switching architectures using wavelength-agile lightwave devices. After graduating from the Institute of Optics, he was involved in the development of optical disk storage at Storage Technology Corp. From 1985 to 1986, he was the manager of technology at Lasers for Medicine, Inc. During this period, he was responsible for the design, development, and clinical testing of laser surgery equipment incorporating Nd:YAG laser and fiber optic technologies. From 1986 to 1993, he was a staff research associate at the National Science Foundation's Center for Telecommunications Research at Columbia University. His research activities included photonic devices for optical interconnects, optical multi-access techniques, and high-speed lightwave network architectures. In 1993, Dr. Elby joined NYNEX Science and Technology Inc. in the Broadband Data and Switching Platforms Laboratory. His activities have focused on ATM switching technology and its deployment into research, educational, and health care environments. He currently manages NYNEX's Business Network Architecture ATM activities, ATM-related residential broadband activities, and represents NYNEX as a principal member of the ATM Forum. His research interests include wide-area high-performance distributed computing, networked multimedia educational services, and TCP/IP over ATM. His e-mail address is elby@nynexst.com