Call Control Alternatives
The call control protocol for frame relay must deal with a number of alternatives.
First, let us consider two cases for the provision of frame handling services. For
frame relay operation, a user is not connected directly to another user, but rather to
a frame handler in the network; just as for X.25, a user is connected to a packet handler.
There are two cases
* Switched Access. The user is connected to a switched network, such as ISDN,
and the local exchange does not provide the frame-handling capability. In this
case, switched access must be provided from the user's terminal equipment
(TE) to the frame handler elsewhere in the network; this can either be a
demand connection (set up at the time of the call) or a semi-permanent connection
(always available). In either case, the frame relay service is provided
over a B or H channel.
Integrated Access. The user is connected to a pure frame-relaying network or
to a switched network in which the local exchange does provide the framehandling
capability. In this case, the user has direct logical access to the frame
handler.
All of the above considerations have to do with the connection between the
subscriber and the frame handler, which we refer to as the access connection. Once
this connection exists, it is possible to multiplex multiple logical connections,
referred to as frame relay connections, over this access connection. Such logical connections
may be either on-demand or semipermanent.
Frame Relay Connection
The discussion will perhaps be easier to follow if we first consider the management
of frame relay connections. So, let us assume that the subscriber has somehow
established an access connection to a frame handler that is part of a frame relay network.
Analogous to a packet-switching network, the user is now able to exchange
data frames with any other user attached to the network. For this purpose, a frame
relay connection, analogous to a packet-switching virtual circuit, must first be established
between two users.
As with X.25, frame relay supports multiple connections over a single link. In
the case of frame relay, these are called data link connections, and each has a
unique data link connection identifier (DLCI). Data transfer involves the following
stages:
1. Establish a logical connection between two end points, and assign a unique
DLCI to the connection.
2. Exchange information in data frames. Each frame includes a DLCI field to
identify the connection.
3. Release the logical connection.
The establishment and release of a logical connection is accomplished by the
exchange of messages over a logical connection dedicated to call control, with
DLCI = 0. A frame with DLCI = 0 contains a call control message in the information
field. At a minimum, four message types are needed: SETUP, CONNECT,
RELEASE, and RELEASE COMPLETE.
Either side may request the establishment of a logical connection by sending
a SETUP message. The other side, upon receiving the SETUP message, must reply
with a CONNECT message if it accepts the connection; otherwise, it responds with
a RELEASE COMPLETE message. The side sending the SETUP message may
assign the DLCI by choosing an unused value and including this value in the
SETUP message; otherwise, the DLCI value is assigned by the accepting side in the
CONNECT message.
Either side may request to clear a logical connection by sending a RELEASE
message. The other side, upon receipt of this message, must respond with a
RELEASE COMPLETE message.
Table 10.2 shows the complete set of call control messages for frame relay.
These messages are defined in ITU-T standard Q.933. They are a subset of a larger
collection of messages defined in Q.931 used for common-channel signaling
between a user and an ISDN.
Access Connection
Now consider the establishment of an access connection. If the connection is semipermanent,
then no call control protocol is required. If the connection is to be set
up on demand, then the user requests such a connection by means of a commonchannel
signaling protocol between the user and the network. In the case of ISDN,
and also many other digital networks, the protocol used is Q.931.
Figure 10.6 provides an example of the types of exchanges involved for
switched access to a frame handler, in this case over an ISDN. First, the calling user
must establish a circuit-switched connection to a frame handler that is one of the
nodes of the frame relay network; this is done with the usual SETUP, CONNECT,
and CONNECT ACK messages, exchanged at the local user-network interface
and at the interface between the network and a frame handler. The procedures
and parameters for this exchange are carried out on the D channel, and are defined
in Q.931. In the figure, it is assumed that the access connection is created for
a B channel.
Once the access connection is established, an exchange takes place directly
between the end user and the frame handling node for each frame mode connection
that is set up. Again, the SETUP, CONNECT, and CONNECT ACK messages areused. In this case, the procedures and parameters for this exchange are defined in
Q.933, and the exchange is carried out on the same B channel that will be used for
the frame mode connection.
The call control protocol for frame relay must deal with a number of alternatives.
First, let us consider two cases for the provision of frame handling services. For
frame relay operation, a user is not connected directly to another user, but rather to
a frame handler in the network; just as for X.25, a user is connected to a packet handler.
There are two cases
* Switched Access. The user is connected to a switched network, such as ISDN,
and the local exchange does not provide the frame-handling capability. In this
case, switched access must be provided from the user's terminal equipment
(TE) to the frame handler elsewhere in the network; this can either be a
demand connection (set up at the time of the call) or a semi-permanent connection
(always available). In either case, the frame relay service is provided
over a B or H channel.
Integrated Access. The user is connected to a pure frame-relaying network or
to a switched network in which the local exchange does provide the framehandling
capability. In this case, the user has direct logical access to the frame
handler.
All of the above considerations have to do with the connection between the
subscriber and the frame handler, which we refer to as the access connection. Once
this connection exists, it is possible to multiplex multiple logical connections,
referred to as frame relay connections, over this access connection. Such logical connections
may be either on-demand or semipermanent.
Frame Relay Connection
The discussion will perhaps be easier to follow if we first consider the management
of frame relay connections. So, let us assume that the subscriber has somehow
established an access connection to a frame handler that is part of a frame relay network.
Analogous to a packet-switching network, the user is now able to exchange
data frames with any other user attached to the network. For this purpose, a frame
relay connection, analogous to a packet-switching virtual circuit, must first be established
between two users.
As with X.25, frame relay supports multiple connections over a single link. In
the case of frame relay, these are called data link connections, and each has a
unique data link connection identifier (DLCI). Data transfer involves the following
stages:
1. Establish a logical connection between two end points, and assign a unique
DLCI to the connection.
2. Exchange information in data frames. Each frame includes a DLCI field to
identify the connection.
3. Release the logical connection.
The establishment and release of a logical connection is accomplished by the
exchange of messages over a logical connection dedicated to call control, with
DLCI = 0. A frame with DLCI = 0 contains a call control message in the information
field. At a minimum, four message types are needed: SETUP, CONNECT,
RELEASE, and RELEASE COMPLETE.
Either side may request the establishment of a logical connection by sending
a SETUP message. The other side, upon receiving the SETUP message, must reply
with a CONNECT message if it accepts the connection; otherwise, it responds with
a RELEASE COMPLETE message. The side sending the SETUP message may
assign the DLCI by choosing an unused value and including this value in the
SETUP message; otherwise, the DLCI value is assigned by the accepting side in the
CONNECT message.
Either side may request to clear a logical connection by sending a RELEASE
message. The other side, upon receipt of this message, must respond with a
RELEASE COMPLETE message.
Table 10.2 shows the complete set of call control messages for frame relay.
These messages are defined in ITU-T standard Q.933. They are a subset of a larger
collection of messages defined in Q.931 used for common-channel signaling
between a user and an ISDN.
Access Connection
Now consider the establishment of an access connection. If the connection is semipermanent,
then no call control protocol is required. If the connection is to be set
up on demand, then the user requests such a connection by means of a commonchannel
signaling protocol between the user and the network. In the case of ISDN,
and also many other digital networks, the protocol used is Q.931.
Figure 10.6 provides an example of the types of exchanges involved for
switched access to a frame handler, in this case over an ISDN. First, the calling user
must establish a circuit-switched connection to a frame handler that is one of the
nodes of the frame relay network; this is done with the usual SETUP, CONNECT,
and CONNECT ACK messages, exchanged at the local user-network interface
and at the interface between the network and a frame handler. The procedures
and parameters for this exchange are carried out on the D channel, and are defined
in Q.931. In the figure, it is assumed that the access connection is created for
a B channel.
Once the access connection is established, an exchange takes place directly
between the end user and the frame handling node for each frame mode connection
that is set up. Again, the SETUP, CONNECT, and CONNECT ACK messages areused. In this case, the procedures and parameters for this exchange are defined in
Q.933, and the exchange is carried out on the same B channel that will be used for
the frame mode connection.
No comments:
Post a Comment