9.4 LAN I/O Architecture

The QIO API is implemented in the LAN common routines to interface between an application and the LAN port driver in user mode. The QIO subsystem passes I/O requests from the application to the LAN driver. The LAN driver performs the requested I/O and returns status and data to the application.

An application calls SYS$QIO with a function code, function modifiers, and addresses of buffers that provide any information needed, such as a buffer containing transmit data, transmit header data, a buffer to contain receive data and receive header data, and buffers for setmode and sensemode functions. This information is passed to the LAN driver via the P1-P6 QIO parameters.

The LAN common routines translate the I/O function in the QIO request to a transmit, receive, sensemode, setmode, or diagnose operation and passes the request on to the LAN port driver.

The LAN port driver does the transmit request, retrieves the receive packet, collects sensemode data, sets characteristics, or does the diagnose function, and passes the results back through the LAN common routines, back through the QIO subsystem, and back to the application.

QIO operations do buffered I/O. This, in addition to considerable validation of the QIO request, makes for a robust user mode interface, but less efficient from a performance standpoint than the VCI interface.

The VCI API is implemented in the LAN common routines to interface between the application and the LAN port driver in kernel mode at IPL 8. The VCI application calls VCI routines in kernel mode at IPL 8. The VCI routines are part of the LAN common routines. There are routines to initiate a port management request (to start, stop, and change a port) and to initiate a transmit request. The VCI application provides routines that the LAN common routines calls for transmit, receive, and port management completion.

An applications calls a VCI initiation routine with an I/O request that contains the transmit buffer or pointers to the transmit data, or the port management buffer data.

The LAN common routines process the transmit or port management request and passes the request on to the LAN port driver.

The LAN port driver does the transmit request, or sets characteristics, and passes the results back through the LAN common routines, and back to the VCI application by calling the application's completion routine. When a receive packet arrives, the LAN common routines passes the receive buffer to the VCI application by calling the application's receive completion routine. When the application has completed processing the receive data, it returns the receive buffer to the LAN common routines by calling a return receive buffer routine.

VCI operations do direct I/O, avoiding buffer copies in most cases. VCI applications are considered trusted applications, so must abide by the VCI specification to gain that trust and to ensure system integrity is maintained operating in kernel mode with privileges.

An Ethernet address can be a physical address of a single node or a multicast address, depending on the value of the low-order bit of the first byte of the address (this bit is transmitted first). Following are the two types of node addresses:

The OpenVMS interface to the LAN controllers allows you to set a physical address of the controller. The selection of the physical address of a LAN controller is different for Ethernet and FDDI.

For Ethernet, all users of the controller must agree on this address. The first user of the controller chooses the physical address; any additional users of the controller must specify either the same physical address, no physical address, or change the address (if allowed). When all channels to the controller are shut down, the next user to start a channel chooses the physical address. The controller's physical address is always chosen on the first successful startup when there are no active ports. If the address is not chosen at this time, the controller's hardware address is used as the physical address.

For Ethernet, the Can Change Address parameter allows the physical address to be changed even though there are active users. If all current users of the controller have set the NMA$C_PCLI_CCA parameter to NMA$C_STATE_ON, then the physical address can be changed.

For FDDI, each port using a controller may specify its own unique physical address. Any combination of sharing of physical addresses is also allowed across the ports of an FDDI controller. For example, ports A, B, and C may use one unique physical address and ports D and E may use another unique address.

The following shows the multicast addresses assigned for use in cross-company communications:.

The following lists the commonly used multicast addresses.

Except for the global broadcast address (FF-FF-FF-FF-FF-FF), Token Ring hardware does not support the 802 standard group LAN address mechanism. Instead, it uses functional addresses. Functional addresses are locally administered group addresses (multicast addresses). The first two bytes of the address are always 03-00 (canonical format), and the remaining four bytes contain a bit mask that specifies which of the 32 possible combination masks is being described.

Because most OpenVMS LAN applications use standard multicast addresses, a mechanism has been designed to map functional addresses to globally and locally administered multicast addresses. This allows applications to use the same multicast addresses that are used in the other LAN media.

Table 9-4 shows the default mapping used by the OpenVMS Alpha Token Ring drivers:

If an application needs to change or add mappings, QIOs exist for performing such operations. If the system or network manager has a requirement regarding mapping of the functional addresses, the LAN control program (LANCP) utility may be used to manage the mapping. The following example maps the multicast address AB-01-01-01-02-03 to functional address 03-00-00-01-00-00 on Token Ring device ICA0:.

$MCR LANCP

Note that it is possible for more than one multicast address to map to the same functional address. In all cases, the use of the functional address is associated with an individual application's protocol.

There are two headers for Ethernet frames:

Figure 9-2 illustrates an Ethernet frame with an Ethernet header.

Figure 9-2 Ethernet Frame with Ethernet Header

The Ethernet header consists of the DA, SA, and PTY fields. Ethernet frames must be at least 64 bytes in length, which means that the minimum data length is 46 bytes. Applications select Ethernet format by specifying NMA$C_LINFM_ETH (the default) as the value for NMA$C_PCLI_FMT in their P2 characteristics buffer. If the amount of actual data to be transmitted is less than 46 bytes, the Ethernet drivers transmit extra bytes of zero after the application data.

Figure 9-3 illustrates a Ethernet frame with an IEEE 802.3 header.

Figure 9-3 Ethernet Frame with IEEE 802.3 Header

The IEEE 802.3 format is similar to the Ethernet format, except the PTY field is replaced by the LEN field.

Figure 9-4 illustrates the format of FDDI frames.

Figure 9-4 FDDI Frame Format

The FDDI header consists of the FC, DA, and SA fields.

Figure 9-5 illustrates the format of Token Ring frames.

Figure 9-5 Token Ring Frame Format

Figure 9-6 illustrates the format of LAN emulation data frame format for the IEEE 802.3 and Ethernet Header.

Figure 9-6 LAN Emulation Data Frame Format with IEEE 802.3/Ethernet Header

The Ethernet format specifies a two-byte protocol type field followed by an optional length field. The length field is included in transmit packets and expected in receive packets with the PAD parameter is enabled. The following sections describe these features.

The IEEE 802 packet formats accepted for a port depend on the service enabled on that port. All 802 packet formats have an 802.2 header. The service on the port determines the valid values for the 802.2 fields.

When a port is started, the NMA$C_PCLI_SRV parameter in the P2 buffer selects the service on that port. A value of NMA$C_LINSR_CLI specifies Class I service and a value of NMA$C_LINSR_USR specifies er-supplied service (the default).

9.4.6.6.2 Class I Service Packet Format

For Class I service, only three packet formats are transmitted and received: UI, XID, and TEST. Figure 9-7 shows the 802.2 header format for Class I service.

Figure 9-7 Class I Service 802.2 Header

The control field for an 802 packet is always an unnumbered control field. The unnumbered control field, which is always 1 byte in length, is passed by the P4 argument of the write QIO and can be one of the following binary values:

• UI command (00000011)

  This is the unnumbered information command. It is the method used to transmit data from one user to another and is the most widely used control field value.

  The UI command can be specified by using NMA$C_CTLVL_UI.

• XID command (101p1111)

  This is the exchange identification command. It is used to convey information about the port. The “p” bit is the poll bit and can be either 0 or 1. This command can be specified by using NMA$C_CTLVL_XID for a “0” poll bit or NMA$C_CTLVL_XID_P for a “1” poll bit.

• XID response (101f1111)

  The XID response is a response to an XID command. The “f” bit is the final bit and matches the poll bit from the XID command.

• TEST command (111p0011)

  The TEST command is used to test a connection. The “p” bit is the poll bit and can be either 0 or 1. This command can be specified by using NMA$C_CTLVL_TEST for a “0” poll bit or NMA$C_CTLVL_TEST_P for a “1” poll bit.

• TEST response (111f0011)

  The TEST response is a response to a TEST command. The “f” bit is the final bit and matches the poll bit from the TEST command.

An 802 format port with Class I service is allowed to transmit UI, XID, and TEST commands. An 802 format port with Class I service is allowed to receive UI commands and XID and TEST responses.

For more information on these control field values and response messages, see the IEEE 802.2 Standard.

9.4.6.6.4 Service Access Point (SAP) Use and Restrictions

The IEEE 802.2 Standard places restrictions on both user SAPs and source SAPs (SSAPs). All SAPs are 8 bits long. Figure 9-8 shows the format of destination SAPs (DSAPs) and SSAPs.

Figure 9-8 DSAP and SSAP Format

Definition of the least significant bit depends on whether the SAP is a source SAP (SSAP) or a destination SAP (DSAP). For a DSAP field, the least significant bit distinguishes group SAPs (bit 0 = 1) from individual SAPs (bit 0 = 0). For an SSAP field, the least significant bit distinguishes commands (bit 0 = 0) from responses (bit 0 = 1). Because these two bits are located at the same bit position within the SAP field, a group SAP cannot be used as an SSAP. If this were allowed, a group SAP would be interpreted as an individual SAP with the command/response bit set to 1, thus implying a response. The IEEE 802.2 Standard reserves for its own definition all SAP addresses with the second least significant bit set to 1. You should use these SAP values for their intended purposes, as defined in the IEEE 802.2 Standard.

Up to four group SAPs can be enabled on each 802 port. The group SAPs enabled on a controller do not have to be unique for each port; for example, two 802 format ports can have the same group SAP enabled. This allows a single packet coming into the controller to be duplicated and passed to each port on the controller that has the group SAP enabled—assuming the packet has a DSAP value that is a group SAP. If the received packet has an individual SAP for a DSAP, the packet goes to, at most, one port.

The 802E format uses the 802.2 and 802.1 headers, as shown in Figure 9-9.

Figure 9-9 802 Extended Header

For an 802E packet format, the DSAP and SSAP fields are always set to the SNAP SAP (AA hex). The SNAP SAP value is a special SAP value reserved for 802 extended format packets. The SNAP SAP value distinguishes an 802 packet from an 802 extended packet. The only valid control field value for 802 extended packets is UI (unnumbered information).