Windows 2000 network has a layered architecture just as the OSI Model does. Each layer rests upon another layer and receives information from a layer above or below. The data is utilized if needed and is passed up towards an application or down to a hardware device. Boundary layers are interfaces between functional layers in the Windows 2000 network architecture model. Refer to the previous diagram.
Connectionless Architecture
The Windows NT 4.0 network architecture supported traditional connectionless network standards such as Ethernet, Token Ring, and FDDI. Connectionless networking does not negotiate, manage, and maintain a connection before transmitting data. Connectionless architecture, sometimes known as a datagram service is a best efforts delivery service. There is no guarantee that messages won’t be lost, duplicated or delivered out of order.
Connection-oriented Architecture
Windows 2000 continues to support traditional connectionless networking, but adds advanced connection-oriented services such as ATM. Windows 2000 negotiates connections using a call manager. A call manager is a portion of software that can initiate and maintain connections, creating virtual circuits between two network endpoints. Virtual circuits act as conduits for the transmission of data, allowing greater control of bandwidth, latency, delay variation, and sequencing. These services provide greater support for distributed voice, data, and video applications. Windows 2000 also adds IP Quality of Service, bringing many of the attributes of connection-oriented networking to traditional TCP/IP networks.
Network Subsystem Background
The modular networking architecture of Windows 2000 utilizes two industry standard models for a layered networking architecture. The first is the International Organization for Standardization (ISO) model for computer networking, called the Open Systems Interconnect (OSI) Reference Model. The second is the Institute of Electrical and Electronic Engineers (IEEE) 802 model. Windows NT, Windows 98,Windows 95 and Windows for Workgroups also utilize these standard models.
The ISO OSI and IEEE 802 models define a modular approach to networking, with each layer responsible for some discrete aspect of the networking process. They are only models. Therefore, they do not c orrespond exactly to any existing network structure. However, models assist in understanding how networks function.
The OSI model describes the flow of data in a network. Data going to and from the network moves from layer to layer. Each layer is able to communicate with the layer immediately above it and the layer immediately below it. In this way, each layer is discrete. When a layer receives a packet of information, it checks the destination address, and if its own address is not there, it passes the packet to the next layer.
When two computers communicate on a network, the software at a layer on one computer assumes it is communicating with the same layer on another computer. For example, the transport layer of one computer assumes that it is communicating directly with the transport layer on the other computer. However, the actual connection occurs only at the physical layer, as the the figure on the left shows. The transport layer on the first computer has no regard for how the communication actually occurs. First, through the lower layers of the first computer then across the physical media. Finally up through the lower layers of the second computer. 
Network Components
The Network subsystem comprises the following main elements.
-
Network Adapter Card Drivers. Provide interfaces between network media and Windows 2000 network software.
-
Network Driver Interface Specification (NDIS). Acts as a boundary layer between network adapter cards and network protocols and manages the binding process. Windows 2000 NDIS adds support for connection oriented network media such as ATM and continues to support traditional connectionless network media such as Ethernet, Token Ring, and FDDI.
-
Network Protocols. Includes support for TCP/IP, ATM, NWLink IPX/SPX, NetBEUI, AppleTalk and DLC. SNA protocols are available with the addition of Microsoft SNA Server.
-
Transport Device Interface (TDI). Provides a standard interface between network protocols and network APIs.
-
Network Application Programming Interface (APIs). Supports Winsock, NetBIOS, TAPI, MAPI, and other network APIs that provide standard programming interfaces for network applications and services.
-
Interprocess Communications. Supports Remote Procedure Calls, Distributed Component Object Model, Named Pipes, Mailslots, Common Internet File System, and other mechanisms that support client-server computing and distributed processing.
-
Basic Network Services. Makes use of the underlying network architecture to support network applications and services. These include network address management, name services, and advanced network services such as IP Security and Quality of Service.
Network Driver Interface Specification (NDIS)
NDIS is a specification for a network driver architecture that allows transport protocols to communicate with an underlying network card or other hardware device. With Windows 2000, NDIS includes improved support for connection-oriented media. In Windows NT, NDIS offered support for connectionless LAN-based media such as Ethernet, Token Ring, Arcnet, and FDDI.
Windows 2000 NDIS (NDIS 5.0) still exposes the standard connectionless interface. It also defines a connection-oriented control, data plane and associated API’s. This allows for the addition of support components like call managers to provide for connection setup and management. Additionally LAN emulation components can support legacy LAN-based protocols. Connection-oriented components also map legacy protocol network addresses to native connection-oriented media addresses.
NDIS permits the high-level protocol components to be independent of the network interface card by providing a standard interface. The network interface card driver is at the bottom of the network architecture. Because Windows 2000 network architecture supports NDIS, it requires that network adapter card drivers be written to the NDIS specification. NDIS allows an unlimited number of network adapter cards in a computer and an unlimited number of protocols binding to one or more adapter cards.
NDIS is a boundary layer. Code written to match this specification reduces programming required by each software and hardware vendor. Network Device Interface Specification (NDIS) is a standard that allows multiple network adapters and multiple protocols to be bound and to coexist. In Windows 2000, NDIS has been implemented in a module called Ndis.sys, which is referred to as the NDIS wrapper, refer to the figure on the left. The NDIS wrapper is a small piece of code surrounding all of the NDIS device drivers. The wrapper provides a uniform interface between protocol drivers and NDIS device drivers, and contains supporting routines that make it easier to develop NDIS drivers.
Network Protocols
Windows 2000 supports many different protocols. A protocol is a standardized packet of data that makes it possible for networks to share information. The packets of information are moved up and down the protocol stack. As well as moved across the transmission media. This is how all data is moved across a network. The following are the allowed protocols.
-
Transmission Control Protocol/Internet Protocol (TCP/IP). Microsoft has adopted TCP/IP as the strategic enterprise transport protocol for Windows 2000 network operating system. The Windows 2000 TCP/IP suite is designed to make it easy to integrate Microsoft enterprise networks into large scale corporate, government, and public networks, including the Internet and to provide the ability to operate over those networks in a secure manner. Several major factors have lead to the success of TCP/IP. The protocol is routable, which means that packets can be switched by use of the packets address. This ability to be routed confers fault tolerance. If a network failure occurs, packets will be routed by a different route. Another factor contributing to the success of TCP/IP is the massive interest in the Internet. TCP/IP has become the standard for computer interconnectivity. Microsoft TCP/IP been updated for Windows 2000 to include several performance improvements for networking within high-bandwidth LAN and WAN environments.
-
Asynchronous Transfer Mode (ATM). ATM protocol is a connection-oriented protocol that is ideal for voice, video and data communications. After the initial connection has been established. The connection-oriented media determines the status of the connection and creates a virtual circuit. While creating a connection the Quality of Service is determined. This virtual circuit is a direct path from one application to another. ATM takes large chunks of data and creates cells of a large fixed length. Since the virtual circuit is connection-oriented the data arrives at the receiving end in proper order.
-
NetWare Internetwork Packet Exchange/Sequenced Packet Exchange. NWLink IPX/SPX NetBIOS Compatible Transport Protocol is a Microsoft IPX/SPX compatible protocol for Windows 2000. By itself, it does not allow a computer running Windows 2000 to access files or printers shared on a NetWare server, or to act as a file or print server to a NetWare client. To access files or printers on a NetWare server, a redirector must be used, such as the Client Service for NetWare (CSNW) on Windows 2000 Workstation or the Gateway Service for NetWare (GSNW) on Windows 2000 Server. NWLink is useful if there are NetWare client/server applications running that use Sockets or NetBIOS over the IPX/SPX protocol. The client portion can be run on a Windows 2000 Server or Windows 2000 Workstation system to access the server portion on a NetWare server, and vice versa. NWNBLink contains Microsoft enhancements to Novell NetBIOS. The NWNBLink component is used to format NetBIOS-level requests and pass them to the NWLink component for transmission on the network. For more information about NetWare IPX/SPX see chapter 12 in the Internetworking Book of the Windows 2000 Resource Kit
-
NetBIOS Extended User Interface. NetBEUI (NetBios Extended User Interface) was originally developed as a protocol for small departmental LANs of 20 to 200 computers. NetBEUI is included with Windows 2000 Server and Windows 2000 Workstation. It is now primarily a legacy protocol to support existing workstations that have not been upgraded to Windows 2000.
-
AppleTalk Protocol. AppleTalk is a protocol suite developed by Apple Computer Corporation to communicate between MacIntosh computers. Windows 2000 Server includes Services for MacIntosh which includes an AppleTalk protocol stack. Services for MacIntosh provides file sharing, printer sharing, AppleTalk routing and remote access. However, AppleTalk relies heavily on broadcast activity to perform station naming, route discovery, re-routing, and other dynamic tasks. For a very large network this overhead is difficult to absorb.
-
Data Link Control.Unlike the other protocols, the Data Link Control (DLC) protocol is not designed to be a primary protocol for network use between personal computers. The DLC protocol is primarily used for two tasks. First, it can be used access IBM mainframes, which usually run IBM 3270 applications. The other major use of DLC is to print to Hewlett-Packard printers connected directly to networks. DLC provides applications with direct access to the data-link layer, but is not used by the Windows 2000 operating system redirector. DLC is not used for normal-session communication between computers running Windows 2000. Network-attached printers use the DLC protocol because the received frames are easy to disassemble and because DLC functionality can easily be coded into read-only memory (ROM). DLC needs to be installed only on those network machines that perform these two tasks, such as a print server sending data to a network HP printer. Client computers sending print jobs to the network printer do not need the DLC protocol. Only the print server communicating directly with the printer needs the DLC protocol installed.
-
Infrared Data Association.
Network Transport Device Interface
TDI is a common interface for drivers (such as the Windows 2000 redirector and server) to communicate with the various network transport protocols. This allows services to remain independent of transports. Unlike NDIS, there is no driver for TDI, it is simply a specification for passing messages between two layers in the network architecture. This is why TDI acts as a boundary layer.
The Windows 2000 redirector and server both use TDI directly, rather than going through the NetBIOS mapping layer. By doing so, they are not subject to many of the restrictions imposed by NetBIOS, such as the legacy 254-session limit.
Microsoft developed the Transport Driver Interface (TDI) to provide greater flexibility and functionality than is provided by existing interfaces, such as Windows Sockets and NetBIOS. All Windows 2000 transport providers expose TDI. The TDI specification describes the set of functions by which transport drivers and TDI clients communicate, and the call mechanisms used for accessing them. TDI may be the most difficult to use of all Windows 2000 network API’s. It is a simple conduit, so programmers must determine the format and meaning of messages.
Network API
Application Programming Interface’s are sets of routines that an application program uses to request and carry out lower-level services performed by the operating system. Windows 2000 network APIs include:
-
Winsock API.
-
NetBIOS API.
-
Telephony API.
-
Messaging API.
-
Other Network API’s.
Network Interprocess Communication
The connection between the client and server portions of distributed applications must allow data to flow in both directions. There are a number of ways to establish this connection. The Windows 2000 operating system provides many different Interprocess Communication (IPC) mechanisms.
-
Distributed Component Object Model (DCOM).
-
R emote Procedure Call (RPC).
-
Named Pipes and Mailslots.
-
Common Internet File System (CIFS).
Network Services
Network Services are located directly under application programs in the network protocol stack and provide the components to access files on networked computers.
The Server Service
Windows 2000 includes a component, called the Server service. The Server service sits above TDI, is implemented as a file system driver, and directly interacts with various other file-system drivers to satisfy I/O requests, such as reading or writing to a file. The Server service supplies the connections requested by client-side redirectors and provides them with access to the resources they request.
When the Server service receives a request from a remote computer asking to read a file that resides on the local hard drive, the following steps occur.
-
The low-level network drivers receive the request and pass it to the server driver (SRV).
-
The Server service passes a read-file request to the appropriate local file-system driver.
-
The local file-system driver calls lower-level, disk-device drivers to access the file.
-
The data is passed back to the local file-system driver.
-
The local file-system driver passes the data back to the Server service.
-
The Server service passes the data to the lower-level network drivers for transmission back to the client computer.
The Server service is composed of two parts. Refer to the figure on the left.
-
Server, a service that runs in the Services.exe, which is the Service Control Manager, where all services start. Unlike the Workstation service, the Server service is not dependent on the MUP service because the server is not a UNC provider. It does not attempt to connect to other computers, but other computers connect to it.
-
Srv.sys, a file system driver that handles the interaction with the lower levels and directly interacts with various file system devices to satisfy command requests, such as file read and write.
The Workstation Service
All user-mode requests from the MUP and the MPR go through the Workstation service. This service consists of two components. Refer to the figure on the left.
-
The user-mode interface, resides in Services.exe in Windows 2000
-
The redirector (Rdr.sys), which is a file-system driver that interacts with the lower-level network drivers by means of the TDI interface.
The Workstation service receives the user request, and passes it to the kernel-mode redirector. Configuration requirements for loading the Workstation service include:
-
A protocol that exposes the TDI interface must be started.
-
The MUP driver must be started.
W indows 2000 Redirector
The redirector (RDR) is a component that resides above TDI and through which one computer gains access to another computer. The Windows 2000 operating system redirector allows connection to Windows 98, Windows 95, Windows for Workgroups, LAN Manager, LAN Server, and other MS-Net-based servers. The redirector communicates to the protocols by means of the TDI interface.
The redirector is implemented as a Windows 2000 file system driver. This provide the following several benefits.
-
It allows applications to call a single API (the Windows 2000 I/O API) to access files on local and remote computers. From the I/O Manager perspective, there is no difference between accessing files stored on a remote computer on the network and accessing those stored locally on a hard disk.
-
It runs in kernel mode and can directly call other drivers and other kernel-mode components, such as Cache Manager. This improves the performance of the redirector.
-
It can be dynamically loaded and unloaded, like any other file-system driver.
-
It can easily coexist with other redirectors.
Network Resource Access
Applications reside above the redirector and server services in user mode. Like all other layers in the Windows 2000 networking architecture, there is a unified interface for accessing network resources, which is independent of any redirectors installed on the system. Access to resources is provided through one of two components, as explained next.
Multiple Universal Naming Convention Provider (MUP).
When applications make I/O calls containing Universal Naming Convention (UNC) names, these requests are passed to the MUP. MUP selects the appropriate UNC provider (redirector) to handle the I/O request.
One of the design goals of the Windows 2000 networking environment is to provide a platform upon which others can build. MUP is a vital part of allowing multiple redirectors to coexist in the computer. M UP frees applications from maintaining their own UNC-provider listings.
MUP is actually a driver, unlike the TDI interface, which merely defines the way a component on one layer communicates with a component on another layer. Refer to the figure on the left. MUP also has defined paths to UNC providers (redirectors). I/O requests from applications that contain UNC names are received by the I/O Manager, which in turn passes the requests to MUP. If MUP has not seen the UNC name during the previous 15 minutes, MUP will send the name to each of the UNC providers registered with it. MUP is a prerequisite of the Workstation service.
When a request containing a UNC name is received by MUP, it checks with each redirector to find out which one can process the request. MUP looks for the redirector with the highest registered-priority response that claims it can establish a connection to the UNC. This connection remains as long as there is activity. If there has been no request for 15 minutes on the UNC name, then MUP once again negotiates to find an appropriate redirector.
Multi-Provider Router (MPR).
N ot all programs use UNC names in their I/O requests. Some applications use WNet APIs, which are the Win32 network APIs. The Multi-Provider Router (MPR) was created to support these applications. Refer to the figure on the left.
MPR is similar to MUP. MPR receives WNet commands, determines the appropriate redirector, and passes the command to that redirector. Because different network vendors use different interfaces for communicating with their redirector, there is a series of provider DLLs between MPR and the redirectors.
The provider DLLs expose a standard interface so that MPR can communicate with them. The DLLs "know" how to take the request from MPR and communicate it to their corresponding redirector. The provider DLLs are supplied by the network-redirector vendor and should automatically be installed when the redirector is installed.
Note The acronym MPR is also used for the Multi-Protocol Routing, a series of routing components supplied with Windows 4.0. In Windows 2000, Multi-Protocol Routing has become the Routing and Remote Access Service.
Network Load Balancing Service
Network Load Balancing Service allows requests for information of an IP address to be handled by a cluster of machines.
T he machines in this cluster are assigned virtual IP addresses. Refer to the figure on the left. Thus, many machines can do the work for one IP address yet appear as only one machine. This is a useful ability since it provides several benefits. These are performance, scalability and reliability. This re-distribution of work allows the overall performance to be increased.
Load balancing is accomplished by filtering incoming packets and distributing them to the host (cluster server) that should handle them. Scalability, or the ability to increase bandwith easily can be accomplished by adding additional servers to the cluster.
Network Load Balancing Service also enhances the availability of Windows 2000 server programs such as Web Servers, Internet Information Services, FTP Servers, E-Mail and other mission critical services. If a host computer in a cluster goes offline, network load balancing service automatically redistributes the requests to the remaining hosts. A cluster is currently limited to 32 computers.
Share with your friends: |
