微软RNDIS协议书范本.docx

1、微软RNDIS协议书范本 Remote NDIS SpecificationRev 1.1August 9, 2002 1998-2001 Microsoft Corporation. All rights reserved.1 Introduction2 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 specific

2、ation 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

3、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 def

4、ines 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-c

5、all 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-h

6、andling 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.2.1 License Agreement2.2 The Remote NDIS Specification and any accompanying materials (the “Specification”) provide

7、d 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 SPE

8、CIFICATION 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 lic

9、ense 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

10、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, copyrig

11、hts, 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 a

12、pplicable 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 remai

13、ns 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 int

14、erruption, 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 conseq

15、uential or incidental damages, the above limitation may not apply to you.3 Concepts and Definitions4 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 initializatio

16、n, halt and reset are also defined here.4.1 Control channel4.2 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 packe

17、ts. 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.4.3 Data channel4.4 The specifics of the dat

18、a 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

19、 specifics of the data channel are likewise defined in the respective bus-mapping chapter.4.5 Initialization and Teardown4.6 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 ho

20、st 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_HA

21、LT_MSG message. All outstanding requests and packets should be discarded on receipt of this message.4.7 Device State Definitions4.8 Following bus-level initialization, the device is in the rndis-uninitialized state. Upon receiving REMOTE_NDIS_INITIALIZE_MSG and returning REMOTE_NDIS_INITIALIZE_CMPLT

22、 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

23、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.4.8.1 Halt4.8.2 At any time that the device is i

24、n 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. 4.8.3 Reset4.8.4 The communication channel is “soft-reset” when an error such as message timeout

25、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 wh

26、en 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

27、remote device may reset some of its hardware components, but keeps all communication channels to the host intact.4.8.4.1 Hard Reset4.8.4.2 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 hos

28、t 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.4.9 Flow Control4.10 The Remote NDIS device may need to ex

29、ercise 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.4.11 Byte Ordering4.12 All numeric values in message fields defined by this specification are assumed to be coded in lit

30、tle-endian format, i.e. least significant byte first.4.13 Encapsulation4.14 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.4.15 Remote NDIS Version4.16 Table 21 defines th

31、e Remote NDIS protocol version identifiers exchanged between host and device. Note that these are unrelated to the revision number of this specification.Table 21: Remote NDIS Protocol VersionVersion IdentifierValueDescriptionRNDIS_MAJOR_VERSION1Remote NDIS Major Version specified in this document.RN

32、DIS_MINOR_VERSION0Remote NDIS Minor Version specified in this document.4.17 Status Values4.18 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 v