Operating System

White Paper

By Dave MacDonald and Warren Barkley

Abstract

This white paper describes the Microsoft® Windows® 2000 operating system TCP/IP implementation details, and is a supplement to the Microsoft Windows 2000 TCP/IP manuals. The Microsoft TCP/IP protocol suite is examined from the bottom up. Throughout the paper, network traces are used to illustrate key concepts. These traces were gathered and formatted using Microsoft Network Monitor, a software-based protocol tracing and analysis tool included in the Microsoft Systems Management Server product. The intended audience for this paper is network engineers and support professionals who are already familiar with TCP/IP.

Introduction

Microsoft has adopted TCP/IP as the strategic enterprise network transport for its platforms. In the early 1990s, Microsoft started an ambitious project to create a TCP/IP stack and services that would greatly improve the scalability of Microsoft networking. With the release of the Microsoft® Windows NT® 3.5 operating system, Microsoft introduced a completely rewritten TCP/IP stack. This new stack was designed to incorporate many of the advances in performance and ease of administration that were developed over the past decade. The stack is a high-performance, portable 32-bit implementation of the industry-standard TCP/IP protocol. It has evolved with each version of Windows NT to include new features and services that enhance performance and reliability.

The goals in designing the TCP/IP stack were to make it:

• Standards-compliant

• Interoperable

• Portable

• Scalable

• High performance

• Versatile

• Self-tuning

• Easy to administer

• Adaptable

This paper describes Windows 2000 implementation details and is a supplement to the Microsoft Windows 2000 TCP/IP manuals. It examines the Microsoft TCP/IP implementation from the bottom up and is intended for network engineers and support professionals who are familiar with TCP/IP.

This paper uses network traces to help illustrate concepts. These traces were gathered and formatted using Microsoft Network Monitor 2.0, a software-based protocol tracing and analysis tool included in the Microsoft Systems Management Server product. Windows 2000 Server includes a reduced functionality version of Network Monitor. The primary difference between this version and the Systems Management Server version is that the limited version can only capture frames that would normally be seen by the computer that it is installed on, rather than all frames that pass over the network (which requires the adapter to be in promiscuous mode). It also does not support connecting to remote Network Monitor Agents.

Capabilities and Functionality

Overview

The TCP/IP suite for Windows 2000 was designed to make it easy to integrate Microsoft systems into large-scale corporate, government, and public networks, and to provide the ability to operate over those networks in a secure manner. Windows 2000 is an Internet-ready operating system.

Support for Standard Features

Windows 2000 supports the following standard features:

• Ability to bind to multiple network adapters with different media types

• Logical and physical multihoming

• Internal IP routing capability

• Internet Group Management Protocol (IGMP) version 2 (IP Multicasting)

• Duplicate IP address detection

• Multiple default gateways

• Dead gateway detection

• Automatic Path Maximum Transmission Unit (PMTU) discovery

• IP Security (IPSec)

• Quality of Service (QoS)

• ATM Services

• Virtual Private Networks (VPNs)

• Layer 2 Tunneling Protocol (L2TP)

Performance Enhancements

In addition, Windows 2000 has the following performance enhancements:

• Protocol stack tuning, including increased default window sizes and new algorithms for high delay links, which increases throughput

• TCP-scalable window sizes (supported by RFC 1323)

• Selective acknowledgments (SACK)

• TCP fast retransmit

• Round Trip Time (RTT) and Retransmission Timeout (RTO) calculation improvements

• Improved performance for management of large numbers of connections

• Hardware task offload mechanisms

Services Available

The Windows 2000 Server family of operating systems provides the following services:

• Dynamic Host Configuration Protocol (DHCP) client and service

• Windows Internet Name Service (WINS), a NetBIOS name client and server

• Dynamic Domain Name Server (DDNS)

• Dial-up (PPP/SLIP) support

• Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol. (L2TP), used for remote virtual private networks

• TCP/IP network printing (lpr/lpd)

• SNMP agent

• NetBIOS interface

• Windows Sockets version 2 (Winsock2) interface

• Remote Procedure Call (RPC) support

• Network Dynamic Data Exchange (NetDDE)

• Wide Area Network (WAN) browsing support

• High-performance Microsoft Internet Information Services (IIS)

• Basic TCP/IP connectivity utilities, including: finger, ftp, rcp, rexec, rsh, telnet, and tftp

• Server software for simple network protocols, including: Character Generator, Daytime, Discard, Echo, and Quote of the Day

• TCP/IP management and diagnostic tools, including: arp, ipconfig, nbtstat, netstat, ping, pathping, route, nslookup, and tracert

Feature Comparison Table for Microsoft TCP/IP Versions

The table below lists features and the operating system versions that they are present in as a reference. Features are described in more detail throughout this document.

Table 1 N=No, Y=Yes, and D=Disabled by Default

Internet RFCs Supported by Microsoft Windows 2000 TCP/IP

Requests for Comments (RFCs) are a constantly evolving series of reports, proposals for protocols, and protocol standards used by the Internet community. You can use FTP to obtain RFCs from any of the following:

• nis.nsf.net

• nisc.jvnc.net

• wuarchive.wustl.edu

• src.doc.ic.ac.uk

• normos.org

Table 2 RFCs supported by this version of Microsoft TCP/IP

Architectural Model

Overview

The Microsoft TCP/IP suite contains core protocol elements, services, and the interfaces between them. The Transport Driver Interface (TDI) and the Network Device Interface Specification (NDIS) are public, and their specifications are available from Microsoft.¹ http://www.microsoft.com/ and ftp://ftp.microsoft.com/).

In addition, there are a number of higher-level interfaces available to user-mode applications. The most commonly-used are Windows Sockets, remote procedure call (RPC), and NetBIOS.

Plug and Play

Windows 2000 introduces support for Plug and Play. Plug and Play has the following capabilities and features:

• Automatic and dynamic recognition of installed hardware. This includes initial system installation, recognition of static hardware changes that may occur between boots, and response to run-time hardware events, such as dock or undock, and insertion or removal of cards.

• Streamlined hardware configuration in response to automatic and dynamic recognition of hardware, including dynamic hardware activation, resource arbitration, device driver loading, drive mounting, and so on.

• Support for particular buses and other hardware standards that facilitate automatic and dynamic recognition of hardware and streamlined hardware configuration, including Plug and Play ISA, PCI, PCMCIA, PC Card/CardBus, USB, and 1394. This includes promulgation of standards and advice about how hardware should behave.

• An orderly Plug and Play framework in which driver writers can operate. This includes infrastructure, such as device information (INF) interfaces, APIs, kernel-mode notifications, executive interfaces, and so on.

• Mechanisms that allow user-mode code and applications to learn of changes in the hardware environment so that they can take appropriate actions.

Plug and Play operation does not require Plug and Play hardware. To the degree possible, the first two bullets above apply to legacy hardware, as well as Plug and Play hardware. In some cases, orderly enumeration of legacy devices is not possible because the detection methods are destructive or inordinately time-consuming.

The primary impact that Plug and Play support has on protocol stacks is that network interfaces can come and go at any time. The Windows 2000 TCP/IP stack and related components have been adapted to support Plug and Play.

The NDIS Interface and Below

Microsoft networking protocols use the Network Device Interface Specification (NDIS) to communicate with network card drivers. Much of the OSI model link layer functionality is implemented in the protocol stack. This makes development of network card drivers much simpler.

Network Driver Interface Specification (3.1 through 5.0)

NDIS 3.1 supports basic services that allow a protocol module to send raw packets over a network device and allow that same module to be notified of incoming packets received by a network device.

NDIS 4.0 added the following new features to NDIS 3.1:

• Out-of-band data support (required for Broadcast PC)

• WirelessWAN Media Extension

• High-speed packet send and receive (a significant performance win)

• Fast IrDA Media Extension

• Media Sense (required for the Designed for Windows logo in PC 97 and later Hardware Design Guide). The Microsoft Windows 2000 TCP/IP stack utilizes media sense information, which is described in the "Automatic Client Configuration" section of this white paper.

• All local packet filter (prevents Network Monitor from monopolizing the CPU)

• Numerous new NDIS system functions (required for miniport binary compatibility across Windows 95, Windows 98, Windows NT, and Windows 2000)

NDIS 5.0 includes all functionality defined in NDIS 4.0, plus the following extensions:

• NDIS power management (required for Network Power Management and Network Wake-up)

• Plug and Play. (Windows 95 NDIS had Plug and Play support already; therefore, this change applies to Windows 2000 network drivers only.)

• Support for Windows Management Instrumentation (WMI), which provides Web-based Enterprise Management (WBEM)–compatible instrumentation of NDIS miniports and their associated adapters

• Support for a single INF format across Windows operating systems. The new INF format is based on the Windows 98 INF format.

• Deserialized miniport for improved performance

• Task offload mechanisms, such as TCP and UDP checksum and Fast Packet Forwarding

• Broadcast Media Extension (needed for Broadcast Services for Windows)

• Connection-oriented NDIS (required to support Asynchronous Transfer Mode [ATM], Asymmetric Digital Subscriber Line [ADSL], and Windows Driver Model–Connection Streaming Architecture [WDM-CSA]

• Support for Quality of Service (QoS)

• Intermediate Driver Support (required for Broadcast PC, Virtual LANs, Packet Scheduling for QoS, and NDIS support of IEEE 1394 network devices)

NDIS can power down network adapters when the system requests a power level change. Either the user or the system can initiate this request. For example, the user may want to put the computer in sleep mode, or the system may request a power level change based on keyboard or mouse inactivity. In addition, disconnecting the network cable can initiate a power-down request if the network interface card (NIC) supports this functionality. In this case, the system waits a configurable time period before powering down the NIC because the disconnect could be the result of temporary wiring changes on the network, rather than the disconnection of a cable from the network device itself.

NDIS power management policy is no network activity–based. This means that all overlying network components must agree to the request before the NIC can be powered down. If there are any active sessions or open files over the network, the power-down request can be refused by any or all of the components involved.

The computer can also be awakened from a lower power state, based on network events. A wakeup signal can be caused by:

• Detection of a change in the network link state (for example, cable reconnect)

• Receipt of a network wakeup frame