1991: Simple and Efficient Adaptation Layer (for ATM)

Standards document submission to ANSI T1S1.5 committee - basis of AAL5 standard.

Abstract:
This document proposes a new ATM adaptation layer suitable for use by connection oriented data
(class C) services, which is believed to be simpler, more efficient, and more appealing to the vast
majority of classes of data transfer than the existing AAL4 definition. In addition, the error detection capability of this AAL is believed to be better for many environments than the current
AAL4’s. A change in the ATM header definition is necessary to support this adaptation layer

Transcript

1. SEAL Proposal August 7, 1991 1 T1S1.5 / 91- 292 ANSI T1S1.5 Standards Project: T1S1.5 AAL Title: Simple and Efficient Adaptation Layer (SEAL) Source: Sun Microsystems, Inc. Tom Lyon Mailstop MTV14-49 2550 Garcia Ave. Mountain View, CA. 94043 Tel: 415-336-2942 Fax: 415-336-3156 Internet: pugs@eng.sun.com Date: Aug. 12-16, 1991 Abstract: This document proposes a new ATM adaptation layer suitable for use by connection oriented data (class C) services, which is believed to be simpler, more efficient, and more appealing to the vast majority of classes of data transfer than the existing AAL4 definition. In addition, the error detec- tion capability of this AAL is believed to be better for many environments than the current AAL4’s. A change in the ATM header definition is necessary to support this adaptation layer.
2. SEAL Proposal August 7, 1991 2 Acknowledgments This document is based on the work of many people, including Steve Deering and Bryan Lyles from Xerox PARC, Allyn Romanow and Tom Lyon from Sun Microsystems, Mike Gaddis and Rick Bubenik from Washington University. We are also grateful for the input from David Tennenhouse of MIT and Ed Geiger of Apple. However, Sun Microsystems takes sole responsibility for its final form. Simple and Efficient Adaptation Layer We propose a Simple and Efficient Adaptation Layer (“SEAL”) designed to handle data traffic such as TCP/IP datagrams. Our proposal specifies a framing structure and an ATM header indication for the end of frame cell. Also, SEAL provides 32 bit CRC error detection which we believe is more appropriate over the hopefully long lifetime of ATM. (See the reliability arguments in Appendix A.) SEAL is suitable only for Class C connection oriented data traffic because it contains no source discrimination fields. We believe the bulk of data traffic over ATM (i.e., the highest speed traffic) will be connection oriented, due to problems with congestion and bandwidth management and inefficiencies of multiplexing connectionless traffic. We believe most of the traffic flowing through these ATM connections will be datagrams from connectionless network-level protocols. It is not our intent to disrupt the on-going deployment of, or future interoperability with, class D services which use AAL4, such as SMDS. SMDS will continue to be important for moderate speed access to the B-ISDN. This work arises from the observation that experts in the computer networking community find the service provided by the “raw” ATM layer to be more appealing than the service provided by the ATM/AAL4 combination. It is felt that AAL4 is unnecessarily complex because it tries to address too many purposes and tries to achieve per-cell integrity. However, cell integrity is of no interest to higher level protocols, which need only datagram integrity. The SEAL proposal is now presented; further background material is in the appendices. Framing A datagram (“user PDU”) is carried in a frame (“convergence sub-layer PDU”) that looks like this: datagram pad CRC
3. SEAL Proposal August 7, 1991 3 The CRC is 4 bytes and enough padding is inserted to make the total frame length be a multiple of 48 bytes. Therefore, there are 0 - 47 bytes of pad and the CRC always occupies the last 4 bytes of a cell. The sender fragments this frame into a sequence of ATM cells, each carrying 48-bytes of the frame (thus there is no AAL overhead in the cell payload field), and each sent on the same virtual channel (i.e., bearing the same VPI/VCI number). The last cell of the frame sequence is identified as such by an end-of-frame (EOF) indication in the ATM cell header (discussed below). The receiver appends incoming cells to a virtual-channel-specific buffer until either an EOF cell is appended or the buffer length is exceeded. Upon either of those events, the buffer is passed to higher-level processing, with an indication of whether or not the EOF cell is present and, if so, whether or not the CRC is correct. Also passed to higher-level processing is the length of the buffer contents (i.e., 48 * number of cells). The CRC used is identical to that used in ANSI FDDI and Fibre Channel. This single error check, along with a higher level length check (see below), covers many possible errors including corrupted, lost, inserted, or mis-ordered cells. It also detects frames joined due to lost end-of-frame cells. It is guaranteed to detect any burst error of up to 32 bits, and is still a very strong check for errors of any length. See Appendix C for further details of its properties and implementations. The higher level is responsible for ignoring buffers whose CRC is reported to be incorrect or absent. Since the higher-level sees all of the incoming data in sequence, it may also opt to perform some sort of higher-level frame recovery, or partial recovery, for applications that can tolerate some bit damage, such as certain audio or video applications. The higher level protocol is responsible for length checking -- no length indication is added to the user PDU by SEAL. This is because such information is already present in most network level protocols, e.g., OSI, TCP/IP, XNS, Appletalk, and would be redundant in SEAL. If the user protocol does not already have a length field or some implied length, then it would need to be added. End-Of-Frame Indication SEAL requires an EOF indication in the ATM header; this indication would be useful for other purposes as well. With negotiation, an EOF indication could be of significance to ATM switches; for example, if a switch has to discard a cell due to congestion, it might as well discard all subsequent cells in the same frame, which the switch could do by discarding from the same virtual channel until the EOF cell arrives. To minimize concatenation of frames at the sender, the EOF cell itself should not be intentionally discarded. Note that while a begin-of-frame indication (BOF) would also be useful for both end-systems and switches, it adds only a small amount of reliability and convenience to the basic framing information. Therefore, we propose only EOF. We propose the EOF indication be carried as a value in the 2 bit Payload Type (PT) field, specifically as the value 10. The value 00 is currently standardized, with (we understand) the value 01 under serious consideration.
4. SEAL Proposal August 7, 1991 4 Appendix A - Arguments for SEAL Simplicity: We see that SEAL is very simple; the chief implementation complexity is in the need to carry a partially computed CRC for each active virtual channel. However, this can be done with only 4 bytes of state (per VC) in the logic which multiplexes or de-multiplexes ATM cells to or from separate packet buffers. This logic will already have per-VC state corresponding to current buffer address, length, etc. Compared to AAL4, SEAL saves some per-frame state because there is no processing and state for MID fields, sequence numbers, and BEtags. The logic to compute SEAL’s CRC-32 requires no exotic or particularly fast hardware; there are widely known techniques for table driven, k-bit parallel CRC computation [1]. Another complexity of SEAL is that it is “yet another” AAL to implement in an ATM interface; it certainly adds complication to support more than one. However, interoperability with the existing AALs may be achieved through mostly software means; we have demonstrated a prototype software-only AAL4 (including 10 bit CRCs), already running at greater than 10 Mbits/sec on current processors. We believe the benefits of an additional AAL optimized for high speed data transfer outweigh the inconvenience of supporting an additional AAL. Efficiency: SEAL is efficient because by eliminating the many fields and procedures of AAL4 much unnecessary cost and processing time is saved. Also, there are important advantages in using 48 bytes of user data per cell rather than 44. The chief advantage of SEAL over connectionless AAL4 is in the elimination of the MID field. The MID field is a hindrance because it requires an additional level of multiplexing and de-multiplexing, which greatly increases the amount of interface logic. In addition, MID allocation and translation functions are rather unclear in B-ISDN, and already greatly complicate IEEE 802.6. Other efficiency gains over AAL4 derive from the fact that there is no need for per-cell sequencing, length checking, and CRC generation/checking. In addition, the BEtag and BAsize functionality of AAL4’s convergence sublayer (CS) is not needed. (In general, we believe that CS functionality should be defined by the higher level protocol entity, and we support the calls in this committee for the separation of the SAR and CS layers of AAL4). By eliminating the per-cell fields, four additional bytes of user data are available in each cell, reducing the total number of cells required per frame by up to 9%. The 48 byte user payload also allows more efficient transfers between the ATM interface and memory. Most computer memories and buses constrain bursts of data to be transferred only in units of powers of two, so 48 bytes may be transferred more quickly than 44 bytes because it can be done in 2 rather than 3 bursts! For example, on Sun’s SBus, an initially
5. SEAL Proposal August 7, 1991 5 aligned transfer of 48 byte cells takes only 2 bursts per cell, but 44 byte cells take an average of 3.5 bursts per cell (due to burst alignment restrictions). Another gain of SEAL versus AAL4 is that SEAL’s 48 byte cells allow 32-bit wide processing of the cell to be simpler and less costly than with AAL4’s scheme in which the user data is at a 16 bit offset into the cell data. This, in conjunction with 32-bit parallel CRC logic, allows the entire data path of a SEAL implementation to be 32 bits wide, which in turn allows higher speed ATM implementations (OC-12, OC-24, etc.) to be built with less expensive and more readily available components. An ATM interface could do 32-bit wide processing for AAL4 if it supported only AAL4 (by shifting the entire cell 16 bits), but if there is a need to process the entire 48 byte cell in the same interface with AAL4 (e.g., null AAL or a switching function) then they cannot both share a 32-bit path. Reliability: We have not yet undertaken a detailed analysis of the SEAL error detection properties. Although the properties of the CRC-32 polynomial have been explored [3], the interactions of this polynomial with ATM cell error modes have not been formally investigated. We are aware of an analysis of per-cell vs. per-frame CRCs in [2], but two serious errors are known in this work and we dispute their conclusion that per-cell CRCs are more reliable. One notable weakness in AAL4 is with the 4 bit sequence number in each cell. This introduces the possibility of un-noticed cell “swaps”, where memory addressing failures in a switch or intermixing of SONET streams in a multiplexer may cause cells to be swapped between AAL4 streams. If using connection oriented transfer with constant MIDs then because the cells are valid, and the length of the CS-PDU remains the same, there is a 1 in 16 chance that the sequence numbers match and the CS-PDU becomes corrupted. Our belief is that a single strong error check, such as CRC-32, is better than a long series of weaker checks (CRC-10, sequence numbers, BEtags, etc.) This is not so much because of the differences in detecting errors in the transmission media, but because of the need to detect failures in ATM processing logic -- reliability analysis tells us that, other things being equal, complex logic fails more often than simple logic. But we believe the detection capability of CRC-32 for transmission errors is more than adequate, as apparently do the FDDI and Fibre Channel committees, who have similar high speed requirements. We believe that ATM will be successful and will, over time, appear on a wide variety of physical layers. Existing physical plant installed for FDDI and Token Ring are but two examples of such alternatives in the local area. When chosen for Ethernet, CRC-32 was though to be “overkill,” but this over-engineering has enabled its migration onto new media, such as unshielded twisted pair (UTP) and radio. We may see ATM cells being carried over infra-red links or packet radio. ATM to the home is a possibility for HDTV distribution; in this case it is likely that some deployments will see fiber to the curb and copper into the house via UTP. Thus it would be a mistake to tie the design of AAL error detection to SONET’s current error statistics.
6. SEAL Proposal August 7, 1991 6 If, in the long term, the error characteristics of CRC-32 prove to be too weak there is a straightforward upgrade to a 64 bit CRC, such as the one DEC has proposed to the ANSI HiPPI committee (X3T9.3/90-105). Using a 64 bit CRC would greatly improve the error detection rate while have minimal impact on the other aspects of this proposal.
7. SEAL Proposal August 7, 1991 7 Appendix B - ATM Header Considerations We present here several mechanisms we considered for how to support the end-of-frame indication in the ATM header. Basically, all SEAL requires from the ATM header is some bit in the header which is carried unchanged through the network. We strongly considered asking for a bit which was of significance only to the AAL layer, but felt that by defining this bit as an end-of-frame (EOF) indication we could enable more sophisticated congestion control capabilities in switches. For reference, the bits under consideration are the last 4 bits of the header before the HEC: Of course, the EOF indication could be obtained by defining the currently reserved bit (RES) to be EOF. However, we understand there is considerable competition for this bit and choose not to enter the debate over it. An appealing choice is to use the complement of the CLP bit as the EOF indication. This is largely compatible with the current definition of CLP, in that it is desirable for EOF cells to be lost less often than non-EOF cells so that joining of frames is less likely to occur. However, this use of CLP would fail unless CLP was guaranteed not to be changed by the network, such as in violation tagging by setting the CLP bit. We also considered proposing that the 2 bit PT field be extended to 3 bits by taking over the RES bit. This would gives 8 different code points in PT, allowing for a number of functions, including perhaps begin-of-frame in addition to end-of-frame. However, this gets us back into the RES bit debate. Our final recommendation, however, is to allocate one of the four values of the PT field to be the EOF indication. Since 00 is allocated already, and 01 has a number of serious proposals for it use, we recommend the value 10. PT RES CLP
8. SEAL Proposal August 7, 1991 8 Appendix C- CRC-32 Details SEAL uses the same CRC computation as IEEE 802.5 (ISO 8802.5), ANSI FDDI, and ANSI Fibre Channel. The same CRC-32 polynomial is also used in Ethernet/IEEE 802.3 and sometimes in HDLC, although these use a different bit order. CRC-32 is also optionally used in IEEE 802.6, although with a different frame format from SEAL. CRC-32 seems to have its origins in Autodin-II; its mathematical properties are described in [3]. The CRC-32 generator polynomial is G(x) = x32 + x26 + x23 + x22 + x16 + x12 + x11 + x10 + x8 + x7 + x5 + x4 + x2 + x + 1 In order to insure the significance of leading zeroes, the initial CRC remainder is preset to all ones before CRC generation or checking. This causes the final remainder of properly received frames to always be equal to C(x) = x31 + x30 + x26 + x25 + x24 + x18 + x15 + x14 + x12 + x11 + x10 + x8 + x6 + x5 + x4 + x3 + x + 1
9. SEAL Proposal August 7, 1991 9 References [1] Sarwate, D.V., “Computation of Cyclic Redundancy Checks Via Table Look-Up”, Communications of the ACM, Vol. 31, No. 8 (Aug. 1988) [2] Dravida, S. and Saksena, V.R., “Error Performance of IEEE 802.6 Metropolitan Area Networks,” Infocom ‘90 Proceedings, Vol. I [3] Hammond, J.L., Brown, J.E., and Liu, S.S., “Development of a Transmission Error Model and an Error Control Model,” Technical Report RADC-TR-75-138, Rome Air Development Center (1975)