From: "Eliyas Yakub" Subject: FYI: Differences Between NDIS and CoNDIS WAN Driver Implementations Date: Tuesday, January 15, 2002 1:23 PM Choosing a WAN Miniport Driver Model For new WAN drivers, Microsoft recommends the CoNDIS WAN model over the NDIS WAN model. However, Microsoft will continue to support NDIS WAN miniport drivers. There are many existing NDIS WAN implementations, and some of them support hardware that is or will soon be obsolete. Independent hardware vendors (IHVs) are not required to write CoNDIS drivers for old hardware. You should have a basic understanding of the Remote Access Service (RAS) architecture to understand this document. Differences Between NDIS and CoNDIS WAN Driver Implementations This topic lists the differences between NDIS WAN drivers and CoNDIS WAN drivers. NDIS WAN drivers are miniport drivers. CoNDIS WAN drivers can be either a miniport call manager (MCM) driver or a miniport driver that is combined with a separate call manager driver. The primary differences between CoNDIS WAN drivers and NDIS WAN drivers are: The version number specified in the NDIS_MINIPORT_CHARACTERISTICS structure that is passed to NdisMRegisterMiniport is version 3.0 to 4.0 for NDIS WAN miniport drivers and is version 5.0 or later for CoNDIS WAN miniport drivers. You register NDIS WAN drivers and CoNDIS WAN miniport or MCM drivers as a miniport. However, if there is a separate call manager, you should register the call manager as a protocol. The medium type indicated by the SelectedMediumIndex parameter that the miniport driver sets in MiniportInitialize is different. In addition, a CoNDIS MCM driver or call manager must register an address family. NDIS WAN miniport drivers implement signaling with TAPI OIDs. The CoNDIS model uses a call manager or MCM to implement signaling. In a NDIS WAN environment, an application must set up a connection by making or accepting a call. After the connection is established, links are used to route data. In a CoNDIS environment, a virtual connection (VC) is created to establish the connection and route data. Different function calls are used to implement the following operations: Sending data. Receiving data. Setting miniport driver or NIC state. Querying miniport driver or NIC information. Indicating miniport driver or NIC status. NDIS WAN miniport drivers keep a WAN-specific set of statistics (see OID_WAN_GET_STATS_INFO. CoNDIS WAN miniport drivers should keep a set of statistics for each VC on the miniport driver's NIC (see OID_WAN_CO_GET_STATS_INFO). CoNDIS WAN miniport drivers use an NDIS_PACKET descriptor instead of the NDIS_WAN_PACKET descriptor that NDIS WAN miniport drivers use. Some functions use different parameter values, for example, NdisMRegisterMiniport is used to register both NDIS WAN and CoNDIS WAN miniport drivers, but the MiniportXxx functions that each driver type registers are different. NDIS WAN and CoNDIS WAN miniport drivers use different WAN OIDs. The OIDs that are prefixed with OID_WAN_ are associated with NDIS WAN drivers. The OIDs that are prefixed with OID_WAN_CO_ are associated with CoNDIS drivers. The exceptions to note are: OID_WAN_PERMANENT_ADDRESS, OID_WAN_CURRENT_ADDRESS, and OID_WAN_MEDIUM_SUBTYPE. These OIDS are used by both NDIS WAN and CoNDIS WAN drivers. A NDIS WAN miniport driver is very closely tied to TAPI. The TAPI provider APIs are directly mapped to TAPI OIDs. In the CoNDIS architecture, however, the TAPI complexity is handled by NDPROXY. Therefore, the CoNDIS model requires fewer TAPI OIDs. NDIS WAN and CoNDIS WAN miniport drivers use different TAPI OIDs. The OIDs that are prefixed with OID_TAPI_ are associated with NDIS WAN drivers. The OIDs that are prefixed with OID_CO_TAPI_ are associated with CoNDIS drivers. Advantages of CoNDIS WAN Drivers This section documents the primary advantages of a CoNDIS WAN implementation over a NDIS WAN implementation. CoNDIS WAN is More Flexible CoNDIS provides a component-based architecture. The CoNDIS model provides four types of drivers: connection-oriented client drivers call manager drivers connection-oriented miniport drivers integrated miniport call manager (MCM) drivers The separation of architectural components remains clearly defined in an MCM. The call manager (or call manager component if there is an MCM) handles the signaling aspects of connections, and the CoNDIS WAN miniport driver handles the NIC hardware. You do not need to write a call manager if one is provided with Windows, as in the case of the ATM call manager. If the call manager is not already provided with the system, as is the case with ISDN, you can either write one or possibly obtain one from a third party. The separation of call manager and miniport components allows the miniport driver to be updated to support new hardware while the call manager remains unchanged. In many cases, the call manager might only require upgrades to correct defects. The WAN services that Windows includes as standard are dominated by remote access services. Windows includes a PPP CoNDIS client, and CoNDIS WAN miniport drivers are available for many devices. You can write CoNDIS WAN clients to extend the system to support other protocols in addition to PPP. The CoNDIS WAN model is not restricted to PPP data. You can implement a custom WAN client driver and miniport driver to handle, for example, raw data streaming or proprietary encryption. The custom CoNDIS WAN client and miniport drivers share the same address family. CoNDIS WAN is Less Complex CoNDIS implements a well-organized model for WAN connections. There are NDIS objects which correspond to each of the logical entities that are involved in a connection. These entities include address families (AFs), virtual connections (VCs), service access points (SAPs), and parties. NDPROXY handles many of the complex requirements of TAPI. A CoNDIS miniport driver is not required to handle as many TAPI OIDs. In addition, the CoNDIS WAN miniport is not required to handle the following status indications: NDIS_STATUS_TAPI_INDICATION, NDIS_STATUS_WAN_LINE_UP, and NDIS_STATUS_WAN_LINE_DOWN. The separation of the call manager and miniport functions enables the implementation of two simple drivers. The simplified drivers should be easier to maintain and debug than one large and complex driver. Other Benefits of CoNDIS WAN In addition to flexibility and simplicity, CoNDIS WAN provides the following benefits: CoNDIS WAN miniport drivers can implement multipacket send and receive functionality. When a NDIS WAN miniport driver calls NdisMWanIndicateReceive, protocols have to copy the data immediately. When a CoNDIS miniport driver calls NdisMCoIndicateReceivePacket, protocols can defer processing to a later time (by returning NDIS_STATUS_PENDING from ProtocolCoReceivePacket) on receives. CoNDIS WAN supports multipoint calls. CoNDIS WAN provides Quality of Service (QoS ) support. CoNDIS WAN uses the NDIS_PACKET packet descriptor instead of the NDIS_WAN_PACKET packet descriptor used by NDIS WAN. NDIS_WAN_PACKET does not contain any QoS information. Debugging can be easier because the call manager and miniport driver are separate. CoNIDS WAN will allow you to take advantage of future NDIS enhancements that support WAN miniports. Other NDIS Features Available to CoNDIS WAN You can use these NDIS features in CoNDIS WAN drivers but they are not available to NDIS WAN miniport drivers: Plug and Play event notification for miniport drivers 64-bit statistical counters Canceling send packets Registering a MiniportShutdown function New miniport driver attributes Safe functions