Previous PageNext Page

Chapter 6 - VINES Transport Layer Protocols

Introduction

Transport Layer Services Provided

Unreliable datagram service
Reliable (acknowledged) message service
Data stream service

Unreliable Datagram Service

Reliable Message Service

Table 6-1. Differences Between Reliable Messages and Unreliable Datagrams

Data Stream Service

IPC and SPP

IPC provides support for the unreliable datagram service and the reliable message service.
SPP provides data stream service support.

VINES Transport Layer Addressing

The high-order 48 bits of the port address are equal to the VINES internet address of the node where the transport layer protocol entity resides.
The low-order 16 bits make up the local port number. The local port number identifies the specific port among the set of ports that the transport layer protocol entity supports.

Well-Known Port Numbers

Transient Port Numbers

VINES IPC

An unreliable datagram consists of a single data packet that is transferred from a single source port to one or more destination ports
A reliable message consists of a set of data packets (from one to four) that is transferred from one source port to one destination port

This connection handles all reliable messages that need to be transferred between transport layer ports on two different nodes.
This connection is not associated with any individual port or set of ports, but acts as a common resource for the IPC entities.

VINES IPC Specification

Figure 6-1. Short IPC Header

Figure 6-2. Long IPC Header

Table 6-2. IPC Packet Type Field Values

Table 6-3. IPC Control Byte Bit Settings

Example CIDs

In IPC error packets, this field indicates the sequence number field value of the data packet with which the error is associated.
In data, probe, and acknowledgment packets, this field indicates the sequence number value of the last packet that the receiving IPC entity accepted on the connection.

Table 6-4. Communication Error Codes in Error Packets

VINES IPC Implementation Notes

Connection in progress
Connected
Connection-idle
Disconnected

IPC Half-Connection Initialization Implementation

Calculate the total path metric
Initialize the half-connection

known cost + last hop cost + bias = total path metric

Known Cost - Either the metric from the network table or the metric from the neighbor table. If the destination is a neighbor, the metric from the neighbor table is used. Otherwise, the metric from the network table is used. See Chapter 4 and Chapter 5 for more information on these tables.

Last Hop Cost - The neighbor cost for routing packets from the last hop to a final destination client node node destination. If the destination client node is a neighbor, this value is 0 (zero), since the "known cost" in this case is all that is needed. If the destination client nodes are not neighbors, this value is the metric for the data link connecting the last router that forwards packets to the destination and the client node itself.

Bias - A floating factor used to adjust the total path metric based on congestion factors. This factor is especially useful for handling congestion on serial lines. Like other routing costs, bias values are in 200-millisecond intervals.

Learn the last hop cost.
Calculate the bias.

1. Sets the metric subfield in the VINES IP header of a packet to 1

2. Sends this packet to the destination client node

(known cost + last hop cost) / 2

The known cost changes.
The current bias is 4 times greater than the new known cost.

Figure 6-3. Half-Connection Initialization and Establishment Algorithm

Figure 6-4. Half-Connection Initialization and Acceptance Algorithm

Table 6-5. IPC Connection Record Fields


Initializes ccb_state to connection-in-progress or connected, depending on whether this node is initializing the connection or the remote node is initializing the connection.
Initializes ccb_nsseq, ccb_lrack, ccb_lrseq, and ccb_lsack to 0 (zero).
Sets the local CID field to the next assignable value not currently in use.
Sets the remote CID field to 0 (zero), indicating that it is currently unknown. The remote IPC entity must eventually supply the remote CID.
Sets ccb_tcount to 30 seconds plus the path metric (ccb_metric).
Sets the acknowledgment timer (ccb_acount) to 0 (zero).

Example Public Connections

Table 6-6. IPC Status Flags

IPC Send Implementation

Sets the local CID field to the local connection value (ccb_lid).
Sets the remote CID field to the remote connection value (ccb_rid). If the entity has not received a packet from the other node, the remote CID field is set to 0 (zero). Setting this field to 0 (zero) indicates that the local node does not know the CID that the remote node has assigned to the connection.
Initializes the local and destination port numbers in the long IPC header.
Sets the sequence number field to the value of the next sequence number to send (ccb_nsseq). The entity increments the next sequence number to send by one.
Sets the acknowledgment number field to the last received sequence number from the remote node (ccb_lrseq). See "IPC Acknowledgment Implementation" later in this chapter for more information.
Sets the length field to the total length of the message.
Sets the beginning-of-message and end-of-message subfields accordingly.
Initializes the VINES IP header. For reliable messages, the IPC entity always enables the error bit in the transport control field.

Figure 6-5. IPC Send Algorithm.

IPC Receive Implementation

The half-connection is in the connection in progress, connected, or connection-idle state.
The remote CID field in the received packet is not 0 (zero) and matches the local CID field (ccb_lid) in the connection record. Remember the sender uses the receiver's local CID as the remote CID.
The local CID field in the received packet matches the remote CID field in the connection record, and both fields are not 0 (zero). If the remote CID field in the connection record is 0 (zero) and the local CID field in the received packet is non-zero, the IPC entity assigns the value of the local CID field in the packet to the remote CID field in the connection record.

A half-connection is not found.
The remote CID in the IPC header of a received packet is 0 (zero).

Initializes the half-connection to the connected state
Sets the remote CID field (ccb_rid) to the local CID from the IPC header in the received packet

Places the half-connection in the connected state
Sets the remote CID (ccb_rid) in the record
Resets the half-connection to the connected state if the record indicates that the half-connection is in connection-idle state

Sets the relevant connection record variables.
Releases all data packets on the acknowledgment queue with sequence numbers lower than or equal to the acknowledgment number. See "IPC Acknowledgment Implementation" later in this chapter for more information.
Resets the idle receive timer (ccb_tcount) for the connection to 30 seconds plus the total path metric.
Sets the acknowledgment timer (ccb_acount) to 400 milliseconds.

Figure 6-6. IPC Data Packet Receive Algorithm

IPC Error Recovery Implementation

Values contained in the packet header do not modify variables in the connection record.
The acknowledgment queue remains intact.

Example Error Packets

IPC Sequencing Implementation

The next sequence number to send (ccb_nsseq)
The last sequence number received (ccb_lrseq)

1. The sending IPC entity copies the value of ccb_nsseq into the sequence number field of the long IPC header before sending the packet.

2. The sending IPC entity increments the value of ccb_nsseq by one.

3. The receiving IPC entity compares the sequence number in the IPC header to the value of ccb_lrseq.

4. The receiving IPC entity accepts the packet if the sequence number in the IPC header is one greater than the value of ccb_lrseq. The receiving IPC entity increments ccb_lrseq by one so that it equals the sequence number in the header.

If the values are equal, the packet is a duplicate of one previously received and dropped.

If the sequence number in the IPC header is less than the value of ccb_lrseq, the packet is dropped.

Sequence number is less than ccb_lrseq.
Sequence number equals ccb_lrseq.
Sequence number is greater than ccb_lrseq by more than one.

Sets the sequence number field in the probe packet header to the value of ccb_nsseq minus one
Sets the acknowledgment number field to the value of ccb_lrseq

Example Sequence Numbers and Probe Packets

Figure 6-7. Sequence Numbers and Probe Packet

IPC Acknowledgment Implementation

Example Implicit Acknowledgment

Figure 6-8. Implicit Acknowledgment

The acknowledgment timer expires.
The last acknowledgment number sent variable (ccb_lsack) is not equal to the last received sequence number variable (ccb_lrseq).

IPC Idle Connection Timeout Implementation

VINES SPP

Table 6-7. Differences Between SPP and IPC

VINES SPP Specification

Figure 6-9. SPP Header

The window field does not appear in the long IPC header.
SPP connections do not support the error packet type.
The 0x80 bit is set in these conditions:

- Data packets, when the connection is in single buffer mode.

- All acknowledgment packets, to indicate that the local SPP entity can send an immediate acknowledgment if the remote SPP entity requests it. See "SPP Pacing Implementation" later in this chapter for more information on single buffer mode.

VINES SPP Implementation Notes

Connection in progress
Connected
Disconnected

SPP Half-Connection Initialization Implementation

SPP connection record
SPP status flags

Table 6-8. SPP Connection Record Fields


Initializes ccb_nsseq, ccb_lrseq, ccb_lrack and ccb_lsack to 0 (zero).
Initializes the local CID to the next assignable value not currently in use and the remote CID to 0 (zero), indicating that the remote CID is currently unknown.
Initializes ccb_nswnd to 4 and ccb_lrwnd to 1. This means that the entity can only send one packet, and will allow the SPP entity on the other end of the connection to send up to four packets.

Because the SPP entity on the other end of the connection initializes these fields in the same way, each side only sends one packet initially, and then allows the SPP entity on the other end of the connection to send up to 4 packets.

Initializes the idle transmit timer (ccb_tidle) to 30 seconds and the idle receive timer for the connection (ccb_tcount) to 120 seconds plus the total path metric value (ccb_metric).
Initializes the acknowledgment timer (ccb_acount) to 0 (zero).

Table 6-9. SPP Status Flags

SPP Send Implementation

The SPP entity sets the window field to the value of ccb_nswnd.
The SPP entity does not initialize the length field.

SPP Receive Implementation

The half-connection is in the connection in progress state, the remote CID field in the received packet is not 0 (zero), and the remote CID field in the packet is the same as the local CID field (ccb_lid) in the connection record. Remember, the sending SPP entity places the value of the receiving entity's local CID (ccb_lid) in the remote CID field.
The half-connection is in the connected state, the remote CID field in the received packet matches the local CID field (ccb_lid), and the local CID field in the received packet matches the remote CID field in the connection record (ccb_rid).

If the remote CID field in the connection record is 0 (zero) and the local CID field in the received packet is non-zero, the SPP entity assigns the value of the local CID field in the packet to the remote CID field in the connection record (ccb_rid).

The remote CID field in the SPP header is non-zero.
The destination port does not exist.

Remote CID field in the SPP header is 0 (zero).
The destination port exists.

Places the half-connection in the connected state
Sets the remote CID (ccb_rid) in the connection record
Returns the pended connection establishment request to the application

Sets the relevant connection record fields
Releases all data packets on the acknowledgment queue with sequence numbers lower than or equal to the acknowledgment number
Resets the idle receive timer (ccb_tcount) to 30 seconds plus the total path metric
Sets the acknowledgment timer to 400 milliseconds

Figure 6-10. SPP Receive Algorithm

SPP Sequencing and Acknowledgment Implementations

SPP Pacing Implementation

Last Window Value Sent (ccb_lswnd) - The current window for the SPP entity on the other end of the connection. This field determines the number of packets that the SPP entity on the other end of the connection can send. It specifies the highest sequence number that the SPP entity on the other end of the connection can send.

Next Window Value to Send (ccb_nswnd) - This field is the next window for the SPP entity on the other end of the connection. When the window changes, this value will be sent to the SPP entity on the other end of the connection in the first SPP packet that is available to be sent.

Last Window Value Received (ccb_lrwnd) - The current window for this side of the connection. This field determines the number of packets that this side is allowed to send.

Figure 6-11. Sample SPP Pacing

Increases the window
Enters single buffer mode

window = ccb_lrseq + 4

Example Increasing the Window by 4

window = (ccb_lrseq - ccb_norpkt) + 4

Example Increasing the Window Using the Formula

window = (32 - 3) + 4
= 33

Send the same packet more than 7 times in a 10 second period
Receive more than 7 probe packets in a 10 second period

SPP Idle Connection Timeout Implementation

Previous PageTop Of PageNext Page