Windows Network Task OffloadUpdated: December 4, 2001 
Network Driver Interface Specification (NDIS) task offload capabilities are documented in the Microsoft Windows DDK. This article provides information about task offload in NDIS 5. On This Page
TCP/IP Task Offload in NDIS 5Network adapters with appropriate NDIS 5 (and later) miniport drivers can increase the system performance by supporting hardware offload of Transmission Control Protocol/Internet Protocol (TCP/IP) CPU-intensive tasks. For example, with TCP/IP checksum offload alone, up to 30 percent performance gain in CPU utilization has been seen in testing at Microsoft. The NDIS interface and the TCP/IP transport have been enhanced to allow miniport drivers to indicate hardware support for performing:
During initialization or when an interface appears as a Plug and Play event, the TCP/IP driver will query the miniport through the NdisRequest() mechanism with an object ID (OID) of OID_TCP_TASK_OFFLOAD in order to find out which offload capabilities the network adapter supports. For each task the network adapter can offload, it will return an NDIS_TASK_OFFLOAD structure that contains an indication of the task supported and parameters specific to that task. The protocol then enables the appropriate tasks by submitting a set request containing the NDIS_TASK_OFFLOAD structures for those tasks. At this point, these tasks are enabled for offload. The network adapter will receive information specific to the task on a per-packet basis, along with each packet. Checksum OffloadOn the send side, the network adapter that supports this offload will calculate checksums that are needed and for which it has indicated the capability of performing. For the TCP checksum, the Microsoft transport will calculate the TCP pseudo header checksum and place this value in the checksum field, so that the network adapter can calculate the correct TCP checksum without touching the IP header. On the receive side, the network adapter will fill in a NDIS_TCP_IP_CHECKSUM_PACKET_INFO structure and set the appropriate bits. If for any reason the network adapter cannot perform the checksum, it will not set any bits and indicate the packet. TCP/IP will then look at this and calculate the appropriate checksum itself. TCP Segmentation OffloadWith Segmentation Offload, or TCP Large Send, TCP can pass a buffer to be transmitted that is bigger than the maximum transmission unit (MTU) supported by the medium. Intelligent adapters implement large sends by using the prototype TCP and IP headers of the incoming send buffer to carve out segments of required size. Copying the prototype header and options, then calculating the sequence number and checksum fields creates TCP segment headers. All other information, such as options and flag values, are preserved except where noted. Sequence number for successive segments is handled by accounting for segment size. As in the checksum offload task, the Microsoft transport will calculate the pseudo header checksum and place the results in the TCP header so that the network adapter can calculate the correct TCP checksum without touching the IP header. The variable component of the TCP checksum for large send must be supplied by the network adapter for each segment it carves out of the larger packet. The IP total length of the prototype header holds the data size, which includes: TCP payload of the first segmented frame expected to be transmitted by the network adapter + the TCP header size + options length + IP header size and options length. The TCP Sequence number holds the sequence number of the first byte in the TCP payload. Similarly, IP ID for each frame is incremented and checksum is computed. Adapters can support Large Send Offload without supporting checksum as a separate offload, even though it should be able to calculate checksums to implement Large Send Offload correctly. In addition, adapters can implement Large Send Offload with or without TCP or IP options. Assumptions:
NOTE: TCP Segmentation Offload is in Windows 2000, but it is disabled by default in the registry. Microsoft recommends that hardware vendors use Windows 2000 as a development platform for TCP Segmentation Offload adapters, enabling it in registry. At this time, Microsoft does not recommend using TCP Segmentation Offload in end-user environments except for Beta testing of hardware and drivers. IPSec OffloadIPSec is an extension to IPv4 that provides encryption of IP traffic per packet (data integrity and source authentication per packet) using the Internet Key Exchange (IKE; formerly ISAKMP/Oakley) protocol for security negotiation and cryptographic key management. Windows IPSec enables network administrators to secure traffic on corporate networks, transparent to existing applications. Centralized configuration of IPSec is provided by the Windows Active Directory and Group Policy features. IPSec has two modes: transport mode for end-to-end security, and tunnel mode for router-to-router security. The transport mode can be used to provide end-to-end security in communication between any two hosts (clients and servers), or between a client and a tunnel server--for example, and L2TP tunnel secured by IPSec transport mode (L2TP/IPSec). IPSec tunnel mode is recommended for gateway-to-gateway VPN scenarios only where L2TP/IPSec is not available. IPSec policy controls the configuration of the IPSec driver and IKE service. Security associations (SA) must be established by IKE between computers before application data can be sent or received securely. IKE generates the shared secret key material using the Diffie Hellman technique and performs mutual authentication using any of three methods: Kerberos version 5.0, Public/Private key signatures with certificates, and pre-shared authentication key. IKE then negotiates which encryption algorithms to use to protect the application data and derives bulk encryption keys for per-packet data encryption and hashing operations. If the encryption algorithms agreed upon can be performed by the sending network adapter, then the IPSec driver adds the security association along with the agreed-upon parameters and keys to the network adapter. TCP/IP will frame the IP packet, and then pass it to the IPSec driver to determine whether the packet matches a security association. The IPSec driver will match the packet against all IPSec filters. If there is a filter match, and there exists a security association and this SA has been offloaded to the network adapter, then the packet is given directly to the network adapter with an SA context, so that the adapter can perform the cryptographic operations for that packet. The IPSec offload capability will enable the network adapter to perform the following transforms and algorithms:
Notes on TCP/IP Offload TasksAlthough the same network adapter can offload several of these tasks, when an IPSec policy is assigned, the checksum and TCP large send offloads are disabled. NOTE: IPSec and related services in Windows were jointly developed by Microsoft and Cisco Systems, Inc. Call to action for NDIS task offload:
For more information about NDIS task offload, please send e-mail to ndisfb@microsoft.com with NDIS Task Offload in the Subject line. Please be sure to include your name, title, company name, company type (IHV or OEM), and phone and fax numbers. For IETF standard protocol specifications, see the RFCs at:
http://www.ietf.org/html.charters/OLD/ipsec-charter.html The following information is available on the web about Microsoft IPSec and related VPN issues:
|
|
- Related developer sites
- Microsoft Connect
- OSR Online
- Windows Phone
- Other Windows sites
- Enterprise
- Small business
- Students
- Home users
- Essentials
- Recently published
- Debugging
- Samples
- Hardware dashboard
- Support
- Forums
- More support resources
© 2013 Microsoft. All rights reserved.
