微软RNDIS协议书范本

Remote NDIS Specification
Rev 1.1
August 9, 2002
© 1998-2001 Microsoft Corporation. All rights reserved.
1INTRODUCTION (4)
1.1L ICENSE A GREEMENT (5)
2CONCEPTS AND DEFINITIONS (6)
2.1C ONTROL CHANNEL (6)
2.2D ATA CHANNEL (6)
2.3I NITIALIZATION AND T EARDOWN (6)
2.4D EVICE S TATE D EFINITIONS (6)
2.4.1Halt (7)
2.4.2Reset (7)
2.5F LOW C ONTROL (7)
2.6B YTE O RDERING (7)
2.7E NCAPSULATION (7)
2.8R EMOTE NDIS V ERSION (7)
2.9S TATUS V ALUES (8)
3MESSAGE SET FOR CONNECTIONLESS (802.3) DEVICES (9)
3.1REMOTE_NDIS_INITIALIZE_MSG (9)
3.1.1REMOTE_NDIS_INITIALIZE_MSG Format (10)
3.1.2Response to REMOTE_NDIS_INITIALIZE_MSG (10)
3.2REMOTE_NDIS_HALT_MSG (12)
3.3REMOTE_NDIS_QUERY_MSG (13)
3.3.1REMOTE_NDIS_QUERY_MSG Format (13)
3.3.2Response to REMOTE_NDIS_QUERY_MSG (14)
3.4REMOTE_NDIS_SET_MSG (14)
3.4.1REMOTE_NDIS_SET_MSG Format (15)
3.4.2Response to REMOTE_NDIS_SET_MSG (15)
3.4.3Setting Device-specific Parameters (16)
3.5REMOTE_NDIS_RESET_MSG (17)
3.5.1REMOTE_NDIS_RESET_MSG Format (17)
3.5.2Response to REMOTE_NDIS_RESET_MSG (17)
3.6REMOTE_NDIS_INDICATE_STATUS_MSG (18)
3.6.1REMOTE_NDIS_INDICATE_STATUS_MSG Format (19)
3.7REMOTE_NDIS_KEEPALIVE_MSG (19)
3.7.1REMOTE_NDIS_KEEPALIVE_MSG Format (20)
3.7.2Response to REMOTE_NDIS_KEEPALIVE_MSG (20)
3.8E XAMPLE C ONNECTIONLESS (802.3)I NITIALIZATION S EQUENCE (21)
3.9D ATA M ESSAGES (REMOTE_NDIS_PACKET_MSG) (22)
3.9.1REMOTE_NDIS_PACKET_MSG Format (22)
3.9.2Multi-Packet Transfers (24)
4REQUIRED NDIS OIDS (27)
4.1G ENERAL OID S (27)
4.2802.3OID S (29)
4.3O PTIONAL P OWER M ANAGEMENT OID S (30)
4.3.1Network Wake-Up (31)
5REMOTE NDIS TO USB MAPPING (32)
5.1R ELATED S PECIFICATIONS (32)
5.2O VERVIEW (32)
5.3P N P AND USB-LEVEL INITIALIZATION (32)
5.3.1USB Device Descriptor (32)
5.3.2USB Configuration Descriptor (33)
5.3.3Communication Class Interface (33)
5.3.4Data Class Interface (33)
5.4USB-LEVEL TERMINATION (34)
5.5C ONTROL CHANNEL CHARACTERISTICS (34)
5.6D ATA CHANNEL CHARACTERISTICS (35)
5.6.1USB Short Packets (35)
5.6.2Flow Control (36)
5.7P OWER MANAGEMENT (36)
5.8T IMER CONSTANTS (36)
1Introduction
Remote NDIS is a bus-independent class specification for Ethernet (802.3) network devices on dynamic PnP busses such as USB, 1394, BlueTooth, and InfiniBand. This specification defines a bus-independent message protocol between a host PC and a Remote NDIS device over abstract control and data channels. Also included are bus-mapping chapters which define specific features of the specification on the respective busses.
The “legacy-free” PC revolution is eliminating not only legacy connection ports (e.g. serial, parallel, PS/2) but also legacy expansion buses like ISA and PCI in mainstream PCs. The resulting “sealed case” PCs will require either built-in networking support on the motherboard or support for network adapters on external busses. This specification defines a message protocol for external bus attached network devices. It is precise enough to allow vendor-independent class driver support for Remote NDIS devices on the host PC. Remote NDIS is a fairly simple extension of the well-understood and time-tested NDIS architecture. NDIS defines a function-call interface for device-specific NDIS miniport drivers. This interface defines primitives to send and receive network data, and to query and set configuration parameters and statistics. Remote NDIS leverages NDIS by defining a message wrapping for the NDIS miniport interface, thus moving the NDIS-handling code from a miniport driver into the device itself. In this and other ways, the Remote NDIS specification allows for a wide range of device functionality and performance levels.
1.1License Agreement
The Remote NDIS Specification and any accompanying materials (the “Specification”) provided by Microsoft is for your personal use only, and may be used solely for the purpose of implementing the Remote NDIS protocol message set to interface with (i) a Microsoft Windows operating system or (ii) a bus or network-connected communications device, such as a USB, 1394 or TCP/IP device. THE SPECIFICATION MAY NOT BE COPIED OR DISTRIBUTED.
Microsoft may have copyrights, patents or pending patent applications covering subject matter in the Specification. To the extent Microsoft has such copyrights, patents or applications, Microsoft agrees to grant a nonexclusive, royalty-free, world-wide license under these copyrights, patents or applications solely to implement the Remote NDIS Specification to interface with (i) a Microsoft Windows operating system or (ii) a bus or network-connected communications device, such as a USB, 1394 or TCP/IP device, on condition that you agree not to assert any intellectual property rights against Microsoft or other companies for their implementation of the Specification. Microsoft reserves all other rights it may have in the Specification. The furnishing of this document does not give you any license to any other Microsoft patents, trademarks, copyrights, or other intellectual property rights. Specifically, neither this document nor the Specification give you any license to the NDIS Specification or to USB Communication Device Class technology.
The Specification is provided "AS IS" without warranty of any kind. To the maximum extent permitted by applicable law, Microsoft further disclaims all warranties, including without limitation any implied warranties of merchantability and fitness for a particular purpose, as well as warranties of title and noninfringement. The entire risk arising out of the use or performance of the Specification remains with you.
To the maximum extent permitted by applicable law, in no event shall Microsoft or its suppliers be liable for any consequential, incidental, direct, indirect, special, punitive, or other damages whatsoever (including, without limitation, damages for loss of business profits, business interruption, loss of business information, or other pecuniary loss) arising out of the use of or inability to use the Specification, even if Microsoft has been advised of the possibility of such damages. Because some states/jurisdictions do not allow the exclusion or limitation of liability for consequential or incidental damages, the above limitation may not apply to you.
2Concepts and Definitions
This section discusses requirements and characteristics of the channels used to communicate between the host and the remote device. Device state transitions and major operations such as initialization, halt and reset are also defined here.
2.1Control channel
The specifics of the control channel are given in the appropriate bus-mapping chapter. The control channel must be reliable and ensure sequenced delivery. It is used for all communication except for the transmission of network data packets. All required control messages except REMOTE_NDIS_HALT and REMOTE_NDIS_INDICATE_STATUS_MSG are request/response exchanges initiated by the host. The device must respond within the ControlTimeoutPeriod as specified in the appropriate bus-mapping chapter.
2.2Data channel
The specifics of the data channel are given in the appropriate bus-mapping chapter. The data channel is used exclusively for the transmission of network data packets. It may consist of multiple sub-channels (e.g. for varying quality of service) as defined in the appropriate bus-mapping chapter. The reliability and delivery specifics of the data channel are likewise defined in the respective bus-mapping chapter.
2.3Initialization and Teardown
The control and data channels are initialized as specified in the respective bus-mapping chapter. The host and Remote NDIS device then exchange initialization messages. The host sends
REMOTE_NDIS_INITIALIZE_MSG to the device, and the device provides information about its type, supported medium and version in the response message REMOTE_NDIS_INITIALIZE_CMPLT.
Either the host or the remote device can halt the network connection in an abortive fashion via the REMOTE_NDIS_HALT_MSG message. All outstanding requests and packets should be discarded on receipt of this message.
2.4Device State Definitions
Following bus-level initialization, the device is in the rndis-uninitialized state. Upon receiving REMOTE_NDIS_INITIALIZE_MSG and returning REMOTE_NDIS_INITIALIZE_CMPLT with status success, the device enters the rndis-initialized state.
Upon receiving REMOTE_NDIS_SET_MSG for the OID_GEN_CURRENT_PACKET_FILTER parameter with a non-zero filter, the device enters the rndis-data-initialized state. When in the rndis-data-initialized state, receiving REMOTE_NDIS_SET_MSG for OID_GEN_CURRENT_PACKET_FILTER with a zero filter value forces the device back into the rndis-initialized state.
Receiving REMOTE_NDIS_HALT_MSG or a bus-level disconnect or hard-reset at any time forces the device into the rndis-uninitialized state.
2.4.1Halt
At any time that the device is in the rndis-initialized or rndis-data-initialized state, the host computer may terminate the Remote NDIS functionality of the device in an abortive fashion by sending
REMOTE_NDIS_HALT_MSG to the device.
2.4.2Reset
The communication channel is “soft-reset” when an error such as message tim eout occurs. The host may initiate a soft-reset at any time when the device is in the rndis_initialized state by sending
REMOTE_NDIS_RESET_MSG to the device (see details below); and the device must send a response message when it has completed the reset. For example, the host may initiate a soft-reset when an error, such as a message timeout has occurred.
Note that this is a soft reset in the sense that any handles (e.g. VCs for connection-oriented devices) continue to be valid after the reset. The Remote NDIS device, as part of the reset process, discards all outstanding requests and packets. The remote device may reset some of its hardware components, but keeps all communication channels to the host intact.
2.4.2.1Hard Reset
If the Remote NDIS device performs a hard reset (i.e. reboot), this event is assumed to be equivalent of “Remove” followed by “Add” plug-and-play events. The host NDIS mini-port will be halted and removed, and a new instance will be added and started. All bus-level and Remote NDIS initialization will be re-executed. A Remote NDIS device may hard-reset itself in the event of a critical device failure.
2.5Flow Control
The Remote NDIS device may need to exercise flow control to prevent the host from overflowing its data buffers with packets. Any flow control provisions or requirements are given in the respective bus-mapping chapter.
2.6Byte Ordering
All numeric values in message fields defined by this specification are assumed to be coded in little-endian format, i.e. least significant byte first.
2.7Encapsulation
This section does not specify the way NDIS messages are encapsulated in native bus messages or primitives. Please refer to the appropriate bus-mapping chapter for more details.
2.8Remote NDIS Version
Table 2-1 defines the Remote NDIS protocol version identifiers exchanged between host and device.
Note that these are unrelated to the revision number of this specification.
Table 2-1: Remote NDIS Protocol Version
2.9Status Values
The Remote NDIS status values are generally equivalent to the 32-bit status values defined in the Windows 2000 DDK. Specifically, high bit set indicates an error state and the high bit clear indicates a success state. The specific Remote NDIS status values used in this specification are listed below, others can be inferred from the Windows 2000 DDK or MSDN. A device may return any semantically correct Remote NDIS status value in a Status field of a message that it generates.
Table 2-2: Remote NDIS Status Values
3Message Set for Connectionless (802.3) Devices The following Remote NDIS control messages that must be supported by an 802.3 connectionless device, see
Table 3-1 for an overview. In the more detailed descriptions below, some messages include a RequestId field. This is used to match sent messages with responses. With this mechanism, a host driver can send multiple Remote NDIS messages to a device without concern for the ordering of responses. A Remote NDIS device must maintain the RequestId field when returning a response.
Table 3-1: Control Messages Set
3.1REMOTE_NDIS_INITIALIZE_MSG
This message is sent by the host to a Remote NDIS device to initialize the network connection. It is sent via the control channel and only when the device is in the rndis-uninitialized state. See
Table 3-2 for details of the message.
The MaxTransferSize indicates the maximum size, in bytes, of any single bus data transfer that the host expects to receive from the device. Typically, each bus data transfer accommodates a single Remote NDIS message. However, as described below (see
Multi-Packet Transfers), the device may bundle several Remote NDIS messages containing Data packets into a single transfer.
MajorVersion and MinorVersion indicate the highest Remote NDIS protocol version implemented by the host. There is no guarantee that the host supports any lower versions; specifics of Remote NDIS version(s) supported by various Windows operating system versions will be documented in appropriate product documentation, e.g. the DDK. See
Table 2-1 for more details.
3.1.1REMOTE_NDIS_INITIALIZE_MSG Format
Table 3-2: REMOTE_NDIS_INITIALIZE_MSG
3.1.2Response to REMOTE_NDIS_INITIALIZE_MSG
The device should report its medium type, Remote NDIS version numbers, and its type (connection-less or connection-oriented) in its response to REMOTE_NDIS_INITIALIZE_MSG.
The Status field should be set to RNDIS_STATUS_SUCCESS if the device initialized successfully; otherwise it is set to an error code indicating the failure.
The device should return the highest Remote NDIS protocol version that it can support, in MajorVersion and MinorVersion– the combined version number should be less than or equal to the version number specified by the host in the REMOTE_NDIS_INITIALIZE_MSG message. This allows for the device to fall back to a compatibility mode when the host implements a Remote NDIS protocol version that is lower than that supported by the device.
The DeviceFlags field specifies the device type. MaxPacketsPerTransfer is the maximum number of REMOTE_NDIS_PACKET_MSGs that the device can handle in a single transfer to it - this should be at least 1. MaxTransferSize is the maximum size, in bytes, of a single data transfer that the device expects to receive from the host. The device can specify the byte alignment it expects for each Remote NDIS message that is part of a multi-message transfer to it –PacketAlignmentFactor contains this value as an exponent of 2. For example, this is set to 3 to indicate 8-byte alignment.
NOTE: The AFListSize and AFListOffset fields are only relevant for connection-oriented devices that include a call manager. Connectionless devices should set these fields to 0.
Table 3-3: REMOTE_NDIS_INITIALIZE_CMPLT
3.2REMOTE_NDIS_HALT_MSG
This message is sent by the host in order to terminate the network connection. Unlike the other host initiated control messages, there is no device response to REMOTE_NDIS_HALT_MSG. The message may be sent at any time that the device is in the rndis-initialized or rndis-data-initialized state.
Table 3-4: REMOTE_NDIS_HALT_MSG Message
It is optional for the device to implement sending the REMOTE_NDIS_HALT_MSG. If implemented, the device sends this message to the host via the control channel only when the device is in the rndis-initialized or rndis-data-initialized state. The device must terminate all communication immediately after sending this message. Sending this message causes the device to enter the rndis-uninitialized state.
3.3REMOTE_NDIS_QUERY_MSG
REMOTE_NDIS_QUERY_MSG is sent to a Remote NDIS device from a host when it needs to query the device for its characteristics or statistics information or status. The parameter or statistics being queried for is identified by means of an Object Identifier (OID). The host may send REMOTE_NDIS_QUERY_MSG to the device via the control channel at any time that the device is in the rndis-initialized or rndis-data-initialized state. A Remote NDIS device will respond to REMOTE_NDIS_QUERY_MSG with information about the desired capabilities or status.
3.3.1REMOTE_NDIS_QUERY_MSG Format
Table 3-5: REMOTE_NDIS_QUERY_MSG Message
3.3.2Response to REMOTE_NDIS_QUERY_MSG
The device sends REMOTE_NDIS_QUERY_CMPLT to the host in response to
REMOTE_NDIS_QUERY_MSG. This message is used to relay the result of a query for a device parameter or statistics counter to the host.
Table 3-6: REMOTE_NDIS_QUERY_CMPLT
3.4REMOTE_NDIS_SET_MSG
REMOTE_NDIS_SET_MSG is sent to a Remote NDIS device from a host, when it needs to set the value of some operational parameter on the device. The specific parameter being set is identified by means of an Object Identifier (OID), and the value it is to be set to is contained in an information buffer sent along with the message. (For a complete list of required and optional OIDs, please refer to Section 1.) The host may send REMOTE_NDIS_SET_MSG to the device via the control channel at any time that the device is in the rndis-initialized or rndis-data-initialized state. A Remote NDIS device will respond to a
REMOTE_NDIS_SET_MSG message with a status.
3.4.1REMOTE_NDIS_SET_MSG Format
Table 3-7: REMOTE_NDIS_SET_MSG Message
3.4.2Response to REMOTE_NDIS_SET_MSG
The device sends the REMOTE_NDIS_SET_CMPLT message to the host in response to
REMOTE_NDIS_SET_MSG. This message is used to relay the result of setting the value of a device operational parameter to the host.
Table 3-8: REMOTE_NDIS_SET_CMPLT
3.4.3Setting Device-specific Parameters
It is expected that most Remote NDIS devices will function well without the need to configure parameters on the host. However, there may be cases where proper network operation requires some configuration on the host. If the device supports configurable parameters, then it should include the following optional OID in the list of supported OIDs it reports in response to a query for OID_GEN_SUPPORTED_LIST:
OID_GEN_RNDIS_CONFIG_PARAMETER (0x0001021B)
If the device supports this OID, the host uses it to set device-specific parameters, soon after the device enters the rndis_initialized state from rndis_uninitialized. The host will send zero or more
REMOTE_NDIS_SET_MSGs to the device, with OID_GEN_RNDIS_CONFIG_PARAMETER as the OID value to set. Each such REMOTE_NDIS_SET_MSG corresponds to one device-specific parameter that is configured on the host.
The InformationBuffer associated with each such REMOTE_NDIS_SET_MSG has the following format. Note that the Offset values are relative to the beginning of the information buffer.
Table 3-9: InformationBuffer for OID_GEN_RNDIS_CONFIG_PARAMETER
The device sends a REMOTE_NDIS_SET_CMPLT in response to each REMOTE_NDIS_SET_MSG, after applying the parameter value. If the parameter setting is acceptable, it returns a status of
RNDIS_STATUS_SUCCESS in the response. If the parameter setting is not acceptable, and the device cannot apply a useful default value for this parameter, then the device returns an appropriate error status value (see
Table 2-2). If an error status is returned, then the host will initiate a Halt process (see Section 3) for the device.
Device-specific parameters are expected to be configured in the Windows registry. The keys that define parameter values are typically created in the registry during the process of device installation; the list of keys, type information, default values and optional range of valid values are specified in the INF file for the device. For more information on using an INF to set up configuration parameters in the registry for network devices, please consult the Windows 2000 DDK.
3.5REMOTE_NDIS_RESET_MSG
A REMOTE_NDIS_RESET_MSG message is sent to a Remote NDIS device from a host via the control channel to soft-reset the device and return status. This message may be sent at any time that the device is in the rndis-initialized or rndis-data-initialized state. A Remote NDIS device will respond to a
REMOTE_NDIS_RESET_MSG message with a status.
3.5.1REMOTE_NDIS_RESET_MSG Format
Table 3-10: REMOTE_NDIS_RESET_MSG Message
3.5.2Response to REMOTE_NDIS_RESET_MSG
When the device receives REMOTE_NDIS_RESET_MSG, it performs a soft-reset and then sends REMOTE_NDIS_RESET_CMPLT to the host with the result status.
Table 3-11: REMOTE_NDIS_RESET_CMPLT
3.6REMOTE_NDIS_INDICATE_STATUS_MSG
The device may send REMOTE_NDIS_INDICATE_STATUS_MSG to the host via the control channel in an unsolicited fashion at any time that the device is in the rndis-initialized or rndis-data-initialized state. This message is used to indicate a change in the status of the device.
REMOTE_NDIS_INDICATE_STATUS_MSG can also be used to indicate an error event, such as an unrecognized message.
The most common use of REMOTE_NDIS_INDICATE_STATUS_MSG is to indicate the state of link for an 802.3 device. Status=RNDIS_STATUS_MEDIA_CONNECT indicates a transition from disconnected (e.g. no 802.3 link pulse) to connected state (802.3 link pulse detected); Status=
RNDIS_STATUS_MEDIA_DISCONNECT indicates a transition from connected to disconnected state . The device must send REMOTE_NDIS_INDICATE_STATUS_MSG with one of these values every time that the 802.3 link state changes. No status buffer is required to return these two common indications.
In the specific case where this is sent in response to a message that the device could not handle, the Status field must be set to RNDIS_STATUS_INVALID_DATA, and the status buffer is formatted as described in Table 3-12.
If the error condition was caused by an Remote NDIS message, for example if the device didn’t understand a particular Remote NDIS message, then the device must append the original message at the end of the status message defined above. In this case, DiagStatus contains additional status about the error itself (e.g.
RNDIS_STATUS_NOT_SUPPORTED) and ErrorOffset is the 0-based byte offset within the offending message at which the error was detected.
Note that this message is used to report an error condition only in circumstances where the device is not able to generate a response message with appropriate status. Examples of appropriate usage are: (a) on receiving a message with unsupported message type (b) on receiving an REMOTE_NDIS_PACKET_MSG with unacceptable contents.
3.6.1REMOTE_NDIS_INDICATE_STATUS_MSG Format
Table 3-12: REMOTE_NDIS_INDICATE_STATUS_MSG Message
Table 3-13: Rndis_Diagnostic_Info
3.7REMOTE_NDIS_KEEPALIVE_MSG
The host sends REMOTE_NDIS_KEEPALIVE_MSG to the device via the control channel in order to check the health of the device. When the device is in the rndis-data-initialized state, the host sends this message periodically when there has been no other control or data traffic from the device to the host for the KeepAliveTimeoutPeriod. KeepAliveTimeoutPeriod is bus-dependent and is defined in the appropriate bus-mapping chapter.
Upon receiving this message, the remote device must send back a response whose Status field indicates whether the device solicits a REMOTE_NDIS_RESET_MSG message from the host.
The host will not send REMOTE_NDIS_KEEPALIVE_MSG until the KeepAliveTimeoutPeriod has elapsed since the last message received from the remote device. This avoids unnecessary exchange of REMOTE_NDIS_KEEPALIVE_MSG messages when the communication channel is active.
The device may optionally send this message to the host as well. For example, the device may use this message to trigger a response from the host for the purpose of computing round-trip delay time. If implemented, the device must send REMOTE_NDIS_KEEPALIVE_MSG via the control channel and only when in the rndis-initialized or rndis-data-initialized state.
NOTE: The device does not need to perform any specific action if it stops seeing
REMOTE_NDIS_KEEPALIVE_MSG messages from the host.
3.7.1REMOTE_NDIS_KEEPALIVE_MSG Format
Table 3-14: REMOTE_NDIS_KEEPALIVE_MSG Message
3.7.2Response to REMOTE_NDIS_KEEPALIVE_MSG
The device sends REMOTE_NDIS_KEEPALIVE_CMPLT to the host in response to a
REMOTE_NDIS_KEEPALIVE_MSG. If the returned Status is not RNDIS_STATUS_SUCCESS, then the host will send REMOTE_NDIS_RESET_MSG to reset the device.
Table 3-15: REMOTE_NDIS_KEEPALIVE_CMPLT
If the device implements the option of sending REMOTE_NDIS_KEEPALIVE_MSG, then the host will respond with REMOTE_NDIS_KEEPALIVE_CMPLT via the control channel.
3.8Example Connectionless (802.3) Initialization Sequence This section describes the general order of events that a device can expect upon startup as a Remote NDIS connectionless device. Because the basic operation of Remote NDIS is the same, regardless of the underlying bus, the require bus enumeration and start up process has been left out of the example.
Table 3-16: Generic Connectionless Remote NDIS Initialization Sequence
Note: real world operation will vary depending on version of Windows and NDIS.
3.9Data Messages (REMOTE_NDIS_PACKET_MSG)
A Remote NDIS device transfers NDIS packets, encapsulated as REMOTE_NDIS_PACKET_MSG across the data channel. REMOTE_NDIS_PACKET_MSG may contain out of band (OOB) data and/or per-packet information.
3.9.1REMOTE_NDIS_PACKET_MSG Format
Table 3-17: REMOTE_NDIS_PACKET_MSG
3.9.1.1Out-of-band data
Each REMOTE_NDIS_PACKET_MSG may contain one or more out-of-band data records. NumOOBDataElements indicates the number of out-of-band data records in this message. The out-of-band data records must appear in sequence. The OOBDataLength field indicates the byte length of the entire out-of-band data block. The OOBDataOffset field indicates the byte offset from the beginning of the DataOffset field to the beginning of the out-of-band data block. See the NDIS specification for more information about out-of-band packet data.
Table 3-18defines the format of a single out-of-band data record.
Table 3-18: Out of Band Data Record Format
Note: (N) is equal to the value of ClassInformationOffset
If there are multiple out-of-band data blocks attached to a REMOTE_NDIS_PACKET_MSG, then each subsequent out-of-band data record must immediately follow the previous out-of-band record’s data. There is no out of band information currently defined for 802.3 devices.
3.9.1.2Per-packet-info Data
Each REMOTE_NDIS_PACKET_MSG may contain one or more per-packet-info data records. Per-packet-info is used to convey packet meta-data such as TCP checksum. See the NDIS specification for more information about per-packet info data.
Table 3-19 defines the format of a per-packet-info data record.
Table 3-19: Per-Packet Info Data Record Format
NOTE: (N) is equal to the value of PerPacketInformationOffset
If there are multiple per-packet-info data blocks, then each subsequent per-packet-info data record must immediately follow the previous per-packet-info record’s data.
3.9.2Multi-Packet Transfers
Multiple REMOTE_NDIS_PACKET_MSG messages may be sent in a single transfer, in either direction. The maximum length of such a transfer is governed by the MaxTransferSize parameter passed in the REMOTE_NDIS_INITIALIZE_MSG and response messages. The host will also limit the number of REMOTE_NDIS_PACKET_MSGs it bundles into a single transfer to the value of the MaxPacketsPerTransfer parameter returned by the device in its response to
REMOTE_NDIS_INITIALIZE_MSG.
Concatenating multiple REMOTE_NDIS_PACKET_MSG elements forms a multi-packet message. Each individual REMOTE_NDIS_PACKET_MSG component is constructed as described above. The difference from the single-packet message case is that the MessageLength field in each
REMOTE_NDIS_PACKET_MSG header includes some additional padding bytes. These padding bytes are appended to all but the last REMOTE_NDIS_PACKET_MSG such that the succeeding
REMOTE_NDIS_PACKET_MSG starts at an appropriate byte boundary. For messages sent from the device to the host, this padding should result in each REMOTE_NDIS_PACKET_MSG starting at a byte offset that is a multiple of 8 bytes starting from the beginning of the multi-packet message. When the host sends a multi-packet message to the device, it will adhere to the PacketAlignmentFactor specified by the device.
Note that neither the combined length of a multi-packet message nor the number of
REMOTE_NDIS_PACKET_MSG elements in a combined message is given explicitly in any Remote NDIS –defined field. The combined length is implicit in the bus-specific transfer mechanism, and the host or device must walk the MessageLength fields of the combined message to determine the number of combined messages.
Table 3-20 contains an example of a multi-packet message that is made up of two
REMOTE_NDIS_PACKET_MSGs, sent from the host to the device. During the。