Communication access system with distributed processing

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

COMMUNICATION ACCESS SYSTEM WITH DISTRIBUTED PROCESSING

NOTICE RE: COPYRIGHT

A portion of the disclosure of this patent document contains matter subject to copyright protection. The copyright owner has no objection to the facsimile reproduction by anyone of the patent disclosure, as it appears in the Patent and 5 Trademark Office files and records, but otherwise retains all copyright rights whatsoever.

BACKGROUND OF THE INVENTION

This invention relates generally to the fields of telecommunications and the processes by which telephone calls are switched into and out of a computer system 10 from a telephone line or other communications link. The invention is particularly suitable for use in an environment in which a high volume of calls are routed into or out of the computer system at the same time.

The methods disclosed herein can be performed by an element of communications equipment we have called a network access server. The 15 network access server is a device that receives incoming calls and routes them to a computer system via a network, or that receives calls from the network and routes them onto a communications link. In our distributed processing invention, a dramatic increase in the efficiency of the call routing process is achieved, thereby maximizing call throughput and minimizing the overall call connect time.

This result is achieved by distributing computationally intensive protocol processing (such as Point-to-Point Protocol or PPP processing) among multiple computing platforms such as the modems of the network access server. Heretofore, the protocol processing has been performed in a single computing platform at the network interface.

Various types of communication devices are placed at the interface between a modem and a computer network, such as routers, terminal servers, and modules

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 2 sometimes referred to as gateway cards”. These devices implement software programs that control the inflow and outflow of calls between the modems and the network. One layer of the software hierarchy that is run in these devices is known in the art as an application layer. This document makes frequent reference to the terms application, application layer and application software layer. As used herein, these terms mean a communication control and management software layer above the protocol stacks in a communication device, the device typically placed at the gateway (or interface) between a modem and a computer network.

State of the art modems, such as the V.34 Quad Modem developed by U.S. Robotics Corp., of Skokie, Illinois, the assignee of the present invention, have a feature whereby two protocols are implemented in the modem. The first protocol is a modified version of an asynchronous High-level Data Link Control (HDLC) framing of Point-to-Point Protocol (PPP). The protocol could be synchronous HDLC framing of PPP in other implementations. The modem performs the flag sequence, data transparency, and Frame Check Sequence (FCS) on each PPP frame. The second protocol performed in the modem is Serial Line Internet Protocol (SLIP).

In the prior art, when an application software routine at the network access server gateway creates a PPP (or SLIP) frame, it checks each byte, looking for a byte that is a control character. If the application finds a control character, a PPP Escape character (or SLIP Escape character) is stuffed into the data stream. Then, the original control character is translated to a transparent character and stuffed into the data stream. This usually requires two buffers, because extra characters are added. For PPP frames, while the application is looking at each byte of the frame, it must also calculate the FCS. When the application receives a PPP (or SLIP) frame, it must do the reverse of the above process. In some network access servers, such as the U.S. Robotics NETServer, up to 60 modems

CA 02222151 1997-11-25

WO 96/41434 PCT/ÜS96/0966Ï

- 3 may be active at any one time. This means that the gateway computing platform in the network access server would be doing this process for each of the 60 modems if the prior art technique was used. This results in a extremely heavy processing load on one computing platform, and introduces latencies and delays 5 in the call routing process. These effects combine to significantly reduce call throughput, particularly where a large volume of calls are simultaneously received or transmitted through the network access server.

One prior art approach to increasing call throughput has been to incorporate communications controller hardware, such as the Cirrus Logic CL-CD 2430/CD 10 2431 device, into the protocol processing circuitry. The present invention eliminates the need for such expensive hardware devices, by enabling the performance of the protocol processing within existing computing platforms, such as the processors in the modems associated with the network access server.

CA 02222151 2001-05-09

76909-69

SUMMARY OF THE INVENTION

The present invention provides a method for routing incoming or outgoing calls into or out of a computer system. One broad aspect provides a method of routing incoming calls onto a network to achieve an efficient call throughput, the method performed in a remote network access system comprising a plurality of modems and a gateway module forming an interface between said remote network access system and said network, comprising the steps of: receiving said incoming calls in said system and routing said calls to said plurality of modems; distributing the processing of a first portion of protocols for said incoming calls among multiple computing platforms in said modems; performing the processing of a second portion of said protocols for said incoming calls in said gateway module; and subsequently routing the incoming calls through said system to a computer system over said network.

Another broad aspect provides a method for routing outgoing calls from a computer system to a communications link via a network to achieve an efficient call throughput, the method performed in a remote network access system comprising a plurality of modems and a gateway module forming an interface between said remote network access system and said network, comprising the steps of: routing said outgoing calls from said network to said modems in said remote access system;

distributing a first portion of the processing of protocols for said outgoing calls among multiple computing platforms in said modems; performing a second portion of the processing of said protocols in said gateway module; and subsequently routing the outgoing calls from said system to said communications link, such as a T1 telephone line, for example.

CA 02222151 2001-05-09

76909-69

4a

In one preferred embodiment of the invention, the method is performed in a network access server having a plurality of modems for receiving a plurality of incoming calls or modulating a plurality of calls onto a communications link.

The computing platforms comprise the data processing structures in each modem.

Another broad aspect provides a network access server, comprising, in combination, an interface operatively connecting said network access server to a communications link;

a plurality of modems; a bus for passing data from said interface to said modems; and a gateway receiving said data from said modems and routing said data from said network access server onto a network; wherein said plurality of modems comprise a computing platform that processes high level communications protocols for incoming or outgoing calls, wherein a first portion of the processing of said high level protocols is performed in a computing platform in said gateway and a second portion of the processing of said high level protocols is performed by said computing platform in said

0 modems .

Another broad aspect provides a communications apparatus for routing calls between a communication line and a computer system, comprising in combination: a plurality of modems connected to said communication line; an interface operatively connecting said plurality of modems to said computer system over a network; wherein each of said plurality of modems comprises a processor that processes said calls between said communications line and said computer system, and wherein said processor implements in software the processing of a first portion of a high level communications protocol for said calls and wherein said interface comprises a computing

CA 02222151 2001-05-09

76909-69

4b platform that performs processing of a second portion of said high level communications protocol.

Another broad aspect provides the communications apparatus wherein each of said plurality of modems comprises a processor implementing a software routine that processes protocols for said incoming calls, thereby distributing the processing of protocols for said calls among a plurality of computing platforms and achieving efficient call throughput.

Another broad aspect provides the communications apparatus wherein said protocols comprise a Point-to-Point Protocol or a Serial Line Interface Protocol.

Another broad aspect provides the communications apparatus wherein said modems comprise an ISDN terminal adapter.

Another broad aspect provides the communications apparatus wherein said interface transmits said incoming calls to said modems via an internal bus of a computer.

Another broad aspect provides the method wherein said modems comprise a Data Synchronizer Unit.

Another broad aspect provides the method wherein said modems comprise a Circuit Switching Unit.

Another broad aspect provides the method wherein said step of routing is performed through a software program in an operating system for a personal computer.

Another broad aspect provides in a communications apparatus having a plurality of modems for transmitting and receiving a call between a communication line and a network, each of said modems comprising a computing platform; a method

CA 02222151 2001-05-09

76909-69

4C for distributing the processing of protocols among a plurality of computing platforms, comprising the steps of: determining the protocol of said call between said communications line and said network; assigning said call to one of said modems;

configuring said computing platform for one of said modems according to said protocol; and performing a first portion of the processing of said protocol in a said computing platform and performing a second portion of the processing of said protocol in a computing platform in a gateway module between said apparatus and said network; transmitting said incoming call or said outgoing call in accordance with said protocol; whereby efficient call throughput between a communications line and a network is achieved.

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 5 BRIEF DESCRIPTION OF THE DRAWINGS

Presently preferred embodiments of the invention are depicted in the drawings, wherein like reference numerals refer to like elements in the various views, and wherein:

FIG. 1A is a block diagram illustrating one form in which the invention may be implemented;

FIG. IB is a block diagram illustrating the implementation of the routing function of FIG. 1A in the operating system software of a host computer;

FIG. 2 is an illustration of the overall communications system in which an alternative form of the invention is implemented, illustrating the relationship between various call originators, a telephone network, a network access server, and a host computer system linked to the network access server via a network;

FIG. 3 is a schematic block diagram of the network access server of FIG. 1;

FIG. 4 is a schematic block diagram showing the connection of the application module and the modem modules of FIG. 3;

FIG. 5 is a detailed block diagram of a preferred form of a quad modem module of the type shown in FIG. 3, the distributed processing according to the present invention being performed by the modem module processing units;

FIG. 6 is a flow chart of the distributed processing procedure;

FIG. 7 is a detailed flow chart of the PPP routine of FIG. 6;

FIG. 8 is a graph of the upload throughput using prior art computation in a single platform at the PPP protocol network gateway;

FIG. 9 is a graph of the upload throughput when the distributed processing 25 technique according to the teaching of the present invention is used;

FIG. 10 is a graph of the download throughput when the PPP processing is performed according to the prior art technique of a single platform at the network gateway; and

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 6 FIG. 11 is a graph of the download throughput when the distributed processing technique according to the teachings of the present invention is used.

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 7 DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

I. General Discussion

Referring to FIG. 1A, the invention may be implemented in a communications system in which a call originates from a computer, such as a PC

20, which sends data via a Data Communications Equipment (DCE) (such as modem M) onto telephone network 50 or other communications link to a receiving DCE 10, such as a modem. The call originating data terminal 20 has communication software that uses a communications protocol, such as PPP or 10 SLIP. The DCE 10 demodulates the call from the personal computer 20 and passes it over a transmission means 11, for example an RS 232 cable or packet bus, to a router or terminal server 12. The router or terminal server 12 passes the call onto a network or host computer system, for example a personal computer (not shown in FIG. 1A). Up to n DCE’s 10 may be provided, depending on the 15 amount of expected incoming traffic. Or, for some applications, only a single

DCE or modem 10 may be required. The DCE 10 and router 12 functions may be implemented in physically distinct hardware, or combined into a single piece of equipment such as in the case of the network access server discussed in conjunction with FIG. 2.

In a preferred form of the present invention, the byte to byte transparency translation processing required by the PPP (or SLIP) protocol is distributed to the

DCE 10 processor, rather than being performed in a computing platform in the router or terminal server 12 as in the prior art. This frees the application processor (such as the computing platform at router or terminal server 12) from 25 this time consuming task. The modem 10 processor already deals with the data on a byte by byte process as it passes data to or from the modem’s data pump.

The additional task of data transparency and FCS calculating is not as burdensome

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 8 as it is for a multi-session application, and hence the modem processor is a preferred computing platform in which to implement the invention.

In our preferred form of the invention, the application software processor at the network interface communicates with the modems 10 via a packet bus, but the communication could be by other equivalent means, such as an RS 232 cable. Two types of messages are passed between them, configure requests and responses, and data. Other message types are currently not applicable to this implementation. All messages have a status field and a length field. There is exactly one PPP or SLIP frame transmitted or received per each packet bus data message. The length field holds the exact number of untranslated data bytes. This is how the modem knows where to insert the flag sequence on outgoing frames.

The basic design of the PPP/SLIP modem 10 is for the gateway application software at the router/terminal server 12 to issue a special command to the modem 10 that puts the modem into PPP mode, SLIP mode, or neither. Other configuration commands that can be issued include: local Async-ControlCharacter-Map, remote Async-Control-Character-Map, local Delete character translation (i.e. ASCII 7F hex), remote Delete character translation, maximum frame size, frame timeout, inter-character timeout, and FCS type (eg. CCITT 16 bit CRC). The modem 10 informs the application software when it is successfully configured.

When the modem 10 receives a data message from the application layer for transmission to the remote PC 20, the modem 10 knows how much data is in the message from the length field. The modem then creates a PPP or SLIP frame by transmitting a frame end character, transmitting the data (translating as required), calculating and transmitting the FCS if it is a PPP frame, then transmitting another frame end character. Note that the PPP address and control fields should be

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 9 prepended to the PPP data when passed to the modem because the modem does not interpret any data.

When the modem 10 receives a PPP or SLIP frame from the remote location, the modem 10 searches for start of the frame character (which is also the frame end character). This character is discarded. The modem then examines each incoming byte of data, translating transparent data as required and keeping a current FCS if it is a PPP frame, while looking for the trailing frame end character. The trailing frame end character is also discarded. If the modem is configured for PPP, the current FCS value is confirmed to be valid and the last two (or four) data characters, which are the FCS characters, are also discarded (i.e., the length is decremented). This frame of raw data (prepended by the address and control fields if PPP) is immediately passed to the application layer in the gateway (such as the router/terminal server 12) via a packet bus or an equivalent menas, such as an RS 232 cable. Status values indicate OK, invalid FCS, frame too large, inter-char timeout, frame timeout, and parity error (frame aborts are discarded and the application layer is not informed).

Note that, using the techniques of the present invention, the application computing platform at the network interface never sees any transparent data. It deals with the actual information in the PPP or SLIP frame. Also note that the modem does not interpret the contents of any PPP or SLIP frame. It only does the most basic encapsulation of a datagram over a serial link, i.e., byte by byte transparency translation and FCS. The PPP address and control field and any negotiation, such as LCP or IPCP, are handled at the application software layer. Accordingly, by using the techniques of the present invention, data through-put in both the uploading and downloading directions through the modem 10 and router/terminal server 12 is greatly improved. This is a result of both reduced processing requirements at the gateway computing platform, and a lower overall latency of the system.

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 10 Referring again to FIG. 1A, it will be understood that other analogous and functionally equivalent DCE’s may be used in accordance with the invention besides the modem 10. For example, other kinds of modems, such as a DSU (data synchronizer unit) and CSU (circuit switching unit) may be used in conjunction with a digital data network 50. An ISDN (integrated services digital network) terminal adapter may also be used where the calls come in via ISDN lines. The term modem” in the claims is intended to be broadly interpreted to include all such functionally equivalent devices.

Referring to FIG. IB, it will be appreciated that the physical location of the router or terminal server 12 is not particularly important. For example, the router function may exist as a software feature in an operating system 14 for a personal computer, for example, the various versions of the Windows™ program of Microsoft Corporation. In this example, the protocol processing is performed in the modem 10. By virtue of the distribution of the protocol processing to the computing platform in the modem 10, rather than in the CPU for the computer, the computational load on the CPU and the latency in the call routing process are reduced, providing for increased call throughput.

Additionally, the particular means for transmitting the calls from the modem to the gateway is not particularly important. An RS 232 cable, a packet bus, or the internal bus of a host personal computer (such as the ISA, EISA, PCI or a VESA bus) may be used.

II. Preferred Network Access Server implementation

The present invention is implemented in a communication processing system that is depicted generally in FIG. 2. A plurality of call originators 20, 22 and 24 are located at various remote locations, which transmit incoming communications to a network access server 30. Call originator 20, 22 and 24 may consist of a personal computers Cl, C2 and C3, respectively, that generates

CA 02222151 1997-11-25

WO 96/41434

PCT/US96109661

- 11 digital data and transmits the data to a modems Ml, M2, and M3, which modulate the data onto a telephone lines 40, 42 and 44, respectively. For the purpose of this specification, the particular type of call originators is not important, and the call originators of FIG. 2 are chosen for purposes of illustration only. The call 5 originators have communication software that uses the PPP or SLIP protocol.

In FIG. 2, the data that is transmitted onto the telephone lines at 40, 42 and 44 is in analog form. The illustration in FIG. 2 assumes that the communication system makes use of the digital public switched telephone network (PSTN) 50 such as the T1 network. The calls from the call originators are 10 digitized and placed into one of the 24 multiplexed channels of the four-wire T1 span line 51 by the telephone company and fed into the network access server 30. As used herein, the term T1 span line refers to twenty-four 64 kbps (thousand bit per second) DS0 channels that are multiplexed in the 1.544 Mbps DS1 rate, with each DS0 channel carrying the digital representation of an analog voice channel. 15 The term trunk”, as used herein, refers to a single DS0 channel.

The digital signals representing the incoming communications are fed into the network access server 30 by the T1 span line 51 (or possibly two span lines). The network access server 30 then routes the incoming call onto the network 52. The network may be a Token ring network, Ethernet, or other type of network, 20 the particular details of which are not important. The host computer system 60 then receives the call and processes the calls as needed. The host computer system 60 depicted in FIG. 2 consists of a variety of computers such as a personal computer C4, data storage terminal C5, and mainframe computer C3. As was the case with the call originators 20, 22 and 24, the details of the host computer 25 system 60 and its constituent components, are not particularly important. The host computer system 60 has the capability of sending out calls via the network access server 30 to the remote data terminals (such as call originator 20).

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 12 Referring now to FIG. 3, the network access server 30 is shown in a functional block diagram form and will be described in more detail. The network access server 30 has a chassis 70 which houses a telephone interface unit 72 which receives the incoming calls on T1 span line 51, demultiplexes the calls, and routes the calls over a high speed time division multiplexed (TDM) bus complex 74 to twelve quad modem modules 76A, 76B, etc. Each modem module 76 has four modems (not shown in FIG. 3) which demodulate the incoming calls. Thus, if there are two T1 span lines 51 incoming to the network access server 30, there are 48 modems in all for the 48 DS0 channels incoming into the network access server 30. The connections on the TDM bus complex between the telephone interface unit and the modems are static or nailed up” connections, and are established on power-up of the network access server 30. The TDM bus complex 74 carries data back and forth between all of the various modules of the network access server 30. The bus complex 74 is described in greater detail below.

Each modem module 76 is provided with a corresponding modem network interface module 78A, 78B, etc. The modem network interface modules 78 have four sync/async RS 232 ports 80. The RS 232 ports 80 are linked to computers of the host computer system and may be used to output the calls from the network access server 30 to the host computer (and thus act as a network 52 as that term is used herein).

The network access server 30 also includes a gateway application module 82, which functions as an interface between the software which governs the operation of the network access server 30 and the software of the host computer system. The gateway application module 82 tells the modems in the modem modules 76 what modulation scheme to use for the incoming calls, whether the call is synchronous or asynchronous, and what error correction protocol to follow. The gateway application module 82 also tells the modems whether to send the calls out the RS 232 ports 80 or whether to send the calls to the network 52 and

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/D9661

- 13 host computer system 60. The gateway application module 82 contains suitable data processors, memories and other hardware, the details of which those of skill in the art are familiar and are not of particular importance here. A network management module 86 provides management and supervision functions for the network access server 30. A power supply module 88, supplying power to all the modules in the incoming call interface, is also incorporated into the chassis 70. The power supply module consists of two power supply units that perform ac to de power conversion, providing full redundancy in the case of failure in one of the units. The power supply units in module 88 are designed according to standard methodologies. A high speed cooling fan 90 is provided in the chassis 70 to dissipate heat generated by the power supplies during operation of the network access server. A power on/off switch (not shown) is provided to turn the whole unit 30 on and off.

The chassis 70 is a standard 19” card cage, and has provisions for 16 front-loading application cards and 16 rear-loading interface cards, and a network management module and associated interface module.

A. Telephone Interface Unit 72

The telephone interface unit 72 of FIG. 3 is composed of two separate modules, an incoming call interface module 105 and an incoming call application module 175. The purpose of interface module 105 is to physically receive the incoming T1 span lines, convert the signal in a digital TTL format, and deliver the signal to the call application module 175. Interface module 105 provides a CSU interface which recovers clock signals and data from the incoming T1 signals, and also provides the transmission of outgoing digital telephone signals representing digital data to line Tl. Module 105 is connected to application module 175 via a backplane connector. Application module 175 provides framing of recovered Tl data to extract the Tl DS0 channel data and then switches the channel data to the modem modules 76 via the TDM bus 74.

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 14 It will be appreciated that the time division multiplex (TDM) bus complex 74 includes a frame sync line, a time slot (TS) clock line, a bit clock line and two data highway lines. A packet bus is also provided for transmitting communications between the modules of the network access server 30.

As shown in FIG. 4, data is directly written from the transmit (TD) terminal of application module 175 (FIG. 3) to the receive terminal (RD) of one of the quad modems (e.g., 76A or 76B) and vice versa, via data highway lines 156, 157.

B. Modem Modules 76 and 78 Detailed Description

FIG. 5 illustrates a representative quad modem module 76A which is identical to the other modem modules of the network access server. Each of modem modules 76 contains four modems for a total of 24 modems. As a result, the network access server 30 can handle a total of 24 simultaneous full duplex channels of data communication. If two T1 span lines are inputted into telephone interface unit 72 (FIG. 3) then 12 modem modules may be provided to handle 48 simultaneous full duplex channels. Of course, additional capacity may be provided if desired.

Modem module 76A comprises a bus interface unit 414 that communicates with packet bus 99 through output bus 419. A board control processor 425 communicates over buses 428, 433 and 435. A flash ROM 431 provides memory for processor 425. Flash ROM also contains the code for the modem control processors 473-476 as well as the digital signal processors 453-456. Bus interface 415 communicates with TDM bus 74 over bus 421.

Digital signal processor serial interface logic 437 communicates with processor 425 over a bus 439 and communicates with individual modems 447-450 over buses 441-444, respectively. Each of modems 447-450 is identical. The modems comprise digital signal processors 453-456, application specific integrated

CA 02222151 1997-11-25

WO 96/41434

PCT7US96/09661

- 15 circuits (ASICs) 463-466 and modem control processors 473-476 connected as shown over buses 457-460 and 467-470. Processors 473-476 communicate with processor 425 over bus 435. ASICs 463-466 provide RS-232 ports 477-480. These ports, together with the comparable ports from modem modules 76B-76F form a group of modem network interface modules 78A-78F (FIG. 3) for coupling digital signals to the host computer system. The hardware for each of modems 447-450 is substantially the same as the hardware found in the USR Courier Dual Standard modem manufactured by U.S. Robotics, Inc., Skokie, Illinois.

Board control processor 425 performs the following functions: control of the reception and transmission of packets to and from a management bus (not shown), multiplexing tasks for the packet bus 99, controlling the code set for the entire modem module 76A, and distributing (i.e., downloading) code to the modems in the module 76A.

Interface logic 437 performs the following functions: handles the interface to the TDM bus 74, counts the time slots, and multiplexes and demultiplexes signals in the TDM bus 74.

The protocol processing for the incoming and outgoing calls, in the present embodiment of the invention, is distributed among the four modem control processors 473, 474, 475, and 476. The data processing and modem control processing functions of DSP 453 and modem control processor 473 may be combined into a single digital signal processor.

The circuits shown in Fig. 6 are available commercially as indicated in the following table:

Circuits Manufacturer & Model

Number

Bus interface 414

Board control processor 425

Flash ROM 431

Xilinx 3064

Intel 80C188EB

Intel 28F020

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

Xilinx 3042

- 16 DSP serial interface logic 437

DSPs 453-456

Tex. Inst. 32OC51

ASICs 463-466

US Rob. 1.016.684

Modem control processors 473-476

Intel 80C188EB

TTT. Distributed Processing of PPP and SLIP protocols

With the above description in mind, the reader’s attention is directed to FIG. 6, which is a flow chart of the distributed processing procedure according to the preferred form of the present invention. The following discussion is made in reference to the network access server embodiment of the invention, and persons of ordinary skill in the art will readily understand that the description can be adapted to other possible embodiments.

At step 200, a call is arrived from one of the remote call originators, or else a call is initiated from the host computer system to a remote computer or other data terminal. At step 202, the call is answered in a well known manner. At step 204, the gateway application module 82 (FIG. 3) determines the protocol of the incoming or outgoing call. This is done by determining, for example, the port configuration of the call, by the telephone number of the call originator or the call destination, by conversation or menu with the user, by the user name and a database look-up, by an automatic detect or inspection of data routine, or whatever other process is implemented.

At step 206 the gateway module 82 configures the protocol mode for the modem. The software routine in CONFIG1.S is implemented in this step. If the asynchronous transparent protocol is performed, at step 214 a forward on timeout or buffer full command is sent to the modem in the modems module 76. If the SLIP protocol is used, for receiving calls at step 210 the modems remove transparency and translation characters, and send the payload (a number of bytes) or overflow errors to the gateway module 82. In the appended software listing,

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 17 routines in SLIPRX.S are implemented at this step. For transmitting calls, at step 212 the modems add transparency translation characters and a SLIP framing character. In the appended software listing, the routines in SLIPTX.S are implemented.

If PPP protocol is used, the routine in CONFIGl.S is implemented at step 208. Step 208 of FIG. 6 is shown in detail in FIG. 7. Referring now to FIG. 7, at step 216 the gateway module 82 enters the LCP negotiation procedure per the instructions set forth in the Request For Comments: 1661 Standard, which is incorporated by reference herein. The Requests For Comments (RFC) 1661 Standard is a publicly available document which specifies an Internet standards track protocol for the Internet community. Persons of ordinary skill in the art are familiar with the RFC 1661 document.

At step 218, the gateway module configures the modems for each LCP negotiated parameter. This may be accomplished in order, for example, MTU, TX Async map, RX Async map. In the appended software listings, the routine in CONFIG2.S describe this procedure. The procedure then enters a data transfer phase at step 220 in which messages are uploaded or downloaded through the network access server 30. In the receiving or uploading direction, the modems remove the HDLC frame characters, and send the payload, number of bytes and error code (such as good FCS, bad FCS, overrun, or partial). This procedure is set forth in the appended software listing PPPRX.S.

In the transmitting (downloading) direction at step 224, the modems get the payload from the gateway module 82, perform character transparency translation and transmit asynchronous map, calculate the FCS, and add HDLC framing characters. At step 226, the messages are sent out through the telephone network 51. This procedure is set forth in the PPPTX.S routine in the appended listing.

CA 02222151 1997-11-25

WO 96/41434 PCT/ÜS96/09661

- 18 One representative example illustrating the advantages of the invention in terms of throughput over the prior art methods can be seen in FIGS. 8 - 11. FIG. 8 is a graph of the upload throughput using prior art computation in a single platform at the PPP protocol network gateway. Note that the total throughput of the network access server remains substantially constant after a peak is reached with 8 active ports and levels out at 17 active ports at 24,000 bytes per second. The per port throughput starts off quite high at roughly 4600 bytes per second for a small number of active ports (that is, less than 10), but drops dramatically at higher numbers of active ports. Thus, FIG. 8 illustrates the processing bottleneck that occurs when the PPP protocol processing is performed in a single platform at the network interface.

FIG. 9 is a graph of the upload throughput when the distributed processing technique according to the teaching of the present invention is used. Note that in FIG. 9 the total throughput rises steadily up to 18 ports, dips slightly between 18 and 21 ports, and then increases up to total throughput of approximately 92,000 bytes per second with 25 active ports. Between 25 and 48 active ports, the total throughput remains between roughly 72,000 bytes per second and 86,000 bytes per second. This is approximately 3 to 4 times the total throughput as compared to the results of FIG. 7. The inventors predict that further improvements in system tuning would smooth out the oscillations in system throughput shown in FIG. 9, especially for higher numbers of active ports. Note also that the average per port throughput using the techniques of the present invention remains relatively high as the number of active ports increases, accomplishing an efficiency improvement of more than 3 times compared to the results of FIG. 8, particularly at higher volumes of active ports.

FIG. 10 is a graph of the download throughput when the PPP processing is performed in the prior art technique of a single platform at the network gateway. In FIG. 10, note that the total download throughput levels off at

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 19 approximately 55,00 bytes per second between above 20 active ports when the prior art techniques are used. The average per port throughput starts at roughly 45,000 bytes per second with under 10 active ports, but this value drops steadily to a low of approximately 12,000 bytes per second when 48 active ports are used.

FIG. 11 is a graph of the download throughput when the distributed processing technique according to the teachings of the present invention is used. Note that the total download throughput using the techniques of the present invention rises steadily to a high of approximately 104,000 bytes per second when 26 active ports are used and remains relatively constant at higher levels of call activity. As can been seen by comparison of FIG. 11 to FIG. 10, this is a substantial improvement in call throughput. The average per port throughput using the techniques of the invention remains relatively constant at 4500 bytes per second up to 22 ports and this value drops gradually to approximately 2000 bytes per second when 48 ports are used. This represents an improvement of approximately 2 to 1 over the download per port throughput, particularly at higher call volumes.

Presently preferred software routines for implementing the procedures shown in FIG. 6 and FIG. 7 are set forth in code form below. A person of ordinary skill in the art will appreciate that the code represents but one example of the implementation of the invention in a network access server environment. The code is stored and executed in the modems of the modem modules 76 of FIG. 3. The software routines in the gateway module 82 that interact with the modem software routines comprise relatively simple higher level control routines, with which can be readily developed by persons of ordinary skill in the art.

The reader is directed to the Notice Regarding Copyright set forth above, which is incorporated by reference here.

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 20 ® 1995 U.S. Robotics Corp.

CONFIG1.S . >(<*** *************************>£**»!<:****»(<***** *************** ******* j

****

<td> .* &gt; .*</td><td> Pap_config_ppp_slip_mode * *</td>

<td> » .* &gt; .* f ·* , .* .* ? .* » .* J .*</td><td> Depending upon the mode, this configure routine sets the * appropriate variables. There are no errors, if unknown command * parameter then it defaults to non-SLIP/non-PPP. The state * machine is set to return an OK response pkt or an error * response if the mode is invalid. * * Interprets a pBus pkt whose format is: *</td>

<PAP_CTRLW_CONFIGURE> <PAP_PPP_SLIP_MODE> < length = 1 > <m ode> * .* * . ***^**ψ**ι|ί********************************************************** ?

****

Public Pap_config_ppp_slip_mode pap_config_ppp_slip_mode proc near add Nwbus_si_ptr,2 ;skip length word sub Nwbus_msg_count,2 mov si, Nwbus_si_ptr cmp byte ptr [si],PAP_MODE_PPP jne #config_mode_slip ;PPP mode mov ppp_slip__mode,PAP_MODE_PPP ;mov pppslip_mtu,MTU_ABSOLUTE_MAX_PPP ;Tx_Data_State gets set to PPP_Transmit_txJData in routine Ctrlwjdata ;after it checks the current mode using variable ppp_slip_mode.

mov Tx_Data_State,offset Transmit_Idle_State mov tx_state_machine,offset dummy_return mov rx_state_machine,offset dummy_retum mov application_tx_state,offset ppp_tx_appl mov application_rx_state,offset ppp_rx_appl_start

CA 02222151 1997-11-25

WO 96141434

PCT/US96/O9661

- 21 mov bcc_type,PAP_BCC_TYPE_CCITT16 ;default, may be changed later

IF PPPSLIP__DEBUG call T um_LED_Red_Far

ENDIF jmp #config_all_modes #config_mode_slip:

cmp byte ptr [si],PAP_MODE_SLIP jne #config_mode_direct ;SLIP mode mov ppp_slip_mode,PAP_MODE_SLIP ;mov pppslip_mtu,MTU_ABSOLUTE_MAX_SL!P ;Tx_Data_State gets set to PPP_Transmit_tx_Data in routine Ctrlw_data ;after it checks the current mode using variable ppp_slip_mode.

mov Tx_Data_State,offset Transmit_Jdle_State mov tx_state_machine,offset dummy__return mov rx_state__machine,offset dummy_return mov application__tx_state, offset slip_tx_appl mov application_rx_state,offset slip_rx_appl_start

IF PPPSLIP_DEBUG call Tum__LED Yellow_Far

ENDIF j mp #config_all_modes #config_mode_direct:

cmp byte ptr [si],PAP_MODE_NO_TRANSLATION jne #config_mode_error ; direct mode mov ppp_slip_mode,PAP_MODE_NO_TRANSLATION ;mov pppslip_mtu,MTU_DIRECT_MODE ;Set up tx_state_machine,rx_state_machine,Tx_Data_State,

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 22 ;application__tx_state, &amp; application_rx_state call Init_State_Machines #config_all_modes :

;Clear out the RC buffer and throw out any data that overflowed to pbus

<td> push mov mov mov POP</td><td> si si,ss:r_store_ptr ss:r_load_ptr,si buf_cur_allocated, 0 si</td>

<td> or ret</td><td> tx_state, (Send_Ok_Config_Resp)</td>

#config_mode_error:

or tx_state 1, (Report_Bad_Indicator) dummy_retum :

ret pap_config__ppp_slip_mode endp

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 23 CONFIG2.S . JJiJfC****** *************************** ********************************* >

**** ; * pap_config_ppp_sl ip_mtu* .* * ?

;* This configure command initializes pppslip mtu, ie. the max * ;* ppp _or SLIP frame size. The state machine is set to return an* ;* error response pkt if the value is too large or the mode is not* ;* PPP or SLIP. Otherwise the state machine is set to return OK.* .* * ;* Interprets a pBus pkt whose format is:* ·* < PAP—CTRLW CONFIGURE > < PAP_PPP_SLIP_MTU > <lenght=2> <word value >* .* * j

. ******* *************************** ********** ****** ****************** »

****

Public Pap_config_ppp_slip_mtu pap_config_ppp_slip_mtu

Nwbus_si_ptr,2

Nwbus_msg_Count,2 si,Nwbus_si__ptr ax, [si] proc add sub mov mov near ;skip length word ;ax has max frame size call handle_frame_ptrs ; update working ptrs ;; 1-20-95 took out max size check ;; cmp ppp_slip_mode,PAP_MODE_PPP ;; jne #mtu_slip_test ;jump if not PPP mode ;; cmp ax,MTU_ABSOLUTE_MAX_PPP ;; jg #mtu_error ;; jmp #mtu_end ί

; ;#mtu_slip_test:

<td> ?</td><td> cmp</td><td> ppp slip mode,PAP_MODE_SLIP</td>

<td> 9</td><td> jne</td><td> #mtu error ;jump if not SLIP mode</td>

<td> 9</td><td> cmp</td><td> ax,MTU_ABSOLUTE_MAXJSLIP</td>

<td> 9</td><td> jg</td><td> #mtu_error</td>

9 ;;#mtu__end:

CA 02222151 1997-11-25

WO 96/43434

PCT/US96/09661

- 24 mov pppslip_mtu,ax or tx_state,(Send_Ok__Config_Resp) ret ;;#mtu_error:

; ; or tx_statel, (Report_Bad_Indicator) ;; ret pap_config_ppp_slip_mtu endp » ****

Pap_config_ppp_in_accm &amp;. Pap_config_ppp__out_accm *

These configure routines initialize the inbound or outbound Async-Control_Char_Map table. The state machine is set to return an OK response pkt.

Interprets a pBus pkt whose format is:

, >

·* ·* ?

·*

J <PAP_CTRLW_CONFIGURE> <PAP_PPP_IN_ACCM > <4> <MSByte> <

> < > <LSByte> * ;* or !* <PAP_CTRLW_CONFIGURE> <PAP_PPP_OUT_ACCM > <4> <MSByte> <><><LSByte> * ·* * ,

SK##*

<td colspan="3"> Public Pap_config_ppp_in_accm</td>

<td colspan="2"> pap__config_ppp_in_accm</td><td> proc near</td>

<td> ;; cmp</td><td> ppp_slip_mode, P A P_</td><td> MODEJPPP</td>

<td> ;; jne</td><td> accm_error</td><td> ;only do this if in PPP mode</td>

<td> add</td><td> Nwbus_si_ptr,2</td><td> ;skip length word</td>

<td> sub</td><td> Nwbus_msg__count,2</td><td></td>

<td> mov</td><td> si,Nwbus_si_ptr</td><td> ;si points to most significant accm byte</td>

push di

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 25 mov di,offset ppp_rx_accm jinbound map (local) config_accm_end:

<td> call POP</td><td> accrn_conversion di</td>

<td> ;call add sub</td><td> handle_frame_ptrs ;update working ptrs Nwbus_si_ptr,3 ;skip rest of data bytes Nwbus_msg_count,3</td>

<td> or ret</td><td> txjstate, (Send_Ok_Config_Resp)</td>

; ;accm_error:

<td> ;call</td><td> handle_frame_ptrs</td><td> ;update working ptrs</td>

<td> add</td><td> Nwbus_si__ptr, 6</td><td> ;skip rest of data bytes</td>

<td> sub</td><td> Nwbus_msg_count,6</td><td></td>

<td> or</td><td colspan="2"> txjstate 1, (Report_Bad_Indicator)</td>

<td> ret</td><td></td><td></td>

<td colspan="2"> config_ppp__in_accm</td><td> endp</td>

Public Pap_config_ppp_out_accm pap_config_ppp_out_accm proc near

<td rowspan="2"> cmp jne</td><td colspan="2"> ppp_slip_mode, P AP_MODE_PPP</td>

<td> accm_error</td><td> ;only do this if in PPP mode</td>

<td> add</td><td> N wb us_si_ptr, 2</td><td> ;skip length word</td>

<td> sub</td><td> N wb us_m sg_coun t, 2</td><td></td>

<td> mov</td><td> si,Nwbus_si_ptr</td><td> ;si points to most significant accm byte</td>

<td> push</td><td> di</td><td></td>

<td> mov</td><td colspan="2"> di,offset ppp_tx__accm ; Outbound map (remote)</td>

<td> jmp</td><td> config_accm_end</td><td></td>

pap_config_ppp_out_accm endp • ifc ## ************* ******>(< ifs*#* ik*****#*****^***»::*^** ****** ********** *$** ;* Pap_conflg_ppp_in_delete & Pap_config_ppp_out_delete * .* «

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

These configure routines initialize the inbound or outbound delete character translation enable. The state machine is set to return an OK response pkt.

- 26 Interprets a pBus pkt whose format is:

·* ·* î

.* <PAP_CTRLW_CONFIGURE> < PAP_PPP_IN_DELETE > <lenght=l > < val ue> * .* ?

·* <PAP_CTRLW_CONFIGURE> < PAP_PPP_OUT_DELETE > <lenght=l> <

* value == 0 value = = !0 or value >

.* .* >

disables delete char translation enables delete char translation *

Î

<td colspan="2"> Public Pap_config_ppp_in_delete</td>

<td colspan="2"> pap__config_ppp_in_delete proc near</td>

<td> add</td><td> Nwbus_si_ptr,2</td>

<td> sub</td><td> Nwbus_msg_count,2</td>

<td> mov</td><td> si,Nwbus_si_j&gt;tr</td>

<td> mov</td><td> al,[si]</td>

<td> mov</td><td> ppp_rx_delete_transl,al</td>

;skip length word ;si points to value or tx_state, (Send_Ok_Config_Resp) ret pap_configjppp_in_delete endp

Public Pap_configjppp_out_delete pap_config_ppp_out_delete proc near

<td> add</td><td> Nwbus_si_ptr,2</td><td> ;skip length word</td>

<td> sub</td><td> Nwbus_msg__count,2</td><td></td>

<td> mov</td><td> si,Nwbus_si__ptr</td><td> ;si points to value</td>

<td> mov</td><td> al, [si]</td><td></td>

<td> mov</td><td> ppp_tx_delete_tran si, al</td><td></td>

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 27 or tx_state, (Send_Ok_Config_Resp) ret pap_configjppp_out_delete endp . 4c »|e * * Ή * * Me * * * * Me ** ** * *** * * * * * * * * * * * * * * * * ** * * * * * * * * * * * * * ** * * * * ** ** * * ** ** ****** ; * accm_conversion .* * »

;*Bytes from pkt configuration command .* * ;*byte[O] byte[l] byte[2] byte[3] . * _ * ;*J3 3 2 2 2 2 2 2] *

12222 1 1 1 11 j 1 1 1 1 1 1 0 01 |0 0 0 0 0 0 0 0|

<td> .*1 9 1 * . ùk</td><td> 10987654] 132 1098761 |5 4 3 2 1 0 9 81 *</td><td colspan="2"> 17 6 5 4 3 2:</td><td> L 0]</td>

<td colspan="2"> 9 ·* ;*These bits are converted to a 32 byte array, in the opposite</td><td> * order.</td><td> *</td><td></td>

<td colspan="3"> ;*Each byte in the 32 byte array will either equal its offset value or</td><td> *</td><td></td>

<td colspan="2"> ;*its offset value exored with 20h.</td><td></td><td> *</td><td></td>

<td> ·* 9</td><td> if (byte === offset value) use byte value only</td><td></td><td> *</td><td></td>

<td> .* &gt; .*</td><td colspan="3"> if (byte = = (offset value exor 20h)) use PPP_ESC then offset value *</td><td> *</td>

<td colspan="2"> 9 ;*eg. if the configure pkt data is 00b OFh FFh 55h,</td><td></td><td> *</td><td></td>

<td> . * &gt; .*</td><td> then the 32 byte ACCM array is:</td><td> *</td><td> *</td><td></td>

<td> 9 ·* 9</td><td> 20 01 22 03 24 05 26 07 28 29 2A 2B 2C 2D 2E 2F</td><td></td><td></td><td> *</td>

<td> ·* 9 • *</td><td> 30 31 32 33 14 15 16 17 18 19 1A IB 1C ID IE IF</td><td> *</td><td></td><td> *</td>

<td> ·* 9</td><td> so if you want to see if 7 if flagged:</td><td></td><td> *</td><td></td>

<td> ·* 9</td><td> if (accm[7] == 7)</td><td> *</td><td></td><td></td>

<td> ·* 9</td><td> data stream gets &lt;07&gt;</td><td></td><td> *</td><td></td>

<td> .* 9</td><td> else</td><td> *</td><td></td><td></td>

<td> ·* , .Me</td><td> data stream gets &lt;PPP_ESC&gt; &lt;27&gt;</td><td> *</td><td></td><td> *</td>

<td colspan="2"> 9 ;*Assumptions for this routine:</td><td></td><td> *</td><td></td>

<td> ·* &gt;</td><td> di = offset of accm table to put values into</td><td></td><td> *</td><td></td>

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 28 ;* si = offset of 4 bitmapped byte array used to create the* ;* accm table (from pBus)* ;* Destroys AX,BX,CX* . *********** **************** ********* ***** ********* ****** ************ 9 ****** accm_conversion

<td> push</td><td> si</td>

<td> mov</td><td> bx,001Fh</td>

<td> mov</td><td> ex,4</td>

<td colspan="2"> #next_bitmap_byte:</td>

<td> push</td><td> ex</td>

<td> mov</td><td> al, [si]</td>

<td> inc</td><td> si</td>

<td> mov</td><td> ex, 8</td>

<td> #next bit:</td><td></td>

<td> shl</td><td> al,l</td>

<td> jc</td><td> ^flagged</td>

<td> push</td><td> di</td>

<td> add</td><td> di,bx</td>

<td> mov</td><td> byte ptr [di],bl</td>

<td> POP</td><td> di</td>

<td> jmp</td><td> #end_of_bit_diddle</td>

<td> #flagged:</td><td></td>

<td> push</td><td> di</td>

<td> push</td><td> bx</td>

<td> add</td><td> di,bx</td>

<td> xor</td><td> bl,20h</td>

<td> mov</td><td> byte ptr [di],bl</td>

<td> pop</td><td> bx</td>

<td> POP</td><td> di</td>

<td> #end_of_bit_</td><td> diddle:</td>

<td> dec</td><td> ’ bl</td>

<td> loop</td><td> #next_bit</td>

<td> pop</td><td> ex</td>

<td> loop</td><td> #next__bitmap_byte</td>

proc near ;BL = offset into accm ;AL — bitmapped byte from pBus pkt ;for each bit in AL

CA 02222151 1997-11-25

WO 96/41434

PCTÆJS96/09661

- 29 pop si ret accm_conversion endp

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 30 PPPRX.S , *********************************** Jis*********************** ****

<td> .* » .*</td><td> ppp_rx_appl_start * *</td>

<td> 9 .* ·* Î .* 9</td><td> This routine’s address is put into application_rx_state when * all chars are to be ignored except for the PPP_FLAG char, which * indicates the start of a new PPP frame. This routine is called *</td>

<td> .* , • *</td><td> with each incoming byte, in register AL. * *</td>

<td> » .* 9</td><td> When the first PPP_FLAG char is received, application rx_state *</td>

<td> ·* ,</td><td> gets ppp__rx_appl’s address. Ppp_jx_appl will then be called *</td>

<td> ·* 9</td><td> for each byte instead of this routine. Ppp_rx_appl cannot *</td>

<td> .* 9</td><td> handle the first PPPJFLAG char because it assumes that when *</td>

<td> ·* $</td><td> it receives a PPP_FLAG char, everything before it was a frame, *</td>

<td> .* 9</td><td> ie. if the data is: &lt; garbage &gt; &lt; PPP FLAG &gt; &lt;data&gt; &lt;PPP_FLAG&gt; *</td>

<td> ·* 9 .*</td><td> &lt; garbage&gt; would be interpreted as a frame. * *</td>

» , * * ** ‘********************** ****

Public Ppp_rx_appl_start ppp_rx_appl_start proc near

<td> push push pop</td><td> ds NUBUS_RAM ds</td>

<td> call</td><td> chk_rx_timer ;reset interchar timer</td>

<td> cmp</td><td> linkjparity,PAP_GEN_NO_PARlTY</td>

<td> je</td><td> #parity_done</td>

<td> call</td><td> check_parity</td>

<td> jc</td><td> #pras_exit ; ignore error,</td>

<td> and</td><td> al,07Fh ; strip parity</td>

<td> #parity_done:</td><td></td>

cmp al,PPP_FLAG jne #pras_exit ;jump if not the starting frame char

CA 02222151 1997-11-25

WO 96/41434

PC17US96/09661

- 31 ;This is start of the first PPP frame, discard framing char, call ppp_slip_rx__frame_init ;reset variables for next frame ;Now call ppp_rx_appl, not ppp_rx_appl_start, when a char comes in 5 mov application_rx_state, offset ppp_rx_appl ;Set up timers

<td></td><td> call</td><td> chk rx timer ;reset interchar timer</td>

<td></td><td> cmp</td><td> X25_Timer_Status,X25_Timer_OFF_Implemented</td>

<td> 10</td><td> jne</td><td> #pras_exit</td>

<td></td><td> mov</td><td> X25_Timer_Status,X25_Timer_ON</td>

<td></td><td> #pras_exit:</td><td></td>

<td></td><td> pop</td><td> ds</td>

<td> 15</td><td> ret</td><td></td>

<td></td><td colspan="2"> ppp_rx_appl_start endp</td>

. ********************************************************************* **** « * • * .* ·* ?

·* .* »

* * >

* ?

.*

J • * *

» .* f

·*

-* ?

·* ·* ppp_rx__appl * This routine’s address is stored at application_rx_state, * which is called for each incoming byte (it is similar to routine x_25_rx_appl).

*

This routine checks one byte of incoming data. That byte in register AL. It checks for PPP_FLAG, PPP_ESC, inbound chars, FCS value, invalid frame size, and to ignore rest of frame if the forward timer expired. When appropriate, the incoming char is put into the RC buffer using routine store rx char. The maximum frame size excludes is

PPP_ESC *

The translation done here is:

<PPP_ESC> <PPP_FLAG>

<PPP_ESC> < x >

<byte flagged in rx ACCM> => discard -prev char ! = *

. ***************************************************** skaie*»|e5{e***sie******

J = > frame = > < x exor abort

20H>

*

ACCM* *

* * chars.

* *

PPP FLAG* ****

WO 96/41434

PCT/US96/09661

CA 02222151 1997-11-25

- 32 ppp_rx_appl push push pop proc ds

NUBUS_RAM ds near » J) ί J > JM» J ;; CHECK TIMERS ;;

call chk_rx_timer ;reset interchar timer ;;The PPP/SLIP forward timer implementation requirement is that ;;when the forward timer expires before the end of frame char, ;;what has already been received is forwarded to the Gateway and ;;all subsequent chars upto the end of frame char are discarded.

;Tum on forward timer, if so enabled cmp X25_Timer_Status,X25_Timer_OFF_Implernented jne #ppp_timer_status mov X25_Timer_Status,X25_Timer_ON #ppp_tim er_statu s :

;; PARITY CHECK ;;

call check_parity jc #parity_error ;chk parity error strip ;; END OF FRAME?;;

;; if (char — = PPP_FLAG) /* end of frame */;;

;; if (pppslip__rx_esc_rcvd);;

;; //Frame abort: This implementation;;

;; //kills the frame without informing;;

;; //the upper layer.;;

;; clear out data;;

;; reset frame variables;;

return;;

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661 ;; if (empty frame) // eg. <PPP_FLAG> <PPP_FLAG> ;; reset frame variables;;

;; return

9999 ;; remove last 2 chars in RC buffer, they are FCS;;

; ; if FCS is OK; ;

;; tx_state j= Recv_End_of_Data_Msg;;

;; else;;

;; tx_state j= FCS_Error;;

;; reset frame variables;;

;; return;;

<td></td><td> cmp</td><td> al,PPP_FLAG</td><td></td>

<td> 15</td><td> jne</td><td> #char_i s_notjppp_flag</td><td> Jump if not framing char</td>

<td></td><td> cmp</td><td> pppslip__rx_esc_rcvd, 0</td><td></td>

<td></td><td> jne</td><td> #frame__abort</td><td> ;jump if prev char was PPP_ESC</td>

<td> 20</td><td> cmp</td><td> pppslip_rc_char_count,0</td><td></td>

<td></td><td> je</td><td> #ppp_exit_frame_end</td><td> ;jump if empty frame</td>

<td rowspan="2"></td><td colspan="4"> ;The last 2 bytes are the FCS, they should be removed</td>

<td colspan="2"> cmp</td><td colspan="2"> pppslip__rc char_count,2</td>

<td> 25</td><td></td><td> js</td><td> #ppp_invalid_fcs</td><td> Jump if # chars &lt; min for FCS</td>

<td></td><td></td><td> call</td><td> remove_rx_char</td><td></td>

<td></td><td></td><td> dec</td><td> pppslip__rc_char_count</td><td></td>

<td></td><td></td><td> call</td><td> remove_rx_char</td><td></td>

<td></td><td></td><td> dec</td><td> pppslip__rc_char__count</td><td></td>

<td> 30</td><td></td><td></td><td></td><td></td>

<td></td><td> IF</td><td colspan="2"> PPPSLIP DEBUG</td><td></td>

<td></td><td> 5</td><td> jmp</td><td> #ppp_valid_fcs</td><td></td>

<td></td><td colspan="2"> ENDIF</td><td></td><td></td>

;Check received frame’s FCS cmp PPP_rx_fcs, CCITT16_GOODCRC je #PPP_^valid_fcs ;frame is good, ship it jmp #ppp_invalid__fcs ;frame is bad #char_is_not_ppp_flag:

CA 02222151 1997-11-25

WO 96/41434

PCT7US96/09661

- 34 ;; TRANSLATE INCOMING CHAR >>

;; if (pppslip_rx_esc_rcvd) /* prev char == PPP_ESC */ ;; pppslip_rx_esc_rcvd = 0;;;

;; char 20h;;

;; else if (char &lt; 20h) /* and prev char ’= PPPESC */ ;; if (char is flagged in inbound accm table);;

;; return /* discard, prev char != PPPJESC */ ;; else if (char == PPP_ESC);;

;; pppslip__rX—esc_rcvd = 10;;;

;; return /* don’t store nor increment */;;

;; else if (char == DELETE) /* and prev char != PPP_ESC */ ;; if (inbound delete char translation is enabled);;

;; return /* discard, prev char != PPPJESC */ ;; /*else put char into buffer unaltered*/;;

cmp pppslip_rx_esc_rc vd, 0 jne #ppp_esc_rcvd ;jump if previous char was PPPJESC test al,0E0h jz #ppp_rx_accm_check cmp al,PPP__ESC je #ppp_esc_char cmp jne ;accm size, 32 bytes ;jump if char &lt; 20h ;jump if char = = PPP_ESC al,ASCII_DELETE #ppp_rx_translation__done ;just an everyday ordinary type of character #is_ascii_delete:

cmp ppp_rx_delete_transl,0 je #ppp_rx_translation_done ;jump if DELETE is not to be translated jmp #ppp_exit_no_save ;discard char #ppp_escjrcvd:

mov pppslip_rx_esc_rcvd, 0 xor al,20h jmp #ppp_rx_translation_done ;prev char was ppp_esc

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 35 #ppp_rx_accm_check:

mov bx,offset ppp_rx__accm ;al is &lt; 20h, use as index into table xlat [bx] ;al gets byte from pre-defined table test al,20h ;is bit set?

jz #ppp_rx_translation_done ;jump if char is not flagged j mp #ppp_exit_no_save ; discard char #ppp_esc_char:

mov pppslip_rx_esc_rcvd, 1 #ppp_exit_no_save:

pop ds ret #ppp_rxjranslation_done:

;; FRAME CHECK SEQUENCE > » ’ 5 ;; Keep running total of FCS, including final FCS chars. ;;

;; If the PPP_FLAG is received, ppp_rx_fcs should be F0B8. ;;

;; AL=data,DX=InitiaI CRC Value; Upon Return: DX = CRC16 mov dx,ppp_rx_fcs ;al has data byte call ppp_generate_crc ;call generate_crc 16 mov ppp_rx_fcs,dx ;; INCREMENT COUNTER, STORE CHAR, EXIT ;;

;; if (4-+pppslip_rc_char_count > mtu) ;;

;; set error status;;

; ; return; ;

;; else;;

;; store char;;

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 36 inc pppslip_rc_char_count mov bx,pppslip_mtu cmp bx ,pppslip_rc_char_coun t j s #ppp__too_man y_char s jump if frame size is too big ;;put char into RC buffer call store_rx_char pop ds ret ;char is already in register al ;; END OF FRAME &amp; ERROR CONDITIONS ;;

;This is end of frame, dispatch data to API #ppp_valid_fcs:

mov event__occurred, P A P_RS_COD_END_OF_D AT A ;Recv_End_of_Data_Msg call load_allocation_buffer jc #frame_abort ;if pBus full, kill this PPP frame #ppp_this_frame_is_over:

test X25_Timer_Status,X25_Timer_ON jz #ppp_aint_no_forward_timer mov X25_Timer_Status,X25_Timer_OFF_Implemented ^pp_aint_no_forward__timer:

and tx_statel ,not Recv_forward_timeout_reached and tx_statel ,not Recv_Interchar_timeout_reached #ppp_exit_frame_end:

call ppp_slip_rx__frame_init pop ds ret ; reset variables for next frame ;This is end of frame, no API error, trash data #frame_abort:

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 37 ;clear out RC buffer push mov mov pop mov jmp si si,ss:rjoad_ptr ss:r_store_ptr,si si buf_cur_allocated, 0 #ppp_this_frame_is_over ; forget about overflowed data ;This is end of frame, issue API error, trash data #ppp_invalid_fcs:

or tx__state 1, (Report_Rec v_BCC_Error_M sg) or ss:packet_processing,active ;this activates tx_reply_state ;mov buf_cur_allocated,0 ; forget about overflowed data jmp #frame_abort ;#ppp_this_frame_is_over ;This could be middle of frame, issue API error, trash data #ppp_too_many_chars:

mov application_rx_state,offset ppp_rx_appl_start or tx_statel,(Recv_Data_Exceeded_MTU) or ss:packet_processing,active ;this activates tx_reply_state ;mov buf_cur_allocated,0 ; forget about overflowed data j mp #frame_abort ; #ppp_this_frame_i s_over ;This could be middle of frame, issue API error, trash data #parity_error:

mov application_rx__state, offset ppp_rx_appl_start or tx_state 1, (Rec v_Data_Parity_Error_Msg) or ss:packet_processing,active ;this activates tx_reply_state ;mov buf_cur_aliocated,0 ;forget about overflowed data jmp #frame_abort ;#ppp_this_frame_is_over ppp_rx_appl endp

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 38 PPPTX.S . ******************************************************************** **** • * .* »

.* î

.* »

.* .* .* .* .* ·* ·* .* .*

J .*

J .* »

• *

J .* >

.* ,

.* .* >

.******************************************************************** **** ppp_transmit_tx_data

When raw data for one PPP frame is ready, puts this routine’s address into tx__data_state. machine then executes this routine.

* routine ctrlw_data

The state * *

to the remote * to

This routine starts a PPP frame transmission modem with a PPPJFLAG char. It then uses pb_input_vector do async char mapping on the data byte by byte, which if online will eventually call ppp_tx_appl. It then appends the FCS * and another PPP_FLAG to the end of the frame.

PPP__tx_appl keeps track of the total size of the frame, excluding PPP_ESC map chars, PPP_tx_appl keeps track of the current FCS. * *

This routine is based on routine transmit_tx_data. It will transmit 20h chars at a time, then release control to give some processing time to the data pump, then rely on the state machine to come back to PPP_Transmit_tx_Data_translate to do an additional 20h chars. The carry bit is set on each return. * *

Public Ppp_transmit_tx_data ppp_transmit_tx_data proc near initialize frame variables

<td> mov mov mov</td><td> pppslip_tx_char_count,0 ;number of chars transmitted pppslip tx frame_maxed,0 ;frame size overflow indicator ppp tx fcs,CCITT16_INITFCS initial FCS value</td>

<td> mov call</td><td> al,PPP_FLAG ;7Eh store_tx_char ;write directly to TC buffer, bypassing filters</td>

<td> mov</td><td> Tx_data_state,offset PPP_Transmit_tx_Data_translate</td>

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 39 PPP_Transmit_tx_Data_translate: push si mov cx,0 #ppp_check_for_jnore_data:

mov si,L_Load_Ptr cmp si, L_store_Ptr j ne #ppp_mo vetxdata ;jump if Gateway pkt has data ;A11 the data has been sent, now send the FCS thru the translator

<td> mov</td><td> ax,ppp tx_fcs</td>

<td> xor</td><td> ax,0FFFFh</td>

<td> push</td><td> ax</td>

<td> call</td><td> pb_input_vector</td>

<td> pop</td><td> ax</td>

<td> xchg</td><td> al,ah</td>

<td> call</td><td> pb_input_vector</td>

;End of frame mov al, PPPJFL A G call store_tx_char ;al = low byte ;This results in FCS of F0B8, ;otherwise it would be 0000. ^PPP_^tx_^aPpi will trash ppp_tx_fcs ;want translation, if needed ;al = high byte ;want translation, if needed ;7Eh ; write directly to TC buffer, bypass filters ; Check if MTU was exceeded cmp pppslip_tX-frame_maxed,0 ;is the frame size too big? jz #past_the__frame_error ;ERROR: frame size too big. Data up to max frame size has been xmitted.

inc pppslip_tx_exceeded_m tu_count j mp #prep_for_landi n g #past_the_frame_error:

inc pppslip__tx_frame_count ;another valid frame #prep_for_landing :

<td> mov test jz xor</td><td> Tx_data_state,OFFSET Transmit—Idle State msg_type, config_at_data #ppp_actual_data msg_type,config_at_data</td>

#ppp_actual_data:

WO 96/41434

PCT/US96/09661

CA 02222151 1997-11-25

<td> mov</td><td> ax ,Nwbus_Frame_Ptr</td><td> ;address of buffer to deallocate</td>

<td> call</td><td> _Deallocate_Rx_Buffer</td><td></td>

<td> call</td><td> pb_rx_done</td><td></td>

<td> mov</td><td> a_data_frame,0</td><td> ; reset</td>

pop si stc ret #ppp_move_tx_data:

<td> mov</td><td> bx,ss:t_storejptr</td><td></td>

<td> sub</td><td> bx,ss:t_load_ptr</td><td></td>

<td> jns</td><td> #ppp_tmd_over</td><td></td>

<td> add</td><td> bx,tc buflen</td><td></td>

<td colspan="2"> #ppp_tmd_over:</td><td></td>

<td> cmp</td><td> bx,tc_buflen-10</td><td> ;check if too many bytes for buffer</td>

<td> jae</td><td> #ppp_tmd_ret</td><td></td>

<td> mov</td><td> al, [si]</td><td> ;get data byte</td>

<td> push</td><td> si</td><td></td>

<td> push</td><td> ex</td><td></td>

<td> call</td><td> PB_input_vector</td><td> ;put byte onto TC buffer</td>

<td> pop</td><td> ex</td><td></td>

<td> ΡθΡ</td><td> si</td><td></td>

<td> inc</td><td> si</td><td></td>

<td> mov</td><td> L_Load__Ptr,si</td><td> ; update pointer</td>

<td> inc</td><td> ex</td><td></td>

<td> cmp</td><td> cx,20h</td><td> ;data pump may need processor</td>

<td> jle</td><td> #ppp_check_for_rnore_data</td><td></td>

#ppp_tmd_ret: pop si stc ret ppp_transmit_tx_data endp ppp_tx_appl

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 41 9k PPP_Transmit_tx_data eventually calls the function whose address is stored at application_tx_state. Instead of the * address of routine x_25_tx_appl, application__tx_—state is setup with this routine’s address. X__25_tx_appl ignores, strips, or appends control chars, then assumes the message terminates. This does

This routine replaces then appends certain characters, and it not assume that such characters terminate the message.

* routine examines one byte of data (in register AL) and puts that byte (or PPPESC & translation) into TC buffer. It keeps track of the pre-translation frame size and limits it to the MTU size. It computes the FCS, assuming it was was previously initialized. It does the following translation: <PPP_FLAG> <PPP_ESC>

<(char<20h) && (flagged in accm)>

* *

* *

* *

* *

* *

*

20h> 20h>

<PPP_ESC> <PPP_FLAG * <PPP ESC > <PPP_ESC = > <PPP ESO <char ·* ·* ·* • ft >

·* •9k •* • * •5k •9K •* • sk

20h>

» . * * φ * »k * * * * * * * * * * * * * * * * * * 9k * sk * *k * * * >k * * * * * * * * * * * * * * * * * * * * ** 9k * 9k * * 9k * * * * * 9k *

5k9k9k>k ppp_tx_appl push push pop ds

NUBUS_RAM ds proc near increment counter, if not over the mtu limit mov cmp jns inc mov bx,pppslip_tx_char_count bx,pppslip_mtu #ppp__tx_max_frame_exceeded ;jump if maxed out bx pppslip_tx_char_count,bx ;update counter ;update FCS with this char ;AL=data,DX=Initial CRC Value; Upon Return: DX = CRC16 mov call mov dx,ppp_tx_fcs ;al has data byte ppp_generate_crc ; call generate_crc 16 ppp_tx_fcs,dx

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

<td> test jz</td><td> al,0E0h #ppp_tx_accm</td><td> ;accm size, 32 bytes</td>

<td> cmp je</td><td colspan="2"> al,PPP_ESC ;check for translatable chars #ppp_tx_translate_esc</td>

<td> cmp je</td><td> al,PPP_FLAG #ppp_tx_translate_flag</td><td></td>

<td> cmp je</td><td> al,ASCII_DELETE #ppp_tx_tran sl_delete</td><td></td>

#ppp_tx_al_char :

call store_tx_char #ppp_tx_appl_fini sh : pop ds ret ;current char is in al #ppp_tx_max_frame-exceeded :

mov pppslip_tx_frame_maxed,l ;nonzero if overflow jmp #ppp_tx_appl_finish #ppp_tx_accm:

mov bx,offset ppp_tx_accm ;al is xlat test jz &lt; 20h, use as index

[bx] al,20h #ppp_tx_al_char into table ;al gets byte from pre-defined table ;is bit set?

;jump if char is not flagged jmp #ppp_tx_translate ;al has translated char #ppp_tx_transl_delete:

<td rowspan="2"> cmp je</td><td colspan="2"> ppp_tX-delete_tran si, 0</td>

<td> #ppp_tx_al_char</td><td> ;jump if DELETE is not to be translated</td>

<td> xor</td><td> al,20h</td><td> translate DELETE</td>

<td> jmp</td><td> #ppp-tx_translate</td><td> ;al has translated char</td>

#ppp_tx_translate_esc :

CA 02222151 1997-11-25

WO 96/41434

PCT/ÜS96/09661

- 43 mov al,PPP_ESC_EXOR_20H jmp #pppj:x_translate ;al has translated char #ppp__tx_translate_flag:

mov al,PPP_FLAG_EXOR_20H ;;jmp #ppp_tx_translate ;al has translated char

<td colspan="3"> #ppp_tx_translate:</td>

<td></td><td> push</td><td> ax</td>

<td> 10</td><td> mov</td><td> al,PPP_ESC</td>

<td></td><td> call</td><td> store_tx_char</td>

<td></td><td> POP</td><td> ax</td>

<td></td><td> call</td><td> store_tx_char</td>

<td></td><td> pop</td><td> ds</td>

<td> 15</td><td> ret</td><td></td>

ppp_tx_appl ;save translated char ;xmit 1st char, ie. PPPESC ;get 2nd char to xmit ;xmit 2nd char en dp

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 44 SUPRX.S . ******************************************************************** « ****

<td> .* .* .* J .* .* S .* 5 .* J ·* 9 .* 9 ·* 9 ·* ί</td><td> slip_rx_appl_start * * This routine’s address is put into application_rx_state when * all chars are to be ignored except for the SLIP_END char, which * indicates the start of a new SLIP frame. This routine is called * with each incoming byte, in register AL. * * When the first SLIP_END char is received, application_rx_state * gets siip_rx_apprs address. Slip_rx_appl will then be called * for each byte instead of this routine. Slip_rx_appl cannot * handle the first SLIPJEND char because it assumes that when *</td>

<td> .* 5 .* 9</td><td> it receives a SLIPJEND char, everything before it was a frame, * ie. if the data is: &lt;garbage&gt; &lt;SLIP_END&gt; &lt;data&gt; &lt; SLIP_END&gt; *</td>

<td> .* 9 ·*</td><td> &lt; garbage&gt; would be interpreted as a frame. * *</td>

?

. ******************************************************************** ?

****

<td colspan="3"> Public Slip_rx_appl_start</td>

<td> slip_rx_appl</td><td> _start proc</td><td> near</td>

<td> push</td><td> ds</td><td></td>

<td> push</td><td> NUBUS_RAM</td><td></td>

<td> pop</td><td> ds</td><td></td>

<td> call</td><td> chk rx timer</td><td> ;reset interchar timer</td>

<td> cmp</td><td> al, SLIPJEND</td><td></td>

<td> jne</td><td> #sras_exit</td><td> ;jump if not the starting frame char</td>

;This is start of the first SLIP frame, discard framing char, call ppp_slip_rx_framejnit ;reset variables for next frame ;Now call slip_rx_appl, not slip_rx_appl_start, when a char comes in mov application_rx_state,offset slip_rx_appl ;Set up timers call chk rx timer ;reset interchar timer

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 45 cmp X25_Timer_Status,X25_Timer_OFF_Implemented jne #sras_exit mov X25_Timer_Status,X25_Timer_ON #sras_exit: pop ds ret slip_rx_appl_start endp ************* * **** ************* **** ·* ·* ·* ·* »

·* ♦ * »

·* ·* ·* .* ·* .* .* .* .* .* .* ·* ·* **** *

* This routine’s address is stored at application_rx_state, * which is called for each incoming byte (it is similar to routine x_25_rx_appl).

slip_rx_appl * This routine checks one byte of incoming data. That byte is in register AL. It checks for SLIP_END, SLIP_ESC, invalid frame size, and if the rest of the frame should be ignored because the forward timer expired. When appropriate, the incoming char is put into the RC buffer using routine store_rx_char. The maximum frame size includes translational chars. * *

The translation done here is:

slip_rx_appl push push pop proc ds

NUBUS_RAM ds near *

* *

* *

*

CA 02222151 1997-11-25

WO 96/41434

PCT7US96/09661

- 46 ;; CHECK TIMERS call chk_rx_timer ; reset interchar timer ;;The PPP/SLIP forward timer implementation requirement is that ;;when the forward timer expires before the end of frame char, ;;what has already been received is forwarded to the Gateway and ;;all subsequent chars upto the end of frame char are discarded.

;Tum on forward timer, if so enabled cmp X25_Timer_S tatus, X2 5 _T i mer_OFF_I m piemen ted jne #slip_timer_status mov X25__Timer__Status,X25_Timer_ON #slip_timer_status:

;; END OF FRAME?;;

;; if (char == SLIPJEND) ”;;

;; if (buffer is not empty);;

; ; tx_state | = Recv_End_of_Data_Msg ; ;

; ; return; ;

cmp al, SLIPJEND je #char_is_slip_end ;jump if framing char ;; INCREMENT COUNTER, CHECK MTU ? ? ? ?

;; if (++slip_rxjrame__count > mtu) ;;

;; set error status ;;

push ax inc slip_rx_frame_count

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

<td></td><td> - 47 -</td><td></td>

<td> mov</td><td> ax,slip_rx_frame_count</td><td></td>

<td> cmp</td><td> pppslip_mtu,ax</td><td></td>

<td> js</td><td> #slip_too_many__chars</td><td> ;jump if frame</td>

<td> #siip_size_is_</td><td> ok:</td><td></td>

<td> pop</td><td> ax</td><td></td>

size is not OK ;; TRANSLATE & STORE ESCAPED CHAR » ’> >

;; if (pppslip_rx_esc_rcvd);;

;; pppslip_rx__esc_rcvd — 0;;;

;; if (char = = SLIPJESC_END) ;;

mov al,SLIP_END ;; else if (char == SL1P_ESC_ESC)

<td></td><td> mov al,SLÏP ESC</td><td> &gt; 3</td>

<td> 9 3</td><td> /* else protocol violation,</td><td> *! ;;</td>

<td> 9 9</td><td> /* do what RFC1055</td><td> does, */ ;;</td>

<td> 9 9</td><td> /* stuff it in anyway</td><td> */ .. ' 9 &gt;</td>

<td> 3 3 3 J</td><td> store char</td><td> 5 5 &gt; &gt;</td>

<td> 33</td><td> return</td><td> ? J</td>

<td> 3399393</td><td> 3999991999933993333333333999333 333 3</td><td></td>

<td> cmp</td><td> pppslip._rx esc rcvd,0</td><td></td>

<td> je</td><td> #prev char not slip esc</td><td> jump if previous</td>

<td> SLIPJESC</td><td></td><td></td>

<td> mov</td><td> pppslip rx esc rcvd,0</td><td></td>

<td> cmp</td><td> al,SLIP_ESC_END</td><td></td>

<td> jne</td><td> #slip_esc_esc_test</td><td></td>

<td> mov</td><td> al,SLIP_END</td><td> ;replacement char</td>

<td> jmp</td><td> #slip_rx_store_char</td><td></td>

char was not

<td colspan="2"> #slip_esc_esc_test:</td>

<td> cmp</td><td> al,SLIP_ESC_ESC</td>

<td> jne</td><td> #slip_rx_store_char</td>

<td> mov</td><td> al,SLIP_ESC ;replacement char</td>

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 48 j mp #slip__rx__store_char #prev_char__not_slip_esc:

HJ J>5>5

<td colspan="2"> CHECK FOR ESCAPE, ELSE STORE</td>

<td> if (char = = SLIP_ESC)</td><td> ?, ? &gt;</td>

<td> pppslip_rx_esc_rcvd</td><td> = 1; ;;</td>

<td> return</td><td> 5 5</td>

<td> else</td><td> ? ?</td>

<td> store char</td><td> 5 ·&gt;</td>

<td> return</td><td> f 5</td>

, J5 > ) n > Ό ) I 1 t 51 1 cmp al,SLIPJESC j e #slip_esc_recei ved #slip_rx_store_char:

<td> inc</td><td> pppslip__rc__char_count</td>

<td> call</td><td> store_rx__char</td>

<td> pop</td><td> ds</td>

<td> ret</td><td></td>

;char is already in register al #slip_esc_received :

mov pppslip_rx_esc_rcvd, 1 pop ds ret ;; END OF FRAME &amp; ERROR CONDITIONS ;;

>,,nJn»nnn,i»nnHHiH»55nj5) ;This is end of frame, dispatch data to API #char_is_slip_end:

cmp pppslip_rc_char_coun t, 0 j e #slip_exit__frame_en d ;jump if empty frame

CA 02222151 1997-11-25

WO 96/41434 PCT/US96/09661

- 49 mov event_occurred, P AP_RS_C OD_END_OF_D ATA ;Recv_End_of_DataJMsg

<td> call jc</td><td> load_allocation_b uffer #slip_trash_data ;if pBus full, kill this PPP frame</td>

#slip__this_frame_is_over:

<td> test jz mov</td><td> X25_Timer_S tatus, X25_Ti mer_ON #slip_aint_no_forward_timer X25_Timer_Status,X25_Timer_OFF_Irnplernented</td>

#slip_aint_no_forward_timer;

<td> and and</td><td> tx_statel ,not Recv_forward_timeout_reached tx_statel ,not Recv_Interchar_timeout_reached</td>

frame end:

<td> call POP ret</td><td> ppp_slip_rx_frame_init ;reset variables for next frame ds</td>

;Throw out data in RC buffer and any that overflowed to pbus #slip__trash_data:

;clear out RC buffer

<td> push mov mov pop mov jmp</td><td> si si,ss:r_Joad_ptr ss:r_store_ptr,si si buf_cur_allocated,0 ; forget about overflowed data #slip_this_frame_is_over</td>

;This could be middle of frame, issue API error, trash data #slip__too_many_chars :

<td> Pop mov</td><td> ax application_rx_state,offset slipjrx appl start</td>

<td> mov or or ;mov j^mP</td><td> application_rx_state,offset slip_rx_appl_start tx_state 1, (Recv__Data_Exceeded__MTU) ss:packet_processing,active jthis activates tx_repiy_state buf_cur_allocated,0 ; forget about overflowed data #slip_trash_data ; #slip_this_frame_is__over</td>

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

- 50 slip_rx_appl endp

SLIPTX.S . ******************************************************************** **** .* »

.* >

.* ?

.* j

.* ?

·* »

.* »

.* ♦* »

♦ * >

.* »

.* ,

.*

J .* ·* i

• * j

.* ?

·* ?

* *

When raw data for one SLIP frame is ready, routine ctrlw_data puts this routine’s address into tx_data— state. The state * machine then executes this routine.

slip_transmit_tx_data * to *

This routine starts a SLIP frame transmission to the remote modem with a SLIP_END char. It then uses pb_jnput_vector do async char mapping on the data byte by byte, which if online will eventually call slip_tx_appl. It then appends a SLIP_END char to the end of the frame. Routine slip_tx_appl will keep track of the total size of the frame, including SLIP_ESC map chars if variable pppslip_tx_char_count is initialized here.

*

This routine is based on routine transmit_tx_data. It will transmit 20h chars at a time, then release control to give some processing time to the data pump, then rely on the state machine to come back to SLIP_Transmit_tx_Data—translate to do an additional 20h chars. The carry bit is set on each return. * * . *********************** ****** *************************************** ? ****

Public Slip_transmit_tx_data slip_transmit_tx_data ;Initialize frame variables mov mov mov call proc near pppslip-tx_char_count,0 ;number of chars transmitted pppslip_tx_frame_maxed,0 ; frame size overflow indicator al,SLIP_END ;COh store_tx_char ;write directly to TC buffer, bypassing filters

CA 02222151 1997-11-25

WO 96/41434

PCT/US96I09661

<td> mov</td><td> Tx_data_state,offset SLIP_Transmit_tx_Data_translate</td>

<td colspan="2"> SLIP Transmit_tx Data translate:</td>

<td> push</td><td> si</td>

<td> mov</td><td> cx,0</td>

<td> #slip_check_</td><td> for_more_data:</td>

<td> mov</td><td> si,L_Load_Ptr</td>

<td> cmp</td><td> si,L_store_Ptr</td>

<td> jne</td><td> #slip_move_tx_data ;jump if Gateway pkt has data</td>

<td> ;End</td><td> of frame</td>

<td> mov</td><td> al,SLIP__END ;C0h</td>

<td> call</td><td> store__tx__char ;write directly to TC buffer, bypassing filters</td>

<td colspan="2"> ; Check if MTU was exceeded</td>

<td> cmp</td><td> pppslip_tx_frame_maxed,0 ;is the frame size too big?</td>

<td> jz</td><td> #past_the_frame_error</td>

<td colspan="2"> ;ERROR: frame size too big. Data up to max frame size has been xmitted</td>

<td> inc</td><td> pppslip_tx_exceeded_mtu_count</td>

<td> jmp</td><td> #prep_for_landing</td>

<td colspan="2"> #pastjhe__frame_error:</td>

<td> inc</td><td> pppslip__tx_frame_count ;another valid frame</td>

<td colspan="2"> #prep_for_landing:</td>

<td> mov</td><td> Tx_data_state, OF FS ET Tran smi t ld 1 eS tate</td>

<td> test</td><td> msg_type,config_at_data</td>

<td> jz</td><td> #slip_actual_data</td>

<td> xor</td><td> msg_type, config_at_data</td>

<td> #slip_actual_</td><td> data:</td>

<td> mov</td><td> ax,Nwbus_Frame_Ptr ;address of buffer to deallocate</td>

<td> call</td><td> —Deallocate—RX-Buffer</td>

<td> call</td><td> pb_rx_done</td>

<td> mov</td><td> a_data_frame, 0 ; reset</td>

<td> pop</td><td> si</td>

<td> stc</td><td></td>

<td> ret</td><td></td>

#siip_move_tx_data:

CA 02222151 1997-11-25

WO 96/41434

PCT/US96/09661

<td colspan="3"> - 52 -</td>

<td> mov</td><td> bx,ss:t__store_ptr</td><td></td>

<td> sub</td><td> bx, ss : t__load-ptr</td><td></td>

<td> jns</td><td> #slip_tmd_over</td><td></td>

<td> add</td><td> bx,tc_buflen</td><td></td>

<td colspan="2"> tmd over:</td><td></td>

<td> cmp</td><td> bx,tc_bufIen-10</td><td> ; check if too many bytes for buffer</td>

<td> jae</td><td> #slip_tmd_ret</td><td></td>

<td> mov</td><td> al_s[si]</td><td> ;get data byte</td>

<td> push</td><td> si</td><td></td>

<td> push</td><td> ex</td><td></td>

<td> call</td><td> PB_input_vector</td><td> ;put byte onto TC buffer</td>

<td> POP</td><td> ex</td><td></td>

<td> ΡθΡ</td><td> si</td><td></td>

<td> inc</td><td> si</td><td></td>

<td> mov</td><td> L_Load_Ptr,si</td><td> ; update pointer</td>

<td> inc</td><td> ex</td><td></td>

<td> cmp</td><td> cx,20h</td><td> ;data pump may need processor</td>

<td> jle</td><td> #slip_check_for-</td><td> more_data</td>

#slip__tmd_ret: pop si stc ret slip_transmit_tx_data endp .»ic **************************************************** *************** ****

<td> .* .*</td><td> slip_tx_appl * *</td>

<td> 5 ·* .* s .* , .* 9 -* 9 .* 9 ·* 9 • *</td><td> SLIP Transmit tx_data eventually calls the function whose * address is stored at application_tx_state. Instead of the * address of routine x„25_tx__appl, application_tx_state is setup * with this routine’s address. X_25_tx_appl ignores, strips, or * appends control chars, then assumes the message terminates. * This routine replaces then appends certain characters, and it * does not assume that such characters terminate the message. * *</td>

<td> 9 ·* 9 -* 9</td><td> This routine examines one byte of data (in register AL) and * puts that byte (or SLIP_ESC and translation) into TC buffer. *</td>

CA 02222151 1997-11-25

WO 96/41434

PCT/ÜS96/09661

- 53 .* .* ?

.*

-* .*

It keeps track of the post-translation frame size and limits * it to the MTU size. It does the following translation: * <SLIP_END> => <SLIP ESC> < SLIP_ESC_END > * <SLIP_ESC> = > <SLIP_ESC> <SLIP_ESCJESC> * *

. ** #*$$*♦**♦*#*****#♦***** ******************* ********** ************** 9 **** slip_tx_appl push push pop proc ds

NUBUS-RAM ds near increment counter, if not over the mtu limit mov bx,pppslip_tx_char_count cmp bx, pppslip_mtu jns #slip_tx_max_frame_exceeded ;jump if maxed out inc bx mov pppslip_tx__char_count,bx ;update counter cmp al,SLIP_ESC ;check for translatable chars je #slip_tx_translate_esc cmp al,SLIP_END je #slip_tx_translate_end call store_tx_char ; current char is in al #slip_tx_appl-finish:

pop ds ret #slip_tx__max_frame_exceeded :

mov pppslip_tx_frame_maxed,l ; nonzero if overflow j mp #slip_tx_appl_fmish #slip_tx_translate_esc:

push ax ;save original ax value (required?) mov al,SLIP_ESC_ESC push ax ;save 2nd char we want xmitted j mp #slip_tx_translate #slip_tx_translate_end:

CA 02222151 1997-11-25

WO 96/41434

PCT7US96/09661

<td> push</td><td> ax</td><td> ;save original ax value (required?)</td>

<td> mov</td><td> al,SLIP_ESC_END</td><td></td>

<td> push</td><td> ax</td><td> ;save 2nd char we want xmitted</td>

<td colspan="2"> #slip__tx_tran slate:</td><td></td>

<td> mov</td><td> aI,SLIP_ESC</td><td></td>

<td> call</td><td> store__tx_char</td><td> ;xmit 1st char, ie. SLIP_ESC</td>

<td> pop</td><td> ax</td><td> ;get 2nd char to xmit</td>

<td colspan="2"> ; increment counter again,</td><td> if not over the mtu limit</td>

<td> cmp</td><td> bx,pppslip_mtu</td><td></td>

<td> jns</td><td colspan="2"> #slip_tx_translate__finish ;jump if maxed out</td>

<td> inc</td><td> bx</td><td></td>

<td> mov</td><td colspan="2"> pppslip_tx_char_count,bx</td>

<td> call</td><td> store_tx_char</td><td> ;xmit 2nd char</td>

#slip_tx_translate_finish :

<td colspan="2"> pop ax</td><td> ; restore ax</td>

<td> pop ds</td><td></td><td></td>

<td> ret</td><td></td><td></td>

<td> slip_tx_appl</td><td> endp</td><td></td>

It will be appreciated from the foregoing detailed description that many variations and modifications may be made without departure from the true spirit and scope of the invention. This true spirit and scope is defined by the appended claims, interpreted in light of the forgoing specification.