- Email: [email protected]
Standardizing the user side of the X.25 interface
Standardizing the user side of the X.25 interface ISO work on X.25-compatible standards for data terminal equipment is discussed by Fred Burg
CCITT Recommendation X.25 describes the interface to a public data network operating in the packet mode. However, it describes this interface almost entirely from the network's viewpoint. Investigations within ANSI X3S3 in 1980 showed that X.25 leaves open many issues regarding DTE operation. As a result, IS0/TC97/SC6, at ANSI's request, undertook an activity to define DTE operation for both DTE-to-DCE (network) operation as well as direct DTE-to-DTE operation. In June 1981, IS0/TC97/SC6 approved for balloting among its member countries a draft proposal of an X.25 LAPB-compatible DTE link layer standard. The results of this balloting were favourable; the DP was then forwarded to IS0/TC97 for further processing as a draft international standard. A proposed X.25 DTE packet layer standard has been submitted to ISO for further consideration within TC97/SC6. The purpose of this paper is to briefly trace the history of this activity and to provide insight into the proposed ISO DTE standards. Keywords: computer networks, standards, interfaces, X.25, DTE, DCE During the past six years, the International Telegraph and Telephone Consultative Committee (CCITT) Recommendation X.251'2 has been significant in the data communications arena. Its purpose is to describe the interface to a public data network (PDN) operating in the packet mode. However, the interface is described almost entirely from the point of view of the network (i.e. the data circuit-terminating equipment (DCE)). In general, X.25 places relatively few requirements on the data terminal equipment (DTE) connecting to PDNs. Bell Laboratories, Crawfords Corner Road, Holmdel, NJ 07733, USA
0140-3664/82/050234-05503.00 234
This, in turn, allows DTE designers a large degree of freedom to optimize DTE design within the general X.25 definition. in addition to connecting DTEs to PDNs using X.25, situations may arise where the direct connection (without an intervening PDN) of two DTEs is desirable. For example, a DTE may use a connection through the public switched telephone network to another DTE as a backup for the primary connection through the PDN. On the other hand, two DTEs, over a period of time, may exchange an increasing amount of data, to the point where it is more economical to use dedicated facilities than to use a PDN. In this case, it is desirable to allow the intervening PDN to be replaced with a direct, dedicated connection with a minimum of DTE modification. While the basic concepts and procedures of X.25 can be applied in these cases, X.25 itself is written from the DCE's perspective and, therefore, cannot be applied directly to a DTE-to-DTE connection. While Recommendation X.25 has been adopted as the international CCITT standard describing how a PDN operates in the packet mode, a companion document is needed to specify DTE operation in the packet mode. The formulation of such a document is one of the activities being carried out by the International Organization for Standardization (ISO).
BACKGROUND The omission of DTE procedures from Recommendation X.25 and the need to standardize them, especially for direct DTE-to-DTF connection, was recognized as early as 19783. The need for an X.25-compatible DTE standard resulted from work begun in 1980 by Task Group X3S3.7, Public Data Networks, within the
© 1982 Butterworth & Co. (Publishers) Ltd. computer communications
American National Standards Institute (ANSI). As shown in the minutes of its January and April meetings, members of the group expressed interest in usingX.25based procedures for direct DTE-to-DTE connection. Figure 1 shows the organizational relationship of Task Group X3S3.7 with its parent organizations and with ANSI. By the August 1980 meeting of X3S3.7, interest in X.25 for DTEs had grown. Not only was it evident to members of the group that the ability to connect two DTEs directly was desirable, it was also evident that X.25 did not adequately define, for connection to a PDN, DTE actions in several areas. While deciding to continue efforts in both of these areas, X3S3.7 also prepared a position paper on these subjects for submission as a USA contribution to ISO/TC97/SC6 - Data Communications. This paper 4 (referred to as N2060 below) was approved by Technical Committee X3S3, Data Communications, and submitted to the ISO in September 1980. Figure 2 shows the organizational structure of the ISO groups involved. The aim of document N 2060 was not only to present ANSI's concerns, but to request that the ISO establish a project to address these concerns. In particular, the document requested that ISO/TC97/SC6 should provide a common solution to define DTE operation in both a direct DTE-to-DTE environment and in a DTE-toDCE (PDN) environment. As a result of this request, ISO/TC97/SC6/WG2 - Network Layer Services and P r o t o c o l s - agreed that an international standard should be established for DTE operation. In its response to N2060, s'6 the ISO identified several areas that X.25 had left undefined relative to DTE operation. These included: • a table, equivalent to Annex C of X.25, of DTE actions on receipt of packets in any state as perceived by the DTE, • a table, equivalent to Annex E of X.25, of DTEgenerated diagnostic codes, • logical channel selection in a DTE-to-DTE environment.
ANSI
X3 Information processing systems
X3S3 Data communications
[
1
X3S3.1 X3S3.2 Planning Vocabulary
Figure 1.
L
I
X3S3.5 X3S3.4 System dotal ink performance control
I
X3S3.7 Public data networks
X3S3.6 Transmission speeds
ANSI structure with respect to X.25 DTE work
IS0/TC97/SC6. These ISO papers 8,9 highlighted 31 problems found in applying X.25 for DTE use. For each problem, ISO cited the BX.25 solution, if one existed, and presented comments regarding an acceptable solution. In June 1981, X3S3 submitted a contribution of an X.25 LAPB-compatible DTE link layer standard to the ISO. Later that month, IS0/TC97/SC6 voted to send out a revised version of this contribution for balloting as
ISO
I
//l \\ TC97 Information processing systems
/I
TOWARDS AN INTERNATIONAL STANDARD
vol 5 no 5 october 1982
I
X3S3.3 "mats
As an illustration of DTE operation in both DTE-to-DTE and DTE-to-DCF environments, ISO cited AT&T's BX.257.
Work progressed on an X.25-com patible DTE standard from October 1980 through June 1981. While X3S3.7 and TC/97/SC6/WG2 maintained responsibilityforthe packet laver. ANSI Task Group X3S3.4, Data Link Control Procedures, and ISO/TC97/SC6/WG1 - - Data Link Layer Services and Protocols, assumed responsibility for the link layer of the X.25 DTE standard. During this period, X3S3.4 prepared initial text describing DTE operations at the link layer. At the same time, X3S3.7 probed deeper into DTE operations atthe packet layer. Its output consisted of two contributions which were then adopted, with minor modifications, by
]
I
i x
c o m m u n i c a t ions
I Datalink layer Figure 2.
Network layer
Physical layer
ISO structure with respect to X.25 DTE work
235
an ISO draft proposal. The results of this balloting period, reviewed at the January 1982 TC97/SC6/WG1 meeting, were mostly in favour of the proposal. After some revisions, the resulting document ~° was then sent to TC97 for further processing as a draft international standard. Some additional work was identified, relating to the allocation of link-level addresses, but this was left for further study to avoid disturbing the DP. Concurrence at the TC97 level would elevate the status of the revised proposal to international standard. Because of the numerous issues needing resolution, movement towards an X.25 DTE packet layer standard has not progressed as rapidly as the link layer standard. An editor (H V Bertine) was appointed by ISO/TC97/SC6/WG2 to prepare initial text of an X.25 DTE packet layer proposal based on the agreed solutions 8'9 to the 31 identified problems. This text was submitted to the next meeting of ISO/TC97/SC6/WG2 in February 1982. This draft ~, amended by ANSI contribution N2338 n, was agreed as the basis for further work. Comments from CCI-I-I- and ISO member countries were reviewed at the September 1982 ISO/TC97/SC6 meeting, with the possibility of a ballot as a draft proposal expected soon.
P R O P O S E D X . 2 5 - C O M P A T I B L E DTE STA N DA R D As stated above, the X.25-compatible DTE standard being developed by ISO/TC97/SC6 actually consists of two parts: one for the link layer and one for the packet layer. These two parts have been designed to be compatible with X.25, while allowing for DTE-to-DTE operation.
X . 2 5 LAPB-compatible DTE link layer As the title of the proposed link layer standard I° states, it is designed to be compatible with the LAPB procedures of Recommendation X.25. These procedures are designed for balanced operation between stations with compatible data-transfer and datalink-control capabilities. Such balanced operation is typical of both DTE-to-DCE and DTE-to-DTE environments. However, a close examination of X.25 reveals a number of areas where X.25 is not as definitive for DTEs as it is for DCEs. Two examples of this and their treatment in the proposed X.25 DTE link layer standard are given below.
at its discretion by transmitting an SABM command and starting the TI timer (as long as a physical connection to the other station exists).
Collision of identical unnumbered commands X.25 discusses collision situations (Section 2.4.5.5.1) involving the same unnumbered command (i.e. collision of two SABMs or of two DISCs). While X.25' 'states that a DTE 'shall send the UA response at the' earliest possible opportunity', it does not state when the DTE should enter the indicated phase. Adopting the X.25 DCE strategy (waiting to receive a UA response) for a DTE can lead to delay if, as shown in Figure 3, a UA response is not properly received. Therefore, the proposed X.25 DTE standard allows the DTE to enter the indicated phase either: • after receiving the UA response (identical to DCE operation in X.25), • after sending the UA response (but without causing an error on subsequent receipt of a UA response), • after timing out waiting for the UA response, having send a UA response. It should be noted that the treatment of this situation in the proposed X.25 DTE standard is similar to that in ISO's high-level datalink control (H DLC) 13 international standard, whereas X.25 has adopted only the first strategy for DCEs. In addition to clarifying DTE operation, the proposed X.25 DTE standard also adds a few procedures which lead to more efficient link operation.
Additional DTE timing functions In addition to timing functions T1 and T2 found in X.25, the proposed ISO DTE standard defines timers T3 and T4. T3 is recommended for use, as a basic datalink level check, during intervals when T1 is not running, to determine when to query the remote station (DCE or DTE) for its status. At the expiration of T3, the DTE transmits a supervisory command (RR, RNR, REJ) with its P bit set to 1 to verify the remote station's existence and to determine its status. No response (after N2 attempts) allows the DTE to identify that a fault condition exists. Time
DTE
Remote station
SABM.
Datalink setup In X.25, only a DCE is required to transmit contiguous flags to indicate that it is able to set up the link (Section 2.4.5.1). A DTI: is not required to recognize such a signal in this manner, nor is a DCE required to signal as an indication, by the DTE, that it is able to set up the link. Therefore, this signal cannot be used by a especially in a DTE-to-DTE environment. A DTE, accordingto the proposed standard, initiates link setup
236
- SABM
UA-
-UA
FCS e r r o r -
~
I- Frame
I- Frome discorded"
Figure 3.
SABM collision situation
computer communications
Timer T4 is used by the DTE upon detection of an idle channel state (i.e. a contiguous 1 s state is detected that persists for at least 15 bit times). When such a state is detected, the DTE starts T4. At the expiration of T4, the DTE should consider the link to be inoperable and should enter the disconnected phase. (Note that not only has X.252 left DTE action upon detection of an idle channel state undefined, but it has left the DCE's actions for further study. However, recently proposed revisions TM to X.25 include this timer for a DCE but leave its actions at the timer's expiration for further study).
Receipt of busy-condition signal On receipt of an R N R frame indicating a busy condition at the remote station, the DTE should not transmit additional I-frames. If the subsequent frame sent by the remote station to indicate clearance of the busy condition is not properly received by the DTE, a deadlock situation may occur (see Figure 4). To eliminate this possibility, the proposed ISO DTE standard calls for the DTE to start a time-out function after receipt of an RN R frame. At the expiration of this time out, the DTE sends a supervisory command with its P bit set to 1 to determine the remote station's status.
DTE
Time
No I frames sent
FCS
Remote stotion ~
-
R
N
~
R
-RR
error
Available ]-frames may not be sent
Figure 4.
Deadlock after receiving RNR frame
Time
DTE
Remote station
I - frame N(S)=O I - frame N(S):I I - frame N (S)=2
RR:N(R)=2 a~
RR " command P=I
FCS error
R~
lCheckpoint responsel cycle
IV (R) =2, F--1 .J
Checkpoint recovery The checkpoint-recovery procedure allows early detection of I-frame sequence errors, and is used to determine the I-frame sequence number at which retransmission should begin. This procedure is based on the pairwise exchange of frames with their P bit and F bit set to 1. A checkpoint cycle begins when a frame I or supervisory command) is sent with its P bit set to 1. Receipt of the matching response with its F bit set to 1 allows the DTE to determine if all I-frames sent up to and including the frame with its P bit set have been received, and, if not, to determine at what point I-frame retransmission should begin. (Note that this procedure is defined in HDLC 13 but not in X.25.) Figure 5 illustrates this procedure.
X.25-compatible DTE packet layer Operation at the packet layer of X.25 involves many more asymmetrical procedures than at the link layer. Furthermore, the DCE is responsible for mediating the differences between two DTEs communicating with one another via a PDN. For example, window sizes and packet sizes can be tailored to fit the characteristics of the DTE and the access line, at each of the DTE/DCE interfaces. When operating in a DTE-to-DTE environment, there is no DCE to mediate such differences. Examination of X.25 shows that it does not fully specify DTE operation at the packet layer. Therefore, the proposed standard attempts to define DTE operations fully, not only for DTE-to-DCE operation but for DTE-to-DTE operation as well. Its design also takes the OSI network layer service definition 1s into account.
vol 5 no 5 october 1982
I - frame N(S) :2
Figure 5.
Checkpoint recovery
Some of the examples of DTE packet-layer operation described below are geared to the problems that the ISO came across when attempting to use X.25 for DTEs~'9.
Receipt of packets Since X.25 is a standard for DCEs operating in the packet mode, it does not specify DTE actions on receipt of various packets. For example, X.25 specifies that a DCE, having sent a restart indication packet, should ignore all subsequent packets from the DTE other than a restart request or a restart confirmation packet. A DTE, however, never transfers restart indication packets, and therefore cannot follow the DCE's actions. In most cases, however, a DTE can follow a procedure that is symmetrical to the DCE's. For example, a DTE, having sent a restart request packet, should ignore all subsequent packets other than a restart indication, a restart confirmation and a diagnostic packet. The proposed standard provides a set of state diagrams and tables for use bya DTE similar to those in X.25. In addition to providing these diagrams and tables for restart, call setup and clearing and reset related states as in X.25, the proposed DTE standard also provides diagrams and tables for interrupt and flow-control-related states.
237
-
0
0 00
Usa of diagnostics X.25 allows a DTE to omit the diagnostic code field in restart request, clear request and reset request packets. Should a DTE take advantage of this option, the network is required to add a diagnostic code field (with all bits set to zero) before passing the corresponding indication packet to the remote DTE. However, in a DTE-to-DTE environment, there is no network to provide this service. In this case, there are two choices for proper operation: require a DTE to accept the above-mentioned packets without a diagnostic code field (i.e. a packet with four octets) or require a DTE sendingthe above-mentioned packets to always supply this field, even if it indicates 'no further information'. For the proposed packet layer standard, the latter alternative was chosen, to maintain consistency with operation in a DTE-to-DCE environment. As cited by ISO in the list of 31 problems 8,9, X.25 specifies diagnostic codes that networks may generate but does not specify diagnostic codes for generation by a DTE. Therefore, the draft packet layer defines a set of diagnostic codes for DTE use. These codes include all of the X.25-specified diagnostic codes, and several additional codes needed to define DTE operation fully. (Some of the additional codes added to the proposed DTE standard are equally valid for use by a DCE and have been tentatively adopted by CCITT at its May 1982 meeting14).
0-@ layer and packet-layer DTE operation for both DTE-toDCE and DTE-to-DTE environments. ISO/TC97/SC6 has approved a draft proposal for X.25 LAPB-compatible DTE link-layer operation. This document has been forwarded to ISO/TC97 for further processing as a draft international standard. A draft proposal for an X.25 DTE packet-layer standard was completed at the IS0/TC97/SC6 meeting in September 1982. The proposed standards fill in many of the blanks in X.25 concerning DTE operation. For example, these standards discuss DTE actions on receipt of all packets at the packet layer. Where necessary, they also provide additional mechanisms, in a way that is compatible with X.25, that lead to more efficient operation.
ACKNOWLEDGEMENTS The author gratefully acknowledges H V Bertine and D E Carlson for providing insight into the workings of ANSI and ISO, particularly with respect to this activity.
REFERENCES 1 2 3
Logical channel selection/call-collision resolution The virtual call procedures of X.25 define how logical channels are selected and how call collisions are handled. In a DTE-to-DTE environment, problems would arise if both DTEs were to follow X.25's suggestions for DTEs. Therefore, one of the DTEs must act as a DCE for these procedures. The determination of which DTE acts as a DCE is also discussed in the proposed DTE standard.
4 5 6 7
Recovery after failure While not prohibiting a DTE from initiating recovery after a level 1 and/or level 2 failure (Section 3.5), X.25 requires a DCE to send a restart indication packet when such a failure is recovered. For DTE-to-DTE operation, DTEs must perform this procedure and allow for receipt of a zero cause code in a restart indication packet (an event that never occurs in a DTE-to-DCE environment).
8 9 10 11
CONCLUSIONS Although X.25 is an international recommendation describing the interface between a DTE and a DCE operating in the packet mode, it completely specifies the actions ofa DCE while leaving open the actions of a DTE. in many cases. ISO/TC97/SC6 is developing companion international standards that detail link-
238
12 13
Recommendation X.25 CCITT, Switzerland (1976) Recommendation X.25 CCITT, Switzerland (1980) Lemberg, H L and Eilelbach, D L 'X.25 for DTEs: evolutionary considerations for point-to-network applications' Proc. Nat. Telecommunications Conf. USA (1980) 'Additional considerations for DTEs implementing X.25' TC97/SC6/N2060 ISO, Switzerland (September 1980) 'Specification of an X.25 DTE' TC97/SC6/N2105 ISO, Switzerland (September 1980) 'Direct connection of X.25 DTEs' TC97/SC6/N2106 ISO, Switzerland (September 1980) 'Operations systems network communications protocol specification-- BX.25' Bell System Technical Reference Publ. 54001 Iss. 2 (June 1980) 'X.25 DTE-to-DTE o p e r a t i o n - - p a c k e t - l e v e l considerations' TC97/SC6/N2258 ISO, Switzerland (June 1981) 'General X.25 DTE o p e r a t i o n - - packet-level considerations' TC97/SC6/N2259 ISO, Switzerland (June 1981) 'Standardization of the X.25 LAPB-compatible DTE single link-layer procedure' ISO/DP7776 ISO, Switzerland 'Draft X.25 packet layer specification for data terminal equipment' TC97/SC/6N2310 ISO, Switzerland (December 1981) 'Automatic selection of X.25 packet level DTE/DCE characteristics' TC97/SC6/N2338 ISO, Switzerland (January 1982) 'Data c o m m u n i c a t i o n s - - high-level datalink control -- consolidation of classes of procedures" ISO/DP7809 (October 1981)
computer communications
CCITT Recommendation X.25 describes the interface to a public data network operating in the packet mode. However, it describes this interface almost entirely from the network's viewpoint. Investigations within ANSI X3S3 in 1980 showed that X.25 leaves open many issues regarding DTE operation. As a result, IS0/TC97/SC6, at ANSI's request, undertook an activity to define DTE operation for both DTE-to-DCE (network) operation as well as direct DTE-to-DTE operation. In June 1981, IS0/TC97/SC6 approved for balloting among its member countries a draft proposal of an X.25 LAPB-compatible DTE link layer standard. The results of this balloting were favourable; the DP was then forwarded to IS0/TC97 for further processing as a draft international standard. A proposed X.25 DTE packet layer standard has been submitted to ISO for further consideration within TC97/SC6. The purpose of this paper is to briefly trace the history of this activity and to provide insight into the proposed ISO DTE standards. Keywords: computer networks, standards, interfaces, X.25, DTE, DCE During the past six years, the International Telegraph and Telephone Consultative Committee (CCITT) Recommendation X.251'2 has been significant in the data communications arena. Its purpose is to describe the interface to a public data network (PDN) operating in the packet mode. However, the interface is described almost entirely from the point of view of the network (i.e. the data circuit-terminating equipment (DCE)). In general, X.25 places relatively few requirements on the data terminal equipment (DTE) connecting to PDNs. Bell Laboratories, Crawfords Corner Road, Holmdel, NJ 07733, USA
0140-3664/82/050234-05503.00 234
This, in turn, allows DTE designers a large degree of freedom to optimize DTE design within the general X.25 definition. in addition to connecting DTEs to PDNs using X.25, situations may arise where the direct connection (without an intervening PDN) of two DTEs is desirable. For example, a DTE may use a connection through the public switched telephone network to another DTE as a backup for the primary connection through the PDN. On the other hand, two DTEs, over a period of time, may exchange an increasing amount of data, to the point where it is more economical to use dedicated facilities than to use a PDN. In this case, it is desirable to allow the intervening PDN to be replaced with a direct, dedicated connection with a minimum of DTE modification. While the basic concepts and procedures of X.25 can be applied in these cases, X.25 itself is written from the DCE's perspective and, therefore, cannot be applied directly to a DTE-to-DTE connection. While Recommendation X.25 has been adopted as the international CCITT standard describing how a PDN operates in the packet mode, a companion document is needed to specify DTE operation in the packet mode. The formulation of such a document is one of the activities being carried out by the International Organization for Standardization (ISO).
BACKGROUND The omission of DTE procedures from Recommendation X.25 and the need to standardize them, especially for direct DTE-to-DTF connection, was recognized as early as 19783. The need for an X.25-compatible DTE standard resulted from work begun in 1980 by Task Group X3S3.7, Public Data Networks, within the
© 1982 Butterworth & Co. (Publishers) Ltd. computer communications
American National Standards Institute (ANSI). As shown in the minutes of its January and April meetings, members of the group expressed interest in usingX.25based procedures for direct DTE-to-DTE connection. Figure 1 shows the organizational relationship of Task Group X3S3.7 with its parent organizations and with ANSI. By the August 1980 meeting of X3S3.7, interest in X.25 for DTEs had grown. Not only was it evident to members of the group that the ability to connect two DTEs directly was desirable, it was also evident that X.25 did not adequately define, for connection to a PDN, DTE actions in several areas. While deciding to continue efforts in both of these areas, X3S3.7 also prepared a position paper on these subjects for submission as a USA contribution to ISO/TC97/SC6 - Data Communications. This paper 4 (referred to as N2060 below) was approved by Technical Committee X3S3, Data Communications, and submitted to the ISO in September 1980. Figure 2 shows the organizational structure of the ISO groups involved. The aim of document N 2060 was not only to present ANSI's concerns, but to request that the ISO establish a project to address these concerns. In particular, the document requested that ISO/TC97/SC6 should provide a common solution to define DTE operation in both a direct DTE-to-DTE environment and in a DTE-toDCE (PDN) environment. As a result of this request, ISO/TC97/SC6/WG2 - Network Layer Services and P r o t o c o l s - agreed that an international standard should be established for DTE operation. In its response to N2060, s'6 the ISO identified several areas that X.25 had left undefined relative to DTE operation. These included: • a table, equivalent to Annex C of X.25, of DTE actions on receipt of packets in any state as perceived by the DTE, • a table, equivalent to Annex E of X.25, of DTEgenerated diagnostic codes, • logical channel selection in a DTE-to-DTE environment.
ANSI
X3 Information processing systems
X3S3 Data communications
[
1
X3S3.1 X3S3.2 Planning Vocabulary
Figure 1.
L
I
X3S3.5 X3S3.4 System dotal ink performance control
I
X3S3.7 Public data networks
X3S3.6 Transmission speeds
ANSI structure with respect to X.25 DTE work
IS0/TC97/SC6. These ISO papers 8,9 highlighted 31 problems found in applying X.25 for DTE use. For each problem, ISO cited the BX.25 solution, if one existed, and presented comments regarding an acceptable solution. In June 1981, X3S3 submitted a contribution of an X.25 LAPB-compatible DTE link layer standard to the ISO. Later that month, IS0/TC97/SC6 voted to send out a revised version of this contribution for balloting as
ISO
I
//l \\ TC97 Information processing systems
/I
TOWARDS AN INTERNATIONAL STANDARD
vol 5 no 5 october 1982
I
X3S3.3 "mats
As an illustration of DTE operation in both DTE-to-DTE and DTE-to-DCF environments, ISO cited AT&T's BX.257.
Work progressed on an X.25-com patible DTE standard from October 1980 through June 1981. While X3S3.7 and TC/97/SC6/WG2 maintained responsibilityforthe packet laver. ANSI Task Group X3S3.4, Data Link Control Procedures, and ISO/TC97/SC6/WG1 - - Data Link Layer Services and Protocols, assumed responsibility for the link layer of the X.25 DTE standard. During this period, X3S3.4 prepared initial text describing DTE operations at the link layer. At the same time, X3S3.7 probed deeper into DTE operations atthe packet layer. Its output consisted of two contributions which were then adopted, with minor modifications, by
]
I
i x
c o m m u n i c a t ions
I Datalink layer Figure 2.
Network layer
Physical layer
ISO structure with respect to X.25 DTE work
235
an ISO draft proposal. The results of this balloting period, reviewed at the January 1982 TC97/SC6/WG1 meeting, were mostly in favour of the proposal. After some revisions, the resulting document ~° was then sent to TC97 for further processing as a draft international standard. Some additional work was identified, relating to the allocation of link-level addresses, but this was left for further study to avoid disturbing the DP. Concurrence at the TC97 level would elevate the status of the revised proposal to international standard. Because of the numerous issues needing resolution, movement towards an X.25 DTE packet layer standard has not progressed as rapidly as the link layer standard. An editor (H V Bertine) was appointed by ISO/TC97/SC6/WG2 to prepare initial text of an X.25 DTE packet layer proposal based on the agreed solutions 8'9 to the 31 identified problems. This text was submitted to the next meeting of ISO/TC97/SC6/WG2 in February 1982. This draft ~, amended by ANSI contribution N2338 n, was agreed as the basis for further work. Comments from CCI-I-I- and ISO member countries were reviewed at the September 1982 ISO/TC97/SC6 meeting, with the possibility of a ballot as a draft proposal expected soon.
P R O P O S E D X . 2 5 - C O M P A T I B L E DTE STA N DA R D As stated above, the X.25-compatible DTE standard being developed by ISO/TC97/SC6 actually consists of two parts: one for the link layer and one for the packet layer. These two parts have been designed to be compatible with X.25, while allowing for DTE-to-DTE operation.
X . 2 5 LAPB-compatible DTE link layer As the title of the proposed link layer standard I° states, it is designed to be compatible with the LAPB procedures of Recommendation X.25. These procedures are designed for balanced operation between stations with compatible data-transfer and datalink-control capabilities. Such balanced operation is typical of both DTE-to-DCE and DTE-to-DTE environments. However, a close examination of X.25 reveals a number of areas where X.25 is not as definitive for DTEs as it is for DCEs. Two examples of this and their treatment in the proposed X.25 DTE link layer standard are given below.
at its discretion by transmitting an SABM command and starting the TI timer (as long as a physical connection to the other station exists).
Collision of identical unnumbered commands X.25 discusses collision situations (Section 2.4.5.5.1) involving the same unnumbered command (i.e. collision of two SABMs or of two DISCs). While X.25' 'states that a DTE 'shall send the UA response at the' earliest possible opportunity', it does not state when the DTE should enter the indicated phase. Adopting the X.25 DCE strategy (waiting to receive a UA response) for a DTE can lead to delay if, as shown in Figure 3, a UA response is not properly received. Therefore, the proposed X.25 DTE standard allows the DTE to enter the indicated phase either: • after receiving the UA response (identical to DCE operation in X.25), • after sending the UA response (but without causing an error on subsequent receipt of a UA response), • after timing out waiting for the UA response, having send a UA response. It should be noted that the treatment of this situation in the proposed X.25 DTE standard is similar to that in ISO's high-level datalink control (H DLC) 13 international standard, whereas X.25 has adopted only the first strategy for DCEs. In addition to clarifying DTE operation, the proposed X.25 DTE standard also adds a few procedures which lead to more efficient link operation.
Additional DTE timing functions In addition to timing functions T1 and T2 found in X.25, the proposed ISO DTE standard defines timers T3 and T4. T3 is recommended for use, as a basic datalink level check, during intervals when T1 is not running, to determine when to query the remote station (DCE or DTE) for its status. At the expiration of T3, the DTE transmits a supervisory command (RR, RNR, REJ) with its P bit set to 1 to verify the remote station's existence and to determine its status. No response (after N2 attempts) allows the DTE to identify that a fault condition exists. Time
DTE
Remote station
SABM.
Datalink setup In X.25, only a DCE is required to transmit contiguous flags to indicate that it is able to set up the link (Section 2.4.5.1). A DTI: is not required to recognize such a signal in this manner, nor is a DCE required to signal as an indication, by the DTE, that it is able to set up the link. Therefore, this signal cannot be used by a especially in a DTE-to-DTE environment. A DTE, accordingto the proposed standard, initiates link setup
236
- SABM
UA-
-UA
FCS e r r o r -
~
I- Frame
I- Frome discorded"
Figure 3.
SABM collision situation
computer communications
Timer T4 is used by the DTE upon detection of an idle channel state (i.e. a contiguous 1 s state is detected that persists for at least 15 bit times). When such a state is detected, the DTE starts T4. At the expiration of T4, the DTE should consider the link to be inoperable and should enter the disconnected phase. (Note that not only has X.252 left DTE action upon detection of an idle channel state undefined, but it has left the DCE's actions for further study. However, recently proposed revisions TM to X.25 include this timer for a DCE but leave its actions at the timer's expiration for further study).
Receipt of busy-condition signal On receipt of an R N R frame indicating a busy condition at the remote station, the DTE should not transmit additional I-frames. If the subsequent frame sent by the remote station to indicate clearance of the busy condition is not properly received by the DTE, a deadlock situation may occur (see Figure 4). To eliminate this possibility, the proposed ISO DTE standard calls for the DTE to start a time-out function after receipt of an RN R frame. At the expiration of this time out, the DTE sends a supervisory command with its P bit set to 1 to determine the remote station's status.
DTE
Time
No I frames sent
FCS
Remote stotion ~
-
R
N
~
R
-RR
error
Available ]-frames may not be sent
Figure 4.
Deadlock after receiving RNR frame
Time
DTE
Remote station
I - frame N(S)=O I - frame N(S):I I - frame N (S)=2
RR:N(R)=2 a~
RR " command P=I
FCS error
R~
lCheckpoint responsel cycle
IV (R) =2, F--1 .J
Checkpoint recovery The checkpoint-recovery procedure allows early detection of I-frame sequence errors, and is used to determine the I-frame sequence number at which retransmission should begin. This procedure is based on the pairwise exchange of frames with their P bit and F bit set to 1. A checkpoint cycle begins when a frame I or supervisory command) is sent with its P bit set to 1. Receipt of the matching response with its F bit set to 1 allows the DTE to determine if all I-frames sent up to and including the frame with its P bit set have been received, and, if not, to determine at what point I-frame retransmission should begin. (Note that this procedure is defined in HDLC 13 but not in X.25.) Figure 5 illustrates this procedure.
X.25-compatible DTE packet layer Operation at the packet layer of X.25 involves many more asymmetrical procedures than at the link layer. Furthermore, the DCE is responsible for mediating the differences between two DTEs communicating with one another via a PDN. For example, window sizes and packet sizes can be tailored to fit the characteristics of the DTE and the access line, at each of the DTE/DCE interfaces. When operating in a DTE-to-DTE environment, there is no DCE to mediate such differences. Examination of X.25 shows that it does not fully specify DTE operation at the packet layer. Therefore, the proposed standard attempts to define DTE operations fully, not only for DTE-to-DCE operation but for DTE-to-DTE operation as well. Its design also takes the OSI network layer service definition 1s into account.
vol 5 no 5 october 1982
I - frame N(S) :2
Figure 5.
Checkpoint recovery
Some of the examples of DTE packet-layer operation described below are geared to the problems that the ISO came across when attempting to use X.25 for DTEs~'9.
Receipt of packets Since X.25 is a standard for DCEs operating in the packet mode, it does not specify DTE actions on receipt of various packets. For example, X.25 specifies that a DCE, having sent a restart indication packet, should ignore all subsequent packets from the DTE other than a restart request or a restart confirmation packet. A DTE, however, never transfers restart indication packets, and therefore cannot follow the DCE's actions. In most cases, however, a DTE can follow a procedure that is symmetrical to the DCE's. For example, a DTE, having sent a restart request packet, should ignore all subsequent packets other than a restart indication, a restart confirmation and a diagnostic packet. The proposed standard provides a set of state diagrams and tables for use bya DTE similar to those in X.25. In addition to providing these diagrams and tables for restart, call setup and clearing and reset related states as in X.25, the proposed DTE standard also provides diagrams and tables for interrupt and flow-control-related states.
237
-
0
0 00
Usa of diagnostics X.25 allows a DTE to omit the diagnostic code field in restart request, clear request and reset request packets. Should a DTE take advantage of this option, the network is required to add a diagnostic code field (with all bits set to zero) before passing the corresponding indication packet to the remote DTE. However, in a DTE-to-DTE environment, there is no network to provide this service. In this case, there are two choices for proper operation: require a DTE to accept the above-mentioned packets without a diagnostic code field (i.e. a packet with four octets) or require a DTE sendingthe above-mentioned packets to always supply this field, even if it indicates 'no further information'. For the proposed packet layer standard, the latter alternative was chosen, to maintain consistency with operation in a DTE-to-DCE environment. As cited by ISO in the list of 31 problems 8,9, X.25 specifies diagnostic codes that networks may generate but does not specify diagnostic codes for generation by a DTE. Therefore, the draft packet layer defines a set of diagnostic codes for DTE use. These codes include all of the X.25-specified diagnostic codes, and several additional codes needed to define DTE operation fully. (Some of the additional codes added to the proposed DTE standard are equally valid for use by a DCE and have been tentatively adopted by CCITT at its May 1982 meeting14).
0-@ layer and packet-layer DTE operation for both DTE-toDCE and DTE-to-DTE environments. ISO/TC97/SC6 has approved a draft proposal for X.25 LAPB-compatible DTE link-layer operation. This document has been forwarded to ISO/TC97 for further processing as a draft international standard. A draft proposal for an X.25 DTE packet-layer standard was completed at the IS0/TC97/SC6 meeting in September 1982. The proposed standards fill in many of the blanks in X.25 concerning DTE operation. For example, these standards discuss DTE actions on receipt of all packets at the packet layer. Where necessary, they also provide additional mechanisms, in a way that is compatible with X.25, that lead to more efficient operation.
ACKNOWLEDGEMENTS The author gratefully acknowledges H V Bertine and D E Carlson for providing insight into the workings of ANSI and ISO, particularly with respect to this activity.
REFERENCES 1 2 3
Logical channel selection/call-collision resolution The virtual call procedures of X.25 define how logical channels are selected and how call collisions are handled. In a DTE-to-DTE environment, problems would arise if both DTEs were to follow X.25's suggestions for DTEs. Therefore, one of the DTEs must act as a DCE for these procedures. The determination of which DTE acts as a DCE is also discussed in the proposed DTE standard.
4 5 6 7
Recovery after failure While not prohibiting a DTE from initiating recovery after a level 1 and/or level 2 failure (Section 3.5), X.25 requires a DCE to send a restart indication packet when such a failure is recovered. For DTE-to-DTE operation, DTEs must perform this procedure and allow for receipt of a zero cause code in a restart indication packet (an event that never occurs in a DTE-to-DCE environment).
8 9 10 11
CONCLUSIONS Although X.25 is an international recommendation describing the interface between a DTE and a DCE operating in the packet mode, it completely specifies the actions ofa DCE while leaving open the actions of a DTE. in many cases. ISO/TC97/SC6 is developing companion international standards that detail link-
238
12 13
Recommendation X.25 CCITT, Switzerland (1976) Recommendation X.25 CCITT, Switzerland (1980) Lemberg, H L and Eilelbach, D L 'X.25 for DTEs: evolutionary considerations for point-to-network applications' Proc. Nat. Telecommunications Conf. USA (1980) 'Additional considerations for DTEs implementing X.25' TC97/SC6/N2060 ISO, Switzerland (September 1980) 'Specification of an X.25 DTE' TC97/SC6/N2105 ISO, Switzerland (September 1980) 'Direct connection of X.25 DTEs' TC97/SC6/N2106 ISO, Switzerland (September 1980) 'Operations systems network communications protocol specification-- BX.25' Bell System Technical Reference Publ. 54001 Iss. 2 (June 1980) 'X.25 DTE-to-DTE o p e r a t i o n - - p a c k e t - l e v e l considerations' TC97/SC6/N2258 ISO, Switzerland (June 1981) 'General X.25 DTE o p e r a t i o n - - packet-level considerations' TC97/SC6/N2259 ISO, Switzerland (June 1981) 'Standardization of the X.25 LAPB-compatible DTE single link-layer procedure' ISO/DP7776 ISO, Switzerland 'Draft X.25 packet layer specification for data terminal equipment' TC97/SC/6N2310 ISO, Switzerland (December 1981) 'Automatic selection of X.25 packet level DTE/DCE characteristics' TC97/SC6/N2338 ISO, Switzerland (January 1982) 'Data c o m m u n i c a t i o n s - - high-level datalink control -- consolidation of classes of procedures" ISO/DP7809 (October 1981)
computer communications