Document revision date: 19 July 1999
[Compaq] [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]
[OpenVMS documentation]

OpenVMS I/O User's Reference Manual


Previous Contents Index

9.12.2 FDDI Frames

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)


9.12.4 ATM ELAN Frames (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


9.12.5 802.2/802.1 Headers

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


9.12.6 Token Ring Source Routing Header (Alpha Only)

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


9.14 Features of Packet Formats

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:

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

9.14.1.3 Protocol Type Sharing

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:

9.14.2 IEEE 802 Packet Format

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:

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:

9.15 LAN Device Information

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.


Previous Next Contents Index

  [Go to the documentation home page] [How to order documentation] [Help on this site] [How to contact us]  
  privacy and legal statement  
6136PRO_031.HTML