Document revision date: 19 July 1999

Figure 9-6 illustrates the format of FDDI frames.

Figure 9-6 FDDI Frame Format

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

9.12.3 Token Ring Frames (Alpha Only)

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

Figure 9-7 Token Ring Frame Format (Alpha Only)

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

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

The 802.2 header follows the 802.3 header in a CSMA/CD frame and follows the FDDI header in an FDDI frame.

The 802.2 header is illustrated in Figure 9-9.

Figure 9-9 802.2 Header

This 802.2 header is followed by the 802.1 header illustrated in Figure 9-10 if the DSAP field is the SNAP SAP (AA hex), the SSAP field is the SNAP SAP, and the CTL field is UI (03 hex).

Figure 9-10 802.1 Header

The PID field consists of two subfields: the company portion of the PID and the implementation-specific portion of the PID (see Figure 9-11).

Figure 9-11 802.1 Header Subfields

Figure 9-12 details the field of the source routing header.

Figure 9-12 Source Routing Field (Alpha Only)

The routing control (RC) contains the information about how the packet is to be routed.

The Sn contains the segment identifier for the hop. Each segment identifier contains a ring number and bridge number used in the hop.

9.13 Format Parameter

Each port (or user) of a LAN controller either specifies a value for the format characteristic of the port or assumes the default. The format characteristic has three valid values: Ethernet, 802, and 802E. This section describes the actual frame formats for each medium for each format parameter value.

For a format parameter value of NMA$C_LIMFM_ETH (the default), the frame formats are shown in Figure 9-13. Note that a name given to the FDDI frame with the Ethernet format is a mapped Ethernet frame.

Figure 9-13 Frames with Ethernet Format

For a format parameter value of NMA$C_PCLI_802, the frame formats are shown in Figure 9-14.

Figure 9-14 Frames with 802 Format

For a format parameter value of NMA$C_PCLI_802E, the frame formats are shown in Figure 9-15.

Figure 9-15 Frames with 802E Format

The Ethernet controllers can transmit and receive both Ethernet and 802.2/802.3 packets. Each port on a controller is able to transmit and receive either Ethernet or 802 packets. Ethernet and 802 ports can be assigned on the same controller at the same time.

The FDDI controllers can transmit and receive FDDI frames. There is a mapped Ethernet frame format that is comparable to the Ethernet packets sent and received by the Ethernet controllers.

At the time each port on the controller is started, one of three packet formats can be specified: Ethernet (default), standard 802 (referred to as 802 packet format), and extended 802. If no format is specified, the default format is used.

Each port on the controller must be unique on that controller. For each packet format, there is a parameter that distinguishes the port from all other ports with the same packet format. For Ethernet packet format ports, the 2-byte protocol type parameter defines the port. For 802 packet format ports, the 1-byte SAP defines the port. For extended 802 format ports, the 5-byte protocol identifier defines the port.

Sections 9.14.1, 9.14.2, and 9.14.3 describe the three packet formats and the characteristics unique to each format.

9.14.1 Ethernet Packet Format

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.

9.14.1.1 Ethernet Protocol Types

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

Following are the cross-company protocol types:

Value	Meaning
08-00	IP protocol (ARPAnet)
08-06	Address resolution protocol (ARPAnet)
90-00	Ethernet Loopback protocol

Some commonly used protocol types are as follows:

Value	Meaning
60-01	DNA Dump/load (MOP)
60-02	DNA Remote Console (MOP)
60-03	DNA Routing
60-04	Local Area Transport (LAT)
60-05	Diagnostics
60-06	Customer use
60-07	System Communication Architecture (SCA)
80-38	Bridge
80-3C	DNA Naming Service
80-3D	CSMA/CD Encryption
80-3E	DNA Time Service
80-3F	LAN Traffic Monitor
80-40	NETBIOS Emulator (PCSG)
80-41	Local Area System Transport (LAST)

9.14.1.2 Ethernet Packet Padding

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

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

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

If the PAD parameter is off (NMA$C_STATE_OFF is specified), Ethernet packets 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), Ethernet packets 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 may benefit from a shared protocol implementation. The protocol access parameter (NMA$C_PCLI_ACC) allows a protocol type to be opened in either of two shareable modes: shared-default (NMA$C_ACC_SHR) and shared-with-destination (NMA$C_ACC_LIM). The LAN drivers also provide the 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 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 user-supplied service (the default).

9.14.2.1 Class I Service Packet Format

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

Figure 9-16 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 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 allowed to receive UI commands and XID and TEST responses.

See the IEEE 802.2 Standard for more information on these control field 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 the IEEE 802.2 Standard. The user-supplied packet format is the generic packet 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 is UI, XID, or TEST, the packet is the same as a Class I packet. Note that Class II packets, as defined in the IEEE 802.2 Standard, include the UI, 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 and source SAPs (SSAPs). All SAPs are 8 bits long. Figure 9-18 shows the format 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 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.

9.14.3 IEEE 802 Extended Packet Format

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

Figure 9-19 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).

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 application may benefit from a shared protocol implementation. The protocol access parameter (NMA$C_PCLI_ACC) allows a PID to be opened in either of two shareable modes: shared-default (NMA$C_ACC_SHR) and shared-with-destination (NMA$C_ACC_LIM). The LAN drivers also provide the 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 the Get Device/Volume Information ($GETDVI) system service. (See the OpenVMS System Services Reference Manual.) $GETDVI returns controller characteristics when you specify the item code DVI$_DEVCHAR. Table 9-8 lists these characteristics, which are defined by the $DEVDEF macro and in the file SYS$LIBRARY:DEVDEF.H.

Table 9-8 Ethernet Controller Device Characteristics

Characteristic	Meaning
Static Bits (Always Set)
DEV$M_AVL	Device is available
DEV$M_IDV	Input device
DEV$M_NET	Network device
DEV$M_ODV	Output device

DVI$_DEVTYPE and DVI$_DEVCLASS return the device type and device class names, which are defined by the $DCDEF macro and in the file SYS$LIBRARY:DCDEF.H. The device class name for the LAN Ethernet controllers listed in Section 9.2.1 and Section 9.2.2 is always DC$_SCOM.

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

Figure 9-20 DVI$_DEVDEPEND Returns

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

Table 9-9 Ethernet Controller Unit and Line Status

Status	Meaning
XM$M_STS_ACTIVE	Port is active.
XM$M_STS_BUFFAIL	Attempt to allocate a system receive buffer failed.
XM$M_STS_TIMO	Timeout occurred.

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

Table 9-10 Error Summary Bits

Error Summary Bit	Meaning
XM$M_ERR_FATAL	Hardware or software error occurred on controller.

	privacy and legal statement
6136PRO_031.HTML