🚀 go-pugleaf

My X.25 network in Norway was a class B network when I started working
in WAN networking 5 years ago - it failed more often than I liked.
Now I would consider it a class A network.

My local UNINETT network had a problem last week - due to a wrong
configuration, it failed about 3 % of my calls. I consider that Class B
behaviour.

Unfortunately, I cannot switch transport protocols dynamically; I am stuck
in class 0, and do recovery in the upper layers.
That is a typical example of having a map that fits the terrain, but the
roads do not follow the terrain, and you must follow the roads......
Nobody seems to CARE about class B behaviour.

                   Harald Tveit Alvestrand
Harald.Alvestrand@elab-runit.sintef.no
C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald
+47 7 59 70 94

An example of a Class A network would be a reliable X.25 network.
(Some people may think that is an oxymoron, but what
constitutes "reliable" depends on your
requirements.)


An example of a Class B network would be an X.25 network that has a lot
of Resets which require re-establishing the network connection.  Early 
experience with some European X.25 networks (Transpac in particular,
I believe) led the standards developers to develop classses within the
transport layer protocol which were more resistant to these resets
(Class 1 and 3) as opposed to simply having a transport class which
presumed the network connection was reliable and stayed up (Classes 0
and 2).

Marvin Sirbu
CMU

In article <1991Jan18.220611.14357@bronze.ucs.indiana.edu> lizhen@silver.ucs.indiana.edu (Zhen Li) writes:
>     Class A:  networks that detect, as an error, any loss 
>	       of data.  These networks never duplicate, 
>	       re-order, or corrupt data. Furthermore, a 
>	       class A  network has a relatively small 
>	       probaility of actually losing data. Such a
>	       network provides the CONS.


      A Class A network, in practice, is provided by the typical Public
Data Network which uses X.25 interfaces.

      Note that not all X.25-interfaced networks provide the full CONS.
CONS is fully supported only by the 1984 version of CCITT X.25, which,
for DTE-DCE applications, is identical to ISO 8208 for the
packet level.

      In COS stack specifications for X.25-based services, we currently
expect 1984 version X.25.  Transitional 1980 versions are under 
consideration.

      If the network provides X.25-1980 interfaces, than the Subnetwork
Dependent Convergence Protocol must run on top of X.25 to provide the
CONS.  See ISO 8878 and appropriate implementors' agreements.

      An X.25 interface to a LAN could potentially provide a Class A
service.  I don't remember the ISO standard number for this, but think
it's 8880.

>     Class B:  like class A networks, class B networks detect, 
>	       as an error, any loss of data. However, such losses 
>	       are more common that the transport service would 
>	       prefer. Class B networks aren't necessarily unreliable,
>               it's just that they are less reliable than class A
>	       networks.  The distinction between the two classes is 
>	       decided locally. Class B provide CONS.
>


     A typical Class B service is found on European X.21-interfaced
Circuit Switched Data Networks (CSDN), on which the provision of
error correction (e.g., using LAP-B) is a user responsibility.

     A "raw" B-channel on ISDN would be a Class B service.  I suspect
a D channel would be considered a Class A service when passing packet
data, although I don't have a formal definition of this.

    
-- 
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.

I would like to interject that European X.21 networks are an order of
magnitude more reliable than European X.25 networks, and have actually
progressed beyond X.25 in relative reliability as the X.25 networks
were upgraded.  X.21 folks in Germany and Scandinavia are waging a
"war" against the X.25 folks, inside the Telcos, to provide 99.99%
reliability when the X.25 want to provide 99.9% reliability.  X.25 in
Norway (Oslo, in particular) has a 97.95% reliability, and is a royal
pain in the butt to use for week-long connections.  (Yes, we have
those, and have _never_ experienced a clear on the X.21 network!)
I don't have exact numbers for the X.21 network as seen in Oslo, but
our experience indicates between 99.95% and 99.97%, counting an
occational call cleared immediately after connection by the service
provider.

--
[Erik Naggum]	Snail: Naggum Software / BOX 1570 VIKA / 0118 OSLO / NORWAY
		Mail: <erik@naggum.uu.no>, <enag@ifi.uio.no>
My opinions.	Wail: +47-2-836-863	Another int'l standards dude.

This message has been on the net now for at least 1 day, and I have had no
counters..... 

In article <42617@cos.com>, howard@cos.com (Howard C. Berkowitz) writes:

|> 
|> >     Class B:  like class A networks, class B networks detect, 
|> >	       as an error, any loss of data. However, such losses 
|> >	       are more common that the transport service would 
|> >	       prefer. Class B networks aren't necessarily unreliable,
|> >               it's just that they are less reliable than class A
|> >	       networks.  The distinction between the two classes is 
|> >	       decided locally. Class B provide CONS.
|> >
|> 
|> 
|>      A typical Class B service is found on European X.21-interfaced
|> Circuit Switched Data Networks (CSDN), on which the provision of
|> error correction (e.g., using LAP-B) is a user responsibility.
|> 
|>      A "raw" B-channel on ISDN would be a Class B service.  I suspect
|> a D channel would be considered a Class A service when passing packet
|> data, although I don't have a formal definition of this.
|>
 
No, I do not think so.
The definition you quoted, first above, is right.
A Class B network will detect any loss OR CORRUPTION of data. Otherwise
transport classes 1 and 3 would not work, since they contain no
checksums at all.

This means that an ISDN B-channel or X.21 channel is NOT Class B.
You might consider the same channel with HDLC added as Class B.

(BTW: I have encountered at least one bug where the X.25 network failed to
meet the Class B criteria...)


                   Harald Tveit Alvestrand
Harald.Alvestrand@elab-runit.sintef.no
C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald
+47 7 59 70 94

In article <1991Jan22.214654.5942@ugle.unit.no> harald.alvestrand@elab-runit.sintef.no writes:
>In article <42617@cos.com>, howard@cos.com (Howard C. Berkowitz) writes:
>|> >     Class B:  like class A networks, class B networks detect, 
>|> >	       as an error, any loss of data. However, such losses 
>|> >	       are more common that the transport service would 
>|> >	       prefer. Class B networks aren't necessarily unreliable,
>|> >               it's just that they are less reliable than class A
>|> >	       networks.  The distinction between the two classes is 
>|> >	       decided locally. Class B provide CONS.
>|> error correction (e.g., using LAP-B) is a user responsibility.
>|>      A "raw" B-channel on ISDN would be a Class B service.  I suspect
>|> a D channel would be considered a Class A service when passing packet
>|> data, although I don't have a formal definition of this.
>No, I do not think so.
>The definition you quoted, first above, is right.
>A Class B network will detect any loss OR CORRUPTION of data. Otherwise
>transport classes 1 and 3 would not work, since they contain no
>checksums at all.

   No.  See below.

>This means that an ISDN B-channel or X.21 channel is NOT Class B.

>You might consider the same channel with HDLC added as Class B.

  A B-channel with HDLC is a Class A service, because HDLC will
do data error correction while the D channel will provide notification
of disconnections.


>(BTW: I have encountered at least one bug where the X.25 network failed to
>meet the Class B criteria...)


I'm afraid I disagree.  It is not a basic OSI assumption that the
network service will be error-free.

There are two kinds of errors which go into the definition of a 
Class A, B, or C network.  The first kind is indeed data corruption,
while the second is undetected disconnection.   Class A protects against
both types, Class B protects against disconnections only, and 
Class C against neither.

Why would you want a service with potential errors?  There are at
least two reasons for this.  First, some service above Transport
may provide error correction.  For example, MHS(1984) contains the
Reliable Transfer Service, which allows it to correct some errors
not caught by Transport Class 0 or X.25 (e.g., duplication or loss
of packets caused by an X.25 Reset).

Second, the error level may be acceptable, when viewed against
the cost of correction.  Consider something like a weather sensor
network, where it simply is not critical if an occasional hourly
wind speed measurement, from one sensor, is lost.  Alternatively,
consider a facsimile application where the human recipient's
pattern recognition ability will sort out the error.

In these applications, the network designer may live with the
computed prediction of undetected errors using a low-level transport
over a Class C or B network.  

COS specifications for protocols include both the COS Platform, which
lists all the protocols one might use, and Stack Specifications
(based on International Standard Profiles) which constrain testable
and "reliable" COMBINATIONS of protocols.  The second edition of
the Platform allows, for examples, "unreliable" combinations such
as FTAM over Transport Class 0.  Such a combination could be appropriate
for specialized applications.

COS Stack Specifications, which are used to describe products we
certify after testing, are more conservative.  The FTAM stack
specifications, for example, expects Class 4 Transport over LANs,
where the Platform would allow lower classes.
-- 
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.

This turned out LONG, I summarize:
- The acceptable rate of undetected network errors is application dependent.
- Class A and B networks should have LOW rates of corrupted packets
  that are delivered to the user (instead of causing a reset).
- Class B networks (for a given application) disconnect/reset more often
  than Class A networks. That is the ONLY difference.
- The RTS service does not guard against data corruption.

Now for the longwinded answer:

In article <42726@cos.com>, howard@cos.com (Howard C. Berkowitz) writes:


|> I'm afraid I disagree.  It is not a basic OSI assumption that the
|> network service will be error-free.
|> 
|> There are two kinds of errors which go into the definition of a 
|> Class A, B, or C network.  The first kind is indeed data corruption,
|> while the second is undetected disconnection.   Class A protects against
|> both types, Class B protects against disconnections only, and 
|> Class C against neither.
|> 
When in doubt, quote.
ISO standard 8073-1986(E), page 7, section 5.4.3, "Choice of network
connection"

a) Type A: Network connection with acceptable residual error rate (for
example not signalled by disconnect or reset) and acceptable rate of
signalled errors.

b) Type B: Network connections with acceptable residual error rate (for
example not signalled by disconnect or reset) but unacceptable rate of
signalled errors

c) Type C: Network connections with unacceptable residual error rate."

Same page, section 5.4.1, "General":
"NOTES:
..
2  Classes 0 to 3 do not specify mechanisms to detect unsignalled
network transmission failures"

The terms "error" and "transmission failure" are not defined in the
standard as far as I can see, but should include packet loss, packet
modification and packet duplication.

You are right that there is no assumption of the channels being
error-free here, or that they never disconnect or reset.
The difference between Type A and Type B is that Type B signals reset or
disconnect "too often".
The user should know the residual error rate of the connection, and
accept the *fact* that the ISO protocols of the layers above do not
provide any guard against the errors.
You are right that a channel with no error correction still may provide
Type A service if the demands of the service user are low enough.

However, I doubt that any *practical* user service (except broadcasting)
could live with undetected data corruption above the 10^-7 level at all.
(s/7/your favourite integer/)
I would start distrusting my mail service if I got "strange" spelling
errors every 1000 letters, and ASN.1 decoding errors every 1000 letters
for a heavily loaded mail node would be a total disaster.

|> may provide error correction.  For example, MHS(1984) contains the
|> Reliable Transfer Service, which allows it to correct some errors
|> not caught by Transport Class 0 or X.25 (e.g., duplication or loss
|> of packets caused by an X.25 Reset).

Yes, the Reliable Transfer Service is able to recover somewhat from loss
of packets, by using syncpoints, so that you do not have to start over
from the beginning. Class 0 takes care of possible duplication by simply
dropping the connection on reset. Class 1 to 3 guard against duplication.
However, the RTS does *nothing* to guard against packet corruption, so
that if this is considered a "network failure", then the "acceptable residual
error rate" for the network is VERY low indeed, leading to the
conclusion that error correction inside the network layer is absolutely
required for MHS(1984) use of Transport class 0.



                   Harald Tveit Alvestrand
Harald.Alvestrand@elab-runit.sintef.no
C=no;PRMD=uninett;O=sintef;OU=elab-runit;S=alvestrand;G=harald
+47 7 59 70 94

Let me just be brief.

Example of Class A Network: X.25

Example of Class B Network: Frame Relaying

Jason Chen