NetWare SPX-II Services

Purpose and Design

Marty Benson

James Brown

Mike Dege

Maciej Laskowski

Prabhakar Krishnaswami

Jonathan Richey

Revision: 1.51

Date: Aug 1, 1996

Copyright©, Novell, Inc. All Rights Reserved

No part of this document may be duplicated, revised, translated, localized or modified in any manner or uploaded or downloaded to or from any computer system without the prior written consent of Novell, Inc.

This document is the property of Novell, Inc. This document is not to be construed as a promise by Novell to develop a particular product. Novell specifically disclaims any promise to deliver a product conforming to the specifications contained herein.

Preface

This manual provides a complete protocol reference for the SPX-II implementer. It consists of the SPX-II reference manual plus annotations.

The SPX-II reference manual alone provides a complete definition of SPX-II, but the terse reference manual style leaves many reasonable questions unanswered. Discussions of why certain features are defined the way they are, and how one might implement some particular feature have no place in a reference manual but are nevertheless of interest to most implementers. Such discussions are presented as annotations.

Organization

The SPX-II reference manual consists of main sections which form the chapters of this manual. The reference manual proper is presented in 11 point Times New Roman font.

Embedded annotations are presented in 9 point Arial font, indented and bracketed by a solid and an open square box, like this sentence. □

Acknowledgements

SPX-II could not have been developed without the use, suggestions, and constructive criticism of the many NetWare users and developers. In addition, many of the suggestions and ideas implemented in SPX-II are the result of papers and manuals written by a variety of researchers in the communications and networking fields; particularly the works on Xerox PARC XNS and the TCP and XTP documents. Van Jacobson's work on congestion avoidance was the primary source for information in that section of the manual.

Special thanks to Dale Neibaur and Mark Hurst for the original SPX implementation. Without the original SPX there would never have been an SPX-II.

Edit History

Revision	Date	Description

1.30	15 Jan 92	First complete revision.

1.31	13 Feb 92	Added packet sequence examples for the different connection sequences, SPX -> SPX-II, SPX-II -> SPX, SPX-II - SPX-II w/o negotiation.

1.32	24 Jun 92	Renamed the SIZ bit to NEG for negotiate. Cleaned up some grammar and clarified some examples. Added annotation in congestion control section.

1.33	21 Jul 92	Set SYS bit in Session Setup packet. This allows the client to distinguish between a data packet and a retransmitted Session Setup packet if the Session Setup ACK was lost.

1.34	18 Aug 92	Clarified definition of Alloc number. It means up to and including alloc number.

1.35	22 Sep 92	Added section 3.8 on session termination; unilateral abort, informed disconnect, and orderly release are explained. Set SYS bit on informed disconnect, informed disconnect ACK, orderly release and orderly release ACK. Clarification on Data Packet Timeout algorithm, to increase retry timeout on retries. Clarification on Windowing Algorithm to deal with potential for lost "open window" ACK.

1.36	02 Oct 92	Removed SYS bit requirement on informed disconnect and orderly release (see 1.35), and added section 5.4 on Additional Resource Requirements to clarify handling disconnect and system packets. Made watchdog, and retry timeouts configurable and added Appendices B and C to specify the TLI option management structure definition and defaults. Clarified definition of "piggy- backed" ACKs. Added Section 3.9 on Connection Phase Timeout.

1.37	04 Nov 92	Added NCP packet type to supported IPX packet type list, clarified Packet types, cleaned up orderly release packet definition that was not fixed in 1.36, and misc doc format corrections. Removed most references to Xerox. Defined SPX-II header and replaced Extended ACK. Clarified how to differentiate between a retransmitted Session setup and a new negotiate size.

1.38	3 Dec 1992	Renumbered sections and rearranged contents to group related items more closely. Renamed packet types. Clarification on Negotiate Size field usage. More restrictive re-transmission re- negotiate algorithm.

1.39	15 Dec 1992	Added NEG bit to renegotiate packets. Changed Orderly Release ACK to normal ACK. Clarified NAK algorithm. Clarified renegotiate sequence and acknowledge numbers. Added SPX_SF_SPX2_SESSION to option mgmt structure.

1.40	12 Jan 1993	Misc cleanup: option state flag SPX_SF_IPX_CHECKSUM, datastream type description, renegotiate single sided, reword Session Setup ACK and section annotation, Session Setup ACK sent to new socket not old. Remove SYS bit from Informed Disconnect ACK.

1.41	19 Feb 1993	Misc format spelling and grammer edits. Annotations on renegotiate packet sequencing and retry count usage. Orderly release not subject to window closure. NetBIOS broadcast IPX packet type. ACKs returned to same source data received from.

1.42	13 Dec 1993	Fixed reserved datastream type numbers to include 0xFC as a reserved value.

1.50	10 May 1994	Made SPX-II name consistent and cleaned up the SPX2 defined constants. Reviewed for technical detail and added state tables. Reformatted for HP Laserjet 4si printer and Times New Roman and Arial fonts.

1.51	1 Aug 1996	Editorial changes to make renegotiation text consistent with renegotiation packet sequence diagram. Modified Data Packet Timeout text to be consistent with renegotiation algorithm when large packet size negotiation is used. Added algorithm summary to watchdog description.

Table of Contents

Preface	i

Organization	i

Acknowledgements	i

Edit History	i

Introduction	1

Definition of Key Terminology	1

Backward Compatibility	1

Windowing Protocol	1

Large Packets	2

NetWare Transport Level Interface (TLI)	2

SPX-II Packet Format	3

SPX-II Header Definition	3

Checksum	4

Length	4

Transport Control	4

Packet Type	4

Destination Network	4

Destination Node	4

Destination Socket	5

Source Network	5

Source Node	5

Source Socket	5

Connection Control	6

Datastream Type	6

Source Connection ID	6

Destination Connection ID	6

Sequence Number	7

Acknowledge Number	7

Allocation Number	7

Negotiation Size	7

SPX-II Acknowledgement Packets	8

Normal SPX-II ACK	9

Normal SPX-II NAK	9

SPX-II Connection Management Packets	10

Connection Request	10

Connection ACK	10

Session Negotiate	11

Session Negotiate ACK	11

Session Setup	12

Session Setup ACK	12

Renegotiate Request	13

Renegotiate ACK	13

Informed Disconnect	14

Informed Disconnect ACK	14

Orderly Release Request	15

Orderly Release ACK	15

Connection Management	16

SPX-II Client to SPX-II Host Connections with Negotiation	16

Connection Request and ACK	16

Session Negotiate Request and ACK	16

Session Setup and ACK	17

Renegotiate Request and ACK	17

Negotiation and Setup Retries	18

Packet Definitions for SPX-II Client to SPX-II Host Without Negotiation	18

Packet Definitions for Mixed SPX-II and SPX Connection Endpoints	19

Session Setup Timeout	19

Negotiating Other Values Between Endpoints	19

The Type Field	20

The Size Subfield	21

The ID Number Subfield	21

Type, Extended Type, Value, Extended Value Combinations	21

Disparate Versions of SPX-II	21

Session Termination	22

Unilateral Abort	22

Informed Disconnect	22

Orderly Release Request	23

SPX-II Watchdog Algorithm	23

Session Watchdog During Connection Establishment	24

Connection ID Numbers	25

Windowing Algorithm	26

Managing Sequence and Acknowledge numbers	26

Positive and Negative Acknowledgements	26

Extensive Error Recovery Mechanisms	26

Data Packet Timeout	27

Window Size	27

Additional Resource Requirements	28

Congestion Control Algorithm	30

Calculating Timeouts and Round Trip Time	31

Calculating Round Trip Time	31

Calculating Timeouts	31

Van Jacobson Average And Mean Deviation Calculations	31

Appendix A - Option Negotiation Type Numbers	33

Appendix B - TLI Option Management	34

Appendix C - Default, Minimum and Maximum Values	37

Documentation Constants	37

Connection Termination Reason Codes	37

Driver Packet Sizes	37

Appendix D - IPX Checksum	39

1	Introduction

With the introduction of Netware v2.0a in early 1986, NetWare supported a guaranteed delivery protocol known as Sequenced Packet Exchange or SPX. It was derived from the XEROX XNS protocol specification known as Sequenced Packet Protocol or SPP. Within Novell, recognition of the need to improve SPX has existed for quite some time and as more applications have used SPX, limitations in the early implementations have become more confining. The improvements specified here are based on the following requirements:

•	Backward compatibility on the wire with existing SPX

•	Implement a true windowing protocol

•	Utilize larger packet sizes

•	Better support for the Transport Layer Interface (TLI) API

•	Future expandability

These enhancements and improvements make SPX-II a message or session protocol, where SPX is only a sequenced protocol.

1.1	Definition of Key Terminology

SPX-II is the designator for the enhanced SPX protocol. Host, passive endpoint, and listener all refer to the network node that is waiting for or has received a connection request. Client, active endpoint and requester all refer to the network node that is making or has made the connection request. Connection partner refers to the other endpoint and connection endpoint refers to either endpoint participating in the connection, without respect to its active or passive status.

1.2	Backward Compatibility

The first goal of SPX-II is to be compatible with SPX. In early 1990, a proposal was considered for replacing IPX/SPX with a new protocol, XTP, which defined many of the improvements wanted for SPX. This proposal was short lived because it entirely ignored the installed base of NetWare and the applications written to IPX/SPX. In defining SPX-II, backward compatibility with SPX on the wire is required.

Compatibility is achieved through bi-modal operation. Meaning, an SPX-II host or client can successfully communicate with an SPX host or client by detecting the type of the connection partner. A bit in the SPX header during connection request indicates that the client wants to use SPX-II services. To minimize the impact on an SPX host no other modification is made to the connection request. When in SPX-II mode new packet definitions, new states and new algorithms are used.

1.3	Windowing Protocol

The SPX packet header has fields for managing sequencing, acknowledgments and window size. In the earliest implementations of SPX these fields were not used to the fullest extent of the definition. The number of receive buffers, posted to IPX sockets, dictated the window size. Having more than one SPX session multiplexed over an IPX socket lead to the problem of determining which buffers belonged to which session. Since this could not be accurately determined, the reported window size could not be trusted and other implementations attempted to guard against this using a send window size of one.

Implementations of SPX for OS/2 and NetWare 3.x have an extended API, where buffers can be posted to the SPX session. This addresses the problem for these platforms, however, true windowing is still not supported because it is not known what support is available at the connection partner.

The fields of the SPX header are used by SPX-II to fully support windowing and SPX II is flexible enough to support different window management algorithms.

1.4	Large Packets

The original XNS specification defined a network packet size as being 576 bytes long. This allowed 512 bytes of data and 64 bytes for header. Early implementations of IPX adhered to this limitation. IPX was enhanced to support media packets larger than 576, however the IPX application was responsible to determine if larger packets could be used. There are several IPX based services which use larger than 576 byte packets by using a simple algorithm for determining the packet size. If both endpoints share the same physical wire and if the media supports larger packets, then use the larger packet size.

SPX-II supports a mechanism for determining the largest packet size supported between endpoints and provides a message level service rather than a packet level service. SPX-II partitions large messages into appropriately sized media packets. The maximum packet size is determined during connection establishment and re-negotiated on route failure. SPX-II also deals with the possibility of different send and receive packet sizes, which results from the non-deterministic nature of IPX RIP routers with parallel routes between two points.

1.5	NetWare Transport Level Interface (TLI)

With the introduction of NetWare 3.1x, NetWare began supporting an AT&T UNIX System V Release 3 API known as the Transport Level Interface or TLI. TLI is a strategic API to Novell and is being promoted heavily. TLI currently supports IPX/SPX/SPX-II on the following platforms:

•	NetWare 3.1x, implemented as an NLM library and STREAMS modules.

•	DOS, implemented as a link library for Microsoft, Turbo and Watcom C.

•	OS/2, implemented as DLLs, with a multiplexer to allow support for other protocols.

•	Windows 3.0 & 3.1, implemented as DLLs, with a multiplexer to allow support for other protocols.

SPX does not provide all the features supported through TLI. SPX-II improves TLI support by providing these additional features.

2	SPX-II Packet Format

SPX-II packet structure is very similar to SPX, consisting of a packet header followed by optional data. The SPX-II header is a superset of the SPX header, with the differences being: additional bits defined in the Connection Control field; and an additional two byte negotiation size field.

2.1	SPX-II Header Definition

Here is the field definition for the SPX-II header:

Description	Length	Type	Value

Checksum*1	2	High-Low Int	0xFFFF if no checksum

Length*	2	High-Low Uint	42 - 65535

Transport Control*	1	Ubyte	0 - 16

Packet Type*	1	Ubyte	5, see detail

Destination Network*	4	Ubyte	0 - 0xFFFFFFFF, see detail
Destination Node*	6	Ubyte	1 - 0xFFFFFFFFFFFE, " "

Destination Socket*	2	High-Low Uint	0 - 0xFFFF, see detail

Source Network*	4	Ubyte	0 - 0xFFFFFFFF, see detail

Source Node*	6	Ubyte	1 - 0xFFFFFFFFFFFE, " "

Source Socket*	2	High-Low Uint	0 - 0xFFFF, see detail

Connection Control	1	Ubyte	see explanation

Datastream Type	1	Ubyte	see explanation

Source Connection ID	2	High-Low Uint	see explanation

Destination Conn. ID	2	High-Low Uint	see explanation

Sequence Number	2	High-Low Uint	see explanation

Acknowledge Number	2	High-Low Uint	see explanation

Allocation Number	2	High-Low Uint	see explanation

Negotiation Size2	2	High-Low Uint	see explanation

All numeric fields in an SPX-II header are in high-low format or "network order", and the length designator is in number of 8 bit bytes or octets.

2.1.1	Checksum

This field is normally set to 0xFFFF indicating that no checksum was performed. However, if this field is not 0xFFFF it holds a checksum of the entire SPX-II packet, including the SPX-II header and data. When checksum verification is requested, it is handled on a per connection basis (See Appendix D for checksum algorithm and checksum negotiation).

2.1.2	Length

This field contains the length of the complete SPX-II packet, which is the length of the header plus the length of the data. The minimum length of an SPX packet and an SPX-II connection request is 42 bytes, the minimum length of an SPX-II packet is 44 bytes, and the maximum length is 65535.

2.1.3	Transport Control

This field is used by IPX routers. SPX and SPX-II always set this field to zero before sending the packet.

2.1.4	Packet Type

This field indicates the type of service offered or required by the packet. The following values are defined:

0	Unknown packet type (do not use)

1	Routing information packet

2	Echo packet (not currently supported)

3	Error packet (not currently supported)

4	Packet exchange packet (normal IPX packet, also used by SAP)

5	Sequenced packet (SPX and SPX-II)

17	NetWare Core Protocol standard packet

20	IPX NetBIOS broadcast

2.1.5	Destination Network

This field contains the network number of the network to which the destination node belongs. Networks within an internetwork are assigned unique 4 byte network numbers by a network administrator.

When this field is 0, the destination node is assumed to reside on the same network as the source node. Such a packet is not processed by an IPX router.

2.1.6	Destination Node

This field contains the physical address of the destination node. Not all LAN topologies use the same size address field. A node on an ethernet network requires all 6 bytes to specify its address, while a node on an arcnet network requires only 1 byte. If a physical network needs less than 6 bytes to specify a node address, the address should occupy the least significant portion of the field and the most significant bytes should be set to zero.

A broadcast node address (0xFFFFFFFFFFFF) is explicitly disallowed by SPX and SPX-II. All connection requests to this node address will be ignored.

2.1.7	Destination Socket

This field contains the socket address of the packet's destination process. Sockets route packets to different processes within a single node. The following socket numbers are reserved by the IPX protocol suite:

0x2	Echo protocol socket

0x3	Error handler packet

In addition Novell has defined and reserved the following sockets for use by NetWare:

0x451	NetWare Core Protocol

0x452	NetWare Service Advertising Protocol

0x453	NetWare Routing Protocol

0x456	NetWare Diagnostics Protocol

Novell administers a list of sockets that are well-known in all IPX environments. Software developers writing IPX, SPX or SPX-II based value-added packages that require well-known addresses, should obtain socket assignments from Novell. Dynamic sockets within the IPX suite begin at 0x4000 and end at 0x7FFF and well-known sockets assigned by Novell begin at 0x8000.

2.1.8	Source Network

This field contains the network number of the network to which the source node belongs. Networks within an internetwork are assigned unique 4 byte network numbers by a network administrator.

This field may contain a value of zero which means the physical network to which the source node is connected is unknown. All packets with a zero in this field that pass through a IPX router will have this field set to their source network number. Thus, whenever a packet is received from a node on a different network, the source network field is always set properly. Packets whose source and destination nodes are on the same network may contain a zero in this field.

2.1.9	Source Node

This field contains the physical address of the source node. Not all physical LAN topologies use the same size address field. A node on an ethernet network requires all 6 bytes to specify its address, while a node on an arcnet network requires only 1 byte. If a physical network needs less than 6 bytes to specify a node address, the address should occupy the least significant portion of the field and the most significant bytes should be set to zero.

2.1.10	Source Socket

This field contains the socket address of the process that transmits the packet. In a client server dialogue, the server node usually listens on a specific socket for connection requests. In such a case, the source socket is not necessarily the same or even significant. All that matters is that the server sends its replies to the source socket contained in the connection request packet. For example, all NetWare file servers have the same socket address, but requests to them may originate from any socket number.

As in the case of destination sockets, these numbers can be static or dynamic. Source socket numbers follow the same conventions as those for destination sockets.

2.1.11	Connection Control

This field contains single-bit flags used by SPX and SPX-II to control the bidirectional flow of data across a connection.

Value	Symbol	Description

0x01	XHD	Reserved for extended header

0x02	RES1	Undefined, must be 0

0x04	NEG	Negotiate size request/response

0x08	SPX2	SPX-II type packet

0x10	EOM	Set by an SPX client to indicate end of message. Automatically set when appropriate by SPX-II, since SPX-II is message based.

0x20	ATN	Reserved for attention indication (Not currently supported by SPX or SPX-II)

0x40	ACK	Set to request the receiving partner acknowledge that this packet has been received. Acknowledgement requests and responses are handled by SPX and SPX-II.

0x80	SYS	Set to indicate a packet is a system packet. System packets are internal SPX packets, are not delivered to the application, and do not consume sequence numbers.

2.1.12	Datastream Type

This field is a 1 byte flag that indicates the type of data found in the packet. For SPX the following types are defined:

0x00-0xFD	Defined by the client.

0xFE	End of connection notification

0xFF	End of connection acknowledge

For SPX-II the following types are defined:

0x00-0x7F	Defined by the client.

0x80-0xFC	Reserved

0xFD	Orderly release request

0xFE	Informed disconnect notification

0xFF	Informed disconnect acknowledge

The TLI interface does not currently provide a mechanism for setting or determining the value of this field on a packet by packet basis. See section on Connection Termination for additional details.

2.1.13	Source Connection ID

This field contains a connection identification number assigned by SPX or SPX-II at the packet's source and was generated during connection establishment.

2.1.14	Destination Connection ID

This field contains a connection identification number assigned by SPX or SPX-II at the packet's destination and was generated during connection establishment. On a connection request this field is set to 0xffff.

Connection ID numbers are used to demultiplex incoming packets from multiple connections arriving on the same socket. All concurrently active connections and all recent connections on a given machine are guaranteed to have unique connection ID numbers.

See section on Connection ID Numbers for additional detail on how connection ID numbers are generated and the bounds of uniqueness. Also see Connection Management for a description of how Connection ID numbers are used during connection establishment.

2.1.15	Sequence Number

This field keeps a count of packets exchanged in one direction on the connection. Each side of the connection keeps its own count. The number wraps to zero after reaching 0xFFFF. SPX-II acknowledgement packets have this field set to zero, except during lost packet error recovery.

See section on Windowing Algorithm for additional detail on how sequence number, acknowledge number and allocation number work together.

2.1.16	Acknowledge Number

This field is used by SPX and SPX-II to indicate the sequence number of the next packet expected from the connection partner. Any packet with a sequence number less than the specified acknowledge number has been correctly received and need not be retransmitted.

2.1.17	Allocation Number

This field is used by SPX and SPX-II to identify to the connection partner the largest sequence number that can be sent and is used to control the number of unacknowledged packets outstanding in one direction on the connection. SPX and SPX-II only send packets until the sequence number equals the last allocation number received from the connection partner.

2.1.18	Negotiation Size

This field exists as part of the SPX-II header on all packets, except the connection request packet and contains a length value. The meaning of this value depends on the type of packet being sent. The following table defines the meaning of this field for the various packet types:

Packet Type	Meaning

Connection Request	Does not exist, connection requests use SPX packet headers.

Connection ACK	Host driver packet size.

Session Negotiate Req.	Client driver packet size, even on smaller packet retries.

Session Negotiate ACK	Size of the largest negotiation request packet received by the host.

Session Setup Request	Size of the largest negotiation request packet received by the host.

Session Setup ACK	Size of the largest session setup request packet received by the client.

Data Packet	Size of the largest packet receivable by the sending endpoint.

Data ACK	Size of the largest packet receivable by the sending endpoint.

Watchdog & ACK	After connection establishment it is the size of the largest packet receivable by the sending endpoint. During negotiation it is the current size relative to the negotiation state.

Renegotiate	Request	Client driver packet size, even on smaller packet retries.

Renegotiate ACK	Size of the largest negotiation request packet received by the endpoint.

If negotiation is not done during connection establishment, the value of this field should be 576.

2.2	SPX-II Acknowledgement Packets

SPX-II is a guaranteed delivery service and requires that the connection endpoints verify that each packet has been received. The SPX-II ACK is an SPX-II header with the SPX2 bit set in Connection Control; Sequence Number set to zero and Acknowledge Number set to acknowledge the packet(s) received (all packets up to but not including the acknowledge number have been received) and Allocation Number set to open/adjust the transmission window.

During connection establishment SPX-II relies on state information rather than on the sequence, acknowledge and allocation number fields and therefore these fields are set to zero.

For normal acknowledgements Sequence Number is set to zero. A non-zero value in Sequence Number is used to indicate a NAK. NAK packets are "timeout accelerators" in the windowing algorithm's lost packet recovery mechanism. When an unexpected packet, indicating lost packets, arrives at the receiving endpoint, a NAK packet is generated to inform the connection partner of the problem. This NAK packet accelerates the retry timer and forces a retransmission. The Sequence Number of the first packet to resend is the value of Acknowledge Number in the NAK packet and Sequence Number in the NAK packet indicates how many packets should be resent. Each resent packet must have the ACK bit set in Connection Control. Once the receiving endpoint receives all the missing packets normal operation resumes.

The ACK packet must be sent back down the route from which the coresponding data was received and not on the route where normal data transmits would be sent.

On route failure each endpoint must determine the failure independently and this only happens during data send. Example: There are exactly parallel routes between the two endpoints and the route in use for both sending and receiving fails. The receiving endpoint has not yet detected the route failure because it has not transmitted a data packet since the failure. When the renegotiate packet arrives if the ACK packet is sent down the old data route (the one that failed) rather than back down the route the renegotiate came from then the transmitting side would never receive the ACK even after several smaller packet retries and would incorrectly determine that the receiving endpoint had failed. □

2.2.1	Normal SPX-II ACK

The SPX-II ACK packet consists only of an SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS & SPX2 bit set

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	0

Acknowledge Number	current #

Allocation Number	m

Negotiation Size	Size of the largest packet receivable by the sending endpoint.

2.2.2	Normal SPX-II NAK

The SPX-II NAK packet consists only of an SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS & SPX2 bit set

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	> 0 (number of packets to be resent)

Acknowledge Number	current # (number of first packet not yet received)

Allocation Number	m

Negotiation Size	Size of the largest packet receivable by the sending endpoint.

2.3	SPX-II Connection Management Packets

In order for SPX-II to establish and maintain a connection between two endpoints, several specific types of packets are necessary. These are:

•	Connection Request

•	Session Negotiate

•	Session Setup

•	Renegotiate Request

•	Informed Disconnect

•	Orderly Release Request

•	Variations of the ACK packet.

2.3.1	Connection Request

The SPX-II Connection Request packet has the following SPX header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	42 (Same size as an SPX connection request)

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS, ACK, & SPX2 bits set (optionally NEG)

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	0xFFFF

Sequence Number	0

Acknowledge Number	0

Allocation Number	m3

2.3.2	Connection ACK

The SPX-II Connection ACK packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS & SPX2 bits set (optionally NEG)

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	0

Acknowledge Number	0

Allocation Number	m

Negotiation Size	Host driver packet size (576-65535)

2.3.3	Session Negotiate

The SPX-II Session Negotiate packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	Variable

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS, ACK, NEG & SPX2 bits set

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	0

Acknowledge Number	0

Allocation Number	m

Negotiation Size	Client driver packet size

Data	Negotiation values and padding to desired size

The header is followed by "n" bytes of data, where "n" is the minimum of the host driver packet size and the client driver packet size or smaller as required by negotiation retries. Only the first 532 bytes of data may contain optional information to be negotiated between the endpoints (See Negotiating Other Values Between Endpoints). The padding value is not significant and can be uninitialized data.

2.3.4	Session Negotiate ACK

The SPX-II Session Negotiate ACK packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS, NEG & SPX2 bits set

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	0

Acknowledge Number	0

Allocation Number	m

Negotiation Size	Size of largest received Session Negotiate packet

2.3.5	Session Setup

The SPX-II Session Setup packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	Variable

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition, the socket may change

Connection Control	SYS, ACK & SPX2 bits set (optionally NEG)

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	0

Acknowledge Number	0

Allocation Number	m

Negotiation Size	Size of largest received Session Negotiate packet

Data	Negotiation values (optional) and padding to desired size

The header is followed by "n" bytes of data, where "n" is the minimum of the host driver packet size and the client driver packet size or smaller as required by negotiation retries. If the NEG bit is set in Connection Control, the first 532 bytes of data may contain optional information to be negotiated between the endpoints (See Negotiating Other Values Between Endpoints). The padding value is not significant and can be uninitialized data.

2.3.6	Session Setup ACK

The SPX-II Session Setup ACK packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS & SPX2 bits set (optionally NEG)

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	0

Acknowledge Number	0

Allocation Number	m

Negotiation Size	Size of largest received Session Setup packet

2.3.7	Renegotiate Request

The SPX-II Renegotiate Request packet is used after connection establishment to renegotiate the packet size if the route has changed. It has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	Variable

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS, NEG, ACK & SPX2 bits set

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	current #

Acknowledge Number	current #

Allocation Number	m

Negotiation Size	Driver packet size

Data	Uint 0 then padding to desired size

The header is followed by "n" bytes of data, where "n" is the driver packet size or smaller as required by negotiation retries. The first word of the data must be zero (See Negotiating Other Values Between Endpoints) and the padding value is not significant and can be uninitialized data.

2.3.8	Renegotiate ACK

The SPX-II Renegotiate ACK packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS, NEG & SPX2 bits set

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	Current #

Acknowledge Number	Current #

Allocation Number	m

Negotiation Size	Size of largest received Renegotiate Request packet

2.3.9	Informed Disconnect

The SPX-II Informed Disconnect packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	ACK & SPX2 bits set

Datastream Type	0xFE

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	current #

Acknowledge Number	current #

Allocation Number	m

Negotiation Size	Size of the largest packet receivable by the sending endpoint.

2.3.10	Informed Disconnect ACK

The SPX-II Informed Disconnect ACK packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SPX2 bit set

Datastream Type	0xFF

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	0

Acknowledge Number	current # (Informed Disconnect Seq # + 1)

Allocation Number	m

Negotiation Size	Size of the largest packet receivable by the sending endpoint.

2.3.11	Orderly Release Request

The SPX-II Orderly Release Request packet has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	ACK, EOM & SPX2 bits set

Datastream Type	0xFD

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	current #

Acknowledge Number	current #

Allocation Number	m

Negotiation Size	Size of the largest packet receivable by the sending endpoint.

2.3.12	Orderly Release ACK

The SPX-II Orderly Release ACK packet is a normal SPX-II ACK, which has the following SPX-II header with these fields set:

Description	Value

Checksum	See SPX-II Header Definition

Length	44

Transport Control	0

Packet Type	5

Destination Address	See SPX-II Header Definition

Source Address	See SPX-II Header Definition

Connection Control	SYS & SPX2 bit set

Datastream Type	0

Source Connection ID	> 0 and != 0xFFFF

Destination Conn. ID	> 0 and != 0xFFFF

Sequence Number	0

Acknowledge Number	current #

Allocation Number	m

Negotiation Size	Size of the largest packet receivable by the sending endpoint.

3	Connection Management

SPX-II is a connection oriented guaranteed delivery service and tracks state and option information about the endpoints utilizing the connection. As a connection is being established between two endpoints, SPX-II allows negotiation of packet size and other parameters. Because IPX RIP based routers are non-deterministic when parallel routes exist between points, SPX-II negotiation exchanges several packets between the endpoints and determines each endpoint's send packet size.

3.1	SPX-II Client to SPX-II Host Connections with Negotiation

Assuming a normal SPX-II connection, the sequence of packets on the wire is as follows:

Packet originator	Packet Definition

Client	SPX-II Connection Request

Host	SPX-II ACK (Connection ACK)

Client	Session Negotiate Request

Host	SPX-II ACK (Session Negotiate ACK)

Host	Session Setup/Negotiate

Client	SPX-II ACK (Session Setup ACK)

3.1.1	Connection Request and ACK

SPX-II utilizes the SPX2 bit in Connection Control of the connect request packet to inform the host that an SPX-II connection is desired. The connect request can also set the NEG bit in Connection Control if the client wants to negotiate options and packet size. The SPX-II connect packet does not use the extended SPX-II header, but uses the SPX header to minimize the potential for impacting an SPX based host.

The SPX-II host recognizing the SPX-II connection request responds with an SPX-II ACK, indicating whether it is willing to negotiate options and packet size by setting the NEG bit in Connection Control.

3.1.2	Session Negotiate Request and ACK

This packet is sent by an SPX-II endpoint during connection establishment if both endpoints set the NEG bit in Connection Control of the Connection Request and Connection ACK packets. It is sent by the client as soon as the SPX-II Connection ACK packet is received. When the host receives a Session Negotiate packet it determines the size of the packet by accessing Length in the SPX-II header. It then uses this value to set Negotiation Size of the Session Negotiate ACK packet and sends the ACK to the client.

If the Session Negotiate packet is not acknowledged within an aggressive timeout period, which should be a function of the driver speed and the number of routers between the endpoints, then the size of the data should be reduced, such that n+44 is the next logical driver size and the packet should be re-sent (See Appendix C - Default, Minimum and Maximum Values).

If multiple Session Negotiate packets are received by the host, because of delayed packets or lost ACKs. Negotiation Size in the Session Negotiate ACK generated by the host should contain the size of the largest Session Negotiate packet received.

3.1.3	Session Setup and ACK

The Session Setup packet is sent by the host only after the Session Negotiate ACK or after the Connection ACK if negotiation is not used. With the reception of this packet the client will inform the application that a connection has been established. The client must also acknowledge this packet with a Session Setup ACK. The session is considered established by the host only after it has received the Session Setup ACK and is considered established by the client only after sending the Session Setup ACK. Once the session is established both endpoints are in data transfer state.

The Session Setup packet may indicate that the host's address has changed to a different socket. This is indicated in Source Address of the SPX-II header. The client must detect this change and send all future packets, including the Session Setup ACK, to this new address (Connection IDs remain unchanged).

If the Session Setup packet is not acknowledged within an aggressive timeout period, which should be a function of the driver speed and the number of routers between the endpoints, then the size of the data should be reduced, such that n+44 is the next logical driver size and the packet should be re-sent (See Appendix C - Default, Minimum and Maximum Values).

If multiple Session Setup packets are received by the client, because of delayed packets or lost ACKs. Negotiation Size in the Session Setup ACK generated by the client should contain the size of the largest Session Setup packet received.

It is very important that Sequence Number in the Session Setup packet be set to zero. This allows the client to differentiate between a Session Setup retry and a Renegotiate Request that happens to occur on the first data packet. A Renegotiate Request that occurs on the first data packet will have a sequence number of 1, even though the data packet will have a sequence number of 0. □

3.1.4	Renegotiate Request and ACK

This packet is sent by either endpoint anytime the endpoint has detected a route change and the following conditions exist: the connection is in data transfer state and both endpoints set the NEG bit in the Connection Control field of the Connection Request and Connection ACK packets. It normally occurs after retry failure and route relocation has been successful. When the connection partner receives a Renegotiate Request packet it determines the size of the packet by accessing Length in the SPX-II header. It then uses this value to set Negotiation Size of the Renegotiate ACK packet. The connection partner flushes any "out of sequence packets" being held because of NAK processing and then returns the Renegotiate ACK.

Assuming a normal SPX-II connection that is recoverable, the sequence of packets on the wire is as follows:

Packet originator	Packet Definition

Endpoint 1	SPX-II Data Packet(s) (not received by Endpoint 2)

Endpoint 1	Route Relocation (Get Local Target)

Endpoint 1	Watchdog with ACK request

Endpoint 2	SPX-II ACK to watchdog

Endpoint 1	Session Renegotiate Request

Endpoint 2	SPX-II ACK (Session Renegotiate ACK)

Endpoint 1	Retransmit SPX-II Data not received by Endpoint 2

(Note: Because of potential packet size differences before and after the renegotiation, the packet boundaries of the retransmitted data may not be the same as when the data was sent the first time.)

If the Renegotiate Request packet is not acknowledged within an aggressive timeout period, which should be a function of the driver speed and the number of routers between the endpoints, then the size of the data should be reduced, such that n+44 is the next logical driver size and the packet should be re-sent (See Appendix C - Default, Minimum and Maximum Values).

If multiple Renegotiate Request packets are received by either endpoint, because of delayed packets or lost ACKs. Negotiation Size in the Renegotiate ACK should contain the size of the largest Renegotiate Request packet received. Only one renegotiation is permitted for a given sequence number. Otherwise it is impossible to differentiate between a delayed Renegotiate Request and a subsequent Renegotiate Request for the same data packet.

The Sequence Number field of the Renegotiate Request contains the next sequence number not already used by a data packet. Acknowledge Number of the Renegotiate Request ACK contains the appropriate number for the last data packet received (ie. last good data packet sequence number + 1). And Allocation Number of the Renegotiate Request ACK contains the appropriate number relative to the Sequence Number of the Renegotiate Request. All data packets buffered by the receiver, due to out of order packet processing, must be discarded. The Sequence Number of the first valid data packet after successful renegotiation is the same Sequence Number contained in the Renegotiate Request.

Example: The route fails during NAK processing of a lost packet and the receiving endpoint is buffering data packets. These buffered data packets cannot be used because after renegotiation the packet size may be different than previously used, and data alignment problems would occur. Similarly the sequence numbers cannot be reused, because some of the older differently sized packets may be delayed in route and must be thrown away as previously seen and acknowledged packets otherwise if they were accepted they would cause the same data alignment problem. □

3.1.5	Negotiation and Setup Retries

The nature of the negotiation algorithm provides a retry mechanism. However, once negotiation has reduced the packet size to the minimum 576 byte packet, the Session Negotiate, Session Setup or Renegotiation Request packets should be retried RETRY_COUNT times.

3.2	Packet Definitions for SPX-II Client to SPX-II Host Without Negotiation

It may be desirable for a given SPX-II session to avoid the negotiation overhead. If the application "knows" that all packets will be small (less than 576) or that the connection will be short lived, the application could specify through the API that negotiation is not wanted. In this case the SPX-II Connection Request packet does not have the NEG bit set in Connection Control. This informs the host that negotiation packets will not be sent nor acknowledged by the client.

Assuming a normal SPX-II connection without negotiation is desired by the client, the sequence of packets on the wire is as follows:

Packet originator	Packet Definition

Client	SPX-II Connection Request (NEG bit NOT set)

Host	SPX-II Ack (NEG bit NOT set)

Host	Session Setup (NEG bit NOT set)

Client	SPX-II Ack (NEG bit NOT set))

If the host application rather than the client application did not want to negotiate the connection sequence would be:

Packet originator	Packet Definition

Client	SPX-II Connection Request (NEG bit set)

Host	SPX-II Ack (NEG bit NOT set)

Host	Session Setup (NEG bit NOT set)

Client	SPX-II Ack (NEG bit NOT set))

3.3	Packet Definitions for Mixed SPX-II and SPX Connection Endpoints

With one of the major goals of SPX-II being backward compatibility with SPX, it is necessary for SPX-II endpoints to be able to connect to SPX endpoints and visa-versa. Assuming a normal SPX-II to SPX connection, the sequence of packets on the wire is as follows:

Packet originator	Packet Definition

Client	SPX-II Connection Request

Host	SPX Connection ACK

The client issues an SPX-II Connection Request with the SPX2 bit set. The host being SPX ignores the SPX2 bit and returns a standard SPX Connection ACK. At this point the client recognizes that the host did not set the SPX2 bit in the ACK and reverts to standard SPX connection protocol.

Assuming a normal SPX to SPX-II connection, the sequence of packets on the wire is as follows:

Packet originator	Packet Definition

Client	SPX Connection Request

Host	SPX Connection ACK

The client issues an SPX Connection Request (which has the SPX2 bit cleared). The host recognizes that the SPX2 bit is not set and returns a standard SPX Connection ACK and uses standard SPX connection protocol.

3.4	Session Setup Timeout

An SPX-II session is not established until the Session Setup packet is received by the client. During this session setup state, a session setup timeout occurs when the Session Setup packet does not arrive within a specific time period. The time period does not begin until after the SPX-II Connection Request and SPX-II Connection ACK have established a connection between the connection partners. The timeout value is configurable by the application with a value of zero indicating an infinite timeout.

3.5	Negotiating Other Values Between Endpoints

Since all sessions that negotiate packet size during connection establishment send negotiation packets from the client to the host and from the host to the client, it is possible for the endpoints to share other information in these packets. The type of information that might be shared is:

•	Timeout values

•	Time to net

•	Retry counts

•	Route information

•	IPX checksum control

The first word (high-low format) in the data portion of the Session Negotiate packet or the Session Setup packet is a count of the number of negotiate value fields contained in the packet. Each field is composed of a type followed by a value.

IMPORTANT: Values (other than size) may only be negotiated at connection establishment time and only if both endpoints agree by setting the NEG bit in Connection Control. All subsequent Renegotiate Request packets must contain a zero (0) in the first word of the data portion of the packet.

The format of a negotiate value field is as follows:

Field	Length	Description

Type	1	ID Number / Size combination

Extended ID	1	Optional: See below

Extended Size	1	Optional: See below

Value	1-?

3.5.1	The Type Field

The type is a byte composed of two subfields. The low two bits of the type specify the size of the value and the upper six bits are the identification number (ID number). Note that the ID number subfield alone has no meaning. The ID number only has meaning in combination with the size subfield (ie. there could be a value of size Ubyte with ID number = 1 and a value of type Uint with ID number = 1 and these would not conflict).

Although it would be possible to identify a value by using the ID number subfield only, it would limit the specification to only 63 possible ID numbers. Further, it would unnecessarily complicate the code by requiring the implementation to verify that the size associated with a particular ID was the size it expected to see and by requiring the implementation to separate the two subfields to process them. Therefore, the combination of the size subfield and the ID number subfield will constitute a unique type rather than the ID number alone.

With the size bits occupying the lowest two bits of the type, an implementation can easily determine the size of an unrecognized type by simply masking off the upper six bits and using the result as a table index. □

See Appendix A - Type Numbers for a list of currently defined type numbers.

3.5.2	The Size Subfield

The size subfield of the type can contain one of four possible values. These values and their corresponding meanings are described below:

Binary	Meaning

00	Ubyte

01	High-Low Uint

10	High-Low Ulong

11	Extended Size (length to follow)

When the size subfield contains a binary 11 (meaning Extended Size) the Ubyte immediately preceding the value will contain the size of the value in bytes. For example: if the size field is set to binary 11 and the byte immediately preceding the value is 12 then the value field is 12 bytes long.

3.5.3	The ID Number Subfield

The ID number subfield of the type can contain one of 64 possible values. Values between 0 and 62 are used to distinguish particular variables to be exchanged (see type table below). A value of 63 (binary 111111) indicates an Extended ID. When used, the extended ID immediately follows the type field. This extended ID field will contain a number between 0 and 255 and will be unique for each size (ie. there could be a value of size Ubyte with extended ID = 1 and a value of size Uint with extended ID = 1 and these would not conflict).

Again, the extended ID alone has no meaning. The extended ID (just like the ID number subfield) only has meaning in combination with the size.

The ID number subfield occupies the upper six bits of the type field. This allow an implementation to check for the extended type without having to mask and shift. Simply compare the type to binary 11111100, if it is greater than or equal then it is an extended ID. □

3.5.4	Type, Extended Type, Value, Extended Value Combinations

It is reasonable to assume that there will be times when a negotiation packet will contain an extended size without an extended ID or vice versa. The minimum size would be a type followed by a value, while the maximum size would be a type followed by an extended ID followed by an extended size followed by a value.

The above scheme was devised in a effort to reduce the amount of space necessary to communicate information between endpoints. This allows maximum information exchange in minimum space (most variables will be communicated in only 2 bytes) while still allowing for larger variables and expansion.

At this time we do not see any reason to use the extended size or extended ID fields. However, it is required that all implementations support both of these concepts so that future versions can make use of them as needed. □

3.5.5	Disparate Versions of SPX-II

Two disparate versions of SPX-II may communicate variables that the other is unaware of by using the following algorithm. If an endpoint receives a type that it does not recognize it can skip the value field by looking at the size subfield to find the number of bytes to skip. An endpoint indicates that it does not recognize a particular type by not returning data for that type in the reply packet. If an endpoint does not receive a type / value pair for a newly defined variable it could use a default value or reject the connection if the information was critical (this would of course be bad for backward compatibility, but could be done in extreme circumstances).

3.6	Session Termination

When one endpoint of an SPX-II session decides to terminate the connection there are three ways of accomplishing it: Unilateral Abort, Informed Disconnect, or Orderly Release.

3.6.1	Unilateral Abort

A Unilateral Abort should only be used when one endpoint has detected a connection failure, through retry failure or watchdog failure. In this case there is no benefit in sending an Informed Disconnect, since the connection partner is not responding. A Unilateral Abort assumes that the connection partner has failed or will be able to detect that the connection is no longer valid.

3.6.2	Informed Disconnect

An Informed Disconnect terminates the session immediately without giving the connection partner an opportunity to complete any transmissions. The Informed Disconnect differs from the Unilateral Abort by exchanging disconnect packets between the endpoints. An Informed Disconnect has the following packet sequence:

Packet originator	Packet Definition

Endpoint 1	SPX-II Informed Disconnect

Endpoint 2	SPX-II Informed Disconnect Ack

The Informed Disconnect packet should be retried as a normal data packet, however route rediscovery and renegotiation are not required. If all retries are exhausted then the endpoint may perform a Unilateral Abort. An Informed Disconnect packet is not subject to window closure (See Additional Resource Requirements).

An Informed Disconnect may cause data to be lost, either because data packets had been lost just prior to the Informed Disconnect, but a NAK cannot be generated in response to an Informed Disconnect, or the requirements of the environment may require queues to be flushed to ensure the Informed Disconnect is processed properly.

3.6.3	Orderly Release Request

An Orderly Release Request terminates the session after both endpoints agree to the termination. This allows the endpoint receiving the release request an opportunity to complete any data transmissions, and the endpoint sending the release request agrees to receive and process the data. Once the endpoint receiving the release request completes its data transmissions it should also send an Orderly Release Request back to the other endpoint. Following the second orderly release exchange the session is terminated by both endpoints. A full orderly release has the following packet sequence:

Packet originator	Packet Definition

Endpoint 1	SPX-II Orderly Release Request

Endpoint 2	SPX-II Orderly Release ACK (Normal ACK)

Endpoint 2	Optional, n data packets, with endpoint 1 responding with the appropriate ACKs.

Endpoint 2	SPX-II Orderly Release Request

Endpoint 1	SPX-II Orderly Release ACK (Normal ACK)

The Orderly Release Request should be treated as a normal data packet, with route rediscovery and renegotiation (if applicable) required. When all reties are exhausted then the endpoint may perform a Unilateral Abort. Neither an Orderly Release Request nor an Orderly Release ACK is subject to window closure, but the Orderly Release Request is still sequenced and retried as a normal data packet.

This allows implementations that determine window size and state based on application receive buffers. An application waiting for an Orderly Release Request would not necessarily have provided receive buffers to the protocol. □

3.7	SPX-II Watchdog Algorithm

SPX implemented the watchdog as an optional component on each connection. Under SPX-II, connection watchdog management is required. Also, SPX-II has changed the watchdog algorithm to provide a more efficient exchange between endpoints. SPX-II only supports the "are you there" request rather than both "are you there" and gratuitous "I am here" packets that SPX uses.

The watchdog routine is a passive element in SPX-II. Watchdog packets are sent only if there is an extended period with no traffic on the session. The default WATCHDOG_TIMEOUT (the period between the last packet traffic on the session and the first watchdog packet) is 60 seconds and is configurable by the application. Any packet that arrives for a session will reset the watchdog timer for that session. This includes system packets as well as user data packets (ie. an acknowledgement of transmitted data would reset the timer).

A watchdog request packet consists of an SPX-II header with the SPX2, SYS and the ACK bits set. The receiver will respond to this packet with a watchdog acknowledgement packet. A watchdog acknowledgement packet consists of a packet with the SPX2 and SYS bits set. Note that a data ACK can be "piggy-backed" on a watchdog packet.

Before the watchdog algorithm can terminate a connection it must perform one half (1/2) the standard number of retries with appropriate timeouts between attempts just as is done for data packets. If the connection partner has still not responded, the watchdog algorithm must also attempt to locate a new route -- same as for a normal data packet. If the watchdog algorithm has completed all these steps and still has not received a response from the connection partner, the algorithm may assume that the partner is unreachable and may perform a Unilateral Abort to terminate the connection.

An approiate timeout for the watchdog retries could be obtained by simply using the data packet transmit and retry code to transmit watchdog packets. This means that this transmit code will need to differentiate between watchdog packets and normal data packets so as not to send a second watchdog or renegotiate size as required by the data timeout and size renegotiation algorithms. Note however that a size renegotiation will not cause problems and may be beneficial in improving recovery time from a route failure. □

In short, the steps for watchdog packets are:

•	Send watchdog packet when the watchdog timer expires, if no ACK received

•	Retry the watchdog RETRY_COUNT/2 times, increasing the timeout value before each retry

•	Attempt to locate a new route

•	Retry the watchdog the remaining RETRY_COUNT/2 times and if unsuccessful perform a Unilateral Abort.

See the annotation in the section Calculating Window Size for additional information how the watchdog assists in window management.

3.8	Session Watchdog During Connection Establishment

SPX-II considers a connection to exist once an endpoint has both connection IDs. This happens after the receipt of a Connection Request at the host, or the receipt of a Connection ACK at the client. If the connection exists it should be monitored by the watchdog system. This is necessary, because a connection may fail after the initial packet exchange, but before any other packet exchange, such as Session Negotiation or Session Setup, has taken place. The watchdog system must be aware that the destination endpoint of the connection may change after the Session Setup packet exchange. It may be necessary for the watchdog system to use different timing parameters for a session that is still in the setup state, as compared to a session that is in the data transfer state.

4	Connection ID Numbers

Connection ID numbers are assigned as follows. Each endpoint determines a random starting point for connection ID numbers when that endpoint first becomes active. When a new connection ID number needs to be generated, SPX-II will increment the current number and then check to see if the new number is in use. If the new number is in use, SPX-II will again increment the number and check to see if the new number is in use. This process continues until an ID number is found that is not in use.

As a performance improvement it is suggested that the implementation use Connection ID as a direct index into the session table. This can be accomplished by incrementing the Connection ID and wrapping at the current maximum table size. Implementations where the configured table size can be changed while running should ensure that table size reduction does not move the end of the table below the last currently used slot.

In an attempt to prevent a reboot of the system from allocating the same Connection ID numbers in the same order it is suggested that the implementation initialize the Connection ID number with a random value. This number might be taken from the system clock, if available. □

5	Windowing Algorithm

One of the goals of SPX-II is to increase transmission speed by implementing a true windowing protocol. SPX-II implements a windowing protocol with the following features:

•	Managing Sequence and Acknowledge numbers

•	Positive and Negative Acknowledgements

•	Extensive error recovery mechanisms

5.1	Managing Sequence and Acknowledge numbers

The sequence number is an ever increasing (except when wrapping past zero) number that identifies the order of the data being sent and received. The acknowledge number is also an ever increasing number identifying all the data packets that have been successfully received and indicating the sequence number of the next packet that is expected by the receiving endpoint. The first data packet sent will have Sequence Number zero and assuming that data packet had the ACK bit set in Connection Control, the ACK sent in response to that data packet will have Acknowledge Number set to one.

There is an easy way to manage these two values (there are actually two sets of values, the numbers for sending and the numbers expected when receiving). When sending a data packet, increment Sequence Number after placing the data packet on the "to be sent" queue or if no queueing mechanism is used, upon return from the send function. When generating an ACK, set Acknowledge Number in the ACK packet to the received data packet's Sequence Number plus one. □

5.2	Positive and Negative Acknowledgements

An SPX-II positive acknowledgement is defined as an SPX-II ACK with Sequence Number set to zero and Acknowledge Number set to the next packet expected by the receiver or a data packet with Acknowledge Number set to the next packet expected by the receiver (this type of acknowledgement is know as a "piggy-
back" ACK, and ACKs can be "piggy-backed" on any packet, data, system or watchdog). A negative acknowledgement (NAK) is defined as an SPX-II ACK with Sequence Number set to the number of packets missed and Acknowledge Number set to the first packet to be resent by the connection partner. There is no way to send a negative acknowledge with a data packet (ie. no "piggy-back" NAK).

In order for the transmitter to properly calculate round trip time the transmitter must be able to determine when acknowledges are generated. The receiver is "passive" with respect to positive acknowledgements and will only generate a positive acknowledgement when the ACK bit is set for a packet (See Connection Control field description).

In addition to allowing the transmitter to determine the round trip time, using this method allows substantial changes to the implementation of the transmitter in future versions. With the receiver in "passive" mode, the transmitter can implement any of a number of windowing algorithms without being incompatible with existing SPX-II implementations. □

5.3	Extensive Error Recovery Mechanisms

When SPX detected an error it didn't know how to handle, it simply aborted the session. SPX-II, however, specifies how various error conditions will be handled.

5.3.1	Data Packet Timeout

During normal operation if the connection partner fails to acknowledge a packet, the sender must retry the packet RETRY_COUNT/2 times, each time increasing the round trip time value by 50%, up to MAX_RETRY_DELAY (default is 5 seconds). If the packet still has not been acknowledged, the sender must attempt to locate a new route to the connection partner. Whether a new route is located or not, immediately send a watchdog packet requesting an acknowledgement. This watchdog packet should be retried RETRY_COUNT times. After receiving an acknowledgement to the watchdog request, renegotiate packet size followed by retransmitting any unacknowledged data with Sequence Number being set according to the rules of renegotiation (See Renegotiate Request and ACK) or to the value of the first unacknowledged data packet if the NEG bit was not set during Connection Setup.

If the watchdog packet is not acknowledged, the remaining retries (RETRY_COUNT/2) are attempted on the data packet and if unsuccessful the connection is aborted with a Unilateral Abort.

If an error occurs with the same data packet after renegotiation the packet is retried RETRY_COUNT times and if unsuccessful then the connection is aborted with a Unilateral Abort. SPX-II only attempts to locate a new route and renegotiate one time for a given sequence number, otherwise the connection partner cannot differentiate between a retried Renegotiate Request and a subsequent Renegotiate Request.

In short, the steps are:

•	Retry the data packet RETRY_COUNT/2 times, increasing the timeout value before each retry

•	Attempt to locate a new route

•	Send a watchdog packet (and retries as needed)

•	If watchdog is successful, renegotiate packet size, resume sending data packet

•	If watchdog is not successful, retry the data packet RETRY_COUNT/2 times and if unsuccessful perform a Unilateral Abort.

•	After successfully retransmitting the first data packet after renegotiation then resume normal operation.

The algorithm is using 1/2 the RETRY_COUNT in order to give preference to the possibility of route failure over endpoint failure or network congestion. By retrying less before attempting to relocate a new route the protocol will recover faster on very dynamic networks. This is better than just reducing the RETRY_COUNT to a smaller number, because it still provides more retries and longer delays between retries on congested networks. □

5.4	Window Size

It is the responsibility of the receiver at each endpoint to calculate the window size for packets received by that endpoint. The receiver then communicates this number to the transmitter via the allocation number field in the SPX-II header by adding the calculated window size to the current sequence number. The receiver is free to change the window size during the session with the stipulation that the receiver can never reduce an already granted window. The transmitter is allowed to send packets while the sequence number is less than or equal to the allocation number.

The reason that the advertised window size cannot be reduced has to do with the processing of the allocation and sequence numbers. The transmitter is allowed to send packets until the sequence number is equal to the allocation number. If the receiver tried to reduce the allocation number after the transmitter had already sent a packet with that sequence number, the transmitter would perceive that the window had grown to nearly 64k packets. The only way for the receiver to reduce the window size is to allow the acknowledge number to grow without increasing the allocation number.

For example, the receiver could not send a packet indicating an allocation number of 1210 and then send a subsequent packet indicating an allocation number of 1208. However the receiver could send a subsequent packet indicating an allocation number of 1210 even though the acknowledge number may have increased by 2, effectively reducing the window size by 2. □

During window management it is possible, because of resource limitation or other reason, for the receiving side to close the data receive window completely by sending a packet indicating that the next sequence number expected is greater than the next allocation number. When this happens the receiver must be prepared to reopen the window after the flow control condition has cleared, and must handle the possibility that the reopen packet may be lost.

Once a window has been closed it is reopened with either a normal data packet or a system packet indicating an allocation number greater than or equal to the sequence number. If this reopen information is attached to a data packet the normal data retry mechanism will ensure delivery. However, if the data flow over the connection is primarily one way or the window also happens to be closed in the opposite direction, the reopen information will be included in a system packet which is not retransmitted and may be lost.

If the reopen packet is lost, the watchdog will eventually send a series of system packets that will reopen the window, however there may be a delay up to WATCHDOG_TIMEOUT before this occurs. When window management is reopening a window with a system packet it could request the watchdog system to increase the frequency of the watchdog packets (about 3 seconds between queries). The watchdog system would remain in this increased frequency state until a data packet arrives. □

There are several options for the receiver to select a window size. The implementor is free to select any algorithm as long as the protocol specification is not violated by the algorithm.

Perhaps the simplest approach is to select a hard coded value and use it. A number between 4 and 16 is probably appropriate under most circumstances. A slightly more complex approach would have specific values for different conditions. For example, a value of 4 for "local" LANs (less than 4 hops away) and a value of 8 for all others. One could also select an algorithm based on the reported time to net. One such algorithm would be to use the reported time to net (in IBM PC "ticks") shifted left 2, with a maximum of value of 16. More complex algorithms, such as a heuristic determination based on dropped packets, are certainly possible, but are beyond the scope of this document. □

5.5	Additional Resource Requirements

Only data packets are subjected to window size constraints, all system packets and the Informed Disconnect packet can be sent even if the receiving side has closed its receive window. This implies that there are resources, considered system resources, which are not included in the size of the window reported to the connection partner.

6	Congestion Control Algorithm

The following notes are for consideration purposes only, since congestion control support was removed for the initial release of SPX-II, due to time constraints.

Congestion control will be included in a future release of SPX-II. This is possible because the receiving side is subservient to the transmitting side and will only send acknowledgements when the transmitting side requests. There are no gratuitous ACKs. Part of congestion control could use Van Jacobson's window size algorithm or an error protocol between routers and SPX-II.

An easy congestion control algorithm is for the transmitter to set the ACK request bit on every packet. This has the effect of holding the transmitter, once the window is full because of a message burst, to a single packet every time an ACK comes in. The ACKs will be delayed or lost appropriate to the congestion on the network. This algorithm does not work well if routers do not forward packets in the order they were received (ie. out of order packets) because the NAK algorithm will cause unnecessary retransmissions. □

7	Calculating Timeouts and Round Trip Time

7.1	Calculating Round Trip Time

In order to calculate an appropriate round trip time it is necessary to use something considerably more accurate than the standard IBM PC 1/18 second system "ticks." Because network speeds are presently at 100 mbps and growing it will be necessary to measure times down to at least the microsecond (1/1,000,000 sec) level. This is not a problem for most computer systems in use today.

On IBM PC type platforms it is possible to achieve this level of resolution by reading the count down counter in the timer chip. By combining this information with the "tick" count kept by the BIOS you can achieve a clock rate of approximately 1.193 mhz or about 838 nanoseconds. □

The calculation of an appropriate round trip time is based on the Van Jacobson method of using the average as well as the deviation of the measured round trip time. A method for calculating this using simple integer arithmetic is shown below.

It is important to note that round trip time must not be measured if the sender issued a retry on the ACK request packet. To do so would allow the reply to the first request to generate a false "short" round trip time if it was received immediately after the second transmit.

7.2	Calculating Timeouts

The timeout value used to determine that a packet has not arrived is round trip time + 2 mean deviations of round trip time. The initial value for the round trip time will be two times the transport time returned by the get local target call. Using this method allows some deviation in the amount of time required to deliver packets, but does not unnecessarily delay a retransmit in cases where a packet may be lost.

7.3	Van Jacobson Average And Mean Deviation Calculations

Calculate the round trip time (RTT) by using Van Jacobson's method (as explained on page 10 of his message). There are three values to be calculated. The first is Err (the absolute value of the difference between the measured round trip time and the calculated round trip time). The second is MDev (the mean deviation of the round trip time). The third value is Avg (the average round trip time). The measured round trip time is represented by Meas. These values are calculated as follows:

Err = abs(Meas - Avg)

Avg += g1 * (Meas - Avg)

MDev += g2 * (Err - MDev)

The g1 and g2 factors are used to dampen the effects of transient bursts in the packet flow. Because g1 and g2 must be less than 1 the above calculations would involve floating point math. To avoid this, we will scale the calculations. To avoid loss of precision we will keep MDev and Avg in the scaled form. Van Jacobson suggests values of .1 (1/10) for g1 and .25 (1/4) for g2. Because a value of .1 (1/10) would be difficult to calculate we will use a value of .125 (1/8). By multiplying 1/g1 and 1/g2 through the above equations we achieve the following:

8 * Avg += Meas - Avg

4 * MDev += Err - MDev

We can express the full function as follows:

Meas -= (Avg >> 3)	// Meas now holds Err

Avg += Meas	// 8 * Avg += Meas - Avg

if (Meas < 0)

Meas = -Meas	// Accomplish abs(Err)

Meas -= (MDev >> 2)	// Calculate Err - MDev

MDev += Meas	// 4 * MDev += Err - MDev

rtt = (Avg >> 3) + (MDev >> 1)	// round trip timer = Avg + 2 * MDev

8	Appendix A - Option Negotiation Type Numbers

The following is a complete list of the Type Field contents and their intended meaning as of the time of this writing. In the following table the Type entry is expressed in hexadecimal, the ID and Size entries (the subfields of the Type) are expressed in binary. The ID and Size entries are provide for ease of understanding only. These are simply the eight bits that make up the Type field.

Type	ID (binary)	Size (binary)	Description

0x02	000000	10 (Ulong)	Time To Net: The time value returned by the Get Local Target or Get Route call expressed in microseconds. This value is communicated from the client to the host to eliminate the need for the host to call Get Local Target simply to get the time to net for initial timeouts. It is not necessary for the host to return this information to the client as it was provided unilaterally for the host's use.

0x04	000001	00 (Ubyte)	IPX Checksum: This is a boolean field, TRUE (non-zero) indicates that the endpoint wants IPX checksum verification.

9	Appendix B - TLI Option Management

TLI provides two mechanisms for exchanging option information between the protocol stack and the application. The first is mechanism is the t_optmgmt function and the second is in the t_call structure. SPX-II has several options and values that an application may need to set or examine. The following 'C' structure is used for TLI and indicated the read (r), write (w) or read/write (r/w) attribute and whether the field is applicable to the t_optmgmt function (o), the t_call structure (c) or both (b).

typedef struct spx2_options	{

u32	versionNumber;	// (r/w,b) Must be set to OPTIONS_VERSION

u32	spxIIOptionNegotiate;	// (r/w,b) Exchange options and negotiate packet size

u32	spxIIRetryCount;	// (r/w,b) Number of retries on data packets

u32	spxIIMinimumRetryDelay;	// (r/w,b) Minimum retry timeout, in milliseconds

u32	spxIIMaximumRetryDelta;	// (r/w,b) Maximum retry delta, in milliseconds

u32	spxIIWatchdogTimeout;	// (r/w,b) Number of milliseconds to wait before 1st // watchdog

u32	spxIIConnectTimeout;	// (r/w,b) Number of milliseconds to wait for full // connection setup

u32	spxIILocalWindowSize;	// (r/w,b) Number of packets in data window

u32	spxIIRemoteWindowSize;	// (r,c) Number of packets in data window

u32	spxIIConnectionID;	// (r,c) Valid only after connection is established

u32	spxIIInboundPacketSize;	// (r,c) Size of packets coming from other endpoint

u32	spxIIOutboundPacketSize;	// (r,c) Size of packets being send to other endpoint

u32	spxIISessionFlags;	// Session characteristic options (see desc. for r/w)

} SPX2_OPTIONS;

When t_optmgmt is used, the protocol stack is able to adjust the values specified and inform the application of the adjustment. When the t_call structure is used the protocol stack may be unable to inform the application of any adjustments, however, the adjustments are still valid. A particular implementation is required to support only the options identified by an asterisk.

versionNumber	This field is a monotonically increasing number which can be used by the protocol to determine the fields supported by the application. Each time the structure is enhanced this version number will be increased. It is recommended that for transparency an SPX-II TLI based application use t_alloc and t_getinfo to allocate and determine the size of the options structure, rather than using stack variables and the 'C' operator sizeof(SPX2_OPTIONS) respectively.

spxIIOptionNegotiate	This option specifies whether the application wants to exchange option information with the remote endpoint and whether or not to determine the largest packet size. The values for this field are:

SPX_NEGOTIATE_OPTIONS	(The default)

SPX_NO_NEGOTIATE_OPTIONS

spxIIRetryCount	When a transmission failure for a data packet is detected, SPX-II will resend the data. This specifies the number of attempts SPX-II will make before unilaterally aborting the connection. A value of zero indicates to the protocol stack to use the current default.

spxIIMinimumRetryDelay	Setting this field to non-zero indicates that the application wants to override the internal round trip time calculation algorithm and wants to specify a minimum timeout value before SPX-II re-sends a data packet. A value of zero indicates to the protocol stack to determine round trip time (recommended).

spxIIMaximumRetryDelta	The value of this field is added to spxIIMinimumRetryDelay or to the current round trip time (if spxIIMinimumRetryDelay is zero) to determine the maximum retry delay. A value of zero indicates to the protocol stack to use the current default.

spxIIWatchdogTimeout	This value determines the amount of time the watchdog algorithm will allow to pass on a silent connection before sending a watchdog query packet to determine if the other side is still available. A value of zero indicates to the protocol stack to use the current default value.

spxIIConnectTimeout	This value determines the amount of time after a successful connect request before the session setup packet must arrive. A value of zero specifies an infinite timeout.

spxIILocalWindowSize	This specifies the size, in packets, of the local endpoint receive window. A value of zero indicates to the protocol stack to determine the receive window size.

spxIIRemoteWindowSize	This is an information only field and is only valid after a connection has been established. It is the number of packets in the remote endpoint's receive window.

spxIIConnectionID	This is an information only field and is only valid after a connection has been established. It is the local endpoint connection ID.

spxIIInboundPacketSize	This is an information only field and is only valid after a connection has been established. It is the size in bytes for incoming packets. This value may change if SPX-II has to renegotiate after a route change. If this occurs there is no way for the application to receive this new information.

spxIIOutboundPacketSize	This is an information only field and is only valid after a connection has been established. It is the size in bytes for outgoing packets. This value may change if SPX-II has to renegotiate after a route change. If this occurs there is no way for the application to receive this new information.

spxIISessionFlags	This is a bit field and contains a set of flags used to control characteristics of the SPX-II packets on the wire. These characteristics might include packet checksums, data signing or data encryption. The currently defined values are:

SPX_SF_NONE	0x00

SPX_SF_IPX_CHECKSUM	0x01	// (r/w,b)

SPX_SF_SPX2_SESSION	0x02	// (r,c)

After connection is established indicates whether or not it is an SPX-II or an SPX connection.

10	Appendix C - Default, Minimum and Maximum Values

Documentation Constants

Throughout the document the following constants are used to indicate some value. The table below provides the default, minimum and maximum values for each constant.

Constant	Default	Min	Max

RETRY_COUNT	10	3	50

MIN_RETRY_DELAY	04	1 ms	60 seconds

MAX_RETRY_DELTA	5 seconds	1 second	60 seconds

MAX_RETRY_DELAY	(calculated from MIN_RETRY_DELAY and MAX_RETRY_DELTA)

WATCHDOG_TIMEOUT	60 seconds	3 seconds	5 minutes

CONNECT_TIMEOUT	05	1 second	2 minutes

LOCAL_WINDOW_SIZE	06	1	16

Connection Termination Reason Codes

A connection can be terminated for several reasons. The following constants represent those reasons and provide the value that SPX-II must generate.

SPX_CONNECTION_TERMINATED	0xec	A disconnect inform packet was received from the connection partner.

SPX_CONNECTION_FAILED	0xed	Watchdog timer detected failure, or retry count reached zero during a send operation

SPX_PACKET_OVERFLOW	0xfd	Internal consistency check failed, usually an indication that packet size negotiation failed to negotiate correctly.

SPX_MALFORMED_PACKET	0xfe	Secondary internal consistency check failed. Usually used to report to application that an implementation bug has been detected.

Driver Packet Sizes

Logical driver packet sizes for packet size negotiation:

576	SPX packet size and SPX-II minimum packet size

1024	"Turbo" Arcnet packet size, (NetWare 3.1x only)

1474	Ethernet 802.2 SNAP

1492	Ethernet 802.2

1500	Ethernet 802.3 or Ethernet II

1954	2k 4 mbit TokenRing

4002	4k 4 mbit TokenRing

8192	16 mbit TokenRing (bandwidth diminishing return point)

17314	17k 16 mbit TokenRing

65535	IPX packet maximum

11	Appendix D - IPX Checksum

With the introduction of NetWare SFT III v3.11, it became necessary to provide checksum support for NetWare Core Protocol (NCP) packets. IPX is a datagram service and there is no way of "negotiating" whether the two endpoints support IPX checksum before the first packet is sent, so NCP negotiates this option. If both endpoints support IPX checksum, NCP tells IPX to perform the checksum on the packets before sending them out. SPX-II also has an option negotiation mechanism during connection establishment which can be used to request that if both endpoints support IPX checksum it should be used. If the endpoints negotiate that checksum is to be used, the checksum algorithm is:

•	Initialize the checksum field of the IPX header to zero

•	Summation (add with carry) of all words (16 bits) in the packet, with the words being picked up as "little endian" (Intel order) unsigned values.

•	If the number of bytes in the packet is odd, the high order byte necessary for the last word summation is set to zero.

•	Add in final overflow indication (carry flag).

•	Negate (1's complement)

•	Store in IPX header checksum field

To verify the checksum the steps are similar:

•	Summation (add with carry) of all words (16 bits) in the packet, with the words being picked up as "little endian" (Intel order) unsigned values.

•	If the number of bytes in the packet is odd, the high order byte necessary for the last word summation is set to zero, then add in final overflow indication (carry flag).

•	Add in final overflow indication (carry flag).

•	The result should be -1, if not an error has occurred.

The default negotiation value for checksum is NO checksum. If an application wants to negotiate checksum with its connection partner it can do so using the TLI t_optmgmt function and by setting the spxIISessionFlags field of the SPX2_OPTIONS structure to SPX_SF_IPX_CHECKSUM.

If the implementation of SPX-II at both endpoints support IPX checksum and if both the host and client applications have requested IPX checksum, then SPX-II will checksum every packet after the session is in data transfer state. Once both endpoints agree that IPX checksum will be used a packet with 0xFFFF in Checksum must still be accepted. This allows for a retransmitted Session Setup packet or for a delayed Session Setup ACK.

Index

Abort	i, 22-24, 27

ACK	i, ii, 6-19, 22-24, 26, 27, 30, 31, 39

Acknowledge Number	3, 7-15, 18, 26, 28

Allocation Number	3, 7-15, 18, 27, 28

Backward Compatibility	1, 19, 22

Checksum	ii-4, 9-15, 20, 33, 36, 39

Congestion	i, 27, 30

Connection Ack	7, 10, 16, 17, 19, 24

Connection Control	3, 6, 8-18, 20, 26

Connection ID	3, 6, 7, 9-15, 25, 35

Connection ID Numbers	7, 25

Connection Management	7, 10, 16

Connection Request	1, 3-7, 10, 16-19, 24, 37

Data Transfer State	17, 24, 39

Datastream Type	ii, 3, 6, 9-15

Default	16-18, 22, 23, 27, 34, 35, 37, 39

Destination Connection ID	6

Destination Network	3, 4

Destination Node	3, 4

Destination Socket	3, 5

Disconnect	i, ii, 6, 10, 14, 22, 29, 37

Extended ID	20, 21

Extended Size	20, 21

Header Definition	3, 9-15

Informed Disconnect	i, ii, 6, 10, 14, 22, 29

Large Packets	2

Length	3, 4, 7, 9-17, 20, 21

Local Endpoint	35

Maximum	2, 4, 16-18, 21, 25, 28, 34, 35, 37, 38

Minimum	4, 11, 12, 16-18, 21, 34, 35, 37

NAK	ii, 8, 9, 17, 18, 22, 26, 30

Negative Acknowledge	26

Negotiate Size Request	6

Negotiation	i-4, 7-9, 11-18, 20, 21, 24, 33, 37, 39

Option Management	ii, 34

Orderly Release	i, ii, 6, 10, 15, 22, 23

Packet Definition	ii, 16-19, 22, 23

Packet Type	ii-4, 7, 9-15

Remote Endpoint	34

Retry	i, ii, 8, 17, 18, 20, 22, 24, 27, 28, 31, 34, 35, 37

Round Trip Time	26, 27, 31, 35

Sequence Number	3, 7-15, 17, 18, 26-28

Session Setup	i, ii, 7, 10, 12, 13, 16-20, 24, 35, 39

Session Termination	i, 22

Session Watchdog	24

Source Connection ID	3, 6, 9-15

Source Network	3, 5

Source Node	3-5

Source Socket	3, 5

Timeout	i, ii, 8, 16-20, 23, 24, 27, 28, 31, 34, 35, 37

TLI	ii, 1, 2, 6, 34, 39

Transport Control	3, 4, 9-15

Unilateral Abort	i, 22-24, 27

Watchdog	ii, 7, 17, 22-24, 26-28, 34, 35, 37

Window	ii, 1, 2, 8, 10, 22-24, 27-30, 34, 35, 37