INTERNET-DRAFT expiration date: March, 2001 Network Working Group J. Rodriguez Request for Comments: nnnn Obsoletes: September 2000 Category: Informational High Level Logical Link Control (HLLC) draft-rodriguez-hllc-00.txt Status of this Memo: -------------------- This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026. The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This RFC suggests a proposed protocol for the Internet community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited. Acknowledgment: --------------- Table of Contents ----------------- Abstract........................................................... 3 1.1 Motivation .................................................... 3 1.2 Scope ......................................................... 5 1.3 Introduction .................................................. 5 2. The format, Fields, control values and options values........... 6 2.1 Format of the HLLC frame ...................................... 6 2.2 Fields ........................................................ 6 2.3 Control Values ................................................ 10 2.3.1 Information (I) ............................................. 11 2.3.2 Test ........................................................ 13 2.3.3 Window Identification (WID) ................................. 14 2.3.4 Set Asynchronous Balance Mode Extended (SABME) .............. 15 2.3.5 Unnumbered Acknowledgement (UA) ............................. 17 2.3.6 Disconnect Mode (DM) ........................................ 17 2.3.7 Received Ready (RR) ......................................... 19 2.3.8 Received Not Ready (RNR) .................................... 21 2.3.9 Re-Send Frame (RSFR) ........................................ 22 2.3.10 Frame Rejected (FRMR) ...................................... 24 2.3.11 Change Window Size (CHWZ) .................................. 26 2.3.12 Status of sent Packets (SOSP) .............................. 28 2.3.13 Loopback (LOOP) ............................................ 29 2.3.14 Options Only (OO) .......................................... 31 2.3.15 Summarize Table ............................................ 32 2.4 Flags PDUs..................................................... 32 2.4.1 Reset (RST) ................................................. 33 2.4.2 Synchronization (SYN) ....................................... 33 2.4.3 Final (FIN) ................................................. 34 J. Rodriguez Informational [Page 1] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.5 Option Code Values ............................................ 34 2.5.1 More data/value ............................................. 34 2.5.2 User ID ..................................................... 35 2.5.3 Password .................................................... 35 2.5.4 User ID and Password Return code............................. 35 2.5.5 Disconnect Mode or Reset return code ........................ 36 2.5.6 Incoming Banner ............................................. 36 2.5.7 Frame Rejected Return Code .................................. 36 2.5.8 Maximum MTU Size (MMTU)...................................... 37 2.5.9 Packet Not Acknowledged (PNACK) ............................. 37 2.5.10 Packet Acknowledged (PACK) ................................. 37 2.5.11 Resend Frame Return Code ................................... 38 2.5.12 New Window Size (NWZ) ...................................... 38 2.5.13 Old Window Size (OWZ) ...................................... 38 2.5.14 HLLC Version ............................................... 39 2.6 Summarized Option's Table...................................... 40 2.7 Traffic Flow .................................................. 3 Functions, variables, timers, counters and Conditions ........... 41 3.1 Poll Bit Function ............................................. 42 3.2 Final Bit Function ............................................ 42 3.3 Duplicated Packets ............................................ 42 3.4 Send State Variable V(S) ...................................... 42 3.5 Received State Variable V(R) .................................. 43 3.6 Control Begin Send Variable B(S) .............................. 43 3.7 Control End Send Variable E(S)................................. 43 3.8 Begin and End Send Variables Functions ........................ 43 3.9 Control Begin Received Variable B(R) .......................... 44 3.10 Control End Received Variable E(R) ........................... 44 3.11 Begin and End Receive Variables Functions .................... 44 3.12 Timers ....................................................... 44 3.13 Counters ..................................................... 45 3.14 Recovery Mode Condition ...................................... 45 3.15 NACK Condition ............................................... 46 4. Window Algorithm ............................................... 46 5.0 author's Address .............................................. 48 6.0 References .................................................... 49 J. Rodriguez Informational [Page 2] RFC nnnn High Level Logical Link Control (HLLC) September 2000 Abstract: --------- The great advance in telecommunications techniques to increase the level of reliability on the physical layer (Packet Loss) has made a tremendous contribution to the way higher layer protocols are designed nowadays. The High-Level Logical Link Control (HLLC) is intended for use as a highly reliable and fast host-to-host protocol between hosts current packet-switched computer communication networks. This document describes the functions to be performed by the High-Level Logical Link Control, the program that implements it, and its interface to programs or users that require its services. 1.1 Motivation: --------------- The tremendous high speed and almost error-free telecommunications infrastructure that has been in place using fiber optic cables has forced the designers of protocols to think differently. The constant increase in the types of applications that require Quality of Service in some way or at least to guarantee certain amount of bandwidth has become a necessity. When we study the protocols that we use today, we also need to study the history of them as part of their code in order to be able to understand them. Some of them were designed when the Telecommunications Infrastructure was not as robust as it is today, and of course not as fast. Also the amount of information and the number of users were very little compared with today's rates and users. Despite the fact that the designers had to deal with a lot of unknown variables in those days the protocols had to have a lot of fields to be able to recover in the worst case. Today's advance in fiber optics and more reliable communications allow the designers to be more flexible in their designs and to pass more of the error checking and recovering to the higher level applications and be more efficient on transport their data. HLLC is a connection-oriented and/or connection-less, end-to-end reliable protocol designed to fit into a layered hierarchy of protocols which support multi-network applications. J. Rodriguez Informational [Page 3] RFC nnnn High Level Logical Link Control (HLLC) September 2000 The HLLC provides for reliable inter-process communication between pairs of processes in host computers attached to distinct but interconnected computer communication networks. Very few assumptions are made as to the reliability of the communication protocols below the HLLC layer. HLLC assumes it can obtain a simple, potentially unreliable datagram service from the lower level protocols. In principle, the HLLC should be able to operate above a wide spectrum of communication systems ranging from hard-wired connections to packet-switched or circuit-switched networks. HLLC used the same philosophy of TCP which is "TCP is based on concepts first described by Cerf and Kahn in [1]. The TCP fits into a layered protocol architecture just above a basic Internet Protocol [2] which provides a way for the TCP to send and receive variable-length segments of information enclosed in Internet datagram "envelopes". The Internet datagram provides a means for addressing source and destination TCPs in different networks. The Internet protocol also deals with any fragmentation or reassembly of the TCP segments required to achieve transport and delivery through multiple networks and interconnecting gateways. The Internet protocol also carries information on the precedence, security classification and compartmentation of the TCP segments, so this information can be communicated end-to-end across multiple networks." [3]. Protocol Layering +---------------------+ | higher-level | +---------------------+ | HLLC | +---------------------+ | internet protocol | +---------------------+ |communication network| +---------------------+ Much of this document is written in the context of HLLC implementations which are co-resident with higher level protocols in the host computer. As a practical matter, many computer systems will be connected to networks via front-end computers, which house the HLLC and Internet protocol layers, as well as network specific software. The HLLC specification describes an interface to the higher level protocols which appears to be implementable even for the front-end case, as long as a suitable host-to-front end protocol is implemented [2]. J. Rodriguez Informational [Page 4] RFC nnnn High Level Logical Link Control (HLLC) September 2000 1.2 Scope: ---------- The HLLC is intended to provide a reliable process-to-process communication service in a multi-network environment. The HLLC is intended to be a host-to-host protocol in common use in multiple networks. 1.3. Introduction The HLLC protocol described here represents a new Windowing algorithm that is able to adjust more efficiently to unpredictable congestion on the network. The other characteristic of this new protocol is better utilization of the resources available at any particular time. HLLC is able to work under any Quality of Services determined by the maximum available bandwidth using any type of queuing techniques available today. Some of the fields used in TCP as well as the commands and responses used in the LLC format's PDU (Protocol Data Unit) respectively, have been proposed under the HLLC header. Therefore, the way those fields operate under their original protocols shall be kept under HLLC. The concept of the fields shall be the same but the way they will be used will vary within in a few differences. The HLLC protocol takes the best of each one as part of its format, with the main difference in the way the fields are used and with the addition of a new Windowing algorithm that helps to take more control and increase the speed of the transport data link connection. 2. The Format, the fields, the control values and the option codes: This section describe the Format of the HLLC and explains each of the fields used in the PDU, the different control values as of the writing of this reference, as well as the different option codes. J. Rodriguez Informational [Page 5] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.1 Format ---------- 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | Window | Window | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ -or- | -or- | |U|A|P|R|S|F|N|H|C|P|O| |D| | Send Sequence | Receive | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| | N(S) | Sequence N(R) | |G|K|H|T|N|N|C|L|R|F|T| | | | -or- | -or- | | | | | | | |K|C| | | | | | | Control | Control Data | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (If Any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (If Any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ User Datagram Header Format 2.2 Fields ---------- SOURCE PORT: 16 bit field is an optional field, when meaningful; it indicates the port of the sending process, and may be assumed to be the port to which a reply should be addressed in the absence of any other information. If not used, a value of zero is inserted. DESTINATION PORT: 16-bit field has a meaning within the context of a particular Internet destination address. LENGTH: 16-bit field is the length in octets of this user datagram including its header and data or options. (This means the minimum value of the length is twelve.) CHECKSUM: 16-bit field is the 16-bit one's complement of the one's complement sum of the header and the data, padded with zero octets at the end (if necessary) to make a multiple of two octets. J. Rodriguez Informational [Page 6] RFC nnnn High Level Logical Link Control (HLLC) September 2000 FLAGS: 16-bit field is used to indicate the type of PDU that has been sent or received. With the help of the different flags, the PDU can be mark as information, control, control with options, urgent, etc. For example, if a Frame Rejected (FRMR) control PDU is received, the option flag can be used to indicate the reason (return code) why the frame was rejected. URG: This bit shall be set with the value of "1" to indicate that an URGENT PDU has arrived and has to be processed immediately. Also this bit shall be used when the sender needs to inform the receiver that has to make some immediate changes and it has to respond to them quickly. ACK: This bit shall be set with the value of "1" to indicate that up to the value of the N(S) field, all the packets have been received with no errors. PSH: When the data that is being transferred is not enough to fill out the maximum data space, this bit shall be set with the value of "1" to indicate that the packet has to be pushed out to the receiver with- out waiting to be filled-out. RST: This bit shall be set with the value of "1" to indicate that the current established connection has to be re-initialized. SYN: This bit shall be used to synchronize the sequence numbers between the sender and the receiver before any data or options can be sent. The Value of the Send and receive Sequence Shall be equal to Zero, so the first Information sequence will be 1. SYN: bit set to "1" +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ SYN | SYN | |U|A|P|R|1|F|N|H|C|P|O| |D| | Send Sequence| Receive | |R|C|S|S| |I|A|L|/|/|P| C1 |E| | N(S)= 0 | Sequence | |G|K|H|T| |N|C|L|R|F|T| | | | | N(R)= 0 | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FIN: This bit shall be set with the value of "1" to indicate the end of the transmission, and that a new SYN process has to be done before trying to send any more PDUs. J. Rodriguez Informational [Page 7] RFC nnnn High Level Logical Link Control (HLLC) September 2000 NACK: This bit shall be used to indicate that either one or more of the packets got lost or did not arrive at the receiver during the maximum waiting windows time-out or by the time the sender sent a command/poll status request packet. HLLC: the HLLC flag shall be used to indicate the type of frame that is been transferred, either an information frame or control frame. The information frames are send with the HLLC bit is set to "0" and the control frames are sent with the HLLC bit set to "1". HLLC bit set to "0" +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |U|A|P|R|S|F|N|0|C|P|O| |D| | Send Sequence| Receive | |R|C|S|S|Y|I|A| |/|/|P| C1 |E| | N(S) | Sequence | |G|K|H|T|N|N|C| |R|F|T| | | | | N(R) | | | | | | | |K| | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ HLLC bit set to "1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |U|A|P|R|S|F|N|1|C|P|O| |D| | Control | Control | |R|C|S|S|Y|I|A| |/|/|P| C1 |E| | | Data | |G|K|H|T|N|N|C| |R|F|T| | | | | | | | | | | | |K| | | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ OPT: The options flag shall be set with the value of "1" to indicates the presence of options at the end of the header. When the HLLC flag is set with the value of "0" this field has to have a value of "0". If the HLLC flag has a value of "1" the OPT bit can be set to either "1" or "0" depending upon the control field. C/R: This bit shall be used to indicate the status of the PDU. When this bit has the value of "0" means it is a command (C) and when is set with the value of "1" means it is a response (R). J. Rodriguez Informational [Page 8] RFC nnnn High Level Logical Link Control (HLLC) September 2000 P/F bit: The Poll bit (P) shall be used to solicit a response from the addressed HLLC. The Final bit (F) shall be used to indicate the response PDU sent as the result of a soliciting (poll) command. In command (C) PDUs the P/F bit shall be referred to as the P bit. In response (R) PDUs it shall be referred as the F bit. The P/F bit exchange provides a distinct command/response linkage that is useful during both normal and recovery situations. C1: 3 bit field shall be used to indicate the number of retransmitted PDUs based on the expiration of the acknowledgment time-out timer. DE: The DE (Discard Elegible) bit shall be used to indicate that in case of network congestion, this I-PDU can be drop. N(S): 8-bit field shall be used to indicate the sequence number of the Information PDU that is been sent. Only Information PDUs shall contain N(S), the send sequence number of the sent PDU. N(R): 8-bit field. All Information and Control PDUs shall contain N(R), the expected sequence number of the next received Information PDU on the specified link connection. N(R) shall indicate that the station sending the N(R) has received correctly all PDUs numbered up through N(R)-1 on the specified link connection. WINDOW: The 8-bit field shall be used to indicate the maximum number of packets that the receiver or sender should be able to handle without being acknowledged. This field is updated by the receiver and can be modified by a control packet indicating the maximum number of packets that can be supported at any given time. CONTROL: 8-bit field shall be used to perform link connection control functions. The different control functions depend upon the state of the link connection. OPTIONS: The option field shall be used with control PDUs only. It is used to transport additional needed information in order to establish, maintain or terminate a link connection. The fields are code, length, and data/value. The code is an 8-bit field that indicates the chosen option, the 8-bit length field shall be specified in bytes (octets) indicating the size of the Data/Value field, the Data/Value field shall be used either to represent the value of the option or the data needed to be transmitted. The code is repeated at the end of the data/value field to indicate either the end of the options field or the next option in the case when more than one option is transmitted in the same PDU. The maximum number of options that can be transmitted on a single PDU, depends on the MTU size of the MAC layer and the type of options being carried. J. Rodriguez Informational [Page 9] RFC nnnn High Level Logical Link Control (HLLC) September 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | C O D E | L E N G T H | DATA / VALUE | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... |1|1|1|1|1|1|1|1| +-+-+-+-+-+-+-+-+ DATA: The data field is a variable length field up to the maximum MTU negotiated between the end-host. It is also determined by the MAC layer on each host. 2.3 CONTROL VALUES: --------------------- This section contains the definition of the set of commands and responses for each of the control field formats. Also this section specifies the elements of the LAN HLLC procedures for code-independent data communications using the HLLC PDU structure. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | Control Data | |U|A|P|R|S|F|N|H|C|P|O| |D| | | (If Any) | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| | | | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (If Any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (If Any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ These HLLC elements of procedure are defined specifically in terms of the actions that shall occur in the HLLC on the receipt of commands, and occasionally on the receipt of a reply to a command (response). The format defined for the control field shall be used to perform numbered information (I) transfer, unnumbered control and unnumbered information transfer (UI) functions. The control field is used only when the HLLC bit is set to 1. The value of Decimal Zero, "0x" Hex or 00000000 binary has been reserved for further use. J. Rodriguez Informational [Page 10] RFC nnnn High Level Logical Link Control (HLLC) September 2000 MSB LSB +-+-+-+-+-+-+-+-+ |C O N T R O L | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0| Reserved. +-+-+-+-+-+-+-+-+ 2.3.1 Information (I): This is the only time the control field is used as N(S) field and the HLLC bit is set with the value of "0". The I-format PDU shall be used to perform a numbered information transfer. Each I-format PDU shall have an N(S) sequence number and N(R)sequence number and shall or shall not acknowledge additional I-format PDUs at the receiving HLLC, and a P/F bit that shall be set to "1" or "0". 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | |U|A|P|R|S|F|N|H|C|P|O| |D| | Send Sequence | Receive | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| | N(S) | Sequence | |G|K|H|T|N|N|C|L|R|F|T| | | | | N(R) | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (If Any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: x x x 0 0 0 0 0 x x 0 (x => 1 or 0) Each Information PDU shall be sequentially numbered with a number that shall have a value between 1 and 255. The sequence number shall cycle through the entire range. The maximum number of sequential numbered I PDUs that may be outstanding (i.e., unacknowledged) in a given direction on a transport link connection at any given time shall never exceed one less than the maximum windows size value. This restriction shall prevent any ambiguity in the association of sent I PDUs with sequence numbers during normal operations and/or error recovery action. J. Rodriguez Informational [Page 11] RFC nnnn High Level Logical Link Control (HLLC) September 2000 A station HLLC shall maintain a send state variable V(S) for the I PDUs it sends and a receive state variable V(R) for the I PDUs it receives on each data link connection. The operations of V(S) shall be independent of the operations of V(R). The station HLLC shall also maintain the begin B(S) and end E(S) send variables as well as the begin B(R) and end E(R) receive variable in order to keep track of the valid ranges of I-PDUs N(S) and I-PDUs N(R) in coordination with the maximum sliding window cycle. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Responses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Information | Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Receive Not Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Re-send Frame | +-+-+-+-+-+-+-+-+-+-+-+ | Frame Reject | +-+-+-+-+-+-+-+-+-+-+-+ | Disconnect Mode | +-+-+-+-+-+-+-+-+-+-+-+ | Change Window Size | +-+-+-+-+-+-+-+-+-+-+-+ After the receipt of a command I PDU with the P bit set to "1", the HLLC shall respond at the earliest opportunity with any of the possible responses show above (I, RR, RNR, RSFR, FRMR, DM or CHWZ). The N(R) field shall be used as described on the Format Section. After the receipt of a command I PDU with the P bit set to "0", the HLLC shall not respond to the command I PDU. In the event that the HLLC has Information to send on the same transport link connection,it shall use the N(R) field to indicate the status of the receive state variable. In order to use the I-PDU as an acknowledge at the receiver end of the last error-free I PDU sent with the value of the N(R), no missing or discontinuous I-PDUs shall exist, and the ACK bit shall be set with the value of "1". In the event that there were missing or discontinuous I-PDUs at the time the I-PDU was sent, the N(R) field shall be used to indicate the status of the receive state variable ONLY and not be used as an acknowledgment of the up through N(R)-1 I-PDUs, so the value of the ACK bit shall be set to "0". J. Rodriguez Informational [Page 12] RFC nnnn High Level Logical Link Control (HLLC) September 2000 When a command PDU is received and there are missing I-PDUs, even though there is Information to be sent, an I-PDU shall NOT be used, instead a RR or a RNR PDU shall be sent with the NACK bit set to "1" and following the RR or RNR PDU procedures decribed below. After the response to the PDU command, then an I-PDU shall be sent if the need to send Information still exists. After waiting for the I-PDU command response with no success and after trying C1-INFO times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the I-PDU is retransmitted, and it shall be initialized with the value zero. 2.3.2 Test: The TEST command PDU shall be used to cause the destination HLLC to respond with the TEST response PDU at the earliest opportunity, thus performing a basic TEST of the HLLC to HLLC transmission path. The TEST command PDU shall not have any effect on any sequence numbers maintained by the remote HLLC and shall use the value of 1 in the control field. MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|1| TEST +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | | |U|A|P|R|S|F|N|H|C|P|O| |D| | | | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |1 0 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Data (If Any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 0 0 0 0 0 0 0 1 x x 0 (x => 1 or 0) J. Rodriguez Informational [Page 13] RFC nnnn High Level Logical Link Control (HLLC) September 2000 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Test | Test | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The TEST response shall be used to reply to the TEST command PDU. The TEST response PDU shall have the F bit set to the value of the P bit in the TEST Command PDU. If the DATA field is present in the TEST command, the same Data shall be returned in the corresponding PDU. After waiting for the I-PDU command response with no success and after trying C1-TEST times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the TEST PDU is retransmitted, and it shall be initialized with the value zero. 2.3.3 Window Identification: The Window Identification (WID) command PDU shall be used to advertise the MAXIMUM WINDOW SIZE (buffer space) the sender can allocate, and also to cause the destination HLLC to respond at the earliest opportunity indicating the MAXIMUM WINDOW SIZE (buffer space) PDU that it will use. The WID command PDU shall not have any effect on any sequence numbers maintained by the remote HLLC and shall use the value of 2 in the control field. MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|0| WID +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 14] RFC nnnn High Level Logical Link Control (HLLC) September 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | WID | |U|A|P|R|S|F|N|H|C|P|O| |D| | | | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |0 1 0 0 0 0 0 0|w w w w w w w w| |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 0 0 0 0 0 0 0 1 x x 0 (x => 1 or 0) (w => Maximum Window Size) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | WID | WID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Maximum Window Size shall not be larger than 255 (2^8 - 1) and greater than zero. The WID response shall be used to reply to the WID command PDU to indicate the Maximum Window Size of the receiver HLLC. The WID response PDU Shall have the F bit set to the value of the P bit in the WID Command PDU. After waiting for the WID PDU command response with no success and after trying C1-WID times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the WID PDU is retransmitted, and it shall be initialized with the value zero. 2.3.4 Set Asynchronous Balance Mode Extended: The Set Asynchronous Balance Mode Extended (SABME) command shall be used to establish a transport data link connection to the destination HLLC in the Asynchronous balance mode. No Data (I-PDUs) shall be permitted with the SAMBE command PDU. The Destination HLLC shall confirm the receipt of the SAMBE command PDU by sending an Unnumbered Acknowledgement (UA) response PDU or a Disconnect Mode (DM) response PDU on the same transport data link connection at the earliest opportunity. J. Rodriguez Informational [Page 15] RFC nnnn High Level Logical Link Control (HLLC) September 2000 MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|1| SABME +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | | |U|A|P|R|S|F|N|H|C|P|O| |D| | | | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 0 0 0 0 0 0 0 1 x x 0 (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | SABME | UA | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Disconnect Mode | +-+-+-+-+-+-+-+-+-+-+-+ Upon acceptance of the SAMBE command PDU (receipt of the UA Response PDU), the destination HLLC's send and receive state variables shall be set to zero. If the UA response PDU is received correctly, then the initiating HLLC shall also assume the asynchronous balance mode with its corresponding send and receive state variables set to zero. Previous PDUs that are unacknowledged when this command is completed shall remain unacknowledged. After waiting for the SABME PDU command response with no success and after trying C1-SABME times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the SABME PDU is retransmitted, and it shall be initialized with the value zero. J. Rodriguez Informational [Page 16] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.3.5 Unnumbered Acknowledgement: The Unnumbered Acknowledgement (UA) response PDU shall be used by a HLLC on the transport data link connection to acknowledge the receipt and acceptance of the SAMBE command PDUs. No Data (I-PDU) field shall be permitted with the UA responses PDU. MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|0| UA +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | | |U|A|P|R|S|F|N|H|C|P|O| |D| | | | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |1 1 0 0 0 0 0 0|0 0 0 0 0 0 0 0| |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (If Any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 0 0 0 0 0 0 0 1 x x x (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | UA | +-+-+-+-+-+-+-+-+-+-+-+ 2.3.6 Disconnect Mode: The Disconnect Mode (DM) command PDU shall be used to inform the receiver HLLC on the transport data link control, that the sender HLLC has been logically disconnected from the transport data link connection. The option flag shall be used in case the sender knows and/or wants to inform the receiver of the reason of the disconnect. No data (I-PDU) field shall be permitted with DM command or response PDUs. J. Rodriguez Informational [Page 17] RFC nnnn High Level Logical Link Control (HLLC) September 2000 MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|1| DM +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | | |U|A|P|R|S|F|N|H|C|P|O| |D| | | | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |1 0 1 0 0 0 0 0|0 0 0 0 0 0 0 0| |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options (If Any) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: x 0 0 0 0 0 0 1 x x x (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | DM | DM | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The disconnect Mode response shall be used to indicate to the Sender that the DM PDU has been received and acknowledged at the earliest opportunity and the Option flag shall not be permitted. After waiting for the DM PDU command response with no success and after trying C1-DM times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the DM PDU is retransmitted, and it shall be initialized with the value zero. J. Rodriguez Informational [Page 18] RFC nnnn High Level Logical Link Control (HLLC) September 2000 During the disconnect mode, the DM timer shall be activated and once reaching the value of the DM timer, a TEST command can be sent to see if the remote HLLC station is ready to reinitiate communications. After waiting for the TEST response PDU with no success and after trying C1-TEST times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the test command after C1 retransmissions. The C1 value shall be increased by one every time the TEST PDU is retransmitted, and shall be initialized with the value zero. 2.3.7 Receive Ready: The Receive Ready (RR) PDU shall be used by the HLLC to indicate it is ready to receive I-PDUs. All I-PDUs numbered up through N(R)-1 shall be considered as acknowledged if the ACK bit is set to "1", which means that all the I-PDUs up through N(R)-1 arrived with no errors and are sequentially ordered, so there are no missing I-PDUs. In the event that there were some missing I-PDUs at the time the command PDU arrived, the response N(R)-1 value shall indicate the the highest numbered I-PDU received with no errors and the NACK bit MUST be used and set with the value of "1" indicating that there were some missing I-PDUs along with the OPT bit to indicate to the sending side all the I-PDUs that did not arrive or were missed using the option PNACK (Packet Not Acknowledged). Once the NACK bit is used, the sender and the receiver MUST remain in the NACK Conditions until all the missing I-PDUs are received with no errors and a response PDU with the ACK bit set to "1" is received or sent. The N(R)-1 value MUST not be changed during the NACK condition. MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|1|0| RR +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 19] RFC nnnn High Level Logical Link Control (HLLC) September 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | Receive | |U|A|P|R|S|F|N|H|C|P|O| |D| | | Sequence | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |0 1 1 0 0 0 0 0| N(R) | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 0 x 0 0 0 0 x 1 x x x (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Responses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Ready | Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Receive Not Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Disconnect Mode | +-+-+-+-+-+-+-+-+-+-+-+ | Change Window Size | +-+-+-+-+-+-+-+-+-+-+-+ After waiting for the RR PDU command response with no success and after trying C1-RR times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the RR PDU is retransmitted, and it shall be initialize with the value zero. J. Rodriguez Informational [Page 20] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.3.8 Receive Not Ready: The Receive Not Ready (RNR) PDU shall be used by the HLLC to indicate a busy condition (i.e. a temporary inability to accept subsequent I-PDUs). All I-PDUs numbered up through N(R)-1 shall be considered as acknowledged if the ACK bit is set to "1", which means that all the I-PDUs up through N(R)-1 arrived with no errors and are sequentially ordered, so there are no missing I-PDUs. In the event that there were some missing I-PDUs at the time the command PDU arrived, the response N(R)-1 value shall indicate the highest numbered I-PDU received with no errors and the NACK bit MUST be used and set with the value of "1", indicating that there were some I-PDUs missing along with the OPT bit to indicate to the sending side all the I-PDUs that did not arrive or were missed using the option PNACK (Packet Not Acknowledged). Once the NACK bit is used, the sender and the receiver MUST remain in the NACK Conditions until all the missing I-PDUs are received with no errors and a response PDU with the ACK bit set to "1" is received or sent. The N(R)-1 value MUST not be changed during the NACK condition. All I-PDUs numbered N(R) and any subsequent I-PDUs received, if any, shall not be considered as acknowledged; the acceptance status of these PDUs shall be indicated in subsequent exchanges. The RNR condition shall only be cleared by the emission of a later RR command or response in the transport data link connection initiated by the HLLC that sent the RNR PDU, indicating it is no longer busy and it can start receiving I-PDUs. There is no time-out variable defined to indicate the maximum amount of times a HLLC connection shall be kept in this state. The upper layers might send a DM command after an application-specific time-out, but that application time-out value is out of the scope of this protocol. Once the HLLC stays in the RNR state, the receiver of the RNR PDU shall send periodic RR PDUs in order to be ready to re-initiate the send of I-PDUs by the time the response of the RR PDU becomes a RR PDU as well. It is the responsibility of the HLLC receiver to send a RR command PDU on the transport data link connection to the sender, as soon as it leaves the busy cycle and becomes ready to receive more I-PDUs. MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|1|1| RNR +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 21] RFC nnnn High Level Logical Link Control (HLLC) September 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | Receive | |U|A|P|R|S|F|N|H|C|P|O| |D| | | Sequence | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |1 1 1 0 0 0 0 0| N(R) | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 0 0 0 0 0 0 0 1 x x x (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Responses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Not Ready | Receive Ready | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Not Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Disconnect Mode | +-+-+-+-+-+-+-+-+-+-+-+ After waiting for the RNR-PDU command response with no success and after trying C1-RNR times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the RNR-PDU is retransmitted, and it shall be initialized with the value zero. 2.3.9 Re-Send Frame: The Re-Send Frame (RSFR) shall be used by the HLLC to indicate to the sender to retransmit the N(R) I-PDU. I-PDUs numbered up through N(R)-1 shall be considered as acknowledged and the ACK bit must be set to 1. The RSFR PDU does not require a poll command PDU to be triggered and can be sent at any time by the receiver. Upon the receive of a RSFR PDU, the N(R) PDU shall be sent at the earliest opportunity to the receiver, unless it has been marked as Urgent where it has to be processed as soon as possible. The Options flag shall be used to indicate the reason of the retransmission like bad CRC, not arrive under the expected time window, missing in the sequence, security check, etc. J. Rodriguez Informational [Page 22] RFC nnnn High Level Logical Link Control (HLLC) September 2000 MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|0| RSFR +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | Re-Send | |U|A|P|R|S|F|N|H|C|P|O| |D| | | Frame | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |0 0 0 1 0 0 0 0| N(R) | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: x 0 0 0 0 0 0 1 x x x (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Responses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Re-Send Frame | Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Not Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Disconnect Mode | +-+-+-+-+-+-+-+-+-+-+-+ In the event that the N(R) I-PDU can not be re-sent, a Disconnect Mode PDU shall be send with the option bit set to "1", indicating the reason of the Disconnect Mode PDU. In the event that the Sender cannot process the request because it is too busy at the time of the arrival, it shall send a RNR PDU and MAY use the option field to indicate the reason of the busy condition or for how long is going to stay in the RNR mode, or any other reason it may want to send. After waiting for the RSFR PDU command response with no success and after trying C1-RSFR times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the RSFR PDU is retransmitted, and it shall be initialized with the value zero. J. Rodriguez Informational [Page 23] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.3.10 Frame Rejected: The Frame Rejected (FRMR) PDU shall be used by the HLLC to report the observance of a condition, that is NOT correctable by re-sending the identical PDU, that resulted from the receipt of a PDU from the remote HLLC. The FRMR PDU shall be used in the case of the following conditions: 1) The receipt of a command PDU or a response PDU that is undefined or not implemented. 2) The receipt of a control PDU that is undefined or not implemented. 3) The receipt of an I-PDU with an information field that exceeded the established maximum information field length that can be accommodated by the receiving HLLC for that transport link connection. 4) The receipt of an invalid N(R) from the remote HLLC. An invalid N(R) shall be defined as one that signifies an I-PDU that has previously been sent and acknowledged (smaller than the B(S) variable), or signifies an I-PDU that has not been sent and is not the next sequential I-PDU awaiting to be sent (greater than the E(S) variable). 5) The receipt of an invalid N(S) from the remote HLLC. An invalid N(S) shall be defined as an N(S) that is greater than the E(R) variable or smaller than the B(R) value. The FRMR PDU may be used in the case of any of the following conditions: a) The receipt of an unsolicited response PDU. b) The receipt of an unsolicited F bit set to "1". c) The receipt of an unexpected UA response PDU. MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|1| FRMR +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 24] RFC nnnn High Level Logical Link Control (HLLC) September 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control |Frame Rejected | |U|A|P|R|S|F|N|H|C|P|O| |D| | | Received | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |1 0 0 1 0 0 0 0| | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: x 0 0 0 0 0 0 1 x x x (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Responses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Reject | Information | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Not Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Disconnect Mode | +-+-+-+-+-+-+-+-+-+-+-+ The option field shall be used to indicate the reason the frame has been rejected. Once upon the receipt of a FRMR PDU, it shall be passed to the upper layer to take the necessary actions on how to respond to that PDU. The responses shall be a Disconnect Mode, a RNR or an Information PDU. After waiting for the FRMR PDU command response with no success and after trying C1-FRMR times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the FRMR PDU is retransmitted, and it shall be initialized with the value zero. J. Rodriguez Informational [Page 25] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.3.11 Change Window Size: The Change Window Size (CHWZ) PDU shall be used to indicate that the buffer on the receiving side is becoming smaller to handle the amount of unacknowledged I-PDUs. The CHWZ command must use the URG bit to indicate that is a high priority control PDU, an also it must use the option bit to indicate the new and the old window sizes. All I-PDUs numbered up through N(R)-1 shall be considered as acknowledged if the ACK bit is set to "1", which means that all the I-PDUs up through N(R)-1 arrived with no errors and are sequentially ordered, so there are no missing I-PDUs. In the event that there were some missing I-PDUs at the time the command PDU was sent, the N(R)-1 value shall indicate the highest numbered I-PDU received with no errors and the NACK bit MUST be used and set with the value of "1" indicating that there were some I-PDUs missing along with the OPT bit to indicate the sending side all the I-PDUs that did not arrive or were missed using the option PNACK (Packet Not Acknowledged). Once the NACK bit is used, the sender and the receiver MUST remain in the NACK Conditions until all the missing I-PDUs are received with no errors and a response PDU with the ACK bit set to "1" is received or sent. The N(R)-1 value MUST not be changed during the NACK condition. The use of the new and old window sizes is based on the fact that changing the window size has a direct impact on the performance of the HLLC transport link control, and in the event that a CHWZ has been received by mistake, at least has to match the old window size to be taken. In the event that the CHWZ-PDU does not match the old window size, a frame rejected PDU (FRMR) shall be sent to indicate that the value is not correct and cannot be performed. When the CHWZ-PDU matches the old value of the Window Size on the HLLC transport link control, the receiver shall respond with the CHWZ-PDU using the same values of the option field in the command PDU to confirm that the new value has been accepted. MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|0| CHWZ +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 26] RFC nnnn High Level Logical Link Control (HLLC) September 2000 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | Receive | |U|A|P|R|S|F|N|H|C|P|O| |D| | | Sequence | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |0 1 0 1 0 0 0 0| N(R) | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 1 0 1 0 0 0 0|1 0 0 0 0 0 0 0|New Window Size|0 0 1 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 0|Old Window Size|1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 1 x 0 0 0 0 x 1 x x 1 (x => 1 or 0) Options Used: MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|1| NWS (New Window Size) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|1|0|0| OWS (Old Window Size) +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Response | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Change Window Size | Change Window Size | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Frame Rejected | +-+-+-+-+-+-+-+-+-+-+-+-+ After waiting for the CHWZ PDU command response with no success and after trying C1-CHWZ times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the CHWZ PDU is retransmitted, and it shall be initialized with the value zero. J. Rodriguez Informational [Page 27] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.3.12 Status of Sent Packets: The Status Of Sent Packets (SOSP) PDU shall be used to Request the I-PDUs that have been missed or not arrived up through the N(Q). The value of the N(S) shall be greater than the S(B) variable and lower than the E(S) variable. All I-PDUs numbered up through N(Q) shall be considered as acknowledged if the ACK bit is set to "1", which means that all the I-PDUs up through N(Q) arrived with no errors and are sequentially ordered, so there are no missing I-PDUs. In the event that there were some missing I-PDUs at the time the command PDU was sent, the N(Q) value shall indicate the highest numbered I-PDU received with no errors and the NACK bit MUST be used and set with the value of "1" indicating that there were some I-PDUs missing along with the OPT bit to indicate the sending side all the I-PDUs that did not arrive or were missed using the option PNACK (Packet Not Acknowledged). Once the NACK bit is used, the sender and the receiver MUST remain in the NACK Conditions until all the missing I-PDUs are received with no errors and a response PDU with the ACK bit set to "1" is received or sent. The N(Q) value MUST not be changed during the NACK condition. MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|1| SOSP +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | Up to the | |U|A|P|R|S|F|N|H|C|P|O| |D| | | I-PDU sent | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |1 1 0 1 0 0 0 0| N(Q) | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 0 x 0 0 0 0 x 1 x x x (x => 1 or 0) J. Rodriguez Informational [Page 28] RFC nnnn High Level Logical Link Control (HLLC) September 2000 If NACK bit is set to '1': +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0 0 0 1 0 0 0 0|1 0 0 0 0 0 0 0| P N A C K |0 0 0 1 0 0 0 0| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |1 0 0 0 0 0 0 0| P N A C K |... ... |1 1 1 1 1 1 1 1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+... ... +-+-+-+-+-+-+-+-+ PNACK is the value of the I-PDU that SHALL be re-sent and its C1 value shall be increased by one. Option Used: MSB LSB +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|0| PNACK (Packet Not Acknowledge) +-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Responses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Status of Sent Packets | Options Only | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Receive Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Receive Not Ready | +-+-+-+-+-+-+-+-+-+-+-+ | Disconnect Mode | +-+-+-+-+-+-+-+-+-+-+-+ After waiting for the SOSP PDU command response with no success and after trying C1-SOSP times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the SOSP PDU is retransmitted, and it shall be initialized with the value zero. 2.3.13 Loopback: The Loopback (LOOP) PDU shall be used to verify that the PDU arrived at the HLLC receiving station and returned with no errors, and it can be used as a way to measure the round trip delay of a single PDU as well as a stress test. J. Rodriguez Informational [Page 29] RFC nnnn High Level Logical Link Control (HLLC) September 2000 Upon the receipt of a Loopback, the receiver shall respond immediately without changing the information on the Options fields if any. The value of the N(P) is a random value between 0 and 255 and has no relation with the V(S) state variable. In the case the PDU is used as a stress test, it should send sequentially LOOP PDUs N(P) starting with 1 and no more than 255 without waiting for the responses. This is the ONLY PDU that allows to have more than one PDU outstanding with no response and be able to send another PDU. This allows to perform a stress test on the media as well as on the receiver. MSB LSB +-+-+-+-+-+-+-+-+ |1|0|1|0|1|0|1|0| Loopback (LOOP) +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | | |U|A|P|R|S|F|N|H|C|P|O| |D| | | | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |0 1 0 1 0 1 0 1| N(P) | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 1 0 0 0 0 0 0 1 x x x (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Responses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Loopback | Loopback | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ After waiting for the LOOP PDU command response with no success and after trying C1-LOOP times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the LOOP PDU is retransmitted, and it shall be initialized with the value zero. J. Rodriguez Informational [Page 30] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.3.14 Options Only: The Options Only (OO) PDU shall be used when there is no Information to send but there are some options that need to be interchange after the SYN process and before the FIN. The options that can be interchanged are a banner, asking for a User ID and Password, asking for the HLLC version that is used, etc. The value of the N(P) is a random number between 1 and 255 and shall not have any relation with the send state variable V(S). MSB LSB +-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|1|1| Options Only (OO) +-+-+-+-+-+-+-+-+ 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source Port | Destination Port | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Length | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | F L A G S | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Control | | |U|A|P|R|S|F|N|H|C|P|O| |D| | | | |R|C|S|S|Y|I|A|L|/|/|P| C1 |E| |1 1 1 1 1 1 1 1| N(P) | |G|K|H|T|N|N|C|L|R|F|T| | | | | | | | | | | | |K|C| | | | | | | | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ FLAGS VALUES: 0 0 0 0 0 0 0 1 x x 1 (x => 1 or 0) +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Command | Responses | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Options Only | Options Only | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ After waiting for the OO PDU command response with no success and after trying C1-OO times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the OO PDU is retransmitted, and it shall be initialized with the value zero. J. Rodriguez Informational [Page 31] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.3.15 Summarize Table: +-+-+-+-+-+-+-+-+ |C O N T R O L | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0| Reserved. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|1| TEST +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|0| WID (Window ID) +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|1| SABME (Set Asynchronous Balnced Mode Extended) +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|0| UA (Unnumbered Acknowledgement) +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|1| DM (Disconnect Mode) +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|1|0| RR (Receive Ready) +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|1|1| RNR (Receive not ready) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|0| RSFR (Re-Send Frame) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|1| FRMR (Frame Rejected) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|0| CHWZ (Change Window Size) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|1| SOSP (Status of Sent Packets) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|1|0|0| UI (Unnumbered Information) +-+-+-+-+-+-+-+-+ |1|0|1|0|1|0|1|0| LOOP (Loopback) +-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|1|1| OO (Options Only). +-+-+-+-+-+-+-+-+ 2.4 FLAGS PDUs: --------------- J. Rodriguez Informational [Page 32] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.4.1 RST: ---------- The RST (reset) flag PDU is used in conjunction with the HLLC bit set to 1 to indicate that it is a control PDU. The RST PDU shall be used to reset an already established HLLC session, and the option bit MIGHT be used to indicate the reason of the reset condition. After waiting for the RST-PDU command response with no success and after trying C1-RST times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the RST-PDU is retransmitted, and it shall be initialized with the value zero. 2.4.2 SYN: ---------- The Syn (Synchronization) flag PDU is used in conjunction with the HLLC bit set to 1 to indicate that it is a control PDU, and the N(S) and N(R) values shall be set to zero to indicate that they are on Syn, so the first I-PDU shall have the value of 1 on the Send variable V(S). This command shall be used to indicate to the receiving HLLC station that it is trying to set-up the session before any information PDU is interchanged. This PDU shall be used only to start a new session; in the event that a SYN PDU is received in some point during an pre-established session, all the I-PDUs after that shall be stopped, a frame reject shall be sent as well as a message to the upper layers indicating that a unexpected SYN PDU has arrived; after that a DM PDU shall be sent. After waiting for the SYN-PDU command response with no success and after trying C1-SYN times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the SYN-PDU is retransmitted, and it shall be initialized with the value zero. J. Rodriguez Informational [Page 33] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.4.3. FIN: ----------- The Fin flag PDU is used in conjunction with the HLLC bit set to 1 to indicate that it is a control PDU and the N(S) value SHALL be the next N(S) sequence (V(S) + 1) to indicate to the Receiver HLLC side that this is the last PDU and is ready to finish the session. This command shall be used only to indicate to the receiving HLLC station that there is no more Data (I-PDUs) to send and needs to close the session. After waiting for the FIN-PDU command response with no success and after trying C1-FIN times, the HLLC station shall send a message to the upper layers indicating that the remote HLLC station is not responding to the PDU command after C1 retransmissions. The C1 value shall be increased by one every time the FIN-PDU is retransmitted, and it shall be initialized with the value zero. 2.5 OPTION CODE VALUES: -------------------------- The options field is used only with control PDUs, and the OPT bit shall be set to 1. The option field has the format of code, length and data/value as described in section 2.2. The value of 0xFF is used to indicate the end of options. The length as well as the data/value fields are variable so it is left out of the scope of this HLLC implementation and rather to be used and defined on the application layer. 2.5.1 More data/value. The option 0x00 shall be used to indicate that there are more data or values of the same previous option code and length. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0| More data/value options. +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 34] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.5.2 User ID. The option 0x01 shall be used to send User ID information when security is very important and is implemented at the Transport Layer. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|1| User ID. +-+-+-+-+-+-+-+-+ 2.5.3 Password. The option 0x02 shall be used to send the Password information when security is very important and is implemented at the Transport Layer. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|0| Password. +-+-+-+-+-+-+-+-+ 2.5.4 User ID and Password Return Code. The option 0x03 is used to indicate the return code based on the User ID and password, for example a value of 0x00 means success, meanwhile a value of 0x01 means User ID wrong, etc. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|1| User ID and Password Return Code. +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 35] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.5.5 Disconnect Mode or Reset Return Code. The option 0x04 is used to indicate the value of the return code used when either a Disconnect Mode or a Reset HLLC PDU is sent or received. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|0| Disconnect Mode or Reset Return Code +-+-+-+-+-+-+-+-+ 2.5.6 Incoming Banner. The option 0x05 is used to indicate an incoming banner is sent; it can be used to display a security alert, a port change, a new service that will be available, etc. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|1| Incoming Banner. +-+-+-+-+-+-+-+-+ 2.5.7 Frame Rejected Return Code. The option 0x06 shall be used to indicate the reason the frame has been rejected. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|1|0| Frame Rejected Return Code. +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 36] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.5.8 MMTU (Maximum MTU size). The option 0x07 shall be used to indicate the maximum MTU size the lower layer protocols can support. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|1|1| MMTU (Maximum MTU size) +-+-+-+-+-+-+-+-+ 2.5.9 PNACK (Packet Not Acknowledge). The option 0x08 shall be used to indicate to the sending HLLC side that the N(S) packet did not arrive and therefore it needs to be resent. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|0| PNACK (Packet Not Acknowledge) +-+-+-+-+-+-+-+-+ 2.5.10 PACK (Packet Acknowledge). The option 0x09 shall be used to indicate to the sending HLLC side that the N(S) packet that did arrive and was acknowledged. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|1| PACK (Packet Acknowledge) +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 37] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.5.11 Resend Frame Return Code. The option 0x0A shall be used to indicate to the sending HLLC side the reason the N(S) packets needs to be resent, for example, a bad FCS, N(S) invalid, etc. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|0| Resend Frame Return Code +-+-+-+-+-+-+-+-+ 2.5.12 NWS (New Window Size). The option 0x0B shall be used to indicate the new window size. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|1| NWS (New Window Size) +-+-+-+-+-+-+-+-+ 2.5.13 OWS (Old Window Size). The option 0x0C shall be used to indicate the old window size. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|1|1|0|0| OWS (Old Window Size) +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 38] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.5.14 HLLC Version. The option 0x0D shall be used to indicate the HLLC version that is implemented on the Host. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|1|1|0|1| HLLC Version. +-+-+-+-+-+-+-+-+ 2.5.15 End of Options. The option 0xFF shall be used to indicate the END of Options. +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|1|1| End of Options. +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 39] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.6. Summarized Option's Table: +-+-+-+-+-+-+-+-+ | C O D E | +-+-+-+-+-+-+-+-+ |7|6|5|4|3|2|1|0| +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|0| More data/value options. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|0|1| User ID. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|0| Password. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|0|1|1| User ID and Password Return Code. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|0| Disconnect Mode or Reset Return Code +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|0|1| Incoming Banner. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|1|0| Frame Rejected Return Code. +-+-+-+-+-+-+-+-+ |0|0|0|0|0|1|1|1| MMTU (Maximum MTU size) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|0| PNACK (Packet Not Acknowledge) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|0|1| PACK (Packet Acknowledge) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|0| Resend Frame Return Code +-+-+-+-+-+-+-+-+ |0|0|0|0|1|0|1|1| NWS (New Window Size) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|1|0|0| OWS (Old Window Size) +-+-+-+-+-+-+-+-+ |0|0|0|0|1|1|0|1| HLLC Version. +-+-+-+-+-+-+-+-+ |1|1|1|1|1|1|1|1| End of Options. +-+-+-+-+-+-+-+-+ J. Rodriguez Informational [Page 40] RFC nnnn High Level Logical Link Control (HLLC) September 2000 2.7 Traffic Flow for a new connection with no errors and a Sliding Window Size of three: ----------------------------------------------------------------- (Control Value, Control Data) SENDER RECEIVER ------ -------- Command Response TEST (P) -------------- (1,0) -------------> <------------- (1,0) ------------- TEST (F) WID (P) -------------- (2,MWZ) -----------> <------------- (2,MWZ) ----------- WID (F) SABME (P) -------------- (3,0) -------------> <------------- (4,0) ------------- UA (F) N(S)=0 N(S)=0 N(R)=0 N(R)=0 Flag Bit: SYN (P) -------------- (N(S),N(R)) --------> <------------- (N(S),N(R)) -------- SYN (F) N(S)=0 N(S)=0 N(R)=1 N(R)=1 RR (P) -------------- (6,N(R)) ----------> <------------- (6,N(R)) ---------- RR (F) N(S)=1 N(S)=0 N(R)=1 N(R)=1 OO (P) -O(7,MTU,255)- (255,0) ------------> <------------- (255,0) -O(7,MTU,255) OO (F) 1 1 I -------------- (N(S),N(R)) -------> N(S)=2 N(S)=0 N(R)=1 N(R)=2 2 1 I -------------- (N(S),N(R)) -------> N(S)=3 N(S)=0 N(R)=1 N(R)=3 3 1 I (P) -------------- (N(S),N(R)) -------> N(S)=4 N(S)=0 N(R)=1 N(R)=4 4 <------------- (6,N(R)) ---------- RR (F),ACK=1 N(S)=4 N(S)=0 N(R)=1 N(R)=4 4 1 Flag bit: FIN (P) -------------- (N(S),N(R)) -------> 1 4 <------------- (N(S),N(R)) ------- FIN (F),ACK=1 MWZ = Maximum Window Size J. Rodriguez Informational [Page 41] RFC nnnn High Level Logical Link Control (HLLC) September 2000 3.1 POLL BIT FUNCTION: ---------------------- A command PDU with the P bit set to "1" shall be used on the connection to solicit a response PDU with the F bit set to "1" from the addressed HLLC on the connection. Only ONE PDU with a P bit set to "1" shall be outstanding in a given direction at a given time on the connection between any specific pair of HLLCs. Before an HLLC issues another PDU on the same link connection with the P bit set to "1", the HLLC shall have received a response PDU with the F bit set to "1" from the addressed HLLC. If no valid response PDU is received within a system-defined P-bit time-out period, the (re)sending of a command PDU with the P bit set to "1" shall be permitted for error recovery purposes. 3.2 FINAL BIT FUNCTION: ----------------------- A response PDU with the F bit set to "1" shall be used to acknowledge the receipt of a command PDU with the P bit set to "1". Following the receipt of a command PDU with the P bit set to "1", the HLLC shall send a response PDU with the F bit set to "1" on the appropriate connection at the earliest possible opportunity. The HLLC shall be permitted to send appropriate response PDUs with the F bit set to "0" at any medium access opportunity on an asynchronous basis (without the need for a command PDU). 3.3 DUPLICATE PACKETS (PDU'S): ------------------------------ In the event of duplicate PDUs, the following received PDUs with the same N(S) will be discarded. 3.4 SEND STATE VARIABLE V(S): ----------------------------- The send state variable shall denote the sequence number of the next in-sequence I-PDU to be sent on a specific traffic transport link control connection. The send state variable shall take on a value between 1 and 255. The value of the send state variable shall be incremented by one with each I-PDU transfer. J. Rodriguez Informational [Page 42] RFC nnnn High Level Logical Link Control (HLLC) September 2000 3.5 RECEIVE STATE VARIABLE V(R): -------------------------------- The receive state variable shall denote the sequence number of the next in-sequence I PDU to be received on a specific traffic transport link control. The receive state variable shall take on a value between 1 and 255. The value of the receiver state variable associated with a specific transport link connection shall be incremented by one whenever an error-free, in sequence I-PDU is received whose send sequence number N(S) equals the value of the receive state variable for the transport link control. 3.6 CONTROL BEGIN SEND VARIABLE B(S): ------------------------------------- The begin send variable B(S) shall be used to indicate the value of the N(S) at the beginning of a new Sliding Window Cycle. This value shall be the value of the N(R) on the RR Final-Response PDU with the ACK bit set to "1" in response to the I-PDU Poll-Request at the end of the preview Sliding Window Cycle (SWC-1). The begin send variable B(S) shall be initialized with the value of 1 after the SYN PDU establishment process. This value shall not be changed under the recovery mode. 3.7 CONTROL END SEND VARIABLE E(S): ----------------------------------- The end send variable E(S) shall be used to indicate the value of the last N(S) I-PDU sent. The value of the E(S) shall be the same as the N(S) value on the poll/command I-PDU sent at the end of the current sliding window cycle (SWC). This value shall not be changed under the recovery mode. 3.8 BEGIN AND END SEND VARIABLE FUNCTION: ----------------------------------------- The B(S) and E(S) variables shall be used to indicate the begin and end of the sequence numbers used on the i-th sliding window cycle. These variables shall prevent the retransmission of previous I-PDU on other Sliding window cycles upon the received of a very long delayed RR Final-Response PDU with the ACK bit set to "1" and a very old R(N) value. Only a value within the [B(S),E(S)] range (greater or equal than B(S) or lower or equal than E(S)) shall be accepted as a valid N(R) RR Final-Response PDU with the ACK bit set to "1". In the event that a PDU is received with a value out of the valid range, it shall be discarded immediately and the HLLC shall send a notification to the upper layers. J. Rodriguez Informational [Page 43] RFC nnnn High Level Logical Link Control (HLLC) September 2000 3.9 CONTROL BEGIN RECEIVE VARIABLE B(R): ---------------------------------------- The begin receive variable B(R) shall be used to indicate the first I-PDU N(S) value on the i-th sliding window cycle. The B(R) value shall be indicated by the next N(S) I-PDU received after the N(S) I-PDU Poll/Request received on the previous Sliding Window Cycle (SWC-1) or by the N(R) value on the RR Final-Response PDU with the ACK bit set to "1" sent on the SWC-1. The begin receive variable B(R) shall be initialized with the value of 1 after the SYN PDU establishment process. This value shall not be changed under the recovery mode. 3.10 CONTROL END RECEIVE VARIABLE E(R): --------------------------------------- The end receive variable E(R) shall be used to indicate the value of the last N(S) I-PDU received on the i-th Sliding Window Cycle. The value of the E(R) shall be the same as the N(S) value on the poll/command I-PDU received at the end of the sliding window cycle (Last I-PDU sent on the i-th sliding window cycle). This value can be calculated in the same way as is calculated at the sending. So the N(S) value at the end of the i-th SWC shall be E(R) = B(R) + int(SWZ). This value shall not be changed under the recovery mode. 3.11 BEGIN AND END RECEIVE VARIABLE FUNCTION: --------------------------------------------- The B(R) and E(R) variables shall be used to indicate the begin and end of the sequences numbers used on the i-th sliding windows cycle. These variables shall prevent the reception of previous I-PDUs on the sliding window cycles upon the receipt of a very long delayed I-PDU N(S) value. Only a value greater than or equal to B(R) or lower than or equal to E(R) shall be accepted as a valid N(S) I-PDU. In the event that a I-PDU is received with a value out of the valid range, it shall be discarded immediately and the HLLC shall send a notification to the upper layers. 3.12 TIMERS: --------------- PBTO: P-bit time-out: 500 ms. PACK: OO PDU with N(S) acknowledged: 100 ms. or 75% filled of MWZ. ACKTO: Acknowledgment time-out: 200 ms (10 to 500) DM timer : Amount of time to reside in this cycle. (1 to 255) seconds. J. Rodriguez Informational [Page 44] RFC nnnn High Level Logical Link Control (HLLC) September 2000 3.13 COUNTERS: -------------- N3: Number of Packets received out of sequence default 3 in the range of (1-255) C1: Counter of the Number of Re-sent PDUs based on the ACKTO. C1-INFO: Maximum number of retransmitted Information PDUs commands. C1-TEST: Maximum number of retransmitted TEST PDUs commands. C1-WID: Maximum number of retransmitted WID PDUs commands. C1-SABME:Maximum number of retransmitted SABME PDUs commands. C1-DM: Maximum number of retransmitted DM PDUs commands. C1-RR: Maximum number of retransmitted RR PDUs commands. C1-RNR: Maximum number of retransmitted RNR PDUs commands. C1-RSFR: Maximum number of retransmitted RSFR PDUs commands. C1-FRMR: Maximum number of retransmitted FRMR PDUs commands. C1-CHWZ: Maximum number of retransmitted CHWZ PDUs commands. C1-SOSP: Maximum number of retransmitted SOSP PDUs commands. C1-LOOP: Maximum number of retransmitted LOOP PDUs commands. C1-OO: Maximum number of retransmitted OO PDUs commands. C1-SYN: Maximum number of retransmitted SYN PDUs commands. C1-FIN: Maximum number of retransmitted FIN PDUs commands. C1-RST: Maximum number of retransmitted RST PDUs commands. R301: Number of cycles that needs to be after recovery mode. SWZ-FREEZE: Number of Acknowleded consecutives cycles. Default 3 in the range from 1 to 10. The default value for all the C1-xxxx shall be set to 3, but the range for this value is between 1 and 7. 3.14 RECOVERY MODE CONDITION: ---------------------------- The recovery mode is the time when the not acknowledged I-PDU, are being re-transmitted based upon the receipt of the response PDU of the last I-PDU on the i-th slinging window cycle with the NACK bit set to "1" indicating that more than one I-PDU did not arrive. The N(S)s of the I-PDUs that need to be re-transmitted are given under the option field, with the option Packet Not Acknowledge. During this mode, the value of the B(S), E(S), B(R) and E(R) should not be modified. Under this mode, the SWZ is reduced by the number of I-PDUs that were lost or missed, in the event that the resultant number is zero, the SWZ shall be set to 1. During this mode, the SWZ shall be freeze with the new value for SWZ-FREEZE consecutives ACK cycles. The sender shall not leave this mode until the receipt of a PDU with the ACK bit set to "1" indicating that all the I-PDUs on the i-th sliding window cycle have been acknowledged, during SWZ-FREEZE consecutives ACK cycles. J. Rodriguez Informational [Page 45] RFC nnnn High Level Logical Link Control (HLLC) September 2000 3.15 NACK CONDITION: -------------------- The NACK Condition is when there are some I-PDUs pending to be sent or acknowledged. The only way to clear the NACK condition on the transmitting side is receiving an ACK flag with the bit set to 1 after retransmitting the missing I-PDUs. On the received side the only way to clear this condition is by receiving all the I-PDUs that were missing. 4.1 WINDOW ALGORITHM: --------------------- The window algorithm has been designed in such a way to react or adapt more efficiently to the network (flow control) and to the host (access control) conditions. The host can change the maximum number of packets that it can receive at any given time, based on the amount of memory left to allocate them. The maximum number of unacknowledged packets that shall be allowed at any given time, shall not be greater than the Sliding Window Size. The maximum number of packets that a host can receive is known as the Maximum Window Size, which shall have a value between 1 and 255. The Maximum Window Size shall be advertised by the WID command PDU before the SABME command PDU is sent. After receiving the WID response PDU the Maximum Window Size (MWZ) variable is set with that value, indicating the maximum amount of memory allocated by the remote end in terms of packets. The MWZ can be changed during the interchange of I-PDUs or Control PDUs with the CHWZ command PDU and the use of the Urgent flag bit at any time. When the CHWZ command PDU is received, the MWZ shall be modified immediately with the new value on the same transport data link connection. The windows algorithm has two variables as we already mentioned, the Maximum Window Size (MWZ) and the Sliding Window Size (SWZ). The MWZ as we describe above, has the value that represent the maximum buffer size in packets allocated on a particular HLLC session, and it is interchanged at the beginning of the process with the WID control PDU command. This value represents the highest value that the SWZ should get under any error-free transmissions and it shall never be greater than the MWZ. In the event that the MWZ is reduce by the CHWZ command PDU, the SWZ value shall be reduce to the same value if the SWZ is higher that the new MWZ value at that particular time. The Sliding Window Size is used to control the amount of packets sent at any given time (access control) based on the performance of the network as well as the performance of the receiver. The SWZ value start with the value of 1 and it increase its size at a rate of 1.5 times after a completed error-free window cycle. J. Rodriguez Informational [Page 46] RFC nnnn High Level Logical Link Control (HLLC) September 2000 SWZ 55 | p 54 | 12 53 | 11x 52 | 10x 51 | 9 50 | 8 49 | 7 48 | 6x 47 | 5 46 | 4 45 | 3 44 | 2 43 | 1 42 | 255 41 | 254x 40 | 253 39 | 252 38 | 251 37 | p 250x 36 | 213 249 35 | 212 248 34 | 211 247 33 | 210 246 32 | 209 245 31 | 208 244 30 | 207 243 29 | 206 232 28 | 205 241 27 | 204 240 26 | 203 239 25 | p 202 238 24 | 177 201 237 23 | 176 200 236 22 | 175 199 235 21 | 174 199 234 20 | p 173 197 233 19 | 105 172 196 232 18 | p 104x 171 195 231 17 | 47x 103 p p p 170 194 230x 16 | 46x 102 121 137 153 169 193 229 15 | 45 101x 120 136 152 168 192 228 14 | 44 p p p 100x 119 135 151 167 191 227 13 | 43x 60 73 86 99 118 134 150 166 190 226 12 | p 42 59 72 85 98 117 133 149 165 189 225 11 | 30 41 58 71 84 97 116 132 148 164 188 224 10 | 29 40x 57 70 83 96 115 131 147 163 187 223 9 | 28 39 56 69 82 95 114 130 146 162 186 222 8 | p 27 38 55 68 81 94 113 129 145 161 185 221 7 | 19 26 37 54 67 80 93 112 128 144 160 184 220 p 6 | p 18 25 36 53 66 79 92 111 127 143 159 183 219 11 5 | 12 17 24 35 p 52 65 78 91 110 126 142 158 182 218 10 4 | p 11 16 23 34 47 51 64 77 90 p 109 125 141 157 181 217 6 3 | p 7 10 15 22 33 46 50 63 76 89 104 108 124 140 156 180 216 254 2 | p p 4 6 9 14 21 32 43 49 62 75 88 101 107 123 139 155 179 215 250 1 | 1 2 3 5 8 13 20 31 40 48 61 74 87 100 106 122 138 154 178 214 230 -------------------------------------------------------------------- 1 2 3 4 5 6 7 8 9 1 1 1 1 1 1 1 1 1 1 1 2 0 1 2 3 4 5 6 7 8 9 0 Sliding Window Cycle J. Rodriguez Informational [Page 47] RFC nnnn High Level Logical Link Control (HLLC) September 2000 p = poll n(s) = packet acknowledged; s= 1...255 x = packet not acknowledged SWZn = (SWZn-1) * (1.5) swz1 => 1.0 swz2 = 1 * 1.5 => 1.5 swz3 = 1.5 * 1.5 => 2.25 swz4 = 2.25 * 1.5 => 3.37 swz5 = 3.7 * 1.5 => 5.06 swz6 = 5.06 * 1.5 => 7.59 swz7 = 7.59 * 1.5 => 11.39 swz8 = 11.39 * 1.5 => 17.08 swz9 = Retransmit the unacknowledged packets. (Recovery Mode) swz10 = 17.08 - 17(4/17)=> 13.09 swz11 = => 13.09 swz12 = => 13.09 swz13 = 13.09 * 1.5 => 19.63 swz14 = Retransmit the unacknowledged packets. (Recovery Mode) swz15 = 19.63 - 19(3/19)=> 16.09 swz16 = => 16.09 swz17 = => 16.09 swz18 = 16.09 * 1.5 => 24.13 swz19 = 24.13 * 1.5 => 36.20 swz20 = 36.20 * 1.5 => 54.30 5.0 AUTHOR's ADDRESS: --------------------- Jorge E. Rodriguez 2301 NW 122nd ST #402 Oklahoma City, OK 73120 e-mail:jerodrig@sprintparanet.com e-mail:jorge_e_rodriguez@hotmail.com J. Rodriguez Informational [Page 48] RFC nnnn High Level Logical Link Control (HLLC) September 2000 6.0 REFERENCES: --------------- [1] Cerf, V., and R. Kahn, "A Protocol for Packet Network Intercommunication," IEEE Transactions on Communications, Vol. COM-22, No. 5, pp 637-648, May 1974. [2] Postel, J. (ed.), "DOD Standard Internet Protocol," Defense Advanced Research Projects Agency, Information Processing Techniques Office, RFC 760, IEN 128, January 1980. [3] Postel, J.(ed.) "DoD standard Transmission Control Protocol.", RFC 761 Jan-01-1980. [4] ANSI/IEEE Std 802.2, "Part 2: Logical Link Control", Second edition, 1994-12-30 expiration date: March, 2001 J. Rodriguez Informational [Page 49]