🚀 go-pugleaf

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.