Special Thanks:
Again, we find ourselves owing a debt of gratitude to Jörn Bardewyck of High-Soft-Tech Ltd. for sharing his broad ATM knowledge.
cFos/ATM does support CAPI 2.0 broadband extensions. To avoid confusion, it should be noted that throughout the following paragraphs, the terms "broadband" and "ATM" will be used interchangeably! We suspect that in the not-too-distant future the CAPI broadband specification will also be used for other networks (such as cable-modem connections), which will then likely be mapped to ATM by the respective broadband CAPI driver. What this would in effect mean is that no changes should be required for existing CAPI applications.
At present, cFos uses HST broadband specification V.1.0 (rev.01) B04. But the "-j$" parameter allows you to switch to support of Proposal V.1.1 (rev.01) B01 (30.11.1999), which is currently under development by the CAPI Association. All changes until standardization will be incorporated as soon as possible. Once the new CAPI broadband extension is finally approved, cFos will fully (and exclusively) support it, while HST broadband specification support and the "-j$" switch will both be discontinued!
cFos uses additional *S registers (marked with a '#' in the MODEM.TXT file) as well as some of the &S string registers for ATM.
Remember that cFos/ATM also supports ISDN and DSL / PPPoE allowing use of three different network technologies with one single driver!
cFos activates support for extended CAPI messages when either AAL 1, 2, 3/4 or 5 is selected as current B1 protocol. By default, cFos uses dial-up connections (SVCs). To enable PVCs, you need to have registers *S8 and *S9 set according to the specifications supplied by your provider.
For dial-up connections (SVCs), you may specify the forward (from calling to called party) and the backward cell rate (from called to calling party) with registers *S0 and *S1. You can always set the backward cell rate to 0, in which case cFos will use the forward cell-rate value for the backward cell rate as well.
If you use AAL1 as B1 protocol, you also have to set registers *S2 and *S3. In this case, *S0 determines the CBR (if the selected bit rate does not match any of the values specified in Q.2931, cFos will choose the closest matching rate).
By default, cFos employs Bearer Class C, VBR non-realtime with constant bit rate as transfer mode. This can be changed though with registers *S4 and *S5. In addition, ATM alllows setting a maximum end-to-end delay by using *S6. Note that AAL5 is the intended protocol for data transfer and should therefore be used as standard B1 protocol (AT S100=10); but you can also choose AAL1 or AAL2 for voice/telephony or video data transfer and AAL 3/4 for other applications.
The narrowband BC, LLC and HLC values provided by Q.2931 are generated and signaled by cFos in the same way as for ISDN, thus allowing ISDN <-> ATM interworking.
cFos transmits all relevant broadband parameters as Q.2931 info elements. Note that according to Q.2931, you can only signal X.75 as CAPI B2 protocol and T.70NL and ISO 8208 as CAPI B3 protocol. Therefore, cFos will code all other CAPI B2 protocols as "layer 2 user protocol." The "user octet" will be set to 0xc0 + B2 protocol, where 0xc0 refers to CAPI protocols. B3 protocols are coded likewise. In addition, you can use ISO/IEC TR 9577 for signaling layer 3. This is done by configuring NLPID with string register &S9. Unless this register is empty, cFos will signal TR9577 as layer 3. Remember though that register &S9 should contain the 8 bytes of protocol information. Thus, in contrast to ISDN, it is for instance possible to signal PPP over AAL5. In case PPP conversion is enabled, cFos will signal this according to TR 9577 with octets 0xcf,0x0,0x0,0x0,0x0,0xcf,0x0,0x0. If register S75.1=1 is set, cFos will signal LAN LLC instead, which is used for LLC-encapsulated PPP frames. For more information on signaling PPP over AAL5, please see RFC 2364.
Should a remote party need additional signaling information in B-HLI, you can provide for this by entering the appropriate values in string register &S8.
Because window size is limited to 7, use of X.75 is not recommended for ATM! In addition, Q.2110 offers selective retransmission of missing frames (like those lost due to cell loss). For this very reason, we do regard Q.2110 as standard B2 protocol for broadband networks just as X.75 is the ISDN standard. Thus, cFos will generate no B-LLI if Q.2110 is the current B2 protocol and the B3 protocol is transparent (much like no LLC is generated for X.75 under ISDN). By the same token, cFos will select Q.2110/transparent as B2/B3 protocol if there is no B-LLI on incoming calls.
Note: As for ISDN, CAPI/ATM applications that do not transmit any protocol signaling information run the risk of causing incompatibilities between caller and called party. This is especially true for so-called SVCs i.e., dial-up connections where one party calls several other parties using different parameters. Fortunately, the authors of Q.2931 were well aware of this and created signaling options for almost every parameter there is. You would be extremely well-advised to make full use of these!
cFos will analyze info elements on incoming calls. If "AAL parameters" is found, cFos will select the B1 protocol accordingly. If an LLI info element was found, B2 and B3 protocols are selected as described in the "Signaling" section above. "LLI, layer 2 == LAN LLC and/or layer 3 == TR 9577" will activate PPP conversion and set B2/B3 protocols to transparent.
We suggest you use small frames as is already customary for 100 Mbit/s Ethernet, where they seem to work to everybody's satisfaction.
The following problems are specifically associated with unnecessarily large frame size:
Large frames cause unneccessary latency (e.g., in routers and/or CAPI applications) and use up inordinate amounts of memory. Also keep in mind that the equipment used by each party in ATM can be quite different. Let's assume, for instance, that a 64kbits/s narrowband user is connecting to a 155Mbits/s server. Normally, the server could send a 64kb frame in just a few milliseconds, but it would take some 8 seconds using the 64kbit/s connection translating into a full 8 seconds of (perfectly avoidable) latency.
Frames larger than 1500 bytes can cause problems with PPP.
Frames larger than 2k cannot be handled by ISDN CAPIs during ISDN / ATM interworking.
Instances of cell loss often accompany use of large frames, forcing parties to retransmit large amounts of data.
For high-speed data transfer, frames of 1-2 kbytes size are absolutely sufficient if used together with a suitably large window size. Therefore, cFos won't support frames larger than 2k.
RFC 1483, IP over AAL5
RFC 2225, Classical IP and ARP over ATM
RFC 1755, ATM Signaling Support for IP over ATM
RFC 2331, ... UNI Signaling 4.0 Update
RFC 2364, PPP over AAL5
At present, ATM parties are assigned only one single phone number (as opposed to the option of receiving multiple subscriber numbers that is open to most ISDN users). Naturally, this also means it is impossible to select specific applications by their MSN if these applications all run on a single ATM controller. But by using subaddresses, cFos can simulate different MSNs here as well (cf. /cfos-professional/subadd.htm).
By default, window size is 4 for Windows & Win NT/2000. Yet, this may lead to unneccessary delays during broadband data transfer with X.75 or Q.2110. A simple solution is to load cFos with a larger window size (using parameter "-wX" and assigning 'X' a value of 7 or 14, depending on the kind of bandwidth you have at your disposal). However, plain AAL 5 connections without B2 or B3 protocols (like PPP over AAL 5) should remain unaffected, since window size is in this case determined by upper-layer protocols, not by cFos or CAPI.