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.