Architectural Model Overview
The Windows 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.1 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.
Figure 1. The Windows Server 2003 TCP/IP architectural model
Note Figure 1 does not show the IPsec components. For more information, see How IPSec Works.
Sending and Receiving IP Packets
When the source sends an IP packet, the following components analyze or change the packet in the following order:
-
Routing and Remote Access service IP packet filters
-
IPsec
When a router running Windows Server 2003 forwards an IP packet, the following components analyze or change the packet in the following order:
-
Internet Connection Sharing of the Network Connections folder or the NAT/Basic Firewall component of the Routing and Remote Access service
-
Routing and Remote Access service IP packet filters
-
IPsec
When an IP packet is received for forwarding, the following components analyze or change the packet in the following order:
-
IPsec
-
Routing and Remote Access service IP packet filters
-
Internet Connection Sharing of the Network Connections folder or the NAT/Basic Firewall component of the Routing and Remote Access service
When an IP packet is received that is destined for the local host, the following components analyze or change the packet in the following order:
-
IPsec
-
Routing and Remote Access service IP packet filters
-
Internet Connection Firewall (for Windows Server 2003 with no service packs installed), Windows Firewall (for Windows Server 2003 with Service Pack 1), or the NAT/Basic Firewall component of the Routing and Remote Access service
-
TCP/IP filters
This discussion only includes components that are provided with Windows Server 2003. This does not include any Windows Sockets layered service providers or NDIS intermediate miniport drivers. For additional information, see TCP/IP Packet Processing Paths.
Plug and Play
Windows Server 2003 includes 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 IEEE 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. Windows Server 2003 TCP/IP 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.1)
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 Windows Server 2003 TCP/IP stack utilizes media sense information, which is described in the “Automatic Client Configuration” section of this paper.
-
All local packet filter (prevents Network Monitor from monopolizing the CPU)
-
Numerous new NDIS system functions (required for miniport binary compatibility across Windows 98, Windows Millennium Edition, Windows NT 4.0, Windows 2000, Windows XP, and Windows Server 2003)
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
-
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 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
-
TCP segmentation offload, also known as large-send offload (LSO)
-
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)
Note You can disable a NIC's use of task offload capabilities on the Advanced tab of the properties of the NIC driver in Control Panel-Network or Device Manager.
NDIS 5.1 enhancements for Windows Server 2003 include:
-
Plug and Play and Power Event Notification – Enables NIC miniport drivers to be notified of power or Plug and Play events. This results in cleaner system operation during these events.
-
Support for Send Cancellation – Allows network protocols to avoid having to wait lengthy amounts of time for network packet send requests to complete.
-
Increased Statistics Capacity (64-bit statistic counters) – This enhancement enables accurate network statistic displays, even on today’s high-speed network media.
-
Performance Enhancements – Several enhancements were made to speed up critical network data paths and avoid unnecessary packet copies.
-
Wake on LAN Change – A change was made to Wake on LAN to allow you to limit wake up packets to just magic packets (instead of protocol registered packet patterns). This is now configurable on the Power Management tab from the properties of a NIC driver.
-
Miscellaneous Changes – Several additional changes have been made to support common needs or requests from driver developers or to improve driver integrity.
Remote NDIS is also included as part of the Windows Server 2003 family. Remote NDIS enables the support of USB-attached network devices without the installation of third party drivers. Microsoft supplies the drivers required to communicate with the network devices. This results in easier installation and a lessened chance of system failure because of a poorly built or tested driver.
For more information about NDIS 5.1 and Remote NDIS, see the Windows DDK and the following Web pages:
-
http://www.microsoft.com/whdc/hwdev/tech/network/NDIS51.mspx
-
http://www.microsoft.com/whdc/hwdev/tech/network/rmNDIS.mspx
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
-
Receipt of a Magic Packet.
At driver initialization, NDIS queries the capabilities of the miniport to determine if it supports such things as Magic Packet, pattern match, or link change wakeups, and to determine the lowest required power state for each wakeup method. The network protocols then query the miniport capabilities. At run time, the protocol sets the wakeup policy, using object identifiers (OIDs), such as Enable Wakeup, Set Packet Pattern, and Remove Packet Pattern.
Currently, TCP/IP is the only Microsoft protocol stack that supports network power management. It registers the following packet patterns at miniport initialization:
-
Directed IP packet
-
ARP broadcast for the station’s IP address
-
NetBIOS over TCP/IP broadcast for the station's assigned computer name
NDIS-compliant drivers are available for a wide variety of NICs from many vendors. The NDIS interface allows multiple protocol drivers of different types to bind to a single NIC driver and allows a single protocol to bind to multiple NIC drivers. The NDIS specification describes the multiplexing mechanism used to accomplish this. Bindings can be viewed or changed as advanced settings from the Network Connections folder.
Windows Server 2003 TCP/IP provides support for the following media types:
-
Ethernet (using Ethernet II or IEEE 802.3 Sub-Network Access Protocol [SNAP] encapsulation)
-
Fiber Distributed Data Interchange (FDDI)
-
Token Ring (IEEE 802.5)
-
IEEE 802.11 Wireless LAN
-
ATM (using LAN emulation [LANE] and Classical IP [CLIP] over ATM)
-
Attached Resource Computing Network (ARCnet)
-
Dedicated wide area network (WAN) links such as Dataphone Digital Service (DDS) and T-carrier (Fractional T1, T1, T3, E1, and E3)
-
Dial-up or permanent circuit-switched WAN services such as analog phone, Integrated Services Digital Network (ISDN), and Digital Subscriber Line (xDSL)
-
Packet-switched WAN services such as X.25, Frame Relay, and ATM
Link Layer Functionality
Link layer functionality is divided between the network interface card/driver combination and the low-level protocol stack driver. The network card/driver combination filters are based on the destination media access control (MAC) address of each frame.
Normally, the hardware filters out all incoming frames except those containing one of the following destination addresses:
-
The address of the adapter
-
The all ones broadcast address (0xFF-FF-FF-FF-FF-FF)
-
Multicast addresses that a protocol driver on this host has registered interest in, using the NDISRequest() function
Because this first filtering decision is made by the hardware, the NIC discards any frames that do not meet the filter criteria without incurring any CPU processing. All frames (including broadcasts) that pass the hardware filter and Frame Check Sequence (FCS) validation are then passed up to the NIC driver through a hardware interrupt.2 The NIC driver is software that runs on the computer, so any frames that make it this far require some CPU time to process. The NIC driver brings the frame into system memory from the interface card. Then the frame is indicated (passed up) to the appropriate bound transport driver(s). The NDIS 5.1 specification provides more detail on this process.
Frames are passed up to all bound transport drivers in the order that they are bound.
As a packet traverses a network or series of networks, the source MAC address is always that of the NIC that placed it on the media, and the destination MAC address is that of the NIC that is intended to pull it off the media. This means that, in a routed network, the source and destination MAC address changes with each hop through a network-layer device (router or Layer 3 switch).
Maximum Transmission Unit (MTU)
Each media type has a maximum frame size that cannot be exceeded. The link layer is responsible for discovering this MTU and reporting it to the protocols above. NDIS drivers may be queried for the local MTU by the protocol stack. Knowledge of the MTU for an interface is used by upper layer protocols, such as TCP, that optimize packet sizes for each media automatically. For details, see the discussion of TCP path Maximum Transmission Unit (PMTU) discovery in the “Transmission Control Protocol (TCP)” section of this paper.
If a NIC driver—such as an ATM driver—uses LAN emulation mode, it may report that it has an MTU that is higher than what is expected for that media type. For example, it may emulate Ethernet but report an MTU of 9180 bytes. Windows Server 2003 TCP/IP accepts and uses the MTU size reported by the adapter, even when it exceeds the normal MTU for a given media type.
Sometimes the MTU reported to the protocol stack may be less than what would be expected for a given media type. For instance, use of the 802.1p standard for QoS over Ethernet often reduces the MTU reported by 4 bytes due to larger link-layer headers (this is hardware dependent).
|
