Chapter 2 - VINES Data Link Layer Protocols
Data link layer protocols support the movement of data between neighbors in the network. Nodes are neighbors when they share a physical medium. For example, all the nodes on an Ethernet LAN segment are neighbors. VINES protocols interconnect devices on a number of industry standard physical media, which use a variety of cabling, signaling, and framing technologies.
Data is moved across physical media in frames. Each frame begins with a MAC header that is specific to the data link protocol used to send and receive it. In some cases, the MAC header may be followed by an LLC header.
When VINES routes data between media that support different frame sizes, the VINES Fragmentation Protocol (FRP) must fragment the data to transmit it on the medium that supports the smaller maximum frame size. The FRP information appears in its own header that directly follows the MAC header.
Figure 2-1 shows a simplified diagram of the data link and FRP headers in relation to the rest of the VINES frame.
The VINES architecture defines two independent uses for data link layer services:
![]()
Transfer VINES IP packets ![]()
Echo diagnostic packets between neighbors
Internet and diagnostic packets can be treated as independent entities, unrelated to any other packet serviced.
Data Link Layer Protocol Entities
A data link layer protocol entity implements a specific data link layer protocol, supporting data movement to and from neighbors. In a typical network configuration, a data link layer protocol entity exists within each node for each physical communications medium to which the node is attached.
A data link layer protocol entity appears as an identifiable object to higher-level protocols, but is not necessarily mapped to one specific hardware or software element. The entity is defined as a finite-state machine. In some cases, a device driver running in the kernel performs data link layer protocol entity functions exclusively. In others, a device driver and the specific communications card work together to perform these functions.
The VINES architecture assumes that each data link layer protocol entity provides the following minimum services:
![]()
Frames can be sent to and received from neighbors. ![]()
Frames can be moved as atomic units of data. ![]()
Frames can be broadcast. (High-level Data Link Control (HDLC) protocol and Block Asynchronous protocol entities do not support broadcasting.)
Some types of data link layer protocol entities (for example, HDLC) provide a greater quality of service than others. They reduce the rate of bit errors for a particular transmission medium.
The VINES architecture also makes the following assumptions about the data link layer:
![]()
The data link layer does not provide guaranteed sequential delivery of error-free packets. ![]()
When the network layer sends a packet, the data link layer probably delivers it correctly to the appropriate entity without error. The network layer assumes that the data link layer protocol entity makes its best effort to deliver data. ![]()
If a data link layer protocol entity cannot guarantee that received packets are free of data bit errors, the entity notifies the network layer so that it can take appropriate action. For example, the entity includes a checksum in the data packet.
Resolving Differences in Physical Media
The VINES FRP helps data link layer protocol entities to provide minimum services. The data link layer protocol entity uses this protocol to break up and reassemble network layer data packets that are larger than the physical medium allows.
If the physical medium cannot support the maximum VINES IP packet size (1500 bytes), the data link layer protocol entity uses VINES FRP to break up and reassemble network layer packets. On these media, the FRP header is always included in the frame, even if the packet does not require fragmentation. For example, if a 50-byte VINES IP packet is transmitted on an HDLC LAPB line, the FRP header is included in the frame, even though the packet does not require fragmentation.
Frames that are transmitted on the following media always have an FRP header, even when no fragmentation is required:
![]()
ARCNET LANs ![]()
IBM PC Network LANs ![]()
OmninetTM LANs ![]()
HDLC LAPB lines ![]()
Block asynchronous lines ![]()
X.25 lines
When network architectures other than VINES are implemented on a VINES node, these architectures can transmit data to neighbors using data link layer protocol entities. For example, on the server, TCP/IP, IPX/SPX, and AppleTalk use Ethernet entities in addition to VINES.
The IEEE 802.2 LLC protocol defines the link control and information transfer procedures that two nodes on a LAN must follow when communicating with each other. This protocol exists in the OSI model as the top sublayer in the VINES data link layer. It supports the IEEE medium access methods, such as IEEE 802.5, which occupy the bottom sublayer.
Note: As of VINES 5.5, VINES supports the LLC protocol on Token-Ring LANs only. Banyan's AppleTalk Phase 2, IPX/SPX, and Remote Program Load (RPL) implementations support the LLC protocol on both Ethernet LANs and Token-Ring LANs.
The IEEE 802.2 LLC protocol provides two types of services:
Data Link Connectionless Service (Type 1) - A simple service, providing minimal recovery and sequencing. This service type is useful when higher layers perform error recovery and sequencing functions. Banyan provides this service for VINES, TCP/IP, AppleTalk, IPX/SPX, and RPL communication.
Data Link Connection Oriented Service (Type 2) - A complex service, providing comprehensive support for sequenced delivery of data and error recovery. Banyan's own native 3270/SNA service provides Type 2 support for SNA communication over Token-Ring LANs.
IEEE 802.2 LLC Protocol Specification
Token-Ring frames that contain VINES, TCP/IP, AppleTalk, IPX/SPX, or RPL packets always include a 3-byte LLC Type 1 Unnumbered Information (UI) frame. For SNA packets, Banyan supports I-format (information format) and S-format (supervisory format).
Ethernet frames that contain AppleTalk Phase 2 and RPL packets also include this header. IPX/SPX packets also include this header if the IPX/SPX Ethernet interface is configured for 802.2 or Ethernet SNAP (Subnetwork Access Protocol).
The LLC header is shown in Figure 2-2.
LLC Header Fields
This section provides summary descriptions of the fields in the LLC header. See the IEEE standards specification, IEEE Std. 802.2-1985 (ISO/DIS 8802/2), for detailed descriptions of these fields.
DSAP and SSAP Fields The Service Access Point (SAP) value that appears in both the Destination Service Access Point (DSAP) and Source Service Access Point (SSAP) fields of the LLC header is unique to the type of traffic (VINES, TCP/IP, AppleTalk, IPX/SPX, RPL, or SNA) contained within the frame. Table 2-1 shows the SAP values for frames containing VINES, TCP/IP, AppleTalk, IPX/SPX, RPL, and SNA traffic. 0
A SAP value of 0xAA indicates that the protocol identification appears in a SNAP header, which follows the LLC header. See the next section "SNAP Header Fields" for more information.
Control Field For SNA communication over Token-Ring LANs, Banyan provides Type 2 service. The LLC header in the Token-Ring frame contains a 2-byte control field in either an Information frame or a Supervisory frame. VINES, TCP/IP, AppleTalk, IPX/SPX, and RPL packets are in UI frames.
The SNAP header consists of a 3-byte Protocol Information Field (PIF), followed by a 2-byte packet type field.
PIF The PIF can contain one of the following identifiers:
![]()
A specific, non-zero protocol identifier. For example, 08 00 07 indicates the AppleTalk protocol family. ![]()
All 0s (zeroes), indicating the field should be ignored.
Packet Type Field The packet type field in the SNAP header contains a specific protocol identifier.
Table 2-2 shows the values for the protocol information and packet type fields for each protocol family.
IEEE 802.2 LLC Protocol Implementation Notes
All LLC functions are implemented by the LAN card driver. For example, the driver for a 3Com EtherLink® II card implements LLC functions for data that the card transmits and receives.
CSMA/CD Ethernet Access Method
The Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method defines how nodes share a bus transmission LAN such as Ethernet. As of VINES 5.5, VINES supports the implementation of CSMA/CD as defined in the specification, The Ethernet, also known as the "Ethernet Blue Book."
CSMA/CD Ethernet Protocol Specification
Figure 2-3 shows the format of the VINES Ethernet frame.
See The Ethernet for detailed information on all fields in the frame. Network layer headers are described in Chapter 3, Chapter 4, and Chapter 5. Transport layer headers are described in Chapter 6.
VINES Packet Type Field VINES uses the value in the packet type field to indicate that the frame originated from a VINES node and the type of VINES packet enclosed.
Other protocol families that Banyan supports also use this field. Table 2-3 shows type field values in hexadecimal.
VINES LAN diagnostic software on a node transmits echo packets to determine if the node can communicate on the LAN. See "VINES Echo Protocol" later in this chapter for detailed descriptions of VINES echo packets.
CSMA/CD Ethernet Protocol Implementation Notes
The Ethernet device driver is responsible for implementing the protocol. Firmware on the Ethernet card is responsible for handling electrical functions such as listening for the carrier signal.
VINES supports both Network Driver Interface Specification (NDIS) drivers and native drivers. For example, the NDIS standard allows VINES 5.5 and greater workstations to use both VINES and non-VINES protocols with the same Ethernet card.
VINES servers and ENS servers support native Ethernet drivers. ENS for UNIX servers support STREAMS-based Ethernet drivers.
The format of VINES Ethernet frames is always identical, regardless of the specific driver implementation.
IEEE 802.5 Token-Ring Access Method
The IEEE 802.5 Token-Ring access method defines how nodes transfer information on a Token-Ring transmission medium.
IEEE 802.5 Token-Ring Protocol Specification
Figure 2-4 shows the format of the Token-Ring frames transferred between VINES nodes.
See the IEEE standards specification, IEEE Std. 802.5-1985 (ISO/DIS 8802/5), for detailed information on all fields in the frame and for information on Token-Ring. See "IEEE 802.2 LLC Protocol Specification" earlier in this chapter for a description of the LLC header. Network layer headers are described in Chapter 3, Chapter 4, and Chapter 5. Transport layer headers are described in Chapter 6.
VINES Packet Type Field The value in the VINES packet type field indicates that the frame originated from a VINES node and the type of VINES packet enclosed. Table 2-4 shows packet type field values for Token-Ring frames originating from VINES nodes. All values are in hexadecimal.
See Chapter 3 for a description of VINES IP packets. See "VINES Echo Protocol" later in this chapter for a description of VINES echo packets.
IEEE 802.5 Protocol Implementation Notes
The Token-Ring device driver is responsible for implementing most protocol functions. Firmware on the Token-Ring card is responsible for handling the token and electrical functions and provides some LLC support.
The VINES Token-Ring driver can send and receive frames containing IBM source-level routing information.
VINES supports both Network Driver Interface Specification (NDIS) drivers and native drivers for Token-Ring cards. For example, the NDIS standard allows VINES workstations to use both VINES and non-VINES protocols with the same Token-Ring card.
VINES servers and ENS servers support native Token-Ring drivers. ENS for UNIX servers support STREAMS-based Token-Ring drivers.
The format of VINES Token-Ring frames is always identical, regardless of the specific driver implementation.
VINES provides drivers for several ARCNET LAN cards, including broadband VistaLANTM/PC. These drivers implement a data link layer protocol that supports information transfer between nodes on an ARCNET token-passing LAN.
Figure 2-5 shows the format of the VINES ARCNET frame.
The data link header in ARCNET frames that originate from VINES nodes have three fields that have VINES-specific characteristics, as follows.
Vendor ID Field ARCNET frames that originate from VINES nodes have a vendor ID of 0xf5, as assigned by Standard Microsystems Corporation (SMC®).
Packet Type Field ARCNET frames that originate from VINES nodes have a packet type of 0x01 for VINES IP packets and 0x02 for VINES echo packets.
VINES Data Field ARCNET frames that originate from VINES nodes have up to 502 bytes of VINES data.
See the appropriate ARCNET documentation for more information on ARCNET frames.
ARCNET Protocol Implementation Notes
Firmware in the specific ARCNET LAN card is responsible for handling the token-passing and timing functions. The driver is responsible for implementing other protocol functions. The VistaLAN/PC card performs channel management functions such as disabling the receive channel during the transmission of data. Whenever the card is reset, the driver helps the card determine the amount of time the receive channel needs to be disabled.
VINES provides a driver for the Corvus Omninet LAN card. This driver implements a data link layer protocol that supports information transfer between neighbors on an Omninet LAN. VINES IP performs a checksum operation on the network layer, transport layer, and application data in Omninet frames.
Omninet Protocol Specification
Figure 2-6 shows the format of the VINES Omninet frame.
Omninet frames that originate from VINES nodes have three fields that have VINES-specific characteristics, as follows.
Protocol ID Field Omninet frames that originate from VINES nodes have a protocol ID of 0x2aaf, as assigned by Corvus. The following reserved byte must have a value of 0.
Packet Type Field Omninet frames that originate from VINES nodes have a packet type of 0x01 for VINES IP packets and 0x02 for VINES echo packets.
VINES Data Field Omninet frames that originate from VINES nodes have up to 1010 bytes of VINES data.
See the appropriate Omninet documentation for more information on Omninet frames.
Omninet Protocol Implementation Notes
Firmware in the Omninet LAN card is responsible for handling electrical functions, such as Non-Return-to-Zero-Inverted (NRZI) functions, and some data link layer protocol functions, such as implementing the collision avoidance algorithm. The driver is responsible for most protocol functions.
VINES provides a driver for the IBM PC Network Adapter. This driver implements a data link layer protocol that supports information transfer between neighbors on a broadband IBM PC Network.
IBM PC Network Protocol Specification
Figure 2-7 shows the format of the VINES IBM PC Network frame.
IBM PC Network frames that originate from VINES nodes have two fields that have VINES-specific characteristics.
Packet Type Field IBM PC Network frames that originate from VINES nodes have a packet type of 0x01 for VINES IP packets and 0x02 for VINES echo packets.
VINES Data Field IBM PC Network frames that originate from VINES nodes have up to 498 bytes of VINES data.
See the appropriate IBM PC Network documentation for more information on IBM PC Network frames.
IBM PC Network Protocol Implementation Notes
Firmware in the IBM PC Network Adapter is responsible for collision detection, carrier detection, and channel access functions. The driver is responsible for all other protocol functions.
VINES provides a driver for the Proteon® ProNET-10 Adapter. This driver implements a data link layer protocol that supports information transfer between neighbors on a ProNET-10 token-passing LAN.
ProNET-10 Protocol Specification
Figure 2-8 shows the format of the VINES ProNET-10 frame.
ProNET-10 frames that originate from VINES nodes have two fields that have VINES-specific characteristics.
Packet Type Field ProNET-10 frames that originate from VINES nodes have a packet type of 0x11 for VINES IP packets, 0x10 for VINES echo packets, 0x0f for VINES diagnostic packets, 0x01 for TCP/IP packets, and 0x03 for TCP/IP Address Resolution Protocol (ARP) packets.
VINES Data Field ProNET-10 frames that originate from VINES nodes have up to 1484 bytes of VINES data.
See the appropriate Proteon ProNET-10 documentation for a detailed description of the ProNET-10 data link layer protocol format for frames.
ProNET-10 Protocol Implementation Notes
Firmware in the ProNET-10 Adapter is responsible for handling the token. The driver is responsible for processing all data in the frame except the EOM and BOM flags.
Link Access Procedure Balanced Protocol
LAPB is used by VINES as the data link layer protocol for bit-synchronous communications over point-to-point HDLC serial lines and X.25 virtual circuits. LAPB enhances the bit-error-rate characteristics of common serial communications lines.
Figure 2-9 shows the format of the VINES LAPB frame for point-to-point HDLC communications. See "X.25 Protocol" later in this chapter for more information on the format of VINES X.25 packets.
See the CCITT Recommendation X.25 for detailed information on all fields in the frame. See "VINES FRP" later in this chapter for information on the fragmentation header. Network layer headers are described in Chapter 3, Chapter 4, and Chapter 5. Transport layer headers are described in Chapter 6.
LAPB Protocol Implementation Notes
As stated in the CCITT Recommendation X.25, the LAPB protocol entities on both ends of the connection must be configured to play consistent roles (DCE or DTE) and to have a maximum data frame size already set.
The VINES LAPB implementation supports the Single-Link Procedure (SLP) for LAPB using basic mode sequence numbering (modulo 8).
VINES supports level 3 of the CCITT standard X.25 for packet switched server-to-server and PC-to-server communications over public and private data networks. VINES uses LAPB as the level 2 protocol for X.25 communications. See "Link Access Procedure Balanced Protocol" earlier in this chapter for more information on LAPB.
Figure 2-10 shows a VINES X.25 packet in a LAPB frame.
The fields in the X.25 packet header are numerous and complex. They are described in Appendix A.
X.25 Protocol Implementation Notes
The VINES X.25 implementation complies with the CCITT 1984 specification. See Appendix A for more information.
VINES supports the X.3, X.28, and X.29 standards for the following kinds of communications:
![]()
PC dial-in over X.25 public and private networks (also known as X.29 dial-in) ![]()
Asynchronous terminal emulation
X.3/X.28/X.29 Protocol Specification
Figure 2-11 shows the frame format for X.29 dial-in communications over X.25 and ISDN pubic and private networks.
Notice that VINES data is encapsulated within the X.25 packet. The PC dial-in software transmits a block asynchronous frame to a PAD or equivalent, which assembles the block asynchronous frame into an X.25 packet. The server receives the X.25 packet and disassembles it. When the server transmits data, it assembles a block asynchronous frame into an X.25 packet. See "VINES Block Asynchronous Protocol" later in this chapter for more information on the block asynchronous protocol.
For communications with host computers over X.25 public and private networks, the VINES Asynchronous Terminal Emulation (ATE) service passes asynchronous characters to software in the server that implements X.3, X.25, X.28, and X.29 protocols. This software assembles the characters into X.25 packets for transmission to the host. When the server receives X.25 packets from the host, this software disassembles the packets into asynchronous characters and passes them to the ATE service. See the Banyan Asynchronous Terminal Emulation Guide for more information.
X.3/X.28/X.29 Protocol Implementation Notes
When the PC dial-in software attempts to call a server, the protocol identifier in the call user data field of the call request packet appears as follows:
01 00 00 00
The server answers every call request packet, except those that request a collect call.
VINES Block Asynchronous Protocol
Block asynchronous protocol is used by VINES as the data link layer protocol for asynchronous server-to-server and PC-to-server full-duplex communications over point-to-point serial lines.
VINES Block Asynchronous Protocol Specification
Figure 2-12 shows the format of the VINES block asynchronous frame.
The fields in the VINES block asynchronous frame are as follows.
Data Link Escape This field is part of the field sequence that begins and ends each frame. Each frame begins with the DLE and STX fields and ends with the DLE and ETX fields. DLE is always 0x10.
Start Transmission This field is part of the field sequence that begins each frame. STX is always 0x02.
Frame Type This field indicates the type of data enclosed in the frame. Table 2-5 describes frame types, their meanings, and values.
VINES Data This field contains up to 152 bytes.
End Transmission This field is part of the field sequence that ends each frame. ETX is always 0x03.
Checksum This field contains a 16-bit checksum, which is used to check for errors in the frame type header, fragmentation header, and user data field. See "VINES Block Asynchronous Protocol Implementation Notes," which follows, for information on how the checksum is implemented.
VINES Block Asynchronous Protocol Implementation Notes
Each character in a block asynchronous frame is transmitted as an 8-bit byte with no parity, one start bit, and one stop bit, for a total of 10 bits per character.
When VINES IP packets are contained in block asynchronous frames, the packets can be fragmented. This fragmentation distributes the contents of one VINES IP packet across several frames. In this section, the term fragment refers to a frame that contains part of a VINES IP packet.
Although the VINES FRP is responsible for guaranteeing that fragments are received in the correct order, the block asynchronous protocol also plays a role in managing fragmentation. Other data link layer protocols are not as involved in handling fragmentation as the block asynchronous protocol.
Sequence Numbers
When two VINES nodes initialize a connection using the block asynchronous protocol, they must exchange reset frames to learn each other's initial sequence numbers. The initial sequence number is the sequence number of the first fragment of a VINES IP packet. Both nodes may have different initial sequence numbers. For example, one node may use 2 as the initial sequence number, and the other node may use 3. Once reset frames are exchanged, each node knows what initial sequence number to expect from the other.
Sequence numbers are in the fragmentation header. See "VINES FRP" later in this chapter for details.
Fragments are numbered in the order they are sent. For example, if one node uses 2 as the initial sequence number, the fragments that the node sends are numbered 2, 3, 4, and so on until the last fragment is sent. The receiving node expects the first fragment from the sending node to have a sequence number of 2. When a fragment arrives out of sequence, the receiving node sends a reject frame to the sending node. The sequence number of the last fragment that arrived in sequence is placed in the fragmentation header of the reject frame. Fragments can be out of sequence in three ways:
![]()
The number of the fragment that is out of sequence can be more than one greater than the number of the last fragment that arrived in sequence. ![]()
The number of the fragment that is out of sequence can be less than the number of the last fragment that arrived in sequence. This typically occurs following transmission of an acknowledgment frame. ![]()
The number of the fragment that is out of sequence is equal to the number of the last fragment that arrived in sequence.
Example Sequence Number Greater than It Should Be
A series of fragments can arrive with sequence numbers in the following order: 2, 3, 4, 5, and 7. In this case, the receiving node transmits a reject frame to the node that sent the missing fragment. The reject frame tells the sending node to transmit:
![]()
The fragment that was supposed to follow the last correctly sequenced fragment (for example, fragment with sequence number 5) ![]()
All the fragments after 5
Figure 2-13 illustrates this error.
Example Sequence Number Less than It Should Be
A series of fragments can arrive with sequence numbers in this order: 2, 3, 4, 5, 4. In this case, the receiving node transmits a reject frame that contains the sequence number of the last correctly sequenced fragment (for example, fragment with sequence number 5). The reject frame tells the sending node to transmit:
![]()
The next properly sequenced fragment (for example, fragment with sequence number 6) ![]()
All the fragments after 6
Figure 2-14 illustrates this error.
Example Current Sequence Number Equals Previous Sequence Number
A series of fragments can arrive with sequence numbers in this order: 2, 3, 4, 5, 5. In this case, the receiving node transmits a reject frame that contains the sequence number of the last correctly sequenced fragment (for example, fragment with sequence number 5). The reject frame tells the sending node to transmit:
![]()
The next properly sequenced fragment (for example, fragment with sequence number 6) ![]()
All the fragments after 6
Figure 2-15 illustrates this error.
Connection Timeouts
Block asynchronous line connections time out if one node does not receive anything from the other after a 2-minute time period. To guarantee that the line connection stays up, VINES nodes transmit alive frames if they have not sent anything for 35 seconds. See Table 2-5 for more information on these frames.
Checksum Method
The block asynchronous protocol uses the checksum to check for errors in the frame type header, fragmentation header, and VINES data portions of the frame only. Stuffed DLEs are not included in the checksum. The checksum is computed before DLE stuffing is performed.
To compute the checksum, the block asynchronous protocol entity adds an initial value of 1 to the binary value of the first character of the frame and to the one-relative position of the character. The one-relative position is 1. The entity then adds this sum to the binary value of the second character and to the one-relative position of the character, which is 2. In turn, the entity adds this sum to the third character's binary value and to its one-relative position, 3. This process continues for each character in the parts of the frame covered by the checksum.
The VINES block asynchronous checksum technique checks for empty frames, blocks of zeros, and zeros being added or lost.
The formula for computing checksums is as follows:
The length of the block asynchronous frame is indicated by n. The length does not include the DLE, STX, and ETX characters. The location of the byte in the frame is indicated by i. For example, i equals 1 for the first byte in the frame, 2 for the second byte, and so on. The value of the byte in the location specified by i is indicated by ai.
The block asynchronous protocol implements DLE stuffing. This is the process by which a value of 0x10 in any place other than the DLE field is followed by another value of 0x10. This process ensures that a value of 0x10 in any place other than the DLE field is not mistaken for a DLE. It also ensures that checksums that consist of a 0x10 0x02 byte sequence are not mistaken for the DLE STX sequence.
VINES supports two T1 implementations:
![]()
Fractional T1 communications using the ICAplus card. For a single FT1 connection to another server, this card supports up to six 64 Kbps DS0 circuits using the LAPB protocol. ![]()
Full and fractional T1 communications using the Link Access Procedure on the D-Channel (LAPD) protocol and SNAP. Currently, the Promptus T-1 Access ModuleTM provides this support.
The following sections describe the LAPD T1 implementation. See "Link Access Procedure Balanced Protocol" earlier in this chapter for more information on LAPB.
Figure 2-16 shows the format of the LAPD frame. See the CCITT Recommendation Q.921 for detailed information on all fields in the frame. Network layer headers are described in Chapter 3, Chapter 4, and Chapter 5. Transport layer headers are described in Chapter 6.
LAPD Protocol Implementation Notes
The T1 card is responsible for formatting the flag, address, control, and frame check sequence headers. The VINES T1 device driver is responsible for formatting the SNAP header and for passing the SNAP header and user data to the card.
The VINES T1 LAPD implementation supports the maximum VINES IP packet size. As a result, fragmentation does not occur on T1 LAPD server-to-server connections.
VINES supports server-to-server communications over ISDN B-Channels. Currently, the DATAVOICE SCii card provides this support.
Figure 2-17 shows the format of the VINES ISDN frame for B-Channel communication.
The frame headers are similar to, but not identical to, LAPB headers. Contact SCii for more information.
ISDN Protocol Implementation Notes
The ISDN card is responsible for formatting the data link headers. The VINES ISDN device driver is responsible for passing the user data to the card.
The VINES ISDN server-to-server implementation supports the maximum VINES IP packet size. As a result, fragmentation does not occur on ISDN server-to-server connections.
Because different physical media and data link protocols do not transmit data units of the same size, VINES FRP breaks up and reassembles network layer VINES IP packets. For example, when a VINES node must switch a VINES IP packet from an Ethernet LAN to an HDLC line, the FRP entity on the node must fragment the packet. This action is necessary because HDLC lines support smaller frame sizes than Ethernet LANs.
On the sending end, FRP converts packets into smaller units, or frames, that the physical medium or data link protocol can accept.
On the receiving end, FRP reassembles frames into VINES IP packets. FRP employs sequencing and control mechanisms that allow it to properly order fragments and to recognize fragments that begin and end a packet.
The FRP includes a 2-byte header with frames on Omninet, ARCNET, IBM PC Network, HDLC LAPB, and block asynchronous frames. The header is included regardless of whether the network layer packet within the frame is fragmented. Figure 2-18 shows the format of the FRP header.
The fields in the FRP header are as follows.
Sequence Number Field The FRP entity on the node that sends the frame
chooses the value for
the sequence number field. The sequence number allows the receiving
FRP entity to determine the correct order in which fragments
are received. The sequence number can be any value from 0 through
0xff. However, one restriction exists. If a sending FRP entity
fragments a network layer packet into more than one data frame,
the entity must consistently increase the sequence number field
of each succeeding frame by 1 (modulo 256).
Control Field The control field indicates whether the fragment begins or ends a VINES IP packet. If the packet is not fragmented, both bits 0 and 1 are set.
Figure 2-19 and Figure 2-20 show the control field and its bit fields for both the first fragment and the last fragment.
VINES FRP Implementation Notes
For each neighbor, the FRP entity maintains the following state table information:
![]()
The next sequence number to send to the neighbor ![]()
The last sequence number received from the neighbor
The FRP entity also maintains the current, partially assembled VINES IP packet received from the neighbor.
When an FRP entity receives a frame that contains a packet fragment, the FRP entity checks the FRP header to see if the frame begins, ends, or continues a VINES IP packet. If both bits 0 and 1 of the control field are set, the entire packet is contained in the frame (that is, no fragmentation has taken place).
The following sections describe the algorithms that the FRP entity performs for fragments that begin a packet and for fragments that follow the first fragment.
Processing the First Packet Fragment
When a node receives the first packet fragment from a neighbor, the FRP entity sets the last sequence number received to the sequence number in the FRP header, as shown in Figure 2-21.
Remember, an FRP entity maintains the last sequence number received as state information. Setting the last sequence number to the sequence number in the FRP header re-initializes the state whenever the FRP entity receives the first fragment.
When the FRP entity re-initializes the state, the entity discards any current, partially assembled VINES IP packet. The FRP entity saves the received fragment as the current, partially assembled VINES IP packet.
Processing Fragments that Follow the First Packet Fragment
For each fragment that follows the first packet fragment, the FRP entity checks whether a current, partially assembled VINES IP packet from the neighbor exists. If one does not exist, the entity discards the fragment. Otherwise, the FRP entity checks the sequence number and control fields in the FRP header, as follows:
Checking the Sequence Number - The FRP entity checks the sequence number in the frame against the last sequence number received from the neighbor. The entity concatenates the fragment to the rest of the VINES IP packet if the sequence number in the frame is equal to the last sequence number plus 1 (modulo 256). If this condition is met, the entity updates the value of the last sequence number received in the state table. Otherwise, the entity discards both the fragment and the current, partially assembled VINES IP packet.
Checking the Control Field - If the FRP entity accepts the received fragment, the entity checks the control field in the FRP header to determine if the fragment is the end of a VINES IP packet. If it is at the end of the packet, the FRP entity passes the assembled VINES IP packet to the target network layer protocol entity on the local node. Otherwise, the FRP entity waits for the next fragment to arrive.
VINES Echo Protocol
VINES Echo Protocol is used for diagnostic purposes on all LANs that VINES supports. This protocol does not make use of VINES IP and does not have its own header. Frames that are sent and received by VINES Echo Protocol entities typically consist of data link headers only.
VINES Echo Protocol Specification
Figure 2-22 shows a sample echo frame sent on an Ethernet LAN.
Type Field Notice that the type field has a value of 0xbaf, indicating the VINES Echo Protocol.
VINES Echo Protocol Implementation Notes
The LAN card driver is responsible for implementing VINES Echo Protocol functions, such as sending and receiving echo frames.