Path: utzoo!attcan!uunet!cos!howard
From: howard@cos.com (Howard C. Berkowitz)
Newsgroups: comp.dcom.lans
Subject: Re: What services does X.25 provide?
Summary: D bit prohibited by implementation agreements
Keywords: x.25, services, login, e-mail, file transfer, IPC
Message-ID: <22877@cos.com>
Date: 30 Sep 89 12:46:16 GMT
References: <796@maxim.erbe.se> <3279@wasatch.utah.edu> <522@wet.UUCP> <1989Sep18.020822.16329@cit5.cit.oz>
Organization: Corporation for Open Systems, McLean, VA
Lines: 75

In article <1989Sep18.020822.16329@cit5.cit.oz>, jwb@cit5.cit.oz (Jim Breen) writes:
> In article <1167@virtech.UUCP>, dennis@virtech.UUCP (Dennis P. Bednar) writes:
> * This is correct. X.25 is specified as a protocol between a DTE
> * (packet switching host) and a DCE (IMP or interface message
> * processor a.k.a. packet switching node). While X.25 level
> * 2 (the lowest protocol layer) has reliability built into it
> * (checksums, acks, retransmissions, sequenced packets), the
> * reliablility is only between the host and the IMP. There is no
> * guarantee of end-to-end reliablity between two hosts:
> * 
> * 	(local)	   (local)	(remote)   (remote)
> * 	DTE	   DCE		DCE	   DTE
> * 	host <---> IMP   <---> IMP  <----> host
> * 
> * In other words, when the local DTE on the left sends
> * a level 3 DATA packet and receives a level 3 RR acknowledgement
> * packet from the local IMP (on the left side of the above
> * diagram), it only means that the local IMP has acked the
> * packet, but not necessarily that the remove DTE in the
> * right side of the figure has even received it.  ..........[etc]
> 
> Full 1984/1988 X.25 allows for the "D" bit in the Call Request
> and Data packets to request "Delivery Confirmation". When this
> option is available and used, RR packets advise successful
> receipt by the *remote* DTE, not the local DCE.
> -- 

While the base standards of CCITT (i.e., Recommendation X.25)
and ISO (ISO 8208) do define the D bit, this is largely for 
historical reasons.  Very few (none to my knowledge) public data
network implementations support end-to-end significance of the
Delivery Conformation bit.  Specifically for the OSI context,
the NIST (formerly NBS) OSI Implementors' Workshop agreements
prohibit negotiation to obtain end-to-end significance, as does
the European SPAG Guide to the Use of Standards.

In the OSI context, there are two main ways by which X.25 is used.
The first, probably more familiar, is to provide the Connection-Oriented
Network Service (CONS), the X.25 realization of which is defined
in ISO 8878.  CONS will be expected to have OSI Transport above it.
The second is one way to provide the Connectionless Network Service
(CLNS); it uses X.25 to provide a technology-specific interface
to a packet-switching network, but the service interface shown to Transport
is connectionless, based on the OSI Internet Protocol (ISO 8473).

OSI Transport is explicitly defined as an end-to-end protocol;
it has different classes with increasingly powerful error detection
and control.  Class 4, the most powerful, is comparable to TCP in
functionality.  Lower classes (only classes 0, 2, and 4 are supported
by European and North American OSI functional standards, as well
as in draft International Standardized Profiles).
The different classes provide different quality of service over
different service-providing networks.  Briefly, the network designer
decides on what undetected connection and undetected bit error level
is economically justified, and uses a transport class which will provided
that over the real service-providing network.  Class 0 is intended for
relatively reliable (e.g., typical X.25) "Class A" networks, where
the service network does bit error connection and signals disconnections
to the service user.  Class 2 is intended for "Class B" networks 
which reliably notify the user of disconnects, but do not do error
correction.  Class B networks are typified by X.21 circuit switching,
and probably ISDN "B-nailed" circuit switched access.  Class C
networks are considered unreliable (e.g., LANs, and require
Class 4 transport.

A connectionless transport service (COTS) comparable to UDP is in
a draft standard.       

So, while the D-bit is provided in the base standards, no one really
uses it.  
-- 
howard@cos.com OR  {uunet,  decuac, sun!sundc, hadron, hqda-ai}!cos!howard
(703) 883-2812 [W] (703) 998-5017 [H]
DISCLAIMER:  Opinions expressed are not necessarily those of the Corporation
for Open Systems, its members, or any standards body.