USER DATA TRANSFER
The operation of frame relay for user data transfer is best explained by beginning
with the frame format, illustrated in Figure 10.7a. This is the format defined for the
minimum-function LAPF protocol (known as LAPF core protocol). The format is
similar to that of LAPD and LAPB with one obvious omission: There is no control
field.
0
0
9
This has the following implications:
There is only one frame type, used for carrying user data. There are no control
frames.
It is not possible to use inband signaling; a logical connection can only carry
user data.
It is not possible to perform flow control and error control, as there are no
sequence numbers.
The flag and frame check sequence (FCS) fields function as in LAPD and
LAPB. The information field carries higher-layer data. If the user selects to implement
additional data link control functions end-to-end, then a data link frame can
Flag [ Address I Information I FCS I Flag
(a) Frame format
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Uo~eDr LCI I C/R I E A O I
(b) Address field-2 octets (default)
. L I -
DLCI IFECN~BECN~ DE I EA o
Upper DLCI
Lower DLCI or DL-Core control I DIC I EA 1 I
Upper DLCI
DLCI IFECN~BECN I I I I
(c) Address field-3 octets
Lower DLCI ~FECN~BECND~E I EA 1
CIR
DLCI
LEGEND
EA Address field extension bit
CIR Commandlresponse bit
EA 0 CIR
DE
EA 0
BECN
DLCI
EAO
EAO
Lower DLCI or DL-Core control I DIC I EA 1
FECN Forward explicit congestion notification DIC
DE
(d) Address field& octets
Backward explit congestion notification
Data link congestion identifier
DLCI or CORE control indicator
Data link congestion identifier
FIGURE 10.7 LAPF-core formats.
3 14 CHAPTER 10 / FRAME RELAY
be carried in this field. Specifically, a common selection will be to use the full LAPF
protocol (known as LAPF control protocol) in order to perform functions above
the LAPF core functions. Note that the protocol implemented in this fashion is
strictly between the end subscribers and is transparent to ISDN.
The address field has a default length of 2 octets and may be extended to 3 or
4 octets. It carries a data link connection identifier (DLCI) of 10, 17, or 24 bits. The
DLCI serves the same function as the virtual circuit number in X.25: It allows multiple
logical frame relay connections to be multiplexed over a single channel. As in
X.25, the connection identifier has only local significance; each end of the logical
connection assigns its own DLCI from the pool of locally unused numbers: and the
network must map from one to the other. The alternative, using the same DLCI on
both ends, would require some sort of global management of DLCI values.
The length of the address field, and hence of the DLCI, is determined by the
address field extension (EA) bits. The C/R bit is application-specific and is not used
by the standard frame relay protocol. The remaining bits in the address field have
to do with congestion control, and are discussed in Section 10.6.
Figure 10.8 is another view of the protocols involved in frame relay, this time
from the point of view of the individual frame relay connections. There is a common
physical layer and frame relay sublayer. An optional layer-2 data link control
protocol may be included above the frame relay sublayer. This selection is application-
dependent and may differ for different frame relay connections (DLC-i). If
frame relay call control messages are carried in frame relay frames, they are carried
on DLCI 0, which provides a frame relay connection between the user and the
frame handler. DLCI 8191 is dedicated to management procedures.
DLCI 0
DLCI k
Higher
layers
DLC-k
DLCI m DLCI n
Higher . . . layers
DLC-m
I
Frame relay sublayer
Physical layer
Higher
layers
DLCI 8191
procs
!DLC-n Q.922 i Layer 2
FIGURE 10.8 Multiplexing at the frame relay sublayer.
10.5 / NETWORK FUNCTION 315
The frame relaying function performed by ISDN, or any network that supports
frame relaying, consists of the routing of frames with the format of Figure 10.7a,
based on their DLCI values.
Figure 10.9 suggests the operation of a frame handler in a situation in which a
number of users are directly connected to the same frame handler over different
physical channels. The operation could just as well involve relaying a frame through
two or more frame handlers. In this figure, the decision-making logic is shown conceptually
as a separate module: the frame relay control point. This module is
responsible for making routing decisions.
Typically, routing is controlled by entries in a connection table based on DLCI
that map incoming frames from one channel to another. The frame handler switches
a frame from an incoming channel to an outgoing channel, based on the appropriate
entry in the connection table, and translates the DLCI in the frame before transmission.
For example, incoming frames from TE B on logical connection 306 are
retransmitted to TE D on logical connection 342. The figure also shows the multiplexing
function: Multiple logical connections to TE D are multiplexed over the
same physical channel.
Note also that all of the TEs have a logical connection to the frame relay control
point with a value of DLCI = 0. These connections are reserved for in-channel
call control, to be used when 1.451lQ.931 on the D-channel is not used for frame
relay call control.
Frame relay m
Frame handle1
FIGURE 10.9 Frame handler operation.
As part of the frame relay function, the FCS of each incoming frame is
checked. When an error is detected, the frame is simply discarded. It is the responsibility
of the end users to institute error recovery above the frame relay protocol.
The operation of frame relay for user data transfer is best explained by beginning
with the frame format, illustrated in Figure 10.7a. This is the format defined for the
minimum-function LAPF protocol (known as LAPF core protocol). The format is
similar to that of LAPD and LAPB with one obvious omission: There is no control
field.
0
0
9
This has the following implications:
There is only one frame type, used for carrying user data. There are no control
frames.
It is not possible to use inband signaling; a logical connection can only carry
user data.
It is not possible to perform flow control and error control, as there are no
sequence numbers.
The flag and frame check sequence (FCS) fields function as in LAPD and
LAPB. The information field carries higher-layer data. If the user selects to implement
additional data link control functions end-to-end, then a data link frame can
Flag [ Address I Information I FCS I Flag
(a) Frame format
8 7 6 5 4 3 2 1 8 7 6 5 4 3 2 1
Uo~eDr LCI I C/R I E A O I
(b) Address field-2 octets (default)
. L I -
DLCI IFECN~BECN~ DE I EA o
Upper DLCI
Lower DLCI or DL-Core control I DIC I EA 1 I
Upper DLCI
DLCI IFECN~BECN I I I I
(c) Address field-3 octets
Lower DLCI ~FECN~BECND~E I EA 1
CIR
DLCI
LEGEND
EA Address field extension bit
CIR Commandlresponse bit
EA 0 CIR
DE
EA 0
BECN
DLCI
EAO
EAO
Lower DLCI or DL-Core control I DIC I EA 1
FECN Forward explicit congestion notification DIC
DE
(d) Address field& octets
Backward explit congestion notification
Data link congestion identifier
DLCI or CORE control indicator
Data link congestion identifier
FIGURE 10.7 LAPF-core formats.
3 14 CHAPTER 10 / FRAME RELAY
be carried in this field. Specifically, a common selection will be to use the full LAPF
protocol (known as LAPF control protocol) in order to perform functions above
the LAPF core functions. Note that the protocol implemented in this fashion is
strictly between the end subscribers and is transparent to ISDN.
The address field has a default length of 2 octets and may be extended to 3 or
4 octets. It carries a data link connection identifier (DLCI) of 10, 17, or 24 bits. The
DLCI serves the same function as the virtual circuit number in X.25: It allows multiple
logical frame relay connections to be multiplexed over a single channel. As in
X.25, the connection identifier has only local significance; each end of the logical
connection assigns its own DLCI from the pool of locally unused numbers: and the
network must map from one to the other. The alternative, using the same DLCI on
both ends, would require some sort of global management of DLCI values.
The length of the address field, and hence of the DLCI, is determined by the
address field extension (EA) bits. The C/R bit is application-specific and is not used
by the standard frame relay protocol. The remaining bits in the address field have
to do with congestion control, and are discussed in Section 10.6.
Figure 10.8 is another view of the protocols involved in frame relay, this time
from the point of view of the individual frame relay connections. There is a common
physical layer and frame relay sublayer. An optional layer-2 data link control
protocol may be included above the frame relay sublayer. This selection is application-
dependent and may differ for different frame relay connections (DLC-i). If
frame relay call control messages are carried in frame relay frames, they are carried
on DLCI 0, which provides a frame relay connection between the user and the
frame handler. DLCI 8191 is dedicated to management procedures.
DLCI 0
DLCI k
Higher
layers
DLC-k
DLCI m DLCI n
Higher . . . layers
DLC-m
I
Frame relay sublayer
Physical layer
Higher
layers
DLCI 8191
procs
!DLC-n Q.922 i Layer 2
FIGURE 10.8 Multiplexing at the frame relay sublayer.
10.5 / NETWORK FUNCTION 315
The frame relaying function performed by ISDN, or any network that supports
frame relaying, consists of the routing of frames with the format of Figure 10.7a,
based on their DLCI values.
Figure 10.9 suggests the operation of a frame handler in a situation in which a
number of users are directly connected to the same frame handler over different
physical channels. The operation could just as well involve relaying a frame through
two or more frame handlers. In this figure, the decision-making logic is shown conceptually
as a separate module: the frame relay control point. This module is
responsible for making routing decisions.
Typically, routing is controlled by entries in a connection table based on DLCI
that map incoming frames from one channel to another. The frame handler switches
a frame from an incoming channel to an outgoing channel, based on the appropriate
entry in the connection table, and translates the DLCI in the frame before transmission.
For example, incoming frames from TE B on logical connection 306 are
retransmitted to TE D on logical connection 342. The figure also shows the multiplexing
function: Multiple logical connections to TE D are multiplexed over the
same physical channel.
Note also that all of the TEs have a logical connection to the frame relay control
point with a value of DLCI = 0. These connections are reserved for in-channel
call control, to be used when 1.451lQ.931 on the D-channel is not used for frame
relay call control.
Frame relay m
Frame handle1
FIGURE 10.9 Frame handler operation.
As part of the frame relay function, the FCS of each incoming frame is
checked. When an error is detected, the frame is simply discarded. It is the responsibility
of the end users to institute error recovery above the frame relay protocol.
FIG I WILL PROVIDE LATER
ReplyDelete