From jneely Tue Jan 18 09:27:02 1994 Received: by Joyce-Perkins.tenet.edu id AA23803 (5.65c/IDA-1.4.4 for gjones); Tue, 18 Jan 1994 09:21:57 -0600 From: Jim Neely Message-Id: <199401181521.AA23803@Joyce-Perkins.tenet.edu> Subject: LAPA To: gjones (Greg Jones) Date: Tue, 18 Jan 94 9:21:56 CST Status: OR AX.25 Link Access Protocol - Amateur Packet Radio Version 2.2 July 1993 By William A. Beech, NJ7P Douglas E. Nielsen, N7LEM Jack Taylor, N7OO This protocol is a guide to aid in the design and use of amateur packet radio systems. Its purpose is to ensure link-layer compatibility between stations. The existence of this protocol does not preclude anyone from designing, marketing or using products, processes or procedures not conforming to the protocol. This protocol is subject to periodic review. Packet operators are encouraged to use the latest edition. Portions Copyright (c) 1984, 1993 by The American Radio Relay League, Inc. Packet radio has linked many thousands of amateur radio stations together directly and by the packet network. The packet network has grown from a series of digipeaters to a full-blown network consisting of network nodes of several types. The network spans the whole world with HF gateways, Internet gateways and satellite links. This progress has happened since the publication of version 2.0 of the AX.25 protocol in 1984 Terry L. Fox, WB4JFI. A major effort towards updating version 2.0 was published in the 7th Computer Networking Conference by Eric Scace, K3NA, in 1988. Additional portions of this update were handed out at the conference. Eric's work is included in this update of the standard, together with protocol improvements that will aid networking and HF users. This document is a revision of the AX.25 Version 2.0 Protocol Stan- dard found on the Internet and available from the American Radio Relay Lea- gue. The authors of this new version took exception to the use of AX.25; none of the Layer 3 protocol has been used. We have changed these references to LAPA to signify the Link Access Protocol - Amateur, a data-link (Layer 2) protocol. The authors wish to thank Eric Gustafson, N7CL, and Lyle Johnson, WA7GXD, for providing the material and encouragement during this development. Preface Note: This preface is not part of the protocol. This is the second edition of the LAPA Amateur Packet-Radio Link- Layer Protocol (Version 2.2, _______ 1994) published by the American Radio Relay League (ARRL). It was approved by the Tucson Amateur Packet Radio Corporation (TAPR) Board of Directors in ____, 1994. It was approved by the ARRL Board of Directors in _____, 1994. The ARRL was designated the inter- national clearinghouse for information relating to packet radio, with a view towards encouraging common standards and regulations on behalf of the Inter- national Amateur Radio Union (IARU) by their Administrative Council at their meeting in Paris during July, 1984. This document defines a protocol used between two amateur radio stations in a point-to-point or networked communications environment. The protocol specifies only link layer and physical layer functions. Other than certain interface requirements to and from other layers, this protocol is not meant to specify any upper-layer protocol. This protocol recognizes that the amateur radio operating environment is unique and takes this into consideration. Since the publication of the first edition of the standard, an amateur radio network has evolved. This development has negated the need for the digipeater mode of operation. For this reason, the proposed new specification limits digipeating to a maximum of two hops or separate radio links. This document goes a step beyond most international standards by making the System Description Language (SDL), included as Appendix C, the basis for the standard. Any discrepancies between the verbal description of the standard in the body of this document and the SDL will be resolved in favor of the SDL. The SDL is a much clearer description of the protocol than the verbal text. A version of this protocol developed from the SDL in the "C" language is available from the authors. Table of Contents: Description Page Preface 4 1. General 6 2. Concepts and Terminology 6 3. Frame Structure 10 4. Elements of Procedure and Format of Fields 19 5. Elements of Layer-to-Layer Communications 35 6. Description of LAPA Procedures 39 Appendix A Glossary A-1 Appendix B References B-1 Appendix C-1 Introduction to System Description Language C-1-1 Appendix C-2-A Simplex Physical State Machine SDL C-2-A-1 Appendix C-2-B Duplex Physical State Machine SDL C-2-B-1 Appendix C-3 Link Multiplexor State Machine SDL C-3-1 Appendix C-4 Data-Link State Machine SDL C-4-1 Appendix C-5 Management Data-Link State Machine SDL C-5-1 Appendix C-6 Segmenter State Machine SDL C-6-1 Appendix D Data-Link Services D-1 Appendix E Implementer's Notes E-1 1. General It is necessary to define a protocol that can accept and deliver data over a variety of communications links to provide a mechanism for the reliable transport of data between two signaling terminals. The LAPA Link- Layer Protocol provides this service, independent of any upper layer that may or may not exist. This protocol conforms to ISO IS 3309, 4335 and 7809 High-Level Data Link Control (HDLC) and uses terminology found in these documents. It also follows the principles of CCITT Recommendation Q.920 and Q.921 (LAP-D) in the use of multiple links distinguished by the address field, on a single shared channel. Parameter negotiation was extracted from ISO IS 8885. The data- link service definitions were extracted from ISO IS 8886. As defined, this protocol works equally well in either half- or full- duplex amateur radio environments. This protocol has been improved for operation over less-reliable HF circuits. This protocol works equally well for direct connections between two individual amateur packet radio stations, or between an individual station and a multi-port controller. This protocol permits the establishment of more than one link-layer connection per device, if the device is so capable. This protocol does not prohibit self-connections. A self-connection occurs when a device establishes a link to itself using its own address for both the source and destination of the frame. Most link-layer protocols assume that one primary (or master) device (generally called a DCE, or Data Circuit Terminating Equipment), is connected to one or more secondary (or slave) device(s) (usually called a DTE, or Data Terminating Equipment). This type of unbalanced operation is not practical in a shared RF amateur radio environment. Instead, LAPA assumes that both ends of the link are of the same class, thereby eliminating the two different classes of devices. In this protocol specification, the expression "Terminal Node Controller" (TNC) describes the balanced type of device found in amateur packet radio. Other standards refer to these peer entities as DXEs. 2. Concepts and Terminology 2.1. Basic Concepts The basic structuring technique in the OSI reference model is layer- ing. According to this technique, communication among application processes is viewed as being logically partitioned into an ordered set of layers repre- sented in a vertical sequence as shown in Figure 2.1. Each layer provides a Service Access Point (SAP) for interface to the next higher layer. Note that any layer may be a null, where no function or code is provided. This is the case in the current TNC-2s where there only Layer 1, 2 and 7 are provided. This is the minimum configuration required for reliable communications. Layer Function ------------------ 7 | Application | ------------------ 6 | Presentation | ------------------ 5 | Session | ------------------ 4 | Transport | ------------------ 3 | Network | ------------------ 2 | Data Link | ------------------ 1 | Physical | ------------------ Fig. 2.1 Seven Layer OSI Model 2.2. LAPA Model The two lower layers, data link and physical, can be further sub- divided into several distinct finite state machines as shown in Figure 2.2. This example shows a single link to the radio port. Layer Function(s) --------------------(DLSAP)----------- | Segmenter | | |-----------| Management | Data | Data Link | Data Link | Link (2) | | | |------------------------| | Link Multiplexor | -------------------------------------| | Physical | Physical (1)|------------------------| | Silicon/Radio | -------------------------------------- Fig. 2.2 LAPA Finite State Machine Model (Single Link) Figure 2.3 shows an example of multiple links to the radio port. The link multiplexor described in this standard multiplexes multiple data-link connections into one physical connection. A separate data-link machine must be provided for each connection allowed by the implementation. Layer Function(s) --------------------(DLSAP)----------- ---------(DLSAP)---------- | Segmenter | | | Segmenter | |... |-----------| Management | |-----------| Management |... Data | Data Link | Data Link | | Data Link | Data Link |... Link (2) | | | | | |... --------------------------------------------------------- | Link Multiplexor | --------------------------------------------------------------------| | Physical | Physical (1)--------------------------------------------------------| | Silicon/Radio | --------------------------------------------------------------------- Fig. 2.3 LAPA Finite State Machine Model (Multiple Stream) 2.3 Data-Link Service Access Point A Data-Link Service Access Point (DLSAP) is the point at which the data-link layer provides services to Layer 3. One or more data-link connec- tions endpoint(s) is associated with each DLSAP Entities exist in each layer. Entities may be the Link Multiplexor, Data Link, Management Data Link or Segmenter. Entities in the same layer, but in different systems that must exchange information to achieve a common objective, are called "peer entities". Entities in adjacent layers interact through their common boundary. The services provided by the data-link layer are the combination of the services and functions provided by both the data- link layer and the physical layer. Cooperation between data-link layer entities is governed by a peer- to-peer protocol specific to the layer. For information to be exchanged between two Layer 3 entities, an association must be established between the entities through the data-link layer using the LAPA protocol. This associa- tion is called a data-link connection. Data-link connections are provided by the data-link layer between two or more DLSAPs. Layer 3 requests services from the data-link layer via service primi- tives. This also applies to the interaction between the data-link layer and the physical layer. In an abstract way, the primitives represent the logical exchange of information and control between the data-link layer and adjacent layers. They do not specify or constrain implementation. The primitives that are exchanged between the data-link layer and adjacent layers are of the following four types: a) REQUEST primitive type: used by a higher layer to request a service from the next lower layer. b) INDICATION primitive type: used by a layer to provide a service to notify the next higher layer of any specific activity that is service related. The INDICATION primitive may be the result of an activity of the lower layer related to the primitive type REQUEST at the peer entity. c) RESPONSE primitive type: used by a layer to acknowledge receipt from a lower layer of the primitive type INDICATION. LAPA does not use the RESPONSE primitive. d) CONFIRM primitive type: used by a layer to provide the requested service to confirm that the activity has been completed. Here is an example of the use of the four primitive types in conjunc- tion with the connect primitive. Station A DLSAP DLSAP Station B DL-CONNECT Request -->| | | |--> DL-CONNECT Indication | |<-- DL-CONNECT Response DL-CONNECT Confirm <--| | Figure 2.4 Example Use of Primitive Types 2.4. Segmenter The Segmenter State Machine accepts input from the higher layer through the DLSAP. If the unit of data to be sent exceeds the limits of a LAPA I or UI frame, the segmenter breaks the unit down into smaller segments for transmission. Incoming segments are reassembled for delivery to the higher layer and passed through the DLSAP. The segmenter passes all other signals unchanged. One segmenter exists per data link. Because a single piece of equip- ment may have multiple data links in operation simultaneously (e.g., to support multiple higher-layer applications), there can be multiple, indepen- dently operating segmenters within the equipment. 2.5. Data Link The Data-link State Machine is the heart of the LAPA protocol. The Data-link State Machine provides all logic necessary to establish and release connections between two stations and to exchange information in a connection- less (i.e., via UI frames) and connection-oriented (i.e., via I frames with recovery procedures) manner. One Data-link State Machine exists per data link. Because a single piece of equipment may have multiple data links in operation simultaneously (e.g., to support multiple higher layer applications), there can be multiple, independently operating data-link machines within the equipment. 2.6. Management Data Link The Management Data-link State Machine provides for the parameter negotiation of the LAPA protocol. The Management Data-link State Machine provides all logic necessary to negotiate operating parameters between two stations. One Management Data-link State Machine exists per data link. Because a single piece of equipment may have multiple data links in operation simul- taneously (e.g., to support multiple higher layer applications), there can be multiple, independently operating management data-link machines within the equipment. 2.7. Link Multiplexor The Link Multiplexor State Machine allows one or more data links to share the same physical (radio) channel. The Link Multiplexor State Machine provides the logic necessary to give each data link an opportunity to use the channel, according to the rotation algorithm embedded within the link multi- plexor. One Link Multiplexor State Machine exists per physical channel. If a single piece of equipment has multiple physical channels operating simultan- eously, then an independently operating Link Multiplexor State Machine exists for each channel. 2.8. Physical The Physical State Machine manipulates the radio transmitter and receiver. One Physical State Machine exists per physical channel. Because different types of radio channel operations are used, the Physical State Machine exists in different forms. Each form hides the pecu- liar characteristics of each radio channel from the higher layer state mach- ines. Two Physical State Machines have been defined in this standard: sim- plex and full duplex Physical State Machines. 2.9. System Description Language Each of the above finite state machines is described in the State Description Language in Appendix C. 3. Frame Structure Link layer packet radio transmissions are sent in small blocks of data, called frames. There are three general types of LAPA frames: The Information frame (I frame); The Supervisory frame (S frame); The Unnumbered frame (U frame). Each frame is made up of several smaller groups, called fields. Fig. 3.1 shows the three basic types of frames. Note that the first bit to be transmitted is on the left side. ------------------------------------------------------------------- | Flag | Address | Control | Info. * | FCS | Flag | |----------+------------+---------+----------+----------+---------| | 01111110 |112/224 Bits|8/16 Bits| N*8 Bits | 16 Bits |01111110 | -------------------------------------------------------------------- Fig. 3.1A -- U and S frame construction * Note: Info field only exists in certain frames. See 4.4.3. -------------------------------------------------------------------------- | Flag | Address | Control | PID | Info. | FCS | Flag | |----------+------------+---------+-------+----------+--------+----------| | 01111110 |112/224 Bits|8/16 Bits| 8 Bits| N*8 Bits | 16 Bits| 01111110 | -------------------------------------------------------------------------- Fig. 3.1B -- Information frame construction Each field is made up of an integral number of octets and serves the specific function outlined below. All fields are transmitted low-order bit first except the FCS, which is transmitted bit 15 first. 3.1. Flag Field The flag field is one octet long. Because the flag delimits frames, it occurs at both the beginning and end of each frame. Two frames may share one flag, that would denote the end of the first frame and the start of the next frame. A flag consists of a zero followed by six ones followed by another zero, or 01111110 (7E hex). As a result of bit stuffing (see 3.6), this sequence is not allowed to occur anywhere else inside a complete frame. 3.2. Address Field The address field identifies both the source of the frame and its destination. In addition, the address field contains the command/response information and facilities for Layer 2 repeater operation. The encoding of the address field is described in 3.12. 3.3. Control Field The control field identifies the type of frame being passed, and controls several attributes of the Layer 2 connection. It is one or two octets in length; its encoding is discussed in paragraph 4. 3.4. PID Field The Protocol Identifier (PID) field appears in information frames (I and UI) only. It identifies the kind of Layer 3 protocol, if any, is in use. The PID itself is not included as part of the octet count of the information field. The encoding of the PID is as follows: --------------------------------- | L3 Type | Bin Data | Hex Data | |---------+----------+----------| | Escape | 11111111 | FF | | No L3 | 11110000 | F0 | | APLP | XX10XXXX | | | APLP | XX01XXXX | | | NetRom | 11001111 | CF | | ARP | 11001101 | CD | | IP | 11001100 | CC | | Segment | 00001000 | 08 | --------------------------------- Figure 3.2 PID Definitions Where: A X indicates all combinations used. Note: All forms of XX11XXXX and XX00XXXX other than those listed above are reserved at this time for future Layer 3 protocols. The assignment of these formats is up to mutual agreement among amateur radio operators. It is recommended that the creators of Layer 3 protocols contact the ARRL for suggested encodings. 3.5. Information Field The information field conveys user data from one end of the link to the other. I fields are allowed in only five types of frames: The I frame; The UI frame; The XID frame; The TEST frame; The FRMR frame. The I field defaults to a length of 256 octets and contains an inte- gral number of octets. These constraints apply prior to the insertion of zero bits as specified in 3.6. Any information in the I field is passed along the link transparently, except for the zero-bit insertion (see 3.6) necessary to prevent flags from accidentally appearing in the I field. 3.6. Bit Stuffing In order to ensure that the flag bit sequence mentioned above does not appear accidentally anywhere else in a frame, the sending station moni- tors the bit sequence for a group of five or more contiguous ONE bits. Any time five contiguous ONE bits are sent, the sending station inserts a ZERO bit after the fifth ONE bit. During frame reception, any time five contigu- ous ONE bits are received, a ZERO bit immediately following five ONE bits is discarded. 3.7. Frame-Check Sequence The Frame-Check Sequence (FCS) is a sixteen-bit number calculated by both the sender and receiver of a frame. It ensures that the frame was not corrupted by the medium passing the frame from the sender to the receiver. The Frame-Check Sequence is calculated in accordance with ISO 3309 (HDLC) Recommendations. 3.8. Order of Bit Transmission With the exception of the FCS field, all fields of an LAPA frame are sent with each octet's least-significant bit first. The FCS is sent most- significant bit first. 3.9. Invalid Frames Any frame consisting of less than 136 bits (including the opening and closing flags), not bounded by opening and closing flags, or not octet align- ed (an integral number of octets), is considered an invalid frame by the link layer. 3.10. Frame Abort If a frame must be prematurely aborted, at least fifteen contiguous ONEs are sent without bit stuffing added. 3.11. Inter-frame Time Fill Whenever it is necessary for a TNC to keep its transmitter on while not actually sending frames, the time between frames should be filled with contiguous flags. 3.12. Address-Field Encoding The address field of all frames consists of a destination, source and (optionally) two Layer 2 repeater subfields. Each subfield consists of an amateur callsign and a Secondary Station Identifier (SSID). The callsign is made up of upper-case alpha and numeric ASCII characters only. The SSID is a four-bit integer that uniquely identifies multiple stations using the same amateur callsign. The HDLC address field is extended beyond one octet by assigning the least- significant bit of each octet to be an "extension bit". The extension bit of each octet is set to ZERO to indicate the next octet contains more address information, or to ONE, to indicate that this is the last octet of the HDLC address field. To make room for this extension bit, the amateur radio call- sign information is shifted one bit left. 3.12.1. Non-repeater Address-Field Encoding If Layer 2 repeaters are not being used, the address field is encoded as shown in Fig. 3.3. The destination address is the callsign and SSID of the amateur radio station to which the frame is addressed; the source address contains the amateur callsign and SSID of the station that sent the frame. These callsigns are the callsigns of the two ends of a Layer 2 LAPA link only. First Octet Sent ---------------------------------------------------- | Address Field of Frame | |--------------------------------------------------| | Destination Address | Source Address | | Subfield | Subfield | |----------------------+---------------------------| | A1 A2 A3 A4 A5 A6 A7 | A8 A9 A10 A11 A12 A13 A14 | ---------------------------------------------------- Fig. 3.3 -- Non-repeater Address-Field Encoding A1 through A14 are the fourteen octets that make up the two address subfields of the address field. The destination subfield is seven octets long (A1 through A7), and is sent first. This address sequence provides the receivers of frames time to check the destination address subfield to see if the frame is addressed to them while the rest of the frame is being received. The source address subfield is then sent in octets A8 through A14. Both of these subfields are encoded in the same manner, except that the last octet of the address field has the HDLC address extension bit set. The SSID octet at the end of each address subfield (A7 and A14) contains the SSID and the C bit. The SSID octet at the end of each optional Layer 2 repeater address subfield (A21 and A28) contains the SSID and the H bit. The C bits identify command and response frames (see 6.1.2). The H bits indicate that the Layer 2 repeater station has repeated the frame (see 3.12.3). Each SSID octet contains two bits that are reserved for future use. Fig. 3.4 shows a typical LAPA frame in the non-repeater mode of operation. ---------------------------------------- | Octet | ASCII | Bin Data | Hex Data | |-------+--------+----------+----------| | Flag | | 01111110 | 7E | | A1 | N | 10011000 | 98 | | A2 | J | 10010100 | 94 | | A3 | 7 | 01101110 | 6E | | A4 | P | 10100000 | A0 | | A5 | space | 01000000 | 40 | | A6 | space | 01000000 | 40 | | A7 | SSID | 11100000 | E0 | | A8 | N | 10011000 | 98 | | A9 | 7 | 01101110 | 6E | | A10 | L | 10011000 | 98 | | A11 | E | 10001010 | 8A | | A12 | M | 10011010 | 9A | | A13 | space | 01000000 | 40 | | A14 | SSID | 01100001 | 61 | |Control| I | 00111110 | 3E | | PID | none | 11110000 | F0 | | FCS | part 1 | XXXXXXXX | HH | | FCS | part 2 | XXXXXXXX | HH | | Flag | | 01111110 | 7E | |-------+--------+----------+----------| | Bit position 76543210 | ---------------------------------------- Fig. 3.4 -- Non-repeater LAPA frame The frame shown is an I frame, not going through a Layer 2 repeater, from N7LEM (SSID=0) to NJ7P (SSID=0), without a Layer 3 protocol. The P/F bit is set; the receive sequence number (N(R)) is 1; the send sequence number (N(S)) is 7. 3.12.2. Destination Subfield Encoding Fig. 3.5 shows how an amateur callsign is placed in the destination address subfield, occupying octets A1 through A7. ---------------------------------------- | Octet | ASCII | Bin Data | Hex Data | |-------+--------+----------+----------| | A1 | N | 10011000 | 98 | | A2 | J | 10010100 | 94 | | A3 | 7 | 01101110 | 6E | | A4 | P | 10100000 | A0 | | A5 | space | 01000000 | 40 | | A6 | space | 01000000 | 40 | | A7 | SSID | 11100000 | E0 | | A7 | SSID | CRRSSID0 | | |-------+--------+----------+----------| | Bit Position 76543210 | ---------------------------------------- Fig. 3.5 -- Destination Field Encoding Where: 1. The top octet (A1) is the first octet sent, with bit 0 of each octet being the first bit sent, and bit 7 being the last bit sent. 2. The first (low-order or bit 0) bit of each octet is the HDLC address extension bit, set to zero on all but the last octet in the address field, where it is set to one. 3. The bits marked "R" are reserved bits. They may be used in an agreed-upon manner in individual networks. When not implemented, they are set to one. 4. The bit marked "C" is the command/response bit of an LAPA frame, as outlined in 6.1.2. 5. The characters of the callsign are standard seven-bit ASCII (upper case only) placed in the left-most seven bits of the octet to make room for the address extension bit. If the callsign contains fewer than six charac- ters, it is padded with ASCII spaces between the last call sign character and the SSID octet. 6. The 0000 SSID is reserved for the first personal LAPA station. This establishes one standard SSID for "normal" stations to use for the first station. 3.12.3. Source Subfield Encoding Fig. 3.6 shows how an amateur callsign is placed in the destination address subfield, occupying octets A1 through A7. ---------------------------------------- | Octet | ASCII | Bin Data | Hex Data | |-------+--------+----------+----------| | A8 | N | 10011000 | 98 | | A9 | 7 | 01101110 | 6E | | A10 | L | 10011000 | 98 | | A11 | E | 10001010 | 8A | | A12 | M | 10011010 | 9A | | A13 | space | 01000000 | 40 | | A14 | SSID | CRRSSID0 | | |-------+--------+----------+----------| | Bit Position 76543210 | ---------------------------------------- Fig. 3.6 -- Source Field Encoding Where: 1. The top octet (A8) is the first octet sent, with bit 0 of each octet being the first bit sent, and bit 7 being the last bit sent. 2. The first (low-order or bit 0) bit of each octet is the HDLC address extension bit, set to zero on all but the last octet in the address field, where it is set to one. 3. The bits marked "R" are reserved bits. They may be used in an agreed- upon manner in individual networks. When not implemented, they are set to one. 4. The bit marked "C" is the command/response bit of an LA PA frame, as outlined in 6.1.2. 5. The characters of the callsign are standard seven-bit ASCII (upper case only) placed in the leftmost seven bits of the octet to make room for the address extension bit. If the callsign contains fewer than six charac- ters, it is padded with ASCII spaces between the last callsign character and the SSID octet. 6. The 0000 SSID is reserved for the first personal LAPA station. This establishes one standard SSID for "normal" stations to use for the first station. 3.12.4. Layer 2 Repeater Address Encoding Repeater chaining is being phased out; this type of operation belongs at a higher protocol layer. In the interim, to maintain backward compatabil- ity, the number of repeaters is limited to two. If a frame is to go through Layer 2 amateur packet repeater(s), an additional address subfield is appended to the end of the address field. This additional subfield contains the callsign(s) of the repeater(s) to be used. This allows more than one repeater to share the same RF channel. If this subfield exists, the last octet of the source subfield has its address extension bit set to ZERO, indicating that more address-field data follows. The repeater address subfield is encoded in the same manner as the destina- tion and source address subfields, except for the most-significant bit in the last octet, called the "H" bit. The H bit indicates whether a frame has been repeated or not. The H bit is set to ZERO on frames going to a repeater. The repeat- er changes the H bit to ONE before it retransmits the frame. Stations moni- tor and repeat frames that meet the following conditions: The frame is addressed to this station in a repeater address subfield. The H bit in its repeater address subfield is 0. All previous H bits are set to one. Fig. 3.7 shows how the repeater address subfield is encoded. Fig. 3.8 is an example of a complete frame after being repeated. ---------------------------------------- | Octet | ASCII | Bin Data | Hex Data | |-------+--------+----------+----------| | A15 | N | 10011000 | 98 | | A16 | J | 10010100 | 94 | | A17 | 7 | 01101110 | 6E | | A18 | P | 10100000 | A0 | | A19 | space | 01000000 | 40 | | A20 | space | 01000000 | 40 | | A21 | SSID | HRRSSID1 | | |-------+--------+----------+----------| | Bit Position 76543210 | ---------------------------------------- Fig. 3.7 -- Repeater Address Encoding Where: 1. The top octet is the first octet sent, with bit 0 being sent first and bit 7 sent last of each octet. 2. As with the source and destination address subfields discussed above, bit 0 of each octet is the HDLC address extension bit, is set to ZERO on all but the last address octet, where it is set to ONE. 3. The "R" bits are reserved in the same manner as in the source and destination subfields. 4. The "H" bit is the has-been-repeated bit. It is set to ZERO when a frame has not been repeated, and set to ONE by the repeating station when repeated. ---------------------------------------- | Octet | ASCII | Bin Data | Hex Data | |-------+--------+----------+----------| | Flag | | 01111110 | 7E | | A1 | N | 10011000 | 98 | | A2 | J | 10010100 | 94 | | A3 | 7 | 01101110 | 6E | | A4 | P | 10100000 | A0 | | A5 | space | 01000000 | 40 | | A6 | space | 01000000 | 40 | | A7 | SSID | 11100000 | E0 | | A8 | N | 10011000 | 98 | | A9 | 7 | 01101110 | 6E | | A10 | L | 10011000 | 98 | | A11 | E | 10001010 | 8A | | A12 | M | 10011010 | 9A | | A13 | space | 01000000 | 40 | | A14 | SSID | 01100000 | 60 | | A15 | N | 10011000 | 98 | | A16 | 7 | 01101110 | 6E | | A17 | O | 10011110 | 9E | | A18 | O | 10011110 | 9E | | A19 | space | 01000000 | 40 | | A20 | space | 01000000 | 40 | | A21 | SSID | 11100011 | E3 | |Control| I | 00111110 | 3E | | PID | none | 11110000 | F0 | | FCS | part 1 | XXXXXXXX | HH | | FCS | part 2 | XXXXXXXX | HH | | Flag | | 01111110 | 7E | |-------+--------+----------+----------| | Bit position 76543210 | ---------------------------------------- Fig. 3.8 -- LAPA frame in repeater mode The above frame is the same as Fig. 3.3, except for the addition of a repeater address subfield (N7OO, SSID=1). The H bit is set, indicating this frame is from the output of the repeater. 3.12.5. Multiple Repeater Operation The link-layer LAPA protocol allows operation through more than one repeater. Up to two repeaters may be used by extending the repeater address subfield. When there is more than one repeater address, the repeater address immediately following the source address subfield will be considered the address of the first repeater of a multiple-repeater chain. As a frame progresses through a chain of repeaters, each successive repeater will set the H bit (has-been-repeated bit) in its SSID octet, indicating that the frame has been successfully repeated through it. No other changes to the frame are made (except for the necessary recalculation of the FCS). The destination station can determine the route the frame took to reach it by examining the address field and use this path to return frames. The number of repeater addresses is variable. The last repeater address will have the address extension bit of the SSID octet set to ONE indicating the end of the address field. All other address octets will have their address extension bit set to ZERO. Note that various timers (see 6.6.1) may require adjustment to accom- modate the additional delays encountered when a frame must pass through a multiple-repeater chain. 4. Elements of Procedure and Formats of Fields 4.1. General The elements of procedure define the command and response frames used on the LAPA link. Procedures are built from these elements and described in section 6. 4.2. Control-Field Formats The control field identifies the type of frame being sent. The control fields in LAPA use the ISO HDLC control fields for balanced opera- tion. There are three types of control fields: The Information frame (I frame); The Supervisory frame (S frame); The Unnumbered frame (U frame). Fig. 4.1 shows the basic format of the control field associated with these types of frames. The control field can be one or two octets long and may use sequence numbers to maintain link integrity. These sequence numbers may be three-bit (modulo 8) or seven-bit (modulo 128) integers. -------------------------------------------------- | Control-Field | Control-Field Bits | | Type | 7 6 5 | 4 | 3 2 1 0 | |----------------+-----------+---+-----------+---| | I Frame | N(R) | P | N(S) | 0 | |----------------+-----------+---+---------------| | S Frame | N(R) |P/F| S S 0 1 | |----------------+-----------+---+---------------| | U Frame | M M M |P/F| M M 1 1 | -------------------------------------------------- Fig. 4.1A -- Control-field formats (modulo 8) ---------------------------------------------------------------------- | Control-Field | Control-Field Bits | | | Second Octet | First Octet | | Type | 15 14 13 12 11 10 9 | 8 | 7 6 5 4 3 2 1 0 | |----------------+----------------------+---+--------------------+---| | I Frame | N(R) | P | N(S) | 0 | |----------------+----------------------+---+--------------------+---| | S Frame | N(R) |P/F| 0 0 0 0 S S 0 1 | ----------------------------------------------------------------------- Fig. 4.1B -- Control-field formats (modulo 128) Where: 1. Bit 0 is the first bit sent and bit 7 (or bit 15 for modulo 128) is the last bit sent of the control field. 2. N(S) is the send sequence number (bit 1 is the LSB). 3. N(R) is the receive sequence number [bit 5 (or bit 9 for modulo 128) is the LSB]. 4. The "S" bits are the supervisory function bits; their encoding is discussed in 4.2.1.2. 5. The "M" bits are the unnumbered frame modifier bits; their encoding is discussed in 4.2.1.3. 6. The P/F bit is the Poll/Final bit. The P/F bit is used in all types of frames. The P/F bit is also used in a command (poll) mode to request an immediate reply to a frame. The reply to this poll is indicated by setting the response (final) bit in the appropriate frame. Only one outstanding poll condition per direction is allowed at a time. The procedure for P/F bit operation is described in 6.2. 4.2.1.1. Information-Transfer Format All I frames have bit 0 of the control field set to ZERO. N(S) is the sender's send sequence number (the send sequence number of this frame). N(R) is the sender's receive sequence number (the sequence number of the next expected receive frame). These numbers are described in 4.2.4. 4.2.1.2. Supervisory Format Supervisory frames have bit 0 of the control field set to ONE, and bit 1 of the control field set to ZERO. S frames provide supervisory link control such as acknowledging or requesting retransmission of I frames, and link-layer window control. Because S frames do not have an information field, the sender's send variable and the receiver's receive variable are not incremented for S frames. 4.2.1.3. Unnumbered Format Unnumbered frames have both bits 0 and 1 of the control field set to ONE. U frames are responsible for maintaining additional control over the link beyond what is accomplished with S frames. U frames are responsible for establishing and terminating link connections. U frames also allow for the transmission and reception of information outside of the normal flow control. Some U frames may contain information and PID fields. 4.2.2 Control-Field Parameters 4.2.3. Sequence Numbers If modulo 8 operation is in effect (the default), an I frame is assigned a sequential number from 0 to 7. This allows up to seven outstand- ing I frames per Layer 2 connection at one time. If modulo 128 operation is in effect, an I frame is assigned a sequential number between 0 and 127. This allows up to 127 outstanding I frames per Layer 2 connection at one time. 4.2.4. Frame Variables and Sequence Numbers 4.2.4.1. Send State Variable V(S) The send state variable exists within the TNC and is never sent. It contains the next sequential number to be assigned to the next transmitted I frame. This variable is updated upon the transmission of each I frame. 4.2.4.2. Send Sequence Number N(S) The send sequence number is found in the control field of all I frames. It contains the sequence number of the I frame being sent. Just prior to the transmission of the I frame, N(S) is updated to equal the send state variable. 4.2.4.3. Receive State Variable V(R) The receive state variable exists within the TNC. It contains the sequence number of the next expected received I frame. This variable is updated upon the reception of an error-free I frame whose send sequence number equals the present received state variable value. 4.2.4.4. Received Sequence Number N(R) The received sequence number exists in both I and S frames. Prior to sending an I or S frame, this variable is updated to equal that of the re- ceived state variable, thus implicitly acknowledging the proper reception of all frames up to and including N(R)-1. 4.2.4.5. Acknowledge State Variable V(A) The acknowledge state variable exists within the TNC and is never sent. It contains the sequence number of the last frame acknowledged by its peer [V(A)-1 equals the N(S) of the last acknowledged I frame]. 4.3. Control Field Coding for Commands and Responses 4.3.1 Information Command Frame Control Field The information (I) command transfers sequentially-numbered frames containing an information field across a data link . The information-frame control field is encoded as shown in Fig. 4.2. These frames are sequentially numbered by the N(S) subfield to maintain control of their passage over the link-layer connection. ------------------------------------------------- | Control Field Bits | 7 6 5 | 4 | 3 2 1 | 0 | |-----------------------+-------+---+-------+---| | Information | N(R) | P | N(S) | 0 | ------------------------------------------------- Fig. 4.2A -- I frame control field (modulo 8) ----------------------------------------------------------------------- | Control-Field | Control-Field Bits | | | Second Octet | First Octet | | Type | 15 14 13 12 11 10 9 | 8 | 7 6 5 4 3 2 1| 0 | |----------------+----------------------+---+--------------------+---| | I Frame | N(R) | P | N(S) | 0 | ----------------------------------------------------------------------- Fig. 4.2B -- I frame control field (modulo 128) 4.3.2 Supervisory Frame Control Field The supervisory frame control fields are encoded as shown in Fig. 4.3. ---------------------------------------------------- | Control Field Bits | 7 6 5 | 4 | 3 2 | 1 0 | |--------------------------+-------+---+-----+-----| | Receive Ready RR | N(R) |P/F| 0 0 | 0 1 | | Receive Not Ready RNR | N(R) |P/F| 0 1 | 0 1 | | Reject REJ | N(R) |P/F| 1 0 | 0 1 | | Selective Reject SREJ | N(R) |P/F| 1 1 | 0 1 | ---------------------------------------------------- Fig. 4.3A -- S frame control fields (modulo 8) ---------------------------------------------------------------------- | Control-Field | Control-Field Bits | | | Second Octet | First Octet | | Type | 15 14 13 12 11 10 9 | 8 | 7 6 5 4 3 2 1 0 | |----------------+----------------------+---+-----------------------| | RR | N(R) |P/F| 0 0 0 0 0 0 0 1 | | RNR | N(R) |P/F| 0 0 0 0 0 1 0 1 | | REJ | N(R) |P/F| 0 0 0 0 1 0 0 1 | | SREJ | N(R) |P/F| 0 0 0 0 1 1 0 1 | ---------------------------------------------------------------------- Fig. 4.3B -- S frame control fields (modulo 128) The Frame identifiers: RR Receive Ready. System Ready To Receive RNR Receive Not Ready. TNC Buffer Full REJ Reject Frame. Out of Sequence or Duplicate SREJ Selective Reject. Request single frame repeat. 4.3.2.1. Receive Ready (RR) Command and Response Receive Ready does the following: 1. indicates that the sender of the RR is now able to receive more I frames; 2. acknowledges properly received I frames up to, and including N(R)-1; 3. clears a previously-set busy condition created by an RNR command having been sent. The status of the TNC at the other end of the link can be requested by sending a RR command frame with the P-bit set to one. 4.3.2.2. Receive Not Ready (RNR) Command and Response Receive Not Ready indicates to the sender of I frames that the re- ceiving TNC is temporarily busy and cannot accept any more I frames. Frames up to N(R)-1 are acknowledged. Frames N(R) and above that may have been transmitted are discarded and must be retransmitted when the busy condition clears. The RNR condition is cleared by the sending of a UA, RR, REJ, or SABM(E) frame. The status of the TNC at the other end of the link is requested by sending a RNR command frame with the P bit set to one. 4.3.2.3. Reject (REJ) Command and Response The reject frame requests retransmission of I frames starting with N(R). Any frames sent with a sequence number of N(R)-1 or less are acknow- ledged. Additional I frames may be appended to the retransmission of the N(R) frame if there are any. Only one reject frame condition is allowed in each direction at a time. The reject condition is cleared by the proper reception of I frames up to the I frame that caused the reject condition to be initiated. The status of the TNC at the other end of the link is requested by sending a REJ command frame with the P bit set to one. 4.3.2.4. Selective Reject (SREJ) Command and Response The selective reject, SREJ, frame is used by the receiving TNC to request retransmission of the single I frame numbered N(R). If the P/F bit in the SREJ frame is set to ONE, then I frames numbered up to N(R)-1 inclu- sive are considered as acknowledged. However, if the P/F bit in the SREJ frame is set to ZERO, then the N(R) of the SREJ frame does not indicate acknowledgement of I frames. Each SREJ exception condition is cleared (reset) upon receipt of the I frame with an N(S) equal to the N(R) of the SREJ frame. A receiving TNC may transmit one or more SREJ frames, each containing a different N(R) with the P bit set to ZERO, before one or more earlier SREJ exception conditions have been cleared. However, a SREJ is not transmitted if an earlier REJ exception condition has not been cleared as indicated in 4.5.4. (To do so would request retransmission of an I frame that would be retransmitted by the REJ operation.) Likewise, a REJ frame is not transmit- ted if one or more earlier SREJ exception conditions have not been cleared as indicated in 4.5.4. I frames transmitted following the I frame indicated by the SREJ frame are not retransmitted as the result of receiving a SREJ frame. Addi- tional I frames awaiting initial transmission may be transmitted following the retransmission of the specific I frame requested by the SREJ frame. 4.3.3. Unnumbered Frame Control Fields Unnumbered frame control fields are either commands or responses. Fig. 4.4 shows the layout of U frames implemented within this proto- col. ----------------------------------------------------------------- | Control Field | Type | Control Field Bits | | | | 7 6 5 | 4 | 3 2 | 1 0| |--------------------------------+------+-------+---+-----+----| | Set Async Balanced Mode SABME | Cmd | 0 1 1 | P | 1 1 | 1 1| | Set Async Balanced Mode SABM | Cmd | 0 0 1 | P | 1 1 | 1 1| | Disconnect DISC | Cmd | 0 1 0 | P | 0 0 | 1 1| | Disconnect Mode DM | Res | 0 0 0 | F | 1 1 | 1 1| | Unnumbered Acknowledge UA | Res | 0 1 1 | F | 0 0 | 1 1| | Frame Reject FRMR | Res | 1 0 0 | F | 0 1 | 1 1| | Unnumbered Information UI |Either| 0 0 0 |P/F| 0 0 | 1 1| | Exchange Identification XID |Either| 1 0 1 |P/F| 1 1 | 1 1| | Test TEST |Either| 1 1 1 |P/F| 0 0 | 1 1| ---------------------------------------------------------------- Fig. 4.4 -- U frame control fields The Frame identifiers: SABM Connect Request SABME Connect Request Extended (modulo 128) DISC Disconnect request FRMR Frame Reject. UI Unnum-bered Information Frame. DM Disconnect Mode. System Busy or Discon-nected. XID Exchange Identifications. Negotiate features. UA Unnumbered Acknowledge. TEST Test 4.3.3.1. Set Asynchronous Balanced Mode (SABM) Command The SABM command places two Terminal Node Comtrollers (TNC) in the asynchronous balanced mode (modulo 8). This is a balanced mode of operation in which both devices are treated as equals or peers. Information fields are not allowed in SABM commands. Any outstanding I frames left when the SABM command is issued remain unacknowledged. The TNC confirms reception and acceptance of a SABM command by send- ing a UA response frame at the earliest opportunity. If the TNC is not capable of accepting a SABM command, it responds with a DM frame if possible. 4.3.3.2. Set Asynchronous Balanced Mode Extended (SABME) Command The SABME command places two TNCs in the asynchronous balanced mode extended (modulo 128). This is a balanced mode of operation in which both devices are treated as equals or peers. Information fields are not allowed in SABME commands. Any outstand- ing I frames left when the SABME command is issued remains unacknowledged. The TNC confirms reception and acceptance of a SABME command by sending a UA response frame at the earliest opportunity. If the TNC is not capable of accepting a SABME command, it responds with a DM frame. A TNC that uses an older version of AX.25 responds with a FRMR. 4.3.3.3. Disconnect (DISC) Command The DISC command terminates a link session between two stations. An information field is not permitted in a DISC command frame. Prior to acting on the DISC frame, the receiving TNC confirms accept- ance of the DISC by issuing a UA response frame at its earliest opportunity. The TNC sending the DISC enters the disconnected state when it receives the UA response. Any unacknowledged I frames left when this command is acted upon remain unacknowledged. 4.3.3.4. Unnumbered Acknowledge (UA) Response The UA response frame acknowledges the reception and acceptance of a SABM(E) or DISC command frame. A received command is not actually processed until the UA response frame is sent. Information fields are not permitted in a UA frame. 4.3.3.5. Disconnected Mode (DM) Response The disconnected mode response is sent whenever a TNC receives a frame other than a SABM(E) or UI frame while in a disconnected mode. The disconnected mode response also indicates that the TNC cannot accept a con- nection at the moment. The DM response does not have an information field. Whenever a SABM(E) frame is received and it is determined that a connection is not possible, a DM frame is sent. This indicates that the called station cannot accept a connection at that time. While a TNC is in the disconnected mode, it responds to any command other than a SABM(E) or UI frame with a DM response with the P/F bit set to ONE. 4.3.3.6. Unnumbered Information (UI) Frame The Unnumbered Information frame contains PID and information fields and passes information along the link outside the normal information con- trols. This allows information fields to go back and forth on the link bypassing flow control. Because these frames cannot be acknowledged, if one such frame is obliterated, it cannot be recovered. A received UI frame with the P bit set causes a response to be trans- mitted. This response is a DM frame when in the disconnected state, or a RR (or RNR, if appropriate) frame in the information transfer state. 4.3.3.7. Exchange Identification (XID) Frame The Exchange Identification frame causes the addressed station to identify itself, and to provide its characteristics to the sending station. An information field is optional within the XID frame. A station receiving an XID command returns an XID response unless a UA response to a mode setting command is awaiting transmission, or a FRMR condition exists. The XID frame complies with ISO 8885. Only those fields applicable to LAPA are described. All other fields are set to an appropriate value. This implementation is compatible with any implementation following ISO 8885. Only the general-purpose XID information field identifier is required in this version of LAPA. The information field consists of zero or more information elements. The information elements start with a Format Identifier (FI) octet. The second octet is the Group Identifier (GI). The third and forth octets form the Group Length (GL). The rest of the information field contains parameter fields. The FI takes the value 82 hex for the general-purpose XID informa- tion. The GI takes the value 80 hex for the parameter-negotiation identi- fier. The GL indicates the length of the associated parameter field. This length is expressed as a two-octet binary number representing the length of the associated parameter field in octets. The high-order bits of length value are in the first of the two octets. A group length of zero indicates the lack of an associated parameter field and that all parameters assume their default values. The GL does not include its own length or the length of the GI. The parameter field contains a series of Parameter Identifier (PI), Parameter Length (PL), and Parameter Value (PV) set structures, in that order. Each PI identifies a parameter and is one octet in length. Each PL indicates the length of the associated PV in octets, and is one octet in length. Each PV contains the parameter value and is PL octets in length. The PL does not include its own length or the length of its associated PI. A PL value of zero indicates that the associated PV is absent; the parameter assumes the default value. A PI/PL/PV set may be omitted if it is not re- quired to convey information, or if present values for the parameter are to be used. The PI/PL/PV fields are placed into the information field of the XID frame in ascending order. There is only one entry for each PI/PL/PV field used. A parameter field containing an unrecognized PI is ignored. An omitted parameter field assumes the currently negotiated value. The parameter fields described below represent the minimum implemen- tation and do not preclude the negotiation of other parameters between con- senting stations. The encoding of each PI/PL/PV applicable to LAPA is detailed in figure 4.5. Some of the fields are defined in this standard. Only the fields discussed below are required in an implementation that complies with this version of LAPA. ------------------------------------------------------------------- | Name | PI | PL | Parameter |Type | Bit|Value| | | | | field element | | | | |-----------+-----+-----+-----------------------+-----+-----+----| |Classes of | 2 | 2 | Balanced-ABM | E | 1 | 1 | |Procedures | | | Unbalanced-NRM-Pri * | E | 2 | 0 | | | | | Unbalanced-NRM-Sec * | E | 3 | 0 | | | | | Unbalanced-ARM-Pri * | E | 4 | 0 | | | | | Unbalanced-ARM-Sec * | E | 5 | 0 | | | | | Half Duplex | E | 6 | 0/1| | | | | Full Duplex | E | 7 | 0/1| | | | | Reserved * | | 8-16| 0 | |-----------+-----+-----+-----------------------+-----+-----+----| | HDLC | 3 | 3 | 1 Reserved * | E | 1 | 0 | | Optional | | | 2 REJ cmd/resp | E | 2 | 0/1| | Functions | | | 3A SREJ cmd/resp | E | 3 | 0/1| | | | | 4 UI cmd/resp * | E | 4 | 0 | | | | | 5 SIM cmd/RIM resp * | E | 5 | 0 | | | | | 6 UP cmd * | E | 6 | 0 | | | | | 7A Basic address * | E | 7 | 0 | | | | | 7B Extended address | E | 8 | 1 | | | | | 8 Delete I resp * | E | 9 | 0 | | | | | 9 Delete I cmd * | E | 10 | 0 | | | | | 10A Modulo 8 | E | 11 | 0/1| | | | | 10B Modulo 128 | E | 12 | 0/1| | | | | 11 RSET cmd * | E | 13 | 0 | | | | | 12 TEST cmd/resp | E | 14 | 1 | | | | | 13 RD resp * | E | 15 | 0 | | | | | 14A 16-bit FCS | E | 16 | 1 | | | | | 14B 32-bit FCS * | E | 17 | 0 | | | | | 15A Synchronous Tx | E | 18 | 1 | | | | | 15B Start/stop Tx * | E | 19 | 0 | | | | | 15C Start/Stop | | | | | | | | Basic Flow Ctl * | E | 20 | 0 | | | | | 15D Start/stop | | | | | | | | Octet Transparent * | E | 21 | 0 | | | | | 3B SREJ Multiframe * | E | 22 | 0 | | | | | Reserved * | E |23-24| 0 | |-----------+-----+-----+-----------------------+-----+-----+----| | I Field | 5 | N | Max I field length | | | | | Length Tx | | | Tx (bits) N1*8 * | B | NA | B | |-----------+-----+-----+-----------------------+-----+-----+----| | I Field | 6 | N | Max I field length | | | | | Length Rx | | | Rx (bits) N1*8 | B | NA | B | |-----------+-----+-----+-----------------------+-----+-----+----| Figure 4.5 Parameter negotiation parameter field elements ------------------------------------------------------------------- | Name | PI | PL | Parameter |Type | Bit |Value| | | | | field element | | | | |-----------+-----+-----+-----------------------+-----+-----+------| | Window | 7 | 1 | Window Size k (frames)| B | 1-7 |0-127 | | Size Tx | | | Tx * | B | 8 | 0 | |-----------+-----+-----+-----------------------+-----+-----+----- | | Window | 8 | 1 | Window Size k (frames)| B | 1-7 |0-127 | | Size Rx | | | Rx | B | 8 | 0 | |-----------+-----+-----+-----------------------+-----+-----+------| | Ack Timer | 9 | N | Wait for Ack T1 (Msec)| B | NA | B | |-----------+-----+-----+-----------------------+-----+-----+------| | Retrys | 10 | N | Retry Count N2 | B | NA | B | ------------------------------------------------------------------- Figure 4.5 Parameter negotiation parameter field elements (Continued) Note: Type E is a bit field and Type B numeric field of N octets. Parameter field elements marked * are defined in ISO 8885 and are shown for compatability purposes only. They are not needed to negotiate the features of this version of LAPA. The Classes of Procedure parameter field (PI = 2) serves to negotiate half- or full-duplex. * Bit 1 is always a 1. * Bits 2 through 5 and 8 through 16 are always zero. * Either Bit 6 (half-duplex) or bit 7 (full-duplex), but not both, must be set. If this parameter field is not present, the cur- rent values are retained. The default is half-duplex. HDLC Optional Functions parameter field (PI = 3) allows the negotia- tion of implicit reject (REJ), selective reject (SREJ), or selective reject- reject (SREJ/REJ) and modulo 8 or 128. * Bits 1, 4-7, 9, 10, 13, 15, 17 and 19-24 are always zero. * Bits 8, 14, 16 and 18 are always a one. * Implicit reject is selected by setting bit 1 and resetting bit 2. * Selective reject is selected by resetting bit 1 and setting bit 2. * Selective reject-reject is selected by setting bit 1 and bit 2. * Clearing both bit 1 and 2 is not allowed. * Modulo 8 operation is selected by setting bit 11 and resetting bit 12. * Modulo 128 operation is selected by setting bit 12 and resetting bit 11. If this parameter field is not present, the current values are retained. The default is selective reject-reject and modulo 8. I Field Length Receive parameter field (PI = 6) allows the sending TNC to notify the receiving TNC of the maximum size of an Information field (N1) it will handle without error. A transmitting TNC may not exceed this size, but may send smaller frames. If this field is not present, the current values are retained. The default is 256 octets (2048 bits). Window Size Receive parameter field (PI = 8) allows the sending TNC to notify the receiving TNC of the maximum size of the window (k) it will handle without error. If the TNCs are using modulo 128, this allows the negotiation of a window size less than 127 to conserve memory. If the TNCs are using selective reject or selective reject-reject, the receiving TNC is required to buffer k frames at any time. A transmitting TNC may not exceed this size, but may send fewer frames. If this field is not present, the current values are retained. The default is 4 for modulo 8 and 32 for modulo 128. Acknowledge Timer parameter field (PI = 9) allows the negotiation of the wait for acknowledgement timer (T1). If this field is not present, the current values are retained. The default is 3000 MSec. Retries parameter field (PI = 10) allows the negotiation of the retry count (N1). If this field is not present, the current values are retained. The default is 10 retries. A FRMR condition may be established if the received XID command information field exceeds the maximum defined storage capability of the station, or if the receiving station is using AX.25 version 2.0 or earlier versions. A typical XID frame is shown in figure 4.6. |Flag| 7E | Start Flag | A1 | 98 | From Address (NJ7P-0) | A2 | 94 | | A3 | 6E | | A4 | A0 | | A5 | 40 | | A6 | 40 | | A7 | E0 | | A8 | 98 | To Address (N7LEM-0) | A9 | 6E | | A10| 98 | | A11| 8A | | A12| 9A | | A13| 40 | | A14| 61 | | Ctl| AF | Control Field (XID) | FI | 82 | Format indicator | GI | 80 | Group Identifier - parameter negotiation | GL | 00 | Group length - all of the PI/PL/PV fields | | 17 | (2 bytes) | PI | 02 | Parameter Indicator - classes of procedures | PL | 02 | Parameter Length | PV | 00 | Parameter Variable - Half Duplex, Async | | 20 | Balanced Mode | PI | 03 | Parameter Indicator - optional functions | PL | 03 | Parameter Length | PV | 86 | Parameter Variable - SREJ/REJ, extended addr | | A8 | 16-bit FCS, TEST cmd/resp, Modulo 128 | | 02 | synchronous transmit | PI | 06 | Parameter Indicator - Rx I field length (bits) | PL | 02 | Parameter Length | PV | 04 | Parameter Variable - 1024 bits (128 octets) | | 00 | | PI | 08 | Parameter Indicator - Rx window size | PL | 01 | Parameter length | PV | 02 | Parameter Variable - 2 frames | PI | 09 | Parameter Indicator - Timer T1 | PL | 02 | Parameter Length | PV | 10 | Parameter Variable - 4096 MSec | | 00 | | PI | 0A | Parameter Indicator - Retries (N1) | PL | 01 | Parameter Length | PV | 03 | Parameter Variable - 3 retries | FCS| XX | | FCS| XX | |Flag| 7E | Figure 4.6 Typical XID frame 4.3.3.8. Test (TEST) Frame The Test command causes the addressed station to respond with the TEST response at the first respond opportunity; this performs a basic test of the data-link control. An information field is optional with the TEST com- mand. If present, the received information field is returned, if possible, by the addressed station, with the TEST response. The TEST command has no effect on the mode or sequence variables maintained by the station. A FRMR condition may be established if the received TEST command information field exceeds the maximum defined storage capability of the station. If a FRMR response is not returned for this condition, a TEST response without an information field is returned. The station considers the data-link layer test terminated on receipt of the TEST response, or when a time-out period has expired. The results of the TEST command/response exchange are made available for interrogation by a higher layer. 4.3.3.9. FRMR Response Frame The FRMR response is removed from the standard for the following reasons: * UI frame transmission was not allowed during FRMR recovery. * During FRMR recovery, the link could not be reestablished by the station that sent the FRMR. * The above functions are better handled by simply resetting the link with a SABM(E) + UA exchange. * An implementation that receives and process FRMRs but does not transmit them is compatible with older versions of the standard. * SDL is simplified and removes the need for one state. This version of LAPA operates with previous versions of AX.25. It does not generate a FRMR Response frame, but handles error conditions by resetting the link. 4.4. Link Error Reporting and Recovery Several link-layer errors can be recovered without terminating the connection. These error situations may occur as a result of malfunctions within the TNC, or if transmission errors occur. 4.4.1 TNC Busy Condition When a TNC is temporarily unable to receive I frames, for example when receive buffers are full, it sends a Receive Not Ready (RNR) frame. This informs the sending TNC that the receiving TNC cannot handle any more I frames at the moment. This condition is cleared by the receiving TNC send- ing a UA, RR, REJ or SABM(E) command frame. 4.4.2 Send Sequence Number Error If the send sequence number, N(S), of an otherwise error-free re- ceived frame does not match the receive state variable, V(R), a send sequence error has occurred. If SREJ has been negotiated and the N(s) is in the greater-than V(r) and less-than V(r)+k, the information field is saved; otherwise it is discarded. The receiver will not acknowledge this frame or any other I frames until N(S) matches V(R). The control field of the erroneous I frame(s) is accepted so that link supervisory functions such as checking the P/F bit can be performed. Because of this update, the retransmitted I frame may have an updated P bit and N(R). 4.4.3 Reject (REJ) Recovery The REJ frame requests a retransmission of I frames following the detection of a N(S) sequence error. Only one outstanding "sent REJ" condi- tion is allowed at a time. This condition is cleared when the requested I frame has been received. A TNC receiving the REJ command clears the condition by resending all outstanding I frames (up to the window size), starting with the frame indicated in N(R) of the REJ frame. 4.4.4. Selective Reject (SREJ) Recovery The SREJ command/response initiates more-efficient error recovery by requesting the retransmission of a single I frame following the detection of a sequence error. This is an advancement over the earlier versions in which the requested I frame was retransmitted togther with all additional I frames subsequently transmitted and successfully received. When a TNC sends one or more SREJ commands, each with the P bit set to "0" or "1", or one or more SREJ responses, each with the F bit set to "0", and the "sent SREJ" conditions are not cleared when the TNC is ready to issue the next response frame with the F bit set to "1", the TNC sends a SREJ response with the F bit set to "1", with the same N(R) as the oldest unre- solved SREJ frame. Because an I or S format frame with the F bit set to "1" can cause checkpoint retransmission, a TNC does not send SREJ frames until it receives at least one in-sequence I frame, or it perceives by time-out that the check- point retransmission will not be initiated at the remote TNC. With respect to each direction of transmission on the data link, one or more "sent SREJ" exception conditions from a TNC to another TNC may be established at a time. A "sent SREJ" exception condition is cleared when the requested I frame is received. The SREJ frame may be repeated when a TNC perceives by time-out that a requested I frame will not be received, because either the requested I frame or the SREJ frame was in error or lost. When appropriate, a TNC receiving one or more SREJ frames initiates retransmission of the individual I frames indicated by the N(R) contained in each SREJ frame. After having retransmitted the above frames, new I frames are transmitted later if they become available. When a TNC receives and acts on one or more SREJ commands, each with the P bit set to "0", or an SREJ command with the P bit set to "1", or one or more SREJ responses each with the F bit set to "0", it disables any action on the next SREJ response frame if that SREJ frame has the F bit set to "1" and has the same N(R) (i.e. same value and same numbering cycle) as a previously actioned SREJ frame, and if the resultant retransmission was made following the transmission of the P bit set to "1". When the SREJ mechanism is used, the receiving station retains cor- rectly-received I frames and delivers them to the higher layer in sequence number order. 4.4.5. Time-out Error Recovery 4.4.5.1. T1 Timer Recovery If, because of a transmission error, a TNC does not receive (or receives and discards) a single I frame or the last I frame in a sequence of I frames, it does not detect a send-sequence-number error; therefore the TNC does not transmit a REJ/SREJ. The TNC that transmitted the unacknowledged I frame(s) following the completion of time-out period T1, takes appropriate recovery action to determine when I frame retransmission should begin as described in 6.4.10. This condition is cleared by the reception of an acknowledgement for the sent frame(s), or by the link being reset. 4.4.5.2. Timer T3 Recovery Timer T3 ensures that the link is still functional during periods of low information transfer. When T1 is not running (no outstanding I frames), T3 periodically causes the TNC to poll the other TNC of a link. When T3 times out, a RR or RNR frame is transmitted as a command with the P bit set, and then T1 is started. When a response to this command is received, T1 is stopped and T3 is started. If T1 expires before a response is received, then the waiting acknowledgement procedure (6.4.11) is executed. 4.4.6. Invalid Frame or FCS Error If an invalid frame is received, or a frame is received with an FCS error, that frame is discarded with no further action taken. 5. Elements for layer-to-layer communication Communication between layers is accomplished with "primitives". In an abstract way, primitives represent the logical exchange of information and control between the data link and adjacent layers. They do not specify or constrain implementations. Primitives consist of commands and their respective responses asso- ciated with the services requested from a lower layer. The general syntax of a primitive is: XX - Generic name - Type: Parameters where XX designates the interface across which the primitive flows. For this Standard, XX is: * DL for communications between Layer 3 and the data-link layer; * LM for communications between the data-link layer and the link multi- plexor. * PH for communications between the link multiplexor and the physical layer. * MDL for communications between Layer 3 and the layer management. 5.1. Layer 3 entity <--> Management Data-Link State Machine MDL-NEGOTIATE Request - the Layer 3 entity uses this primitive to request the Data-link State Machine to notify/negotiate. MDL-NEGOTIATE Confirm - the Management Data-link State Machine uses this primitive to notify the Layer 3 entity that notification/negotiation is complete. MDL-ERROR Indicate - the Management Data-link State Machine uses this primitive to notify the Layer 3 entity that notification/negotiation has failed. 5.2. Management Data-Link State Machine <--> Link Multiplexor State Machine LM-DATA Request - the Management Data-link State Machine uses this primitive to pass frames of any type (XID, UI, etc.) to the Link Multiplexor State Machine. LM-DATA Indication - the Link Multiplexor State Machine uses this primitive to pass frames of any type (XID, UI, etc.)to the Management Data- link State Machine. 5.3. Layer 3 entity <--> Data-Link State Machine DL-CONNECT Request - the Layer 3 entity uses this primitive to re- quest the establishment of a LAPA connection. DL-CONNECT Indication - the Data-link State Machine uses this primi- tive to indicate that a LAPA connection has been requested. DL-CONNECT Confirm - the Data-link State Machine uses this primitive to indicate that a LAPA connection has been made. DL-DISCONNECT Request - the Layer 3 entity uses this primitive to request the release of a LAPA connection. DL-DISCONNECT Indication - the Data-link State Machine uses this primitive to indicate that a LAPA connection has been released. DL-DISCONNECT Confirm - the Data-link State Machine uses this primi- tive to indicate that a LAPA connection has been released and confirmed. DL-DATA Request - the Layer 3 entity uses this primitive to request the transmission of data using connection-oriented protocol. If necessary, this frame is examined and acted upon by the segmenter. DL-DATA Indication - the reassembler uses this primitive to indicate reception of Layer 3 data using connection oriented protocol. DL-UNIT-DATA Request - the Layer 3 entity uses this primitive to request the transmission of data using connectionless protocol. If neces- sary, this frame is examined and acted upon by the segmenter. DL-UNIT-DATA Indication - the reassembler uses this primitive to indicate reception of Layer 3 data using connectionless protocol. DL-ERROR Indication - the Data-link State Machine uses this primitive to indicate when frames inconsistent with this protocol definition have been received. This includes short frames, frames with inconsistent parameter values, etc. The error indications are discussed in the SDL appendices. DL-FLOW-OFF Request - the Layer 3 entity uses this primitive to temporarily suspend the flow of incoming information. DL-FLOW-ON Request - the Layer 3 entity uses this primitive to resume the flow of incoming information. 5.4. Data-Link State Machine <--> Link Multiplexor State Machine LM-SEIZE Request - the Data-link State Machine uses this primitive to request the Link Multiplexor State Machine to arrange for transmission at the next available opportunity. The Data-link State Machine uses this primitive when an acknowledgement must be made; the exact frame in which the acknowledgement is sent will be chosen when the actual time for transmission arrives. LM-SEIZE Confirm - this primitive indicates to the Data-link State Machine that the transmission opportunity has arrived. LM-RELEASE Request - the Link Multiplexor State Machine uses this primitive to stop transmission. LM-EXPEDITED-DATA Request - the data-link machine uses this primitive to pass expedited data to the link multiplexor. LM-DATA Request - the Data-link State Machine uses this primitive to pass frames of any type (SABM, RR, UI, etc.) to the Link Multiplexor State Machine. LM-DATA Indication - the Link Multiplexor State Machine uses this primitive to pass frames of any type (SABM, RR, UI, etc.) to the Data-link State Machine. 5.5. Link Multiplexor State Machine <--> Physical State Machine PH-SEIZE Request - the Link Multiplexor State Machine uses this primitive before each transmission to request access to the radio channel. PH-SEIZE Confirm - the Physical State Machine uses this primitive to confirm that the channel has been seized. PH-RELEASE Request - the Link Multiplexor State Machine uses this primitive to release the radio channel. PH-QUIET Indication - the Physical State Machine uses this primitive to indicate that the channel is not busy. PH-BUSY Indication - the Physical State Machine uses this primitive to indicate that the channel is busy. PH-EXPEDITED-DATA Request - the Link Multiplexor State Machine uses this primitive to request transmission of each digipeat or expedite data frame. PH-DATA Request - the Link Multiplexor State Machine uses this primi- tive to request transmission of each normal frame. PH-DATA Indication - the Physical State Machine uses this primitive to provide incoming frames to the link multiplexor. 5.6. Physical State Machine <--> Hardware Acquisition of Signal - the hardware uses this primitive to notify the Physical State Machine that modem synchronization, flag fill or frame structure have been detected. Loss of Signal - the hardware uses this primitive to notify the Physical State Machine that modem synchronization, flag fill or frame struc- ture have been lost. Frame - the hardware uses this primitive and the Physical State Machine to pass frames to send or that have been received. Turn On Transmitter - the Physical State Machine uses this primitive to tell the hardware to key the transmitter. Turn Off Transmitter - the Physical State Machine uses this primitive to tell the hardware to unkey the transmitter. 6. Description of LAPA Procedures The following paragraphs describe the procedures used to setup, use, and disconnect a balanced link between two TNC stations. 6.1. Address Field Operation 6.1.1. Address Information All transmitted frames have address fields conforming to 3.12. All frames have both the destination device and the source device addresses in the address field, with the destination address coming first. This allows many links to share the same RF channel. The destination address is always the address of the station(s) for which the frame is intended; the source address contains the address of the device that sent the frame. If point-to-multipoint operation is desired, the destination address can be a group name or club callsign. Operation with destination addresses other than actual amateur callsigns is a subject for further study. 6.1.2 Command/Response Procedure LAPA implements the command/response information in the address field. The command/response information is conveyed using two bits to maintain compatibility with previous versions of LAPA. An upward-compatible LAPA TNC determines if it is communicating with a TNC using an older version of this protocol by testing the command/response bit information located in bit 7 of the SSID octets of both the destination and source address subfields. If both C bits are set to ZERO, the device is using the older protocol. The newer version of the protocol always has one of these two bits set to ONE and the other set to ZERO, depending on whether the frame is a command or a response. The command/response information is encoded into the address field as shown in Fig. 6.1. Versions prior to 2.0 defined these bits to be either both ZERO or both ONE. Frame Type Dest. SSID C-Bit Source SSID C-Bit Previous versions 0 0 Command (V.2.X) 1 0 Response (V.2.X) 0 1 Previous versions 1 1 Fig. 6.1 -- Command/Response encoding Because all frames are considered either commands or responses, a device always has one of the bits set to ONE and the other bit set to ZERO. The use of the command/response information in LAPA allows S frames to be either commands or responses. This helps maintain proper control over the link during the information transfer state. 6.2. Poll/Final (P/F) Bit Procedures The next response frame returned by the TNC to a SABM(E) or DISC command with the P bit set to ONE is a UA or DM response with the F bit set to ONE. The next response frame returned to an I frame with the P bit set to ONE, received during the information transfer state, is a RR, RNR, or REJ response with the F bit set to ONE. The next response frame returned to a supervisory command frame with the P bit set to ONE, received during the information transfer state, is a RR, RNR, or REJ response frame with the F bit set to ONE. The next response frame returned to a S or I command frame with the P bit set to ONE, received in the disconnected state, is a DM response frame with the F bit set to ONE. The P bit is used in conjunction with the time-out recovery condi- tion discussed in 4.5.5. When not used, the P/F bit is set to ZERO. 6.3. Procedures For Link Set-Up and Disconnection 6.3.1 LAPA Link Connection Establishment To connect to a distant TNC, the originating TNC sends a SABM command frame to the distant TNC and starts its T1 timer. If the distant TNC exists and accepts the connect request, it responds with a UA response frame and resets all of its internal state variables (V(S), V(A) and V(R)). Reception of the UA response frame by the originating TNC causes it to cancel the T1 timer and set its internal state variables to 0. If the distant TNC doesn't respond before T1 times out, the originat- ing TNC resends the SABM frame and starts T1 running again. The originating TNC tries to establish a connection until it has tried unsuccessfully N2 times. N2 is defined in 6.7.2.3. If the distant TNC receives a SABM command and cannot enter the indicated state, it sends a DM frame. When the originating TNC receives a DM response to its SABM(E) frame, it cancels its T1 timer and does not enter the information-transfer state. The originating TNC sending a SABM(E) command ignores and discards any frames except SABM, DISC, UA, and DM frames from the distant TNC. In response to a received SABM(E), frames other than UA and DM are sent only after the link is set up and if no outstanding SABM(E) exists. 6.3.2. Parameter Negotiation Phase Parameter negotiation occurs at any time. It is accomplished by sending the XID command frame and receiving the XID response frame. LAPA versions prior to 2.2 respond to a XID command frame with a FRMR response frame. The TNC receiving the FRMR uses a default set of parameters compat- ible with previous version of LAPA. The receipt of a XID response from the other station establishes that both stations are using LAPA version 2.2 or higher and enables the use of the segmenter/reassembler and selective reject. This version of LAPA implements the negotiation or notification of six LAPA parameters. Notification simply tells the distant TNC some limit that cannot be exceeded. The distant TNC can choose to use the limit or some other value that is within the limits. Notification is used with the Window Size Receive (k) and Information Field Length Receive (N1). Negotiation involves both TNCs choosing a value that is mutually acceptable. The XID command frame contains a set of values acceptable to the originating TNC. The distant TNC chooses to accept the values offered, or other acceptable values, and places these values in the XID response. Both TNCs set them- selves up based on the values used in the XID response. Negotiation is used by Classes of Procedures, HDLC Optional Functions, Acknowledge Timer and Retries. The Classes of Procedure parameter field (PI = 2) negotiates half- or full-duplex operation. This reverts to half duplex if either TNC cannot support full duplex (i.e., if the XID command requests full-duplex and the receiving TNC can only support half duplex, it sets the value to half-duplex in the XID response. If this parameter field is not present, the default half-duplex operation is selected. HDLC Optional Functions parameter field (PI = 3) allows the negotia- tion of implicit reject (REJ), selective reject (SREJ), or selective reject- reject (SREJ/REJ), and modulo 8 or 128. Function reverts to the lesser of the selection offered in the XID command and XID response frames. Ordering is (Highest to lowest): selective reject-reject, selective reject and impli- cit reject: Modulo 128 and modulo 8. If this parameter field is absent, the default function selective reject and modulo 8 are selected. I Field Length Receive parameter field (PI = 6) allows the sending TNC to notify the receiving TNC of the maximum size of an Information field (N1) it will handle without error. A transmitting TNC may not exceed this size, but may send smaller frames. Window Size Receive parameter field (PI = 8) allows the sending TNC to notify the receiving TNC of the maximum size of the window (k) it will handle without error. If the TNCs are using modulo 128, this allows the negotiation of a window size less than 127 to conserve memory. If the TNCs are using selective reject or selective reject-reject, the receiving TNC is required to buffer k frames at any time. Acknowledge Timer parameter field (PI = 9) allows the negotiation of the "Wait for Acknowledgement" timer (T1). Function reverts to the greater of the values offered in the XID command and XID response frames. Retries parameter field (PI = 10) allows the negotiation of the retry count (N1). Function reverts to the greater of the values offered in the XID command and XID response frames. Defaults for the negotiated parameters for use with a previous ver- sion of LAPA are: Set Half Duplex Set Implicit Reject Modulo = 8 I Field Length Receive = 2048 bits Window Size Receive = 4 Acknowledge Timer = 3000 MSec Retries = 10 Defaults for the negotiated parameters for use with this version of LAPA are: Set Half Duplex Set Selective Reject Modulo = 8 I Field Length Receive = 2048 bits Window Size Receive = 7 Acknowledge Timer = 3000 MSec Retries = 10 6.3.3. Information-Transfer Phase After establishing a link connection, the TNC enters the information- transfer state. In this state, the TNC accepts and transmits I and S frames according to the procedure outlined in 6.4. When receiving a SABM(E) command while in the information-transfer state, the TNC follows the resetting procedure outlined in 6.5. 6.3.4. Link Disconnection While in the information-transfer state, either TNC may indicate a request to disconnect the link by transmitting a DISC command frame and starting timer T1. After receiving a valid DISC command, the TNC sends a UA response frame and enters the disconnected state. After receiving a UA or DM response to a sent DISC command, the TNC cancels timer T1 and enters the disconnected state. If a UA or DM response is not correctly received before T1 times out, the DISC frame is sent again and T1 is restarted. If this happens N2 times, the TNC enters the disconnected state. 6.3.5. Disconnected State In the disconnected state, a TNC monitors received commands, reacts to the receipt of a SABM(E) as described in 6.3.1, and transmits a DM frame in response to a DISC command. In the disconnected state, a TNC may initiate a link set up as out- lined in connection establishment (6.3.1). It may also respond to the re- ceipt of a SABM(E) and establish a connection, or it may refuse the SABM(E) and send a DM instead. Any TNC receiving a command frame other than a SABM(E) or UI frame with the P bit set to ONE responds with a DM frame with the F bit set to ONE. The offending frame is ignored. When the TNC enters the disconnected state after an error condition, or if an internal error has resulted in the TNC being in the disconnected state, the TNC indicates this by sending a DM response rather than a DISC frame and follows the link disconnection procedure outlined in 6.3.4. The TNC may then try to reestablish the link using the link set up procedure outlined in 6.3.1. 6.3.6. Collision Recovery 6.3.6.1. Collisions in a Half-Duplex Environment Collisions of frames in a half-duplex environment are taken care of by the retry nature of the T1 timer and retransmission count variable. No other special action is required. 6.3.6.2. Collisions of Unnumbered Commands If sent and received SABM(E) or DISC command frames are the same, both TNCs send a UA response at the earliest opportunity, and both devices enter the indicated state. If sent and received SABM(E) or DISC commands are different, both TNCs enter the disconnected state and transmit a DM frame at the earliest opportunity. 6.3.6.3. Collision of a DM with a SABM(E) or DISC When an unsolicited DM response frame is sent, a collision between it and a SABM(E) or DISC may occur. In order to prevent this DM from being misinterpreted, all unsolicited DM frames are transmitted with the F bit set to ZERO. All SABM(E) and DISC frames are sent with the P bit set to ONE. This prevents confusion when a DM frame is received. 6.3.7. Connectionless Operation An additional type of operation exists in amateur radio that is not feasible using Layer 2 connections. This is the "round-table" operation, in which several amateurs may be engaged in one conversation. This type of operation cannot be accommodated by current LAPA link-layer connections. The way roundtable activity is implemented is technically outside the LAPA connection, but still uses the LAPA frame structure. LAPA uses a special frame for this operation, the Unnumbered Informa- tion (UI) frame. In this type of operation, the destination address has a code word installed in it that prevents users of that specific roundtable from seeing all frames going through the shared RF medium. For example, if a group of amateurs are in a roundtable discussion about packet radio, they could put "PACKET" in the destination address; they will receive frames only from others in the same discussion. An added advantage of the use of LAPA in this manner is that the source of each frame is in the source address subfield; software could be written to automatically display who is making what comments. Since this mode is connectionless, there are no requests for retrans- missions of bad frames. Collisions also occur, with the potential of losing the frames that collided. 6.4. Procedures for Information Transfer Once a connection has been established as outlined above, both TNCs can accept I, S, and U frames. 6.4.1. Sending I Frames Whenever a TNC has an I frame to transmit, it sends the I frame with the N(S) of the control field equal to its current send state variable V(S). After the I frame is sent, the send state variable is incremented by one. If timer T1 is not running, it is started. If timer T1 is running, it is be restarted. The TNC does not transmit any more I frames if its send state vari- able equals the last received N(R) from the other side of the link plus k. Were it to send more I frames, the flow control window would be exceeded and errors could result. If a TNC is in a busy condition, it may still send I frames as long as the distant TNC is not also busy. 6.4.2. Receiving I Frames The reception of I frames that contain zero-length information fields is reported to the next layer; no information field will be transferred. 6.4.2.1. Not Busy If a TNC receives a valid I frame (one with a correct FCS and whose send sequence number equals the receiver's receive state variable) and is not in the busy condition, it accepts the received I frame, increments its re- ceive state variable, and acts in one of the following manners: 1. If it has an I frame to send, that I frame may be sent with the transmitted N(R) equal to its receive state variable V(R) (thus acknowledging the received frame). Alternately, the TNC may send a RR frame with N(R) equal to V(R), and then send the I frame. 2. If there are no outstanding I frames, the receiving TNC sends a RR frame with N(R) equal to V(R). The receiving TNC may wait a small period of time before sending the RR frame to be sure additional I frames are not being transmitted. 6.4.2.2. Busy If the TNC is in a busy condition, it ignores any received I frames without reporting this condition, other than repeating the indication of the busy condition. If a busy condition exists, the TNC receiving the busy condition indication polls the sending TNC periodically until the busy condition disappears. A TNC may poll the busy TNC periodically with RR or RNR frames with the P bit set to ONE. 6.4.3 Priority Acknowledge This version of LAPA implements the priority acknowledgement proce- dure. This feature precludes a non-priority frame from being transmitted during slot 0, the time when the TNC receiving the previous frame would be expected to send an acknowledgement. 6.4.4. Reception of Out-of-Sequence Frames 6.4.4.1 Implicit Reject (REJ) When an I frame is received with a correct FCS but its send sequence number, N(S), does not match the current receiver's receive state variable, the frame is discarded. A REJ frame is sent with a receive sequence number equal to one higher than the last correctly received I frame if an uncleared N(S) sequence error condition has not been previously established. The received state variable and poll bit of the discarded frame is checked and acted upon, if necessary. This mode requires no frame queueing and frame resequencing at the receiver. However, because the mode requires transmission of frames that may not be in error, its throughput is not as high as selective reject. This mode is ineffective on systems with long round-trip delays and high data rates. 6.4.4.2 Selective Reject (SREJ) When an I frame is received with a correct FCS but its send sequence number, N(S), does not match the current receiver's receive state variable, the frame is saved. SREJ frames are sent with a receive sequence number equal to the value N(R) of the missing frame, and P=1 if an uncleared SREJ condition has not been previously established. If an SREJ condition is already pending, an SREJ as above with the P=0 will be sent. The received state variable and poll bit of the received frame are checked and acted upon, if necessary. This mode requires frame queueing and frame resequencing at the receiver. The holding of frames can consume precious buffer space, especial- ly if the user device has limited memory available and several active links are operational. 6.4.4.3 Selective Reject-Reject (SREJ/REJ) When an I frame is received with a correct FCS, but its send sequence number, N(S), does not match the current receiver's receive state variable, and if N(S) indicates 2 or more frames are missing, a REJ frame is trans- mitted. All subsequently received frames are discarded until the lost frame is correctly received. If only one frame is missing, a SREJ frame is sent with a receive sequence number equal to the value N(R) of the missing frame. The received state variable and poll bit of the received frame are checked and acted upon. If another frame error occurs prior to recovery of the SREJ condition, the receiver saves all frames received after the first erred frame and discards frames received after the second erred frame until the first erred frame is recovered. Then, a REJ is issued to recover the second erred frame and all subsequent discarded frames. 6.4.5. Reception of Incorrect Frames When a TNC receives a frame with an incorrect FCS, an invalid frame, or a frame with an improper address, that frame is discarded. 6.4.6. Receiving Acknowledgement Whenever an I or S frame is correctly received, even in a busy condi- tion, the N(R) of the received frame is checked to see if it includes an acknowledgement of outstanding sent I frames. The T1 timer is canceled if the received frame actually acknowledges previously unacknowledged frames. If the T1 timer is canceled and there are still some frames that have been sent that are not acknowledged, T1 is started again. If the T1 timer expires before an acknowledgement is received, the TNC proceeds with the retrans- mission procedure outlined in 6.4.11. 6.4.7. Receiving REJ After receiving a REJ frame, the transmitting TNC sets its send state variable to the same value as the REJ frame's received sequence number in the control field. The TNC then retransmits any I frame(s) outstanding at the next available opportunity in accordance with the following: 1. If the TNC is not transmitting at the time and the channel is open, the TNC may begin retransmission of the I frame(s) immediately. 2. If the TNC is operating on a full-duplex channel transmitting a UI or S frame when it receives a REJ frame, it may finish sending the UI or S frame and then retransmit the I frame(s). 3. If the TNC is operating in a full-duplex channel transmitting another I frame when it receives a REJ frame, it may abort the I frame it was sending and start retransmission of the requested I frames immediately. 4. The TNC may send just the one I frame outstanding, or it may send more than the one indicated if more I frames followed the first unacknowl- edged frame, provided that the total to be sent does not exceed the flow-con- trol window (k frames). If the TNC receives a REJ frame with the poll bit set, it responds with either a RR or RNR frame with the final bit set before retransmitting the outstanding I frame(s). 6.4.8. Receiving an SREJ After receiving a SREJ frame, the transmitting TNC retransmits the individual I frame indicated by the N(R) contained in the SREJ at the next available opportunity. After retransmitting the frame above, new I frames may be retransmitted subsequently if they become available. If the P bit was set, then all frames up to N(R)-1 are acknowledged. 6.4.9. Receiving an RNR Frame Whenever a TNC receives a RNR frame, it stops transmitting I frames until the busy condition is cleared. If timer T3 expires after the RNR was received, a RR or RNR command with the P bit set is sent to poll the distant TNC of its status; then timer T1 is started. If a RNR frame is received in response to this poll, T1 is stopped and T3 is started again. If no response is received before T1 expires, the waiting acknowledgment procedure (6.4.11) is performed. If a RR frame is received in response to the poll, then T1 is stopped and the busy condition cleared. 6.4.10. Sending a Busy Indication Whenever a TNC enters a busy condition, it indicates this by sending a RNR response at the next opportunity. While the TNC is in the busy condi- tion, it may receive and process S frames. If a received S frame has the P bit set to ONE, the TNC sends a RNR frame with the F bit set to ONE at the next possible opportunity. To clear the busy condition, the TNC sends either a RR or REJ frame with the received sequence number equal to the current receive state variable, depending on whether the last received I frame was properly received or not. 6.4.11. Waiting Acknowledgement If the originating TNC's timer T1 expires while awaiting the distant TNC's acknowledgement of an I frame transmitted, the originating TNC restarts timer T1 and transmits an appropriate supervisory command frame (RR or RNR) with the P bit set. If the TNC receives correctly a supervisory response frame with the F bit set and with an N(R) within the range from the last N(R) received to the last N(S) sent plus one, the TNC restarts timer T1 and sets its send state variable V(S) to the received N(R). It may then resume with I frame trans- mission or retransmission, as appropriate. If, on the other hand, the TNC receives correctly a supervisory response frame with the F bit not set, or an I frame or supervisory command frame, and with an N(R) within the range from the last N(R) received to the last N(S) sent plus one, the TNC does not restart timer T1; it uses the received N(R) as an indication of acknowledgement of transmitted I frames up to and including I frame numbered N(R)-1. If timer T1 expires before a supervisory response frame with the F bit set is received, the TNC retransmits an appropriate supervisory command frame (RR or RNR) with the P bit set. After N2 attempts to get a supervisory response frame with the F bit set from the distant TNC, the originating TNC initiates a link resetting procedure as described in 6.5. 6.5. Resetting Procedure The resetting procedure initializes both directions of data flow after a unrecoverable error has occurred. This resetting procedure is used only in the information-transfer state of an LAPA link. A TNC initiates a reset procedure whenever it receives an unexpected UA response frame, or after receipt of a FRMR frame from an older version of the protocol. A TNC resets the link by sending a SABM(E) frame and starting timer T1. After receiving a SABM(E) frame from the TNC to which it was previously connected, the receiver of a SABM(E) frame sends a UA frame back at the earliest opportunity, sets its send and receive state variables V(S) and V(R) to ZERO and stops T1, unless it has sent a SABM(E) or DISC itself. If the UA frame is correctly received by the first TNC, it resets its send and receive state variables V(S) and V(R), and stops timer T1. Any busy condition that previously existed is also cleared. If a DM response is received, the TNC enters the disconnected state and stops timer T1. If timer T1 expires before a UA or DM response frame is received, the SABM(E) is retransmitted and timer T1 restarted. If timer T1 expires N2 times, the TNC enters the disconnected state. Any previously existing link conditions are cleared. Other commands or responses received by the TNC before completion of the reset procedure are discarded. One TNC may request that the other TNC reset the link by sending a DM response frame. After the DM frame is sent, the sending TNC then enters the disconnected state. 6.6. Disassembler/Reassembler The segmenter/reassembler procedure is only enabled if both stations on the link are using LAPA version 2.2 or higher. The use of the segmenter- /reassembler allows the transmission of packets longer than N1 in a simple and clean manner. This adds less than one percent overhead for the standard N1 of 256 bytes. It adds the ability to send large Level 3 data entities such as IP datagrams as single entities over LAPA. The segmenter is a simple process that divides long data units into smaller segments for transmission, attaching a two-octet header to each segment. At the receiving end, segments are reassembled into the original data unit. Overhead is kept to a minimum throughout; steps are taken to prevent deadlock situations from arising in the buffer management of both stations on the link. The header is described in figure 6.2. --------------------------------- | 7 6 5 4 3 2 1 0 | |-------------------------------| | 0 0 0 0 1 0 0 0 | <-- Segmentation PID |-------------------------------| | | | <-- Number of Segments --------------------------------- Remaining to be sent ^ First Segment Flag Figure 6.2 Segment Header Format The reassembler can tell when a segmented frame is received by the PID. If the first segment flag is set, then the amount of buffer space required for the entire frame can be calculated and allocated. If using the segmenter over connectionless service and a segment is lost, error recovery is not done by the reassembler. An error is passed to Layer 3; it is up to Layer 3 to recover. 6.7. List of System Defined Parameters 6.7.1. Timers These timers maintain the integrity of the LAPA Layer 2 connection, 6.7.1.1. Acknowledgment Timer T1 T1, the Acknowledgement Timer, ensures that a TNC doesn't wait for- ever for a response to a frame it sends. This timer cannot be expressed in absolute time; the time required to send frames varies greatly with the signaling rate used at Layer 1. T1 should take at least twice the amount of time it would take to send maximum length frame to the distant TNC and get the proper response frame back from the distant TNC. This allows time for the distant TNC to do some processing before responding. If Layer 2 repeaters are used, the value of T1 should be adjusted according to the number of repeaters through which the frame is being trans- ferred. 6.7.1.2. Response Delay Timer T2 T2, the Response Delay Timer, may optionally be implemented by the TNC to specify a maximum amount of delay to be introduced between the time an I frame is received and the time the resulting response frame is sent. This delay is introduced to allow a receiving TNC to wait a short period of time to determine if more than one frame is being sent to it. If more frames are received, the TNC can acknowledge them at once (up to seven), rather than acknowledging each individual frame. The use of timer T2 is not mandatory; is recommended to improve channel efficiency. Note that, on full-duplex channels, acknowledgments should not be delayed beyond k/2 frames to achieve maximum throughput. The k parameter is defined in 6.8.2.3. 6.7.1.3. Inactive Link Timer T3 T3, the Inactive Link Timer, maintains link integrity whenever T1 isn't running. It is recommended that whenever there are no outstanding unacknowledged I frames or P-bit frames (during the information-transfer state), a RR or RNR frame with the P bit set to ONE be sent every T3 time units to query the status of the other TNC. The period of T3 is locally defined, and depends greatly on Layer 1 operation. T3 should be greater than T1; it may be very large on channels of high integrity. 6.7.1.4. Repeater Hang Timer T100 (AXHANG) T100, the Repeater Hang Timer, tracks the amount of time an audio repeater will keep its transmitter keyed after it stops receiving. This timer can increase channel efficiency when an audio repeater is used. If the repeater's transmitter remains keyed, it is not necessary to add AXDELAY to the transmitter key-up time. 6.7.1.5. Priority Window Timer T101 (PRIACK) T101, the Priority Window Timer, prevents stations from transmitting non-priority frames during the first available transmission time slot. The first transmission time slot is reserved for priority frames (acknowledgments and digipeat frames). 6.7.1.6. Slot Time Timer T102 (p-persistence) T102, the Slot Time Timer, randomly delays stations before they begin transmitting immediately after the channel becomes clear. This helps prevent several stations from beginning to transmit at the same time and causing collisions. 6.7.1.7. Transmitter Startup Timer T103 (TXDELAY) T103, the Transmitter Startup Timer, ensures that the transmitter is up and ready to transmit after being keyed, before any frames are sent. 6.7.1.8. Repeater Startup Timer T104 (AXDELAY) T104, the Repeater Startup Timer, ensures that audio repeaters have had time to start their transmitters before frames are sent. 6.7.1.9. Remote Receiver Sync Timer T105 T105, the Remote Receiver Sync Timer, introduces additional delay time after TXDELAY, if needed, to allow a remote receiver to sync up before transmitting frames. 6.7.1.10. Ten Minute Transmission Limit Timer T106 T106, the Ten Minute Transmission Limit Timer, ensures that the transmitter is not keyed for more that ten minutes. 6.7.1.11. Anti-hogging Limit Timer T107 T107, the Anti-hogging Limit Timer, prevents a station from monopol- izing the channel. 6.7.1.12. Receiver Startup Timer T108 T108, the Receiver Startup Timer, ensures that the receiver is monitoring the status of the channel (busy or not) after unkeying the transmitter, before attempting to start transmitting again. 6.7.1.13. Next Segment Timer TR210 T210, the Next Segment Timer, ensures that the reassembler doesn't wait forever for the next segment of a segmented frame. 6.7.2. Parameters 6.7.2.1. Maximum Number of Octets in an I Field (N1) The default maximum number of octets allowed in the I field is 256. This variable is negotiable between end stations. The I field is an integral number of octets. 6.7.2.2. Maximum Number of Retries (N2) The maximum number of retries is used in conjunction with the T1 timer. 6.7.2.3. Maximum Number of I Frames Outstanding (k) The maximum number of I frames outstanding at a time is seven (modulo 8) or 127 (modulo 128). Appendix A -- Glossary Note: This appendix is not part of the protocol. ARRL American Radio Relay League C/R Command/Response Bits CSMA Carrier Sense Multiple Access DISC Disconnect Frame DL Communications between Layer 3 entity and data link layer DM Disconnect Mode Frame DLSAP Data-Link Service Access Point FCS Frame Check Sequence HDLC High-Level Data-Link Control I Information Frame ISO Interna-tional Standards Organization LAPA Link Access Protocol - Amateur LM Communications between link multiplexor and data-link Layer MDL Communications between management entity and data-link Layer N(r) Receive Sequence Number N(s) Send Sequence Number OSI Open Systems Interconnect P/F Poll/Final bit PH Communications between physical Layer and link multiplexor PID Protocol Identifier REJ Reject Frame RNR Receiver Not Ready Frame RR Receiver Ready Frame SABM Set Asynchronous Balanced Mode Frame SABME Set Asynchronous Balanced Mode Extended Frame SREJ Selective Reject Frame SSID Secondary Station Identifier TAPR Tucson Amateur Packet Radio TEST Test Frame TNC Terminal Node Controller UA Unnumbered Acknowledge Frame UI Unnumbered Information Frame V(a) Acknowledge State Variable V(r) Receive State Variable V(s) Send State Variable XID Exchange Identification Frame Appendix B -- References Note: This appendix is not part of the protocol. Black, Uyless D., 1993, "Data-Link Protocols." CCITT Recommendation X.25, "Interface between Data Terminal Equipment (DTE) and Data-Circuit Terminating Equipment (DCE for Terminals Operating in the Packet Mode on Public Data Networks." CCITT Recommendation Q.920/Q.921, Blue Book, 1989, "Digital subscriber sig- naling system no. 1 (DSS 1), Data link Layer." Fox, Terry L., October 1984, "AX.25 Amateur Packet-Radio Link-Layer Proto- col." ISO 3309, 4th edition, 1 June 91, "Information Technology - Telecommunica- tions and information exchange between systems -High-level data-link control (HDLC) procedures - Frame structure." ISO 4335, 4th edition, 15 September 91 (w/ amendment 4), "Information Tech- nology - Telecommunications and information exchange between systems - High- level data-link control (HDLC) procedures - Elements of procedures." ISO 7776, 1st edition, 15 December 86, "Information processing systems - Data communication - High-level data-link control procedures - Description of the X.25 LAPB-compatible DTE data-link procedures." ISO 7809, 2nd edition, 15 September 91 (w/ amendment 5, 6, and 7), "Informa- tion technology - Telecommunications and information exchange between systems - High-level data-link control (HDLC) procedures - Classes of procedures." ISO 8885, 2nd edition, 1 June 91 (w/ amendment 3, 4 and 5), "Information technology - Telecommunications and information exchange between systems - High-level data-link control (HDLC) procedures - General purpose XID frame information field content and format." ISO 8886, 1st edition, 15 June 91, "Information Technology - Telecommunica- tions and information exchange between systems -Data link service definition for Open Systems Interconnection ." Scace, Eric L., K3NA, Various AX.25 State Machines, 7th Computer Networking Conference. Page: 6 Page: 10 LAPA Link Access Protocol Specification Appendix C-1 Introduction to System Description Language C-1.1. Principles of Extended Finite State Machines An extended finite state machine models the operation of one party on a communications channel. The condition of the machine is described by its state, a resting condition where the machine awaits input signals from either the application or from remote parties on the communications channel. Whenever an input signal arises, the machine is triggered to execute a series of operations. These operations may include calculations, the gener- ation of signals to the remote parties on the communications channel, and the generation of signals to the application. The sequence of operations con- cludes with the machine reaching again a resting state (the same state or a different one). The entire sequence of operations performed by the machine is atomic. For modeling purposes, the sequence is considered to occur instantaneously, and can not be interrupted by any further event. The processing of such fur- ther events does not begin until the machine has completed the sequence of operations and has reached a resting state. Signals may be sent between machines within the same equipment, or via the communications channel(s) to machines in other equipment's. These signals are often called "Primitives". Extended finite state machines differ from their cousins, finite state machines, in three respects relevant to LAPA: * They can maintain internal variables, such as flags, sequence count- ers, and lists. * Timers may be set. The expiration of a timer at a later time gener- ates an input signal to trigger the machine to execute a specific series of operations. Timers may be stopped before they expire. * Internal queues may be maintained. The queues are used to retain in- put signals (or other information) for processing at a later, more appropriate time. C-1.2. SDL Symbol Definition Figure C-1.1 defines the symbols used in all of the SDL graphic de- scriptions. You may find it helpful to review the text below and the figure along with an actual SDL description from one of the following appendices. The SDL descriptions combine together the operations described by the various symbols into a sequence that is read down the page. The state symbol denotes the resting states of the extended finite state machine. Each state is numbered and named. The sequence number simply indicates the order in which the states are drawn in the SDL. All the per- mitted sequences of operations from a given state originate below the corres- ponding state symbol. For convenience, each SDL machine is accompanied by a summary page that lists, among other things, all of the state names and their corresponding numbers. Input signal reception (primitive) symbols have notches on either the left or right side. By convention, inputs with the notch on the left are from higher or equal layer state machines; inputs with the notch on the right are from the lower layer state machine. The name of the input primitive is labeled within the symbol. The SDL machine summary page lists all of the in- put primitives by name and source. In addition, the left-notch input signal symbol is used for timer ex- piration. The number of the expired timer is written inside the symbol. All timers are numbered, by convention, with indications beginning "T" and then (usually) a three-digit number. The "hundreds" digit indicates the OSI layer number at which the state machine resides; e.g., T1xx timers are physical layer, T2xx timers are data-link layer, etc. However, in order to prevent confusion, the present indicators T1 and T3 are used for LAPA timers. The SDL machine summary page lists all of the timers by their indicator, and gives a brief description of the purpose of each timer. Similarly, output signal reception (primitive) symbols have pointers on either the left or right side. Output symbols pointing to the left are outputs to the higher or equal layer state machines; outputs pointing to the right are to the lower layer state machine. The name of the output primitive is written within the symbol. The SDL machine summary page lists all of the output primitives by name and destination. Internal signal symbols are used to post items onto queues (points to left) and to trigger the state machine when something is waiting on the que- ues to be popped off (notch to left). Each internal signal has a description label identifying which queue is involved, and what material is being posted or popped. The SDL machine summary page describes each internal queue used by the state machine. The save symbol is used to indicate that a particular input event does not cause operations to be done in the present state. Instead, that particular input event is "saved" until the state machine (triggered by other events) has reached a new and different state. The processing description symbol contains within it a description of internal action(s) executed by the state machine. Examples of these actions are starting and stopping timers, setting and clearing flags, and setting values into variables. The test symbol is used for branching. The text written within the symbol is posed as a question, and then the appropriate branch is taken. The subroutine symbol is used to encapsulate frequently used se- quences of steps; the name of the subroutine is written within the symbol. The expansion of the subroutine is listed at the end of the SDL machine de- scription. Subroutine expansions begin with a subroutine start symbol, flow down the page through the specified sequence of operations, and end with the return-from-subroutine symbol. Note that subroutines are not permitted to contain states, nor are they permitted to branch into different return legs. Each subroutine has a single point of return. [example.ps] Figure C-1.1 SDL Examples C-1-4 Appendix C-2-A. Simplex Physical Layer State Machines C-2-A.1. Interaction with the Link Multiplexor The Link Multiplexor State Machine directs the operation of the sim- plex Physical State Machine through the physical (PH) primitives described below. PH-SEIZE Request -- This primitive requests the simplex state machine to begin transmitting at the next available opportunity. When that opportun- ity has been identified (according to the CSMA/p-persistence algorithm in- cluded within), the transmitter started, a parameterized window provided for the start-up of a conventional repeater (if required), and a parameterized time allowed for the synchronization of the remote station's receiver (known as TXDELAY in most implementations), then a PH-SEIZE Confirm primitive is re- turned to the link Multiplexor. PH-DATA Request -- This primitive from the Link Multiplexor State Machine provides a LAPA frame of any type (UI, SABM, I, etc.) that is to be transmitted. An unlimited number of frames may be provided. If the trans- mission exceeds the 10-minute limit or the anti-hogging time limit, the half- duplex Physical State Machine automatically relinquishes the channel for use by the other stations. The transmission is automatically resumed at the next transmission opportunity indicated by the CSMA/p-persistence contention algo- rithm. PH-RELEASE Request -- The Link Multiplexor State Machine provides this primitive when the submission of a sequence of frames to be transmitted on behalf of a particular LAPA connection has been completed. The simplex Physical State Machine will then piggyback any straggling digipeat frames (if time permits) and then relinquish the channel. PH-EXPEDITED-DATA Request -- This primitive from the Link Multiplexor State Machine provides the LAPA frame that is to be transmitted immediately. The simplex Physical State Machine gives preference to priority frames over normal frames, and will take advantage of the PRIACK window. Priority frames can be provided by the link multiplexor at any time; a PH-SEIZE Request and subsequent PH Release Request are not employed for priority frames. PH-DATA Indication -- During reception, the simplex Physical State Machine provides each LAPA frame to the link multiplexor in a Frame primi- tive. No analysis is done on the frame by the simplex Physical State Mach- ine; it does not examine lengths, the frame check sequence, the need for digipeating, or any other content of the frame; these responsibilities are carried out by the higher level state machines. PH-BUSY Indication -- The simplex Physical State Machine provides this primitive whenever the channel becomes busy. "Busy" here means the de- tection of a valid modem synchronization sequence, HDLC Flags, or HDLC frames; it does not mean FM carrier detection on a two-meter radio! An indica- tion of busy is provided to the higher layer state machines so that various timers that supervise the LAPA connection can be suspended. This avoids the undesirable situation on a busy channel where LAPA, having sent data and ex- pecting and acknowledgement, times out and attempts retransmissions -- and the only reason an acknowledgement was not received was because the remote station did not yet have a chance to make a transmission. Since the channel is simplex, this primitive is also provided when the simplex Physical State Machine starts transmitting. PH-QUIET Indication -- The simplex Physical State Machine provides this primitive whenever the channel becomes quiet. Since the channel is sim- plex, this primitive is also provided when the simplex Physical State Machine finishes transmitting. C-2-A.2. Interface to the Hardware As the lowest layer state machine in the standard, this machine is envisioned to manipulate a typical radio tranceiver. The following primi- tives are used: Turn On Transmitter -- This primitive keys the transceiver's PTT line. Turn Off Transmitter -- This primitive unkeys the transceiver's PTT line. Frame -- This primitive passes data for actual transmission of a frame. Although SDL representation of bit-by-bit transmission of the contents of a frame are possible, they are not used here because the addi- tional complexity was not required. The Frame primitive differs, however, from all other primitives used in the state machines in one respect: it is not atomic. Under this model, the Frame primitive occupies time; this allows the simplex Physical State Machine to consume time associated with transmis- sion, and to trigger the 10 minute transmitter protection and anti-hogging timers. This primitive also passes data from an actual reception of a frame. Acquisition of Signal -- This primitive indicates the presence of modem synchronization, flag fill or frame structure. Loss of Signal -- This primitive indicates the loss of modem synchro- nization, flag fill or frame structure. C-2-A.3. Internal Operation of the Machine The internal states, queues, flags, and timers are summarized in figure C-2-A.1. All queues are first-in, first-out queues. These items are used in a straightforward manner; no further explanation will be provided here. Note that the anti-hogging time limit is not applied to the digipeating function. However, the 10-minute transmitter timer is enforced while digipeating. In the unlikely event that the 10-minute limit is exceeded, the transmission of digipeated frames is temporarily suspended and the channel is relinquished. After other stations have had the opportunity to digipeat frames (i.e., PRIACK expires), but before the p-persistence algorithm takes effect, the state machine jumps back on the channel to resume transmission of those frames still in the priority queue. While this logic is provided in the state diagrams for completeness, it seems unlikely that it would ever be used. PH Primitives (Received from the Link Multiplexor): PH-SEIZE Request PH-RELEASE Request PH-EXPEDITED-DATA Request PH-DATA Request PH Primitives (Sent to the Link Multiplexor): PH-SEIZE Confirm PH-BUSY Indication PH-QUIET Indication PH-DATA Indication PH Primitives (Received from the Radio): Acquisition of Signal Loss of Signal Frame PH Primitives (Sent to the Radio): Turn on Transmitter Turn Off Transmitter Frame States: 0 -- Ready 1 -- Receiving 2 -- Transmitter Suppression 3 -- Transmitter Start 4 -- Transmitting 5 -- Digipeating 6 -- Receiver Start Error Codes: No Error Codes Used. Queues: Priority Queue -- holds all expedited data frames to be transmitted in the order in which they arrived from the higher layer. Normal Queue -- holds all normal frames, plus Seize and Release Requests, in the order in which they arrived from the higher level. Flags and Parameters: Digipeating -- set when this transmission is for digipeating frames. Cleared when this transmission is for normal frames. Repeater Up -- set when repeater is expected to still be transmit- ting. Cleared when repeater carrier is expected to have dropped. Interrupted -- set when anti-hogging or 10-minute transmitter limits have interrupted the transmission of normal frames. p -- p-persistence value, in the range 0-1. Timers: T100 -- repeater hang (AXHANG) T101 -- priority window (PRIACK) T102 -- slottime (p-persistence) T103 -- transmitter startup (TXDELAY) T104 -- repeater startup (AXDELAY) T105 -- remote receiver sync T106 -- 10-minute transmission limit T107 -- anti-hogging limit T108 -- receiver startup Figure C-2-A.1 Summary of Primitives, States, Queues, Flags, Errors and Timers. [phs_01.ps] Figure C-2-A.2 Simplex Physical Ready State. [phs_11.ps] Figure C-2-A.3 Simplex Physical Receiving State. [phs_21.ps] Figure C-2-A.4 Simplex Physical Transmitter Suppression State. [phs_31.ps] Figure C-2-A.5 Simplex Physical Transmitter Start State. [phs_41.ps] Figure C-2-A.6 Simplex Physical Transmitting State. [phs_51.ps] Figure C-2-A.7 Simplex Physical Digipeating State. [phs_61.ps] Figure C-2-A.8 Simplex Physical Receiver Start State. [phs_s1.ps] Figure C-2-A.9 Simplex Physical Subroutines. C-2-A-12 Appendix C-2-B. Duplex Physical Layer State Machines C-2-B.1. Interaction with the Link Multiplexor The Link Multiplexor State Machine directs the operation of the duplex Physical State Machine through the physical (PH) primitives described below. PH-SEIZE Request -- This primitive requests the duplex state machine to begin transmitting. When that opportunity has been identified, the trans- mitter started and a parameterized time allowed for the synchronization of the remote station's receiver (known as TXDELAY in most implementations), then a PH-SEIZE Confirm primitive is returned to the link multiplexor. PH-DATA Request -- This primitive from the Link Multiplexor State Machine provides a LAPA frame of any type (UI, SABM, I, etc.) that is to be transmitted. An unlimited number of frames may be provided. If the trans- mission exceeds the 10-minute limit or the anti-hogging time limit, the duplex Physical State Machine shuts down the transmitter. PH-RELEASE Request -- The Link Multiplexor State Machine provides this primitive when the submission of a sequence of frames to be transmitted on behalf of a particular LAPA connection has been completed. PH-EXPEDITED-DATA Request -- This primitive from the Link Multiplexor State Machine provides the LAPA frame that is to be transmitted immediately. The duplex Physical State Machine gives preference to priority frames over normal frames. Priority frames can be provided by the link multiplexor at any time. PH-DATA Indication -- During reception, the duplex Physical State Machine provides each LAPA frame to the link multiplexor in a Frame primi- tive. No analysis is done on the frame by the duplex Physical State Machine; it does not examine lengths, the frame check sequence, or any other content of the frame; these responsibilities are carried out by the higher level state machines. PH-BUSY Indication -- The duplex Physical State Machine provides this primitive whenever the channel becomes busy. "Busy" here means the detection of a valid modem synchronization sequence, HDLC Flags, or HDLC frames; it does not mean FM carrier detection on a two-meter radio! An indication of busy is provided to the higher layer state machines so that various timers which are supervise the LAPA connection can be suspended. This avoids the undesirable situation on a busy channel where LAPA, having sent data and expecting and acknowledgment, times out and attempts retransmissions -- and the only reason an acknowledgment was not received was because the remote station did not yet have a chance to make a transmission. PH-QUIET Indication -- The duplex Physical State Machine provides this primitive whenever the channel becomes quiet. C-2-B.2. Interface to the Hardware As the lowest layer state machine in the standard, this machine manipulate a typical radio transceiver. The following primitives are used: Turn On Transmitter -- This primitive keys the transceiver's PTT line. Turn Off Transmitter -- This primitive unkeys the transceiver's PTT line. Frame -- This primitive passes data for actual transmission of a frame. Although SDL representation of bit-by-bit transmission of the contents of a frame are possible, they are not used here because the addi- tional complexity was not required. The Frame primitive, however, differs from all other primitives used in the state machines in one respect: it is not atomic. Under this model, the Frame primitive occupies time; this allows the duplex Physical State Machine to consume time associated with transmis- sion, and to trigger the 10 minute transmitter protection and anti-hogging timers. This primitive is also used to pass data from an actual reception of a frame. Acquisition of Signal -- This primitive indicates the presence of modem synchronization, flag fill or frame structure. Loss of Signal -- This primitive indicates the loss of modem synchro- nization, flag fill or frame structure. C-2-B.3. Internal Operation of the Machine The internal states, queues, flags, and timers are summarized in figure C-2-A.1. All queues are first-in first-out queues. These items are used in a straightforward manner, so no further explanation will be provided here. PH Primitives (Received from the Link Multiplexor): PH-SEIZE Request PH-RELEASE Request PH-EXPEDITED-DATA Request PH-DATA Request PH Primitives (Sent to the Link Multiplexor): PH-SEIZE Confirm PH-BUSY Indication PH-QUIET Indication PH-DATA Indication PH Primitives (Received from the Radio): Acquisition of Signal Loss of Signal Frame PH Primitives (Sent to the Radio): Turn on Transmitter Turn Off Transmitter Frame States: 0 -- Receiver Ready 1 -- Receiving 2 -- Transmitter Ready 3 -- Transmitter Start 4 -- Transmitting Error Codes: No Error Codes Used. Queues: Normal Queue -- holds all normal frames, plus Seize and Release Requests, in the order in that they arrived from the higher level. Flags and Parameters: Interrupted -- set when anti-hogging or 10-minute transmitter limits have interrupted the transmission of normal frames. Timers: T105 -- remote receiver sync T106 -- 10-minute transmission limit T107 -- anti-hogging limit Figure C-2-B.1 Summary of Primitives, States, Queues, Flags, Errors and Timers. [phd_01.ps] Figure C-2-B.2 Duplex Physical Receiver Ready State. [phd_11.ps] Figure C-2-B.3 Duplex Physical Receiving State. [phd_21.ps] Figure C-2-B.4 Duplex Physical Transmitter Ready State. [phd_31.ps] Figure C-2-B.5 Duplex Physical Transmitter Start State. [phd_41.ps] Figure C-2-B.6 Duplex Physical Transmitting State. Appendix C-3. Link Multiplexor State Machine C-3.1. Interaction with the Data-Link State Machine The Data-link State Machine directs the operation of the Link Multi- plexor State Machine through the link multiplexor (LM) primitives described below. LM-SEIZE Request -- This primitive request the Link Multiplexor State Machine to arrange for transmission at the next available opportunity. The Data-link State Machine uses this primitive when an acknowledgment must be made, but the exact frame in which the acknowledgment will be sent will be chosen when the actual time for transmission arrives. The Link Multiplexor State Machine uses the LM-SEIZE Confirm to indicate that the transmission opportunity has arrived. After the Data-link State Machine has provided the acknowledgment, the Data-link State Machine gives permission to stop trans- mission with the LM Release Request primitive. LM-DATA Request -- This primitive from the Data-link State Machine provides a LAPA frame of any type (UI, SABM, I, etc.) that is to be trans- mitted. An unlimited number of frames may be provided. The Link Multiplexor State Machine accumulates the frames in a first-in first-out queue until it is time to transmit them. LM-DATA Indication -- This primitive from the Link Multiplexor State Machine provides a LAPA frame of any type (UI, SABM, I, etc.) that has been received. An unlimited number of frames may be provided. C-3.2. Interaction with the Physical Layer State Machine The Link Multiplexor State Machine works with the physical layer state machine. Importantly, the variation in operating characteristics of radio channels is kept hidden from the Link Multiplexor State Machine. The Link Multiplexor State Machine uses the same primitives to communicate with the physical layer state machine, regardless of which type it is. PH-SEIZE Request -- This primitive is used by the Link Multiplexor State Machine before each transmission to request access to the radio chan- nel. PH-SEIZE Confirm -- This primitive notifies the Link Multiplexor State Machine when access has been obtained (i.e., the transmitter is opera- ting, any intervening repeater has had an opportunity to be activated, the remote station's receiver has had an opportunity to become synchronized, and the channel is considered ready to send traffic) . PH-DATA Request - This primitive is used by the Link Multiplexor State Machine to deliver each frame to the physical layer state machine. PH-RELEASE Request -- This primitive is used when all frames that have been awaiting transmission for a given link have been submitted for transmission. The intention here is that a single transmission will contain frames for only one remote station. The PH-RELEASE Request primitive permits the physical layer state machine to release the channel for use by others, for digipeating, and for receipt of acknowledgments in a contention environ- ment (such as shared simplex channels). PH-DATA Indication -- This primitive is used by the physical layer state machine to provide incoming frames to the Link Multiplexor State Mach- ine. The Link Multiplexor State Machine checks each incoming frame for FCS errors. Correctly-received frames are checked to see if digipeating by the station has been requested and if the digipeat function is enabled (a user specified parameter); if so, the frame is resubmitted to the physical layer state machine in a Digipeat Frame primitive. Correctly-received frames ad- dressed to this station are delivered to the indicated higher-layer Data-link State Machine (see Section 5.3.1). PH-EXPEDITE-DATA Request -- This primitive is used by the Link Multi- plexor State Machine to submit a frame to the physical layer state machine to be transmitted immediately. (PH-SEIZE Request and PH-RELEASE Request are not used for digipeat operation.) PH-BUSY Indication -- This primitive is used by the Link Multiplexor State Machine to suspend all LAPA data-link timers. PH-QUIET Indication -- This primitive is used by the Link Multiplexor State Machine to resume ticking on all LAPA data-link timers. The suspension of timers overcomes a problem noted in some implemen- tations on busy channels. This problem occurs when frames are transmitted and a response is expected. If the channel is busy, it is possible for the retry timers (LAPA timer T1) to expire before the remote station had an op- portunity to send any acknowledgment. This premature expiration causes need- less retries and polling, further cluttering an already busy frequency. C-3.3. Internal Operation of the Machine The internal states, queues and flags are summarized in figure C-3.1 All queues are first-in first-out queues. Three queues are used, in conjunction with two flags, to implement round-robin rotation among the vari- ous Data-link State Machines. The Awaiting Queue contains all primitives received from Data-link State Machines that have not yet had an opportunity to transmit. When a primitive pops off the Awaiting Queue, it and all other primi- tives from that same Data-link State Machine are placed in order on the Cur- rent Queue. The identity of this Data-link State Machine is maintained in the Current DL Flag. The Link Multiplexor State Machine then proceeds to ob- tain a transmission opportunity for that Data-link State Machine. Any fur- ther primitives received from that particular Data-link State Machine are added to the Current Queue. When the transmission opportunity arrives, every- thing in the Current Queue is conveyed to the physical layer state machine for transmission. (In the event of an overly large amount of information to be sent, the physical layer state machine makes whatever breaks in transmis- sion are appropriate for reasonable channel sharing. This is done within the physical layer state machine and hidden from the higher layer.) Once everything has been sent for the current Data-link State Machine, its identity is moved to the Served List. Any subsequent primitives from this Data-link State Machine are added to the Served Queue. The Link Multiplexor State Machine then goes back to the Awaiting Queue to pop off the next primitive, and thereby identify which Data-link State Machine has the next transmission opportunity. If the Awaiting Queue is empty, then the Link Multiplexor State Machine concludes that all Data- link State Machines that had frames to be sent have now been served. The queue system is reset by converting the Served Queue into the new Awaiting Queue, and by purging all identifiers from the Served List. LM Primitives (Received from LM): LM-SEIZE Request LM-RELEASE Request LM-DATA Request LM Primitives (Sent to LM): LM-SEIZE Confirm LM-DATA Indicate PH Primitives (Received from PH): PH-SEIZE Confirm PH-QUIET Indication PH-BUSY Indication PH-DATA Indication PH Primitives (Sent to PH): PH-SEIZE Request PH-RELEASE Request PH-EXPEDITED-DATA Request PH-DATA Request States: 0 -- Idle 1 -- Seize Pending 2 -- Seized Error Codes: No error codes used. Queues: Awaiting Queue -- queue of primitives received from Data-link State Machines that are not presently using the transmitter. Current Queue -- queue of primitives received from the Data-link State Machine that is presently using the transmitter. Served Queue -- queue of primitives received from Data-link State Machines that already have used the transmitter. Note -- after all Data-link State Machines have had an opportunity to be served, then the Served Queue is converted to the Awaiting Queue. Flags: Current DL -- Identifies the Data-link State Machine currently using the transmitter. Served List -- Identifies the Data-link State Machines that have already used the transmitter. This list is cleared when all Data-link State Machines with frames to send have been served. Timers: No timers used. Figure C-3.1. Summary of Primitives, States, Flags, Errors and Timers. [lm_01.ps] Figure C-3.1 Link Multiplexor Idle State. [lm_11.ps] Figure C-3.2 Link Multiplexor Seize Pending State. [lm_21.ps] Figure C-3.3 Link Multiplexor Seized State. [lm_s1.ps] Figure C-3.4 Link Multiplexor Subroutines. Appendix C-4. Data-Link State Machine C-4.1. Interaction with the Data-Link Service Access Point The data-link service access point directs the operation of the Data- link State Machine through the data link (DL) primitives described below. The segmentor state machine is between the datalink state machine and the Data-Link Service Access Point. It passes all DL primitives except DL-DATA and DL-UNIT-DATA through transparently. DL-CONNECT Request - this primitive is used by the Layer 3 entity to request the establishment of a LAPA connection. DL-CONNECT Indication - this primitive is used by the Data-link State Machine to indicate an LAPA connection has been requested. DL-CONNECT Confirm - this primitive is used by the Data-link State Machine to indicate a LAPA connection has been made. DL-DISCONNECT Request - this primitive is used by the Layer 3 entity to request the release of a LAPA connection. DL-DISCONNECT Indication - this primitive is used by the Data-link State Machine to indicate an LAPA connection has been released. DL-DISCONNECT Confirm - this primitive is used by the Data-link State Machine to indicate an LAPA connection has been released and confirmed. DL-DATA Request - this primitive is used by the Layer 3 entity to re- quest the transmission of data using connection oriented protocol. This frame is examined and acted upon by the segmentor, if necessary. DL-DATA Indication - this primitive is used by the reassembler to indicate reception of Layer 3 data using connection oriented protocol. DL-UNIT-DATA Request - this primitive is used by the Layer 3 entity to request the transmission of data using connectionless protocol. This frame is examined and acted upon by the segmenter, if necessary. DL-UNIT-DATA Indication - this primitive is used by the reassembler to indicate reception of Layer 3 data using connectionless protocol. DL-ERROR Indication - this primitive is used by the Data-link State Machine to indicate when frames have been received that are inconsistent with this protocol definition. This includes short frames, frames with inconsis- tent parameter values, etc. DL-FLOW-OFF request - this primitive is used by the Layer 3 entity to temporarily suspend the flow of incoming information. DL-FLOW-ON Request - this primitive is used by the Layer 3 entity to resume the flow of incoming information. C-4.2. Interaction with the Link Multiplexor State Machine The data-link machine directs the operation of the Link Multiplexor State Machine through the data link (LM) primitives described below. LM-SEIZE Request - this primitive is used by the Data-link State Mach- ine to request the Link Multiplexor State Machine to arrange for transmission at the next available opportunity. The Data-link State Machine uses this pri- mitive when an acknowledgment must be made, but the exact frame in which the acknowledgment is sent will be chosen when the actual time for transmission arrives. LM-SEIZE Confirm - this primitive indicates to the Data-link State Machine that the transmission opportunity has arrived. LM-RELEASE Request - this primitive is used by the Link Multiplexor State Machine to stop transmission. LM-EXPEDITED-DATA Request - this primitive is used by the Data-link State Machine to pass expedited data to the link multiplexor. LM-DATA Request - this primitive is used by the Data-link State Mach- ines to pass frames of any type (SABM, RR, UI, etc.) to the Link Multiplexor State Machine. LM-DATA Indication - this primitive is used by the Link Multiplexor State Machines to pass frames of any type (SABM, RR, UI, etc.) to the Data-link State Machine. C-4.3. Internal Operation of the Machine The internal states, queues and flags are summarized in figure C-4.1. All queues are first-in first-out queues. DL Primitives (Received from DL): DL-CONNECT Confirm DL-CONNECT Indicate DL-DISCONNECT Confirm DL-DISCONNECT Indicate DL-DATA Indicate DL-UNIT-DATA Indicate DL-ERROR Indicate DL Primitives (Sent to DL): DL-CONNECT Request DL-DISCONNECT Request DL-DATA Request DL-UNIT-DATA Request DL-FLOW-OFF Request DL-FLOW-ON Request LM Primitives (Sent to LM): LM-SEIZE Request LM-RELEASE Request LM-DATA Request LM-EXPEDITED-DATA Request LM Primitives (Received from LM): LM-SEIZE Confirm LM-DATA Indicate States: 0 -- Disconnected 1 -- Awaiting Connection 2 -- Awaiting Release 3 -- Connected 4 -- Timer Recovery Error Codes: A -- F=1 received but P=1 not outstanding. B -- Unexpected DM with F=1 in states 3, 4 or 5. C -- Unexpected UA in states 3, 4 or 5. D -- UA received without F=1 when SABM or DISC was sent P=1. E -- DM received in states 3, 4 or 5. F -- Data link reset; i.e., SABM received in state 3, 4 or 5. I -- N2 timeouts: unacknowledged data. J -- N(r) sequence error. L -- control field invalid or not implemented. M -- Information field was received in a U- or S-type frame. N -- Length of frame incorrect for frame type. O -- I frame exceeded maximum allowed length. P -- N(s) out of the window. Q -- UI response received, or UI command with P=1 received. R -- UI frame exceeded maximum allowed length. S -- I response received. T -- N2 timeouts: no response to enquiry. U -- N2 timeouts: extended peer busy condition. V -- No DL machines available to establish connection. Queues: I Frame Queue -- queue of information to be transmitted in I frames. Flags: Layer 3 Initiated -- SABM was sent by request of Layer 3; i.e., DL-CONNECT Request primitive. Peer Receiver Busy -- remote station is busy and cannot receive I frames. Own Receiver Busy -- Layer 3 is busy and cannot receive I frames. Reject Exception -- a REJ frame has been sent to the remote station. Selective Reject Exception -- a SREJ frame has been sent to the remote station. Acknowledge Pending -- I frames have been successfully received but not yet acknowledged to the remote station. SRT -- smoothed round trip time. T1V -- next value for T1; default initial value is initial value of SRT. N1 -- maximum number of octets in the information field of a frame, excluding inserted 0-bits. N2 -- maximum number of retries permitted. Timers: T1 -- outstanding I frame or P-bit. T3 -- idle supervision (keep alive). Figure C-4.1 - Summary of Primitives, States, Flags, Errors and Timers. [dl_01.ps] Figure C-4.2 - Data-Link Disconnected State [dl_11.ps] Figure C-4.3 - Data-Link Awaiting Connection State [dl_1a1.ps] Figure C-4.4 - Data-Link Awaiting Connection State (cont) [dl_21.ps] Figure C-4.5 - Data-Link Awaiting Release State [dl_2a1.ps] Figure C-4.6 - Data-Link Awaiting Release State (cont) [dl_31.ps] Figure C-4.7 - Data-Link Connected State [dl_3a1.ps] Figure C-4.8 - Data-Link Connected State (cont) [dl_3b1.ps] Figure C-4.9 - Data-Link Connected State (cont) [dl_3c1.ps] Figure C-4.10 - Data-Link Connected State (cont) [dl_41.ps] Figure C-4.11 - Data-Link Timer Recovery State [dl_4a1.ps] Figure C-4.12 - Data-Link Timer Recovery State (cont) [dl_4b1.ps] Figure C-4.13 - Data-Link Timer Recovery State (cont) [dl_4c1.ps] Figure C-4.14 - Data-Link Timer Recovery State (cont) [dl_4d1.ps] Figure C-4.15 - Data-Link Timer Recovery State (cont) [dl_s1.ps] Figure C-4.16 - Data-Link Subroutines State [dl_sa1.ps] Figure C-4.17 - Data-Link Subroutines State (cont) [dl_sb1.ps] Figure C-4.18 - Data-Link Subroutines State (cont) Appendix C-5. Management Data-Link State Machine C-5.1. Interaction with the Data-Link Service Access Point The Data-Link Service Access Point directs the operation of the Management Data-link State Machine through the data link (DL) primitives described below. MDL-NEGOTIATE Request - this primitive is used by the Layer 3 entity to request the Data-link State Machine to notify/negotiate. MDL-NEGOTIATE Confirm - this primitive is used by the Management Data-link State Machine to notify the Layer 3 entity notification/negotiation is complete. MDL-ERROR Indicate - this primitive is used by the Management Data- link State Machine to notify the Layer 3 entity notification/negotiation has failed. C-5.2. Interaction with the Link Multiplexor State Machine The Management Data-link State Machine directs the operation of the Link Multiplexor State Machine through the data link (LM) primitives described below. LM-DATA Request - this primitive is used by the Data-link State Mach- ines to pass frames of any type (SABM, RR, UI, etc.) to the Link Multiplexor State Machine. LM-DATA Indication - this primitive is used by the Link Multiplexor State Machines to pass frames of any type (SABM, RR, UI, etc.) to the Data- link State Machine. C-5.3. Internal Operation of the Machine The internal states, queues and flags are summarized in figure C-5.1. The Management Data-link State Machine handles the negotiation/notifi- cation of operational parameters. It uses a single command/response exchange to negotiate the final values of negotiable parameters. The station initiating the LAPA connection will send an XID command after it receives the UA frame. If the other station is using a version of LAPA earlier than 2.2, it will respond with a FRMR of the XID command. The default version 2.0 parameters will be used. If the other station is using version 2.2 or better, it will respond with an XID response. MDL Primitives (Received from MDL): MDL-NEGOTIATE Confirm MDL-ERROR Indicate MDL Primitives (Sent to MDL): MDL-NEGOTIATE Request LM Primitives (Sent to LM): LM-DATA Request LM Primitives (Received from LM): LM-DATA Indicate States: 0 -- Ready 1 -- Negotiating Error Codes: A -- XID command without P=1. B -- Unexpected XID response. C -- Management retry limit exceeded. D -- XID response without F=1. Queues: None used. Flags: RC -- Retry count. NM201 -- Maximum number of retries of the XID command. Timers: TM201 -- Retry timer for management functions. Figure C-5.1 - Summary of Primitives, States, Flags, Errors and Timers. [mdl_01.ps] Figure C-5.1 Management Data-Link Ready Stat [mdl_11.ps] Figure C-5.2 Management Data-Link Negotiating Stat [mdl_s11.ps] Figure C-5.3 Management Data-Link N1 Notification Subroutine [mdl_s21.ps] Figure C-5.4 Management Data-Link Window Notification Subrou-tine [mdl_s31.ps] Figure C-5.5 Management Data-Link T1 Negotiation Subroutine [mdl_s41.ps] Figure C-5.6 Management Data-Link Retry Notification Subroutine [mdl_s51.ps] Figure C-5.7 Management Data-Link Optional Functions Negotiation Subroutine [mdl_s61.ps] Figure C-5.8 Management Data-Link Classes of Procedure Negotia- tion Subroutines C-5-1 Appendix C-6 Segmenter/Reassembler C-6.1. Segmenter State Machine Only the following DL primitives will be candidates for modification by the segmented state machine: DL-DATA Request -- The user employs this primitive to provide infor- mation to be transmitted using connection-oriented procedures; i.e., using I frames. The segmenter state machine examines the quantity of data to be transmitted. If the quantity of data to be transmitted is less than or equal to the data link parameter N1, the segmenter state machine passes the primi- tive through transparently. If the quantity of data to be transmitted ex- ceeds the data link parameter N1, the segmenter chops up the data into seg- ments of length N1-2 octets. Each segment is prepended with a two octet header. See Figures 3.1 and 3.2. The segments are then turned over to the Data-link State Machine for transmission, using multiple DL Data Request primitives. All segments are turned over immediately; therefore the Data- link State Machine will transmit them consecutively on the data link. DL-UNIT-DATA Request -- The user employs this primitive to provide information to be transmitted using connectionless procedures; i.e. using UI frames. The segmenter state machine examines the quantity of data to be transmitted. If the quantity of data to be transmitted is less than or equal to the data link parameter N1, the segmenter state machine passes the primi- tive through transparently. If the quantity of data to be transmitted ex- ceeds the data link parameter N1, the segmenter chops up the data into seg- ments of length N1-2 octets. Each segment is prepended with a two octet header. See Figures 3.1 and 3.2. The segments are then turned over to the Data-link State Machine for transmission, using multiple DL Data Request pri- mitives. All segments are turned over immediately; therefore the Data-link State Machine will transmit them consecutively on the data link. All Other DL Primitives -- All other DL primitives are passed through the segmenter state machine unchanged. C-6.2. Reassembler State Machine All primitives from the Data-link State Machine are delivered trans- parently, except the following: DL-DATA Indication -- This primitive is examined by the reassembler state machine. If the accompanying received data begins with an octet other than 0x08, it is assumed it has not been segmented, and is passed up trans- parently. If the data begins with 0x08, the reassembler state machine allo- cates buffers and switches to state 1. After various checks for errors, this segment and all remaining segments received in subsequent DL Data Indication primitives are assembled together to recreate the original larger data unit. If a segment is received without the proper PID or out of sequence, the accumulated packets are discarded, buffers are freed, a DL Error Indication is delivered and the state machine returns to state 0. The larger data unit is delivered with one DL Data Indication primitive. DL-UNIT-DATA Indication -- This primitive is examined by the reassem- bler state machine. If the accompanying received data begins with an octet other than 0x08, it is assumed it has not been segmented, and is passed up transparently. If the data begins with 0x08, the reassembler state machine allocates buffers and switches to state 2. After various checks for errors, this segment and all remaining segments received in subsequent DL Unit Data Indication primitives are assembled together to recreate the original larger data unit. If a segment is received without the proper PID or out of se- quence, the accumulated packets are discarded, buffers are freed, a DL Error Indication is delivered and the state machine returns to state 0. The larger data unit is delivered with one DL Unit Data Indication primitive. Timer TR210 Expiry -- This primitive occurs when a segment is not received before timer TR210 times out. When this primitive is received, the accumulated packets are discarded, buffers are freed and the state machine returns to state 0. An DL Error Indication is passed to the higher level. All Other DL Primitives -- All other DL primitives are passed through the reassembler state machine unchanged. If the state machine is in states 1 or 2 when another DL primitive is received, the accumulated packets are discarded, buffers are freed and the state machine returns to state 0. An DL Error Indication is passed to the higher level. C-6.3. Internal Operation of the Machine The internal states, error codes, and timers are summarized in figure C-2.1. C-6.3.1. Internal Operation of the Segmenter State Machine The segmenter state machine operation is quite straightforward. Only one state exists for this machine. C-6.3.2. Internal Operation of the Reassembler State Machine The reassembler state machine resides in the Null state until the start of a segmented data stream is detected. At this point, a check is made to ensure that the first segment received is, in fact, the first segment of the message. This check is performed by examining octet 2, bit 8 of the segment header (see figure 6.X). If this is not the first segment, then the reassembler state machine assumes that the actual first segment was lost somewhere, and signals an error. All segments will be discarded as they are received. Assume now that the first segment was received correctly. The reas- sembler state machine then allocates sufficient storage to receive all the remaining segments; this prevents deadly embrace (resource deadlock) condi- tions. The reassembler state machine enters either the reassembling data state (if segments are arriving in I frames) or the reassembling unit data state (if segments are arriving in UI frames). A lengthy timer supervises both of these states; its purpose is to protect the reassembly process from hanging if a very long delay happens to occur (e.g., the remote station breaks down and never completes transmission). This timer is TR210: "R" for reassembler; "2" for level 2, the data link level of the OSI open systems interconnection protocol architecture; and "10" simply to avoid confusion with any other timers in this family of state machines. Each incoming segment is examined to ensure that it is indeed the next expected segment. If the loss of a segment is detected, the entire accumulation of data is discarded and an error notification is provide to the LAPA user. No attempt is made by the segmenter and reassembler state mach- ines to recover segmented data units; this is left to the higher level LAPA user. Rather the reassembler state machine works to ensure that large data units are completely received and correctly reassembled over the data link. In other words, segmentation error detection is provided, but no segmentation error correction is provided. The reassembler state machine also insists that, once the transmis- sion of a segmented large data unit is begun, all segments will be transmit- ted until the complete large data unit has been transferred. No other event is permitted to occur over the data link. This constraint is imposed for two reasons: * to ensure that stations with multiple data links minimize the amount of buffer capacity tied up in partially received or transmitted large data units. This in turn reduces connectionless links; and, * to minimize the delay in transmission of large data units, once the large data unit has reached the top of the queue. C-6.4. Final Observations As mentioned above, the use of connection-oriented data-link proced- ures is recommended when segmentation is used across data links with even moderately low collision levels. If connectionless data-link procedures (UI frames) are used to carry segments, the loss of a single UI frame will result in the loss of the entire segmented large data unit; higher level attempts at recovery will increase the amount of congestion on the physical channel. DL Primitives (Received from DLSAP DL-DATA Request DL-UNIT-DATA Request NOTE: all other primitives are passed transpar- ently. DL Primitives (Sent to DLSAP DL-DATA Indication DL-UNIT-DATA Indication DL-ERROR Indication NOTE: all other primitives are passed transpar- ently. DL Primitives (Received from the Data-Link State Machine) DL-DATA Indication DL-UNIT-DATA Indication NOTE: all other primitives are passed trans- parently. DL Primitives (Sent to the Data-Link State Machine) DL-DATA Request DL-UNIT-DATA Request NOTE: all other primitives are passed transpar- ently. Segmenter States 0 -- Ready Reassembler States 0 -- Null 1 -- Reassembling Data 2 -- Reassembling Unit Data Queues None. Error Codes Y -- data too long to segment Z -- reassembly error. Flags and Parameters N -- number of segments remaining to be reassembled. Timers TR210 -- time limit for receipt of next segment. Figure C-6.1. Primitives, States, Queues, Flags, Parameters, Errors and Timers. [seg_01.ps] Figure C-6.2. Segmenter Ready State. [reass_01.ps] Figure C-6.3. Reassembler Ready State. [reass_11.ps] Figure C-6.4. Reassembler Assembling Data State. [reass_21.ps] Figure C-6.5. Reassembler Assembling Unit Data State. Appendix D DLSAP and Primitives D.1. Model of a Data-Link Connection A DLSAP is the point at which the data-link layer provides services to Layer 3. It provides a uniform programming interface to access the data-link services. This Appendix specifies this interface but does not specify the upper layer entities. In a basic user TNC, the upper layer entity may consist only of a Layer 7 user application with Layers 3-6 being null. The following primitives are used to pass commands and receive re- sponses from the DLSAP. DL-CONNECT Request (Called Callsign) - this primitive is used by the Layer 3 entity to request the establishment of a LAPA connection. DL-CONNECT Indication (Calling Callsign) - this primitive is used by the Data-link State Machine to indicate a LAPA connection has been requested. DL-CONNECT Confirm (VOID) - this primitive is used by the Data-link State Machine to indicate an LAPA connection has been made. DL-DISCONNECT Request - this primitive is used by the Layer 3 entity to request the release of a LAPA connection. DL-DISCONNECT Indication - this primitive is used by the Data-link State Machine to indicate a LAPA connection has been released. DL-DISCONNECT Confirm - this primitive is used by the Data-link State Machine to indicate a LAPA connection has been released and confirmed. DL-DATA Request - this primitive is used by the Layer 3 entity to re- quest the transmission of data using connection oriented protocol. This frame is examined and acted upon by the segmenter, if necessary. DL-DATA Indication - this primitive is used by the reassembler to in- dicate reception of Layer 3 data using connection oriented protocol. DL-UNIT-DATA Request - this primitive is used by the Layer 3 entity to request the transmission of data using connectionless protocol. This frame is examined and acted upon by the segmenter, if necessary. DL-UNIT-DATA Indication - this primitive is used by the reassembler to indicate reception of Layer 3 data using connectionless protocol. DL-ERROR Indication - this primitive is used by the Data-link State Machine to indicate when frames have been received that are inconsistent with this protocol definition. This includes short frames, frames with inconsis- tent parameter values, etc. The error indications are discussed in the SDL appendices. DL-FLOW-OFF Request - this primitive is used by the Layer 3 entity to temporarily suspend the flow of incoming information. DL-FLOW-ON Request - this primitive is used by the Layer 3 entity to resume the flow of incoming information. MDL-NEGOTIATE Request - this primitive is used by the Layer 3 entity to request the Data-link State Machine to notify/negotiate. MDL-NEGOTIATE Confirm - this primitive is used by the Management Data-link State Machine to notify the Layer 3 entity notification/negotiation is complete. MDL-ERROR Indicate - this primitive is used by the Management Data- link State Machine to notify the Layer 3 entity notification/negotiation has failed. D.2. Queue Model Concepts The queue model represents the operation of the Data-Link Connection (DLC) in the abstract by a pair of queues linking the two DLSAPs. There is one queue for each direction of information flow (Figure D.1). ------------- ------------- | Data Link | | Data Link | | Service | | Service | | User A | | User B | ------------- ------------- | | | | ---(DLSAP)--- ---(DLSAP)--- ^ | ^ | | +---------Queue from A to B----------+ | | | +-------------Queue from B to A--------------+ Figure D.1. Queue Model of a DLC Each queue represents a flow control function in one direction of transfer. The ability of a Data-Link Service (DLS) user to add objects to a queue will be determined by the behavior of the other DLS user in removing objects from the queue and the state of the queue. Objects are entered or removed from the queue as a result of interactions at the two DLSAPs. The pair of queues is considered to be available for each DLS user. The following objects may be placed in a queue by a DLS user: * a connect object, representing a DL-CONNECT primitive and its parameters. * a data object, representing a DL-DATA primitive and its parameters. * a disconnect object, representing a DL-DISCONNECT primitive and its parameters. The following objects may be placed in a queue by the DLS-provider: * a disconnect object, representing a DL-DISCONNECT primitive and its parameters. The queues are defined to have the following general properties: * a queue is empty before a connect object has been entered and can be returned to this state, with loss of its contents, by the DLS pro- vider. * objects are entered into a queue by the sending DLS user, subject to control by the DLS provider. Objects may also be entered by the DLS provider. * objects are removed from the queue, under the control of the receiving DLS user. * objects are normally removed in the same order that they were entered. * a queue has a limited capacity, but this capacity is not necessarily either fixed or determinable. D.3. DLC Establishment A pair of queues is associated with a DLC between two DLSAPs when the DLS provider receives a DL-CONNECT request primitive at one of the DLSAPs, and a connect object is entered into one of the queues. From the standpoint of the DLS users of the DLC, the queues remain associated with the DLC until a disconnect object representing a DL-DISCONNECT primitive is either entered or removed from the queue. DLS user A, who initiates a DLC establishment by entering a connect object representing a DL-CONNECT request primitive into the queue from DLS user A to DLS user B, is not allowed to enter any other object, other than a disconnect object, into the queue until after the connect object representing the DL-CONNECT confirm primitive has been removed from the DLS user B to DLS user A queue. In the queue from DLS user B to DLS user A, objects can be entered only after DLS user B has entered a connect object representing a DL-CONNECT response primitive. The properties exhibited by the queues while the DLC exists represent the agreements reached among the DLS users and the DLS provider during this connection establishment procedure. D.4. Data Transfer Flow control on the DLC is represented in this queue model by the management of the queue capacity, allowing objects to be added to the queues. The addition of a object may prevent the addition of a further object. Once objects are in the queue, the DLS provider may manipulate pairs of adjacent objects, resulting in deletion. An object may be deleted if, and only if, the object that follows it is defined to be destructive with respect to the object. If necessary, the last object on the queue will be deleted to allow a destructive object to be entered - they may therefore always be added to the queue. Disconnect objects are defined to be destructive with respect to all objects. The relationship between objects that may be manipulated in the above fashion are summarized in figure D.2. Following Object Connect Data Sync Disconnect Preceding Object Connect N/A -- N/A DES Data N/A -- N/A DES Sync N/A -- N/A DES Disconnect N/A N/A N/A DES Where: N/A Not a valid state of the queue -- Not to be destructive nor to be able to advance ahead DES To be destructive to the preceding object Figure D.2. Relationships between Queue Model Objects Whether the DLS provider performs actions resulting in deletion or not will depend upon the behavior of the DLC users. In general, if a DLS user does not remove objects from a queue, the DLS provider shall, after some unspecified period of time, perform all the permitted deletions. D.5. DLC Release The insertion into a queue of a disconnect object, which may occur at any time, represents the initiation of the DLC release procedure. The re- lease procedure may be destructive with respect to other objects in the two queues and eventually results in the emptying of the queues and the disasso- ciation of the queues with the DLC. The insertion of a disconnect object may also represent the rejection of a DLC establishment attempt or the failure to complete DLC establishment. In such cases, if a connect object representing a DL-CONNECT request primi- tive is deleted by a disconnect object, then the disconnect object is also deleted. The disconnect object representing the DL-CONNECT response. D.6. Relationship of Primitives at the Two DLC Endpoints A primitive issued at one DLC endpoint will, in general, have conse- quences at the other DLC endpoint. The relationship of primitives of each type at one DLC endpoint to primitives at the other DLC endpoint are defined in the appropriate subclauses A simple connection oriented transmission of data would be handled by the following primitives at the DLSAPs: Station A DLSAP DLSAP Station B DL-CONNECT Request -->| | | |--> DL-CONNECT Indication DL-CONNECT Confirm <--| | ...connection established... MDL-NEGOTIATE Request -->| | MDL-NEGOTIATE Confirm <--| | ...parameters negotiated... DL-DATA Request -->| | | |--> DL-DATA Indication DL-DATA Confirm <--| | ...data packet passed... DL-DATA Request -->| | | |--> DL-DATA Indication DL-DATA Confirm <--| | . | | . . | | . . | | . . | | . ...all data has been passed... DL-DISCONNECT Request -->| | | |--> DL-DISCONNECT Indication DL-DISCONNECT Confirm <--| | ...disconnection... Figure D.3. Example of a Connection Oriented Data Exchange Notice that the MDL primitives do not generate an Indicate primitive nor require a Response primitive from the Layer 3 entity in the station B. The MDL entities in the stations A and B work on a peer-to-peer relationship. The other primitives work in groups of 4 with the Request from the station A causing an Indicate in the station B, and a Response in station B causing a Confirm in the station A.