lizhen@silver.ucs.indiana.edu (Zhen Li) (01/19/91)
Hello,
In Marshall's Open Book when discussing transport
protocol classes three network classes (Class A, B, and C)
are defined.
Quote:
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.
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.
End quote.
Could anybody give me a real example of class A network and class
B network?
Thanks in advance!
Zhen Li
harald.alvestrand@elab-runit.sintef.no (01/21/91)
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 94ms6b+@ANDREW.CMU.EDU (Marvin Sirbu) (01/21/91)
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
howard@cos.com (Howard C. Berkowitz) (01/22/91)
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.
enag@ifi.uio.no (Erik Naggum) (01/22/91)
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.
BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) (01/23/91)
Aren't X.21 and X.25 vastly different technologies? circuit switched vs packet switched? BillW -------
harald.alvestrand@elab-runit.sintef.no (01/23/91)
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
howard@cos.com (Howard C. Berkowitz) (01/24/91)
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.
hta@isolde.Berkeley.EDU (Harald Tveit Alvestrand) (01/24/91)
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
jchen@flash.bellcore.com (Jason Chen) (01/25/91)
Let me just be brief. Example of Class A Network: X.25 Example of Class B Network: Frame Relaying Jason Chen
howard@cos.com (Howard C. Berkowitz) (01/28/91)
In article <12656004461.12.BILLW@mathom.cisco.com> BILLW@MATHOM.CISCO.COM (William "Chops" Westfield) writes: >Aren't X.21 and X.25 vastly different technologies? circuit switched >vs packet switched? It's really a worthwhile point, which I think is practical rather than pedantic, to remember that X.21 and X.25, respectively, are interfaces to networks rather than network specifications. X.21 specifies a circuit-switching interface to a network, which really could be packet-switching internally. X.25 specifies a packet-switching interface to a network which could be an X.25-like virtual call connection-oriented network, or DECnet, or SNA, or a LAN... To confuse things further, X.25 cites X.21 as is physical interface specification. Really, what is meant by this is the Level 1 (physical) part of X.21, which specifies a 15-pin connector and pin assignments. At the next level of confusion, very few people, certainly in North America, use the X.21 connector specification (the CONNECTOR, but not the logical pin definitions, IS used for T1 and other applications). Instead, people use X.21 _bis_, which is more or less RS-232C. [Actually, X.21 bis points to the physical connector specification in V.24]. RS-232C, V.24, and X.21 bis will interoperate in practice if one is careful, and sensitive to issues such as the screw thread on the locking connector (as opposed to the compatible pins). The EIA standard specifies an English 4-40 screw thread, while the international specs specify a metric screw thread. At COS, we finessed this in our testing and stack specifications by referring to X.21 bis, but asking the implementor to state whether he was using English or metric threads. -- 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.