HP OpenVMS Systems Documentation

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

9.14.1.1 Ethernet Protocol Types

Every Ethernet frame has a 2-byte protocol-type field. This field isused to determine the port to which a packet belongs. Protocol typesare independent of addresses; unique protocol designations can beassigned by Xerox Corporation. Whenever an Ethernet user at aparticular station starts an Ethernet port, that user must specify theprotocol type to be used on that port. Messages sent over that portalways have the protocol type attached to them by the device driver,and messages received with that protocol type are delivered to thestarter of that port. Valid protocol types are in the range 05-DDthrough FF-FF.

Following are the cross-company protocol types:

Some commonly used protocol types are as follows:

This section describes the PAD parameter NMA$C_PCLI_PAD, which is usedonly in the Ethernet packet format.

All CSMA/CD frames must be at least 64 bytes in length. This includesthe Ethernet header, the user data, and the CRC. If the user data, CRC,and Ethernet header together are less than 64 bytes, zero padding bytesare inserted between the user data and the CRC to make a 64-bytepacket. This packet padding cannot be turned off.

The PAD parameter directs the LAN drivers to place a data-size field inthe packet between the standard header and the user data. If padding ison (NMA$C_STATE_ON is specified) , a 2-byte length field is insertedafter the Protocol Type field and before the user data.

If the PAD parameter is off (NMA$C_STATE_OFF is specified), Ethernetpackets have the following characteristics:

• Packets transmitted are padded with null bytes as needed (CSMA/CD only).
• Packets transmitted do not include the size field.
• The length of user data in the packets received is always between 46 and 1500 bytes for CSMA/CD, and 0 to 4470 for FDDI. For example, if a 10-byte packet is transmitted, it is received as 46 bytes because the driver cannot determine the amount of user data in the packet---only the amount of user data plus padded null bytes.

If the PAD parameter is on (NMA$C_STATE_ON is specified), Ethernetpackets have the following characteristics:

• Packets transmitted are padded with null bytes as needed (CSMA/CD only).
• Packets transmitted include the size field.
• The length of user data in the packets received is always between 0 and 1498 bytes for CSMA/CD, and 0 to 4468 bytes for FDDI. The driver uses the size field to determine the amount of user data in the packet. The size field is not included in the data returned to the user.

Protocol types are usually nonshareable; however, an application maybenefit from a shared protocol implementation. The protocol accessparameter (NMA$C_PCLI_ACC) allows a protocol type to be opened ineither of two shareable modes: shared-default (NMA$C_ACC_SHR) andshared-with-destination (NMA$C_ACC_LIM). The LAN drivers also providethe nonshareable exclusive mode (NMA$C_ACC_EXC). (See Table 9-16.)The rules and requirements for using each mode are as follows:

• The exclusive mode is the default if no access mode is supplied as a P2 buffer parameter. This mode of operation does not allow the protocol to be shared by other users. Any attempt to start up another protocol of the same type results in an error status of SS$_BADPARAM.
• The shared-with-destination mode is a protocol type/destination address pairing that allows multiple users to share a protocol type and to communicate with a different node.
  For a given shared protocol type, there can be many "shared-with-destination" users; each user communicates with a different destination address. Any attempt to start a port with a destination address that is in use results in an error status of SS$_BADPARAM.
  When a "shared-with-destination" user passes the set mode P2 buffer, the buffer must contain a destination address in the NMA$C_PCLI_DES parameter. This destination address is used as the destination address in all messages transmitted, and the user receives messages only from this address.
• The shared-default mode is the default user of a shared protocol type. There can be only one such user for each shared protocol type. A "shared-default" user does not have to exist if a protocol type is shared, but there can be no more than one such user per shared protocol type.
  The "shared-default" user receives all messages for the shared protocol type, but not for any of the "shared-with-destination" users. The "shared-default" user also receives all messages matching both the shared protocol type and any multicast address enabled by the "shared-default" user.
  The "shared-default" user can only transmit to multicast addresses and physical addresses that are not enabled by any of the "shared-with-destination" users sharing the same protocol type.
  If there is no "shared-default" user of a protocol type, incoming messages from nodes not among the "shared-with-destination" users for that protocol type are ignored.

The IEEE 802 packet formats accepted for a port depend on the serviceenabled on that port. All 802 packet formats have an 802.2 header. Theservice 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 bufferselects the service on that port. A value of NMA$C_LINSR_CLI specifiesClass I service and a value of NMA$C_LINSR_USR specifies user-suppliedservice (the default).

9.14.2.1 Class I Service Packet Format

For Class I service, only three packet formats are transmitted andreceived: UI, XID, and TEST. Figure 9-16 shows the 802.2 headerformat for Class I service.

Figure 9-16 Class I Service 802.2 Header

The control field for an 802 packet is always an unnumbered controlfield. 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 thefollowing 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 will match 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 will match 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 allowedto receive UI commands and XID and TEST responses.

Refer to the IEEE 802.2 Standard for more information on these controlfield values and response messages.

9.14.2.2 User-Supplied Service Header Format

Figure 9-17 shows the 802.2 header format for user-supplied service.

Figure 9-17 User-Supplied Service 802.2 Header

The user provides the control field values, which are documented in theIEEE 802.2 Standard. The user-supplied packet format is the genericpacket format as specified in the IEEE 802.2 Standard. Class I packets(see Section 9.14.2.1) are a subset of this generic packet format.Therefore, if the control field value of the user-supplied packet isUI, XID, or TEST, the packet is the same as a Class I packet. Note thatClass II packets, as defined in the IEEE 802.2 Standard, include theUI, XID, and TEST command/response formats.

9.14.2.3 Service Access Point (SAP) Use and Restrictions

The IEEE 802.2 Standard places restrictions on both user SAPs andsource SAPs (SSAPs). All SAPs are 8 bits long. Figure 9-18 shows theformat of desination SAPs (DSAPs) and SSAPs.

Figure 9-18 DSAP and SSAP Format

Definition of the least significant bit depends on whether the SAP is asource SAP (SSAP) or a destination SAP (DSAP). For a DSAP field, theleast significant bit distinguishes group SAPs (bit 0 = 1) fromindividual SAPs (bit 0 = 0). For an SSAP field, the least significantbit distinguishes commands (bit 0 = 0) from responses (bit 0 = 1).Because these two bits are located at the same bit position within theSAP 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 thecommand/response bit set to 1, thus implying a response. The IEEE 802.2Standard reserves for its own definition all SAP addresses with thesecond least significant bit set to 1. You should use these SAP valuesfor 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 SAPsenabled on a controller do not have to be unique for each port; forexample, two 802 format ports can have the same group SAP enabled. Thisallows a single packet coming into the controller to be duplicated andpassed to each port on the controller that has the group SAPenabled---assuming the packet has a DSAP value that is a group SAP. Ifthe received packet has an individual SAP for a DSAP, the packet goesto at most one port.

9.14.3 IEEE 802 Extended Packet Format

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

Figure 9-19 802 Extended Header

For an 802E packet format, the DSAP and SSAP fields are always set tothe SNAP SAP (AA hex). The SNAP SAP value is a special SAP valuereserved for 802 extended format packets. The SNAP SAP valuedistinguishes an 802 packet from an 802 extended packet. The only validcontrol field value for 802 extended packets is UI (unnumberedinformation).

9.14.3.1 Protocol Type PID Sharing (Alpha Only)

On Alpha systems, the 802E format allows user's protocol identifier(PID) sharing. PIDs are usually nonshareable; however, an applicationmay benefit from a shared protocol implementation. The protocol accessparameter (NMA$C_PCLI_ACC) allows a PID to be opened in either of twoshareable modes: shared-default (NMA$C_ACC_SHR) andshared-with-destination (NMA$C_ACC_LIM). The LAN drivers also providethe nonshareable exclusive mode (NMA$C_ACC_EXC). (See Table 9-16.)The rules and requirements for using each mode are as follows:

• The exclusive mode is the default if no access mode is supplied as a P2 buffer parameter. This mode of operation does not allow the protocol to be shared by other users. Any attempt to start up another protocol of the same type results in an error status of SS$_BADPARAM.
• The shared-with-destination mode is a PID/destination address pairing that allows multiple users to share a PID and to communicate with a different node.
  For a given shared protocol type, there can be many "shared-with-destination" users; each user communicates with a different destination address. Any attempt to start a port with a destination address that is in use results in an error status of SS$_BADPARAM.
  When a "shared-with-destination" user passes the set mode P2 buffer, the buffer must contain a destination address in the NMA$C_PCLI_DES parameter. This destination address is used as the destination address in all messages transmitted, and the user receives messages only from this address.
• The shared-default mode is the default user of a shared PID. There can be only one such user for each shared PID. A "shared-default" user does not have to exist if a PID is shared, but there can be no more than one such user per shared PID.
  The "shared-default" user receives all messages for the shared PID, but not for any of the "shared-with-destination" users. The "shared-default" user also receives all messages matching both the shared PID and any multicast address enabled by the "shared-default" user.
  The "shared-default" user can only transmit to multicast addresses and physical addresses that are not enabled by any of the "shared-with-destination" users sharing the same PID.
  If there is no "shared-default" user of a PID, incoming messages from nodes not among the "shared-with-destination" users for that PID are ignored.

You can obtain information on controller characteristics by using theGet Device/Volume Information ($GETDVI) system service. (Refer to theOpenVMS System Services Reference Manual.)

$GETDVI returns controller characteristics when you specify the itemcode DVI$_DEVCHAR. Table 9-8 lists these characteristics, which aredefined by the $DEVDEF macro and in the file SYS$LIBRARY:DEVDEF.H.

DVI$_DEVTYPE and DVI$_DEVCLASS return the device type and device classnames, which are defined by the $DCDEF macro and in the fileSYS$LIBRARY:DCDEF.H. The device class name for the LAN Ethernetcontrollers listed in Section 9.2.1 and Section 9.2.2 is alwaysDC$_SCOM.

DVI$_DEVBUFSIZ returns the maximum message size. The maximum send orreceive message size depends on the packet format and whether padding(NMA$C_PCLI_PAD) is enabled (see Sections 9.16.1 and9.16.2). DVI$_DEVDEPEND returns the unit and line status bitsand the error summary bits in a longword field as shown inFigure 9-20.

Figure 9-20 DVI$_DEVDEPEND Returns

Table 9-9 lists the status values and their meanings. These valuesare defined by the $XMDEF macro. XM$M_STS_ACTIVE is set when the portis started. XM$M_STS_BUFFAIL and XM$M_STS_TIMO are dynamically set andcleared by the LAN driver.

The error summary bits are set when an error occurs. They are read-onlybits. If an error is fatal, the Ethernet port is shut down.Table 9-10 lists the error summary bit values and their meanings.

The LAN drivers can perform logical, virtual, and physical I/Ooperations. The basic functions are read, write, set mode, setcharacteristics, sense mode, and sense characteristics. Table 9-11lists these functions and their codes. The following sections describethese functions in greater detail.

Although the LAN device drivers do not differentiate among logical,virtual, and physical I/O functions (all are treated identically), youmust have the required privilege to issue the request. (Logical I/Ofunctions do not require I/O privilege.)