1.6.1 LDAP

LDAP has been designed to access directory services. It is currently being developed and maintained by the IETF (Internet Engineering Task Force), an open, international community of network designers, operators, vendors, and researchers who define the standards and protocols that drive Internet computing. LDAP is not a transport protocol and has been implemented to use TCP/IP for a transport protocol.

NDS versions 5.73 through 6.xx support LDAP v2, and NDS versions 7.xx and 8.xx support LDAP v3 on NetWare, NT and Solaris platforms. In NDS 8 when LDAP clients formulate and send requests, an LDAP server listens for the requests, accepts them and sends them to NDS for processing. NDS processes the requests and returns the replies to the LDAP server which then sends them to the client. The LDAP server has become tightly integrated with the DS agent and is no longer an optional loadable module.

1.6.2 NDAP

NDAP is built on top of NCP (NetWare Core Protocol). Like NCP, NDAP is a request/reply protocol, but unlike NCP, it is a messaging protocol. Since an NDS request or reply can be larger than a single packet, NDS messages can be fragmented across multiple packets and reassembled by NDS before NDS hands the message to the NDS agent for processing.

NCP is not a transport protocol, and thus it relies on other protocols to transport packets on the wire. Since NDAP is built on top of NCP, any transport protocol supported by NCP is automatically supported by NDAP. In NetWare 4.x, NCP supports IPX™ and IPX encapsulated by IP (called NetWare/IP™) as its transport protocols. In NetWare 5.x, NCP supports IPX and IP as its transport protocol; the NetWare server can be configured to support IPX/SPX, TCP/IP, or both.

NDS 8 on NT and Solaris use TCP/IP as the transport protocol since TCP/IP is their native supported transport protocol.

SLP and SAP

In NetWare 4.x, NDS clients rely upon SAP to discover NDS trees and to advertise NDS tree names. In NetWare 5.x when a network is configured only for IP, NDS clients can rely on SLP (Service Location Protocol), if available, to discover NDS tree names, or the clients can be manually configured to know NDS tree names.

NDS uses SLP in two ways: advertise (or registration), and lookup (or name resolution). The NDS server (agent) advertises it’s IP referral addresses in an SLP record so others looking for a particular NDS tree by name may use SLP name resolution services to detect its presence. The NDS client (dclient) uses SLP name resolution to gain an entry point into the tree. That is, if it has no existing connections to the target tree, it will use SLP to locate a server in the tree (preferrably one that is close in heirarchical location to itself). After connecting to this server, it will use NDS resolve name functionality to lookup a server containing a replica of a partition containing that portion of the tree containing the target object. NDS resolve name protocol is always used first, if possible. Only in the condition that the client has no existing connections to any server in the tree will it go to SLP for that information.

DHCP

To make management of IP networks and IP addresses easier, NetWare 5.x includes a DHCP (Dynamic Host Configuration Protocol) server. The DHCP server provides dynamic IP address assignment so that many devices can share a limited address space. It also uses NDS to simplify the administration of IP address and device configuration information and passes this information to the hosts (DHCP clients) on the TCP/IP network.

Mixed IP and IPX Networks

For NDS to work in a mixed IP and IPX network, the following modifications were made to NDS:

These features eliminate the need for all servers in a replica ring to communicate directly with each other. The only requirement in a mixed IP and IPX network is that one server in the replica ring must support both IP and IPX.

In the figure, Server 1 cannot synchronize directly with Server 3 because they are using different protocols. However, both Server 1 and Server 3 can synchronize with Server 2 and thus Server 2 becomes the intermediator. In this example, Server 1 will send its updates to Server 2. Server 2 will relay these updates to Server 3 and then update its transitive vector to indicate that Server 3 has received the updates from Server 1. The next time Server 1 and Server 2 synchronize, Server 1 will examine the transitive vector of Server 2 and then update its transitive vector to indicate that Server 3 has been synchronized.

Mixed NDS Version Networks

If an NDS replica ring contains servers running NDS versions 6.xx, 7.xx, and 8.xx, NDS automatically detects which synchronization process the server supports: