![[Return to Library]](BOOKSHLF.GIF)
![[Contents]](TOC.GIF)
![[Previous Chapter]](REW.GIF)
![[Next Section]](NEXT.GIF)
![[Next Chapter]](FF.GIF)
![[Index]](INDEX.GIF)
![[Help]](HELP.GIF)
The networking functionality in Digital UNIX Version 4.0 comes primarily from OSF Version 1.0, although certain modules, like System V Release 4.0 STREAMS which were not available in OSF Version 1.0, have been taken from the OSF Version 1.2 code base. Some functionality, like IP Multicasting and the packet filter applications, has been taken from the public domain, enhanced, and integrated into the operating system as a service to our customers. The Network File System (NFS) code, as well as the Remote Procedure Calling (RPC) code, Network Information Service (NIS), and remote daemons and their corresponding commands came from Sun Microsystem's Open Network Computing (ONC) Version 4.2. And finally, functionality that Digital has licensed and enhanced, like Yellow Pages/Network Information Service which was licensed from SUN, was ported to Digital UNIX Version 4.0 from ULTRIX, since, although conforming to the OSF Version 1.2 standards, it was determined to be more robust than the corresponding code from the OSF.
Like all subsystems in Digital UNIX Version 4.0, the networking subsystem is designed to provide a standardized programming interface to enable third-party vendors to develop and port their networking applications to OSF with a minimum of difficulty. To this end Digital UNIX Version 4.0 supports the following:
The following sections briefly discuss the networking functionality in Digital UNIX Version 4.0.
![[Previous Section]](PREV.GIF)
TCP/IP supports a suite of protocols, each of which provides a different service. These protocols allow networking communications to be independent of network hardware. The TCP/IP protocol suite is organized into the following groups:
Figure 3-1 illustrates the relationship of the major protocols in the TCP/IP suite.
Applications programs send messages (streams of data) to the Internet Transport-Level Protocols, which are the UDP and the TCP. These protocols receive the data from the application, divide it into packets, add a transport header, and then pass the packets along to the next protocol layer, the Internet layer.
The Internet layer encloses the packet in an IP datagram, adds the datagram header, decides where to send the datagram (either directly to a destination or else to a gateway), and passes the datagram on to the Network Interface layer. The Network Interface layer accepts IP datagrams and transmits them as frames over a specific network hardware.
Frames received by a network go through the protocol layers in reverse. Each layer strips off the corresponding header information until the data is back at the application level. Frames are received by the Network Interface layer (for example, an Ethernet adapter), which strips off the physical layer header and sends the datagram to the Internet layer. In the Internet layer, the Internet Protocol strips off the IP header and sends the packet to the Transport layer. The Transport layer strips off the TCP or UDP header and sends the data up to the Application layer.
When an application needs to send data to an application on another host, the application sends the information down to the transport level protocols to prepare the information for transmission. These protocols include DOMAIN, EGP, BGP RIP, OSPF, FTP, NFS, TELNET, TFTP, FINGER, SMTP, and SNMP.
The Domain Name Protocol (DOMAIN) allows one or more hosts in a domain to act as a name server for other hosts within the domain. DOMAIN uses UDP or TCP as its underlying protocol and allows a local network to assign host names within its domain independently from other domains. UDP is the preferred protocol for use with DOMAIN; however, if the UDP response is truncated, TCP can be used.
In the Digital UNIX environment, the Berkeley Internet Name Domain (BIND) naming service uses the Domain Name Protocol. In this hierarchical naming system, local resolver routines may resolve Internet names and addresses using a local name resolution database maintained by the named daemon. If the name requested by the host is not in the local database, the resolver routine or the local named daemon queries the remote BIND name server.
Routing Protocols allow systems on either internal or external LANs to share routing information. In addition to the somewhat outmoded External Gateway Protocol (EGP), Digital UNIX supports the Border Gateway Protocol (BGP) and both the Routing Information Protocol (RIP) and Open Shortest Path First Protocol (OSPF) as part of the GateD daemon from Cornell University (for more information on the GateD, see Section 3.5.6).
The Exterior Gateway Protocol (EGP) allows the exterior gateway of an autonomous system to share routing information with exterior gateways on other autonomous systems.
An autonomous system is a group of networks and gateways for which one administrative authority has responsibility. Gateways are interior neighbors if they reside on the same autonomous system and exterior neighbors if they reside on different autonomous systems. Gateways that exchange routing information using EGP are said to be EGP peers (neighbors). Autonomous system gateways use EGP to provide reachability information to their EGP neighbors.
EGP allows an exterior gateway to provide remote communications among systems as follows:
EGP restricts exterior gateways by allowing them to advertise only those destination networks reachable entirely within that gateway's autonomous system. Thus, an exterior gateway using EGP passes on information to its EGP neighbors, but does not advertise reachability information about its EGP neighbors.
EGP does not interpret the distance metrics that appear in routing update messages from other protocols. EGP uses the distance field to specify whether a path exists (a value of 255 means that the network is unreachable). The value cannot be used to compute the shorter of two routes, unless those routes are both contained within a single autonomous system. For this reason, EGP cannot be used as a routing algorithm. As a result, there is only one path from an exterior gateway to any network.
EGP routes are predetermined in the /etc/gated.conf file. This contrasts with the Routing Information Protocol (RIP), which can be used within (that is, interior to) an autonomous system of Internet networks that dynamically reconfigure routes. EGP assumes that IP is the underlying protocol. See the gated(8) reference page for further information.
The Border Gateway Protocol (BGP) is an exterior routing protocol used for exchanging routing information between autonomous systems that are either multiple transit autonomous systems or transit and stub autonomous systems. BGP is related to EGP but operates with more capability, greater flexibility, and less required bandwidth. For example, BGP uses path attributes to provide more information about each route and, unlike EGP, maintains an Autonomous System (AS) path, which provides enough information (such as the AS number of each autonomous system the route has traversed) to prevent routing loops in an arbitrary topology.
Like EGP, BGP supports both internal and external sessions. When sending routes to an external peer, BGP prepends the local AS number to the AS path so that routes received from an external peer are guaranteed to have the AS number of that peer at the start of the path. Routes received from an internal neighbor will not in general have the local AS number prepended to the AS path, and in general have the same AS path that the route had when the originating internal neighbor received the route from an external peer. Routes with no AS numbers in the path may be legitimately received from internal neighbors; these indicate that the received route should be considered internal to your own AS.
The Digital UNIX implementation of BGP supports three versions of the BGP protocol (versions 2, 3 and 4). BGP versions 2 and 3 are quite similar in capability and function. They will only propagate classed network routes, and the AS path is a simple array of AS numbers. BGP 4 will propagate fully general address-and-mask routes, and the AS path has some structure to represent the results of aggregating dissimilar routes.
The Routing Information Protocol (RIP) is an implementation of a distance-vector, or Bellman-Ford routing protocol for local networks and in Digital UNIX is contained in the GateD daemon from Cornell University. RIP classifies routers as active and passive: active routers advertise their routes to other routers; passive routers listen and update their routes based on the advertisements they receive, but do not advertise themselves. Typically, routers run RIP in active mode, while hosts use passive mode.
A router running RIP in active mode broadcasts updates at set intervals. Each update contains paired values where each pair consists of an IP network address and an integer distance to that network. RIP uses a hop count metric to measure the distance to a destination. The number of hops along a path from a given source to a given destination refers to the number of gateways that a datagram would encounter along that path.
For example, a router advertises directly connected networks as having a hop count of one. Networks that are reachable through another gateway are two hops away, networks that are reachable through two gateways are three hops away, and so forth. Then RIP chooses the path with the shortest hop count.
Of course, using hop counts to calculate shortest paths between networks may not always produce optimal results. For example, a path with a hop count of three that crosses three Ethernets may be substantially faster than a path with a hop count of 2 that crosses two slow-speed serial lines. To compensate for differences in network and serial line rates of transfer, administrators can configure RIP routers to advertise artificially high hop counts for slow links.
Open Shortest Path Routing (OSPF) is a shortest path first (SPF) or link-state interior gateway protocol that distributes routing information between routers in a single autonomous system. Suitable for complex networks with a large number of routers, OSPF provides equal cost multipath routing whereby packets to a single destination can be sent by more than one network interface simultaneously.
A link-state protocol dictates that each router maintains a database describing the entire AS topology, which it builds out of the collected link state advertisements of all routers. Each participating router distributes its local state (that is the router's usable interfaces and reachable neighbors) throughout the AS by flooding. Each multiaccess network that has at least two attached routers has a designated router and a backup designated router. The designated router floods a link state advertisement for the multiaccess network and has other special responsibilities. The designated router concept reduces the number of adjacencies required on a multiaccess network.
OSPF allows networks to be grouped into areas. Routing information passed between areas is abstracted, potentially allowing a significant reduction in routing traffic. OSPF uses four different types of routes, listed in order of preference: intra-area, inter-area, type 1 external and type 2 external. Intra-area paths have destinations within the same area, inter-area paths have destinations in other OSPF areas and Autonomous System External (ASE) routes are routes to destinations external to the AS. Routes imported into OSPF as type 1 routes are supposed to be from EGPs whose external metrics are directly comparable to OSPF metrics. When a routing decision is being made, OSPF will add the internal cost to the AS Border router to the external metric. Type 2 ASEs are used for EGPs whose metrics are not comparable to OSPF metrics. In this case, only the internal OSPF cost to the AS Border router is used in the routing decision.
From the topology database, each router constructs a tree of the shortest paths with itself as the root. This shortest-path tree gives the route to each destination in the AS. Externally derived routing information appears on the tree as leaves. The link-state advertisement format distinguishes between information acquired from external sources and information acquired from internal routers, so there is no ambiguity about the source or reliability of routes. Externally derived routing information (for example, routes learned from EGP or BGP) is passed transparently through the autonomous system and is kept separate from OSPF's internally derived data. Each external route can also be tagged by the advertising router, enabling a passing of additional information between routers on the borders of the autonomous system.
File Transfer Protocol (FTP) allows hosts to transfer files. FTP provides for such tasks as listing remote directories, changing the current remote directory, creating and removing remote directories, and transferring multiple files in a single request. FTP maintains a secure transport by passing user and account passwords to the foreign host. FTP allows interactive user-oriented sessions.
FTP uses reliable stream transport (TCP/IP) to send the files and uses a TELNET-like connection to transfer commands and replies. FTP also understands several basic file formats, including ASCII, IMAGE, and Local 8. TCP/IP implements FTP in the ftp user command and the ftpd server command.
The Network File System (NFS) provides access to files via standard UNIX system calls. This allows any program to access files across the network. NFS uses the UDP transport layer; therefore, it has to deal with lost datagrams. NFS does this by retransmitting requests if a reply has not been received within a reasonable amount of time. Some requests can be re-executed on the server without problems, but others (such as file deletion) cause an error if the first request reaches the server but the reply is lost. If the second request is executed, the server finds that the file does not exist and returns an error. NFS servers hold on to such replies and retransmit them if they see a duplicate request.
On the other hand, the protocol is designed so that the servers need no other state information. This allows server performance to be improved by running multiple copies of the server daemon, and also means that server crashes are tolerated with no special code on either client or server.
For more information on NFS, see Chapter 4.
Digital UNIX Version 4.0 contains Digital's first release of NFS support over the TCP transport. Previously, only the UDP transport was available. UDP may still be the preferred transport in local area networks, but for NFS access over wide area, congested, or lossy networks, TCP may offer better performance.
Separate threads are used to maintain some of the performance optimizations made to the UDP code paths. The nfsiod daemon has been changed to spawn kernel threads, instead of forking multiple processes as it did previously. Each nfsiod thread can handle UDP or TCP mounts, so the nfsiod command still accepts one argument.
For more information on NFS, see Chapter 4.
The Telnet Protocol (TELNET) provides a standard method for terminal devices and terminal-oriented processes to interface. TELNET is commonly used by terminal emulation programs that allow you to log in to a remote host. However, TELNET can also be used for terminal-to-terminal communications and interprocess communications. TELNET is also used by other protocols (for example, FTP) for establishing a protocol control channel.
TCP/IP implements TELNET in the telnet user command and the telnetd server command.
The Trivial File Transfer Protocol (TFTP) can read and write files to and from a foreign host. Like FTP, TFTP can transfer files as either 8-bit NETASCII characters or as 8-bit binary data. Unlike FTP, TFTP cannot be used to list or change directories at a foreign host and it has no provisions for security, such as password protection. Data normally can be written or retrieved only in public directories.
TCP/IP implements TFTP in the tftp user command and in the tftpd server command.
The Finger Protocol (FINGER) is an application-level Internet protocol that provides an interface between the finger command and the fingerd daemon. The fingerd daemon returns information about the users currently logged in to a specified remote host. If you execute the finger command specifying a user at a particular host, you obtain specific information about that user. The Finger Protocol must be present at the remote host and at the requesting host. FINGER uses TCP as its underlying protocol.
The Simple Mail Transfer Protocol (SMTP) is the standard for mail exchange between machines attached to the Internet. It specifies the format of control messages sent between two machines to exchange electronic mail.
As its name implies, SMTP is simple in design and purpose. Its objective is to provide a reliable and efficient mail delivery system across the links between machines. SMTP does not specify the mail interface.
The Simple Network Management Protocol (SNMP) is the Internet standard protocol for exchanging network management information. The SNMP agent provides a local or remote network manager with system information, network interface data, address resolution information (ARP), information about the routing layer (IP and ICMP), and information about the transport layer (TCP and UDP). Digital UNIX SNMP agent also permits management of basic host information, such as processes, file systems, memory, attached devices, and so forth.
The TCP/IP transport-level protocols (UDP and TCP) allow application programs to communicate with other application programs. The User Datagram Protocol (UDP) and the Transmission Control Protocol (TCP) are the basic transport-level protocols for making connections between Internet hosts. When an application sends a message to the transport layer, UDP and TCP break the information into packets, add a packet header including the destination address, and send the information to the network layer for further processing.
Other protocols and applications use UDP to make datagram connections and TCP to make stream connections. The socket interface implements these protocols.
UDP provides a datagram means of communication between applications on Internet hosts. UDP uses destination protocol ports (abstract destination points within a machine), identified by positive integers, to send messages to one of multiple destinations on a host. The protocol ports receive and hold messages in queues until applications on the receiving host can retrieve them.
UDP relies on the underlying IP to send its datagrams and provides the same connectionless message delivery as IP. It offers no assurance of datagram delivery or duplication protection. However, UDP allows the sender to specify source and destination port numbers for the message and also calculates a checksum of both the data and header. These two features allow the sending and receiving applications to ensure the correct delivery of a message.
TCP provides reliable stream delivery of data between Internet hosts. Like UDP, TCP uses IP, the underlying protocol, to transport datagrams, and supports the block transmission of a continuous stream of datagrams between process ports. Unlike UDP, TCP provides reliable message delivery and ensures that data is not damaged, lost, duplicated, or delivered out of order to a receiving process. Because of this transport reliability, applications programmers are not required to build communications safeguards into their software.
Both TCP and UDP allow programs to send messages to and receive messages from applications on other hosts, and both use protocol ports on the host to identify the specific destination of the message. The TCP retransmission time-out value is dynamically determined for each connection, based on round-trip time.
TCP has the following operational characteristics:
TCP transfers a continuous stream of 8-bit octets in each direction between its users by packaging some number of bytes into segments for transmission through the Internet system. In general, TCP determines the best time to block and forward packets.
TCP recovers data that is damaged, lost, duplicated, or delivered out of order by the Internet. To achieve this reliability, TCP assigns a sequence number to each octet it transmits, and requires a positive acknowledgment (ACK) from the receiving TCP. If the ACK is not received within the time-out interval, the data is retransmitted. At the receiver, the sequence numbers are used to correctly order segments that are received out of order and to eliminate duplicates. To detect damage, TCP adds a checksum to each segment transmitted, checks it at the receiver, and discards damaged segments.
To control how much data is sent, TCP returns the following information with every acknowledgment:
Many processes within a single host can use TCP communications facilities simultaneously. TCP maintains a set of addresses (ports) within each host. TCP combines the port number with the network address and the host address to uniquely identify each connection endpoint (socket). A pair of sockets uniquely identifies each connection.
TCP must initialize and maintain certain status information for each data stream. The combination of this information, including sockets, sequence numbers, and window sizes, is called a connection. Each connection is unique.
The Internet network-level protocols (IP, ARP, ICMP) handle machine-to-machine communications. These protocols provide for transmission and reception of transport requests, and handle network-level control.
The Internet Protocol (IP) is the primary network-level protocol and provides unreliable, connectionless packet delivery for the Internet. IP defines the format of all the data sent over the Internet. IP also specifies packet processing and error handling.
IP is connectionless because it treats each packet independently. It is unreliable because it does not guarantee delivery or the order of arrival of packets. However, underlying mechanisms guarantee data integrity, assuming it arrives.
IP provides the interface to the network interface level protocols. The physical connections of a network transfer information in a frame with a header and data. IP uses an Internet datagram, which contains a source host address, along with sequencing and control information.
IP automatically adds an IP header to outgoing packets and removes the IP header from incoming packets before sending them to higher level protocols. IP provides for the universal addressing of hosts in the Internet network.
IP is not a reliable communications facility because it does not require acknowledgments from the sending host, the receiving host, or intermediate hosts.
The total length of IP packets can be configured independently for each interface. Packets are broken up into smaller chunks at gateways and reassembled when they reach their destination.
Digital UNIX Version 4.0 supports IP Multicasting on a Local Area Network (LAN), as described in RFC 1112. Digital UNIX Version 4.0 also supports Version 3.5 of the IP Multicast Kernel support and Version 3.6 of the mrouted implementation of the Distance Vector Multicast Routing Protocol (DVMRP) which provides support for "tunnelling" and "pruning."
Unlike IP Broadcasting, IP Multicasting allows packets to be taken off the network only by those clients who have configured their systems to receive the packets. Packets are accepted or rejected at the hardware level, thereby greatly reducing processing overhead. In addition, IP Multicasting does not consume a lot of network bandwidth, since applications do not have to send separate packets with identical data to reach several destinations, as they do with point-to-point connections. With IP Multicasting, one packet is sent to all interested hosts.
As a result, IP Multicasting is very valuable to video conferencing applications and applications that provide constant updates to ever-changing information, like applications that provide stock market quotes.
The IP Multicasting code was taken from the public domain, integrated with DECnet and LAT, and is supported on all Ethernet and FDDI adapters.
Digital UNIX Version 4.0 has complete IP support for a serial line, so that users can transfer files or NFS-mount file systems across phone lines. Using the CSLIP slattach option, headers can be compressed, thereby increasing performance.
The SLIP/CSLIP code is from OSF Version 1.0. However, since the OSF code did not provide a way to access the CSLIP feature, Digital modified the slattach command to provide the necessary access to CSLIP.
Digital UNIX Version 4.0 supports the Point-to-Point (PPP) protocol (as defined in RFC 1144, 1171, 1172, 1331, 1332, 1334, 1548, 1549, 1661, and 1662) which provides a method for transmitting datagrams over serial point to point links. Unlike SLIP, PPP supports standard encapsulation, simultaneous multiplexing of different network layer protocols, an HDLC Frame Check Sequence for error detection, an HDLC escaping mechanism for use with miscellaneous non-8-bit-transparent telephone and switching equipment, and the dynamic negotiation of IP addresses.
In addition, while SLIP only supports clist tty drivers, PPP supports both clist and STREAMS-based tty drivers, as well as remote logins over LANs.
Note that the PPP code was taken from the public domain and includes contributions identified by the footnoted copyright notices [Footnote 1]. Certain sections of the PPP code was derived from the RSA Data Security, Inc., MD5 Message-Digest Algorithm.
For more information on PPP, see the System Administration guide and the pppd(8), pppstats(8), and chat(8) reference pages.
The Address Resolution Protocol (ARP) translates Internet addresses into hardware addresses. ARP does not translate addresses for the Serial Line Interface Protocol (SLIP) or Point-to-Point Protocol (PPP) because SLIP and PPP have no hardware address.
ARP dynamically traces Internet addresses to hardware addresses on local area networks. The result of this tracing is called a map. The mapped information is stored in mapping tables. TCP/IP uses ARP to collect and distribute the information for mapping tables.
The kernel maintains the mapping tables, and ARP is not directly available to users or applications. When an application sends an Internet packet to an interface driver, the driver requests the appropriate address mapping. If the mapping is not in the table, an ARP broadcast packet is sent through the requesting interface driver to the hosts on the local area network.
When a host that supports ARP receives an ARP request packet, the host notes the IP and hardware addresses of the requesting system and updates its mapping table, if necessary. If the receiving host's IP address does not match the requested address, the host ignores the request packet. If the IP address does match, the receiving host sends a reply packet to the requesting system. The requesting system stores the new mapping and uses it to transmit future Internet packets.
Unlike most protocols, ARP packets do not have fixed-format headers. Instead, the message is designed to be useful with a variety of network technologies.
The Internet Control Message Protocol (ICMP) is a required part of every IP implementation. ICMP handles error and control messages for IP.
ICMP does the following:
ICMP provides feedback about problems in the communications environment, but does not make IP reliable. That is, ICMP does not guarantee that an IP packet will be delivered reliably or that an ICMP message will be returned to the source host when an IP packet is not delivered or is incorrectly delivered.
ICMP messages are sent in varying situations, including the following:
Digital UNIX Version 4.0 supports interfacing to the following networks:
Digital UNIX Version 4.0 supports PCI and TURBOchannel machines on 155.5 MB per second Asynchronous Transfer Mode (ATM) networks. ATM is a high-speed, connection-based, cell-switched network that--unlike traditional packet switched networks--can carry different kinds of traffic (voice, video, and data) simultaneously. In addition, ATM provides predictable services to those classes of traffic that require bounded latencies and dedicated bandwidths, and--because ATM separates the physical interface from the datalink layer--the same cell and packet formats can be used over a wide variety of physical interfaces from 1 MB per second to 10 GB per second.
Digital UNIX Version 4.0's implementation of ATM consists of permanent virtual circuit support; switched virtual circuit support through ATM Forum UNI 3.0 and 3.1 signalling for point-to-point connections; Classic IP (as defined by RFC 1577, RFC 1483, and RFC 1626) for a single Logical IP Subnet (LIS); and ATM Forum Interim Local Management Interface (ILMI) for dynamic network address registration. For more information on ATM, see the Network Programmer's Guide.
Digital UNIX Version 4.0 supports 10 MB per second Ethernet networks on all Alpha platforms.
At the physical and IP levels, Digital UNIX Version 4.0 supports an Ethernet network with a Maximum Transfer Unit (MTU) of 1500 bytes at a maximum of 10 MB per second.
In conformance with Ethernet standards, Digital UNIX Version 4.0 always ensures a minimum packet size of 60 bytes.
The default MTU at the IP level is 1500 bytes at a maximum of 10 MB per second, although this value can be decreased using the ifconfig command.
Digital UNIX Version 4.0 supports 100 MB per second Fast Ethernet (IEEE 802.3 100Base-TX) networks on all PCI-based Alpha hardware platforms.
MTU sizes at the physical and IP levels are the same as those for regular 10 MB per second Ethernet.
Digital UNIX Version 4.0 supports 100 MB per second FDDI networks in conformance with RFC 1042 and RFC 1188 on all Alpha hardware platforms.
At the physical level, Digital UNIX Version 4.0 supports an FDDI network with a Maximum Transfer Unit (MTU) of 4500 bytes at a maximum of 100 MB per second. At the IP level, the MTU is 4352 bytes at a maximum of 100 MB per second.
The default MTU at the IP level is always 4352 bytes at a maximum of 100 MB per second, although this value can be decreased using the ifconfig command.
Digital UNIX Version 4.0 supports 4 MB per second and 16 MB per second Token Ring networks and source routing in conformance with RFC 1042 on TURBOchannel, ISA, EISA, and PCI-based Alpha hardware platforms.
Support for Token Ring networks extends networking support to the PC community, since most PC networks are Token Ring and most PCs do not have Ethernet or FDDI adapters.
At the physical level, Digital UNIX Version 4.0 supports a Token Ring network with a Maximum Transfer Unit (MTU) of 4472 bytes at a maximum of 4 MB per second and 17800 bytes at a maximum of 16 MB per second. At the IP level, the MTU is 4092 bytes at a maximum of 4 MB per second and 8188 bytes at a maximum of 16 MB per second.
The default MTU at the IP level is always 4092 for both 4 and 16 MB per second, although this value can be increased or decreased using the ifconfig command.
The network programming environment includes the programming interfaces for application, kernel, and driver developers writing network applications and implementing network protocols. Additionally, it includes the kernel level resources that an application requires to process and transmit data, some of which include libraries, data structures, header files, and transport protocols.
This section briefly discusses the following application programming interfaces that are supported in Digital UNIX Version 4.0:
For more detailed information on the network programming environment, see the Network Programmer's Guide.
The X/Open Transport Interface (XTI) defines a transport layer application interface that is independent of any transport provider. This means that programs written to XTI can be run over a variety of transport providers, such as the Transmission Control Protocol (TCP) or the User Datagram Protocol (UDP). The application specifies which transport provider to use.
Because XTI provides an interface that is independent of a transport provider, application developers are encouraged to write programs to XTI instead of STREAMS or sockets. Figure 3-2 illustrates the interaction between XTI and the STREAMS and sockets frameworks.
Depending on the transport provider specified by the application, data can flow along one of two paths:
Sockets are the industry standard programming interface. Digital UNIX Version 4.0 implements the socket interface for both 4.3BSD and X/Open CAE Specification, Networking Services, Issue 4 interfaces. Using the _SOCKADDR_LEN option to the connect system call, however, you can access the 4.4BSD interface. For more information, see the connect(2) reference page.
The sockets framework consists of a series of system and library calls, header files, and data structures. Applications can access kernel-resident networking protocols, such as the Internet Protocol suite, through socket system calls. Applications can also use socket library calls to manipulate network information, for example, mapping service names to service numbers or translating the byte order of incoming data to that appropriate for the local system's architecture. The Internet Protocol suite, for example, which consists of TCP, UDP, IP, ARP, ICMP, and SLIP is implemented over sockets.
With sockets, the application in user space passes data to the appropriate socket system calls, which then pass it to the network layer. Finally, the network layer passes it, via the ifnet layer, to the BSD driver, which puts it on to the network. For more information, on sockets, see RFC 1200: IAB Protocol Standards, the Network Programmer's Guide, and the X/Open CAE Specification, Networking Services, Issue 4.
The STREAMS framework provides an alternative to sockets. The STREAMS interface was developed by AT&T and consists of system calls, kernel routines, and kernel utilities that are used to implement everything from networking protocol suites to device drivers. Applications in user space access the kernel portions of the STREAMS framework using system calls such as open, close, putmsg, getmsg and ioctl. Digital UNIX Version 4.0 supports System V Release 4.0 STREAMS from the OSF Version 1.2 code base, which provides support for the STREAMS tty interface (although Digital UNIX Version 4.0 continues to support the existing CLIST or Berkeley-based tty interface ). For more information on STREAMS, see the Network Programmer's Guide.
Digital UNIX Version 4.0 provides the ifnet STREAMS module to allow programs using Digital UNIX Version 4.0's BSD-based TCP/IP to access STREAMS-based drivers. It provides the Data Link Bridge (DLB) pseudodriver to allow programs using a STREAMS-based protocol stack to access BSD-based drivers provided on Digital UNIX Version 4.0.
DLI is provided on Digital UNIX Version 4.0 as a backward compatibility feature to ULTRIX. DLI support on Digital UNIX Version 4.0 allows programs written to DLI on the ULTRIX operating system to access the data link layer. For more information on DLI, see the Network Programmer's Guide.
DLPI is a kernel level interface that maps to the data link layer of the OSI reference model. DLPI frees its users from specific knowledge of the characteristics of the data link provider, allowing those characteristics to be implemented independently of a specific communications medium. It is primarily a kernel-level interface targeted for STREAMS protocol modules that either use or provide data link services.
Only a partial subset of the DLPI interface is supported in Digital UNIX Version 4.0. For more information, see the Network Programmer's Guide.
Digital UNIX supports extensible SNMP (eSNMP), an application-layer Application Programming Interface (API) that permits user-written programs to function as part of a distributed SNMP agent on a Digital UNIX host system.
User programs can dynamically register SNMP MIB objects with the eSNMP master agent (/usr/sbin/snmpd), and subsequently handle the SNMP protocol operations for those objects.
The distribution of MIB objects between cooperating processes is transparent to SNMP applications, which can access all MIB objects using the standard transport endpoints specified in the SNMP RFCs.
For more information, see the Network Programmer's Guide.
Digital UNIX Version 4.0 supports a variety of network administration software which is briefly described in the following sections.
Digital UNIX Version 4.0 supports the entire suite of networking commands from OSF Version 1.2, including: gated, finger, ftp, rdump, rdist, routed and the complete suite of remote commands, snmp, smtp, telnet, and tftp. The bootpd command has been folded into the Digital-specific joind command which provides configurations to clients using either the DHCP or BOOTP protocol. Additionally, Digital UNIX Version 4.0 supports the following Open Network Computing (ONC) Version 4.2 utility programs, which can be invoked by the inetd:
The Ethernet packet filter is a software driver interface that provides demultiplexing of networking packet headers, as well as reception and transmission of packets containing user-defined network protocols. The packet filter can also function as an Ethernet monitor when used to filter specific network protocols.
Digital UNIX Version 4.0 supports the following packet filter applications:
The reverse ARP daemon responds to RARP requests on a network by sending an IP address to a host which only knows its Ethernet address. It uses the /etc/ethers file to map the Ethernet address to an IP address.
The reverse ARP daemon can serve IP addresses to remote PC clients. Also, some customers are using ULTRIX on DECstations today and rely on the Reverse ARP protocol to supply remote stations with their IP address. If they want to serve these addresses using a Digital UNIX Version 4.0 server, they can do so with the rarpd daemon.
Digital UNIX Version 4.0 supports Version 2.2.1 of the tcpdump utility. This version of tcpdump uses the Berkeley Packet Filter (BPF) language.
The tcpdump utility is used to debug and analyze TCP/IP network activity, on both Ethernet and FDDI networks, and has some support for other protocol suites (including NFS). This product includes software developed by the University of California, Lawrence Berkeley Laboratory and its contributors.
The tcpslice utility manipulates tcpdump trace log files by either extracting pieces of or glueing together tcpdump log files. It can select portions of a large tcpdump log file and display selected traces without having to dump the entire log file.
Digital UNIX Version 4.0 supports Version 4.1 of nfswatch from Purdue University. The nfswatch utility is curses-based and displays the NFS traffic between any number of NFS servers and clients on a LAN.
The nfslogsum utility condenses the log files produced by nfswatch into a traffic analysis summary and is very helpful in troubleshooting networks.
Note
Since the packet filter is an optional kernel subsystem, application programs that make calls to the packet filter kernel routines may fail if the packet filter is not configured in the currently running kernel. For more information, see the packetfilter(7) reference page.
Digital UNIX Version 4.0 supports the Dynamic Host Configuration Protocol (DHCP), a client/server framework in which the DHCP server can dynamically assign an IP address to a client as the client boots onto the network. Additionally, a DHCP server can provide configuration information to the client, such as the name of the BIND server or the name of the default router for that client.
For example, when a new system is booted for the first time, the DHCP server assigns that system a unique IP address; if that system is moved to another location on the same LAN (perhaps on a different subnet), the DHCP server ensures that a new IP address appropriate to that subnet is assigned to the system, if necessary, when it boots up for the first time.
As a result, with DHCP, customers with hundreds of clients no longer have to worry about the assignment of IP addresses; DHCP assigns IP addresses automatically and requires no intervention by a system administrator.
For more information on DHCP, see the Network Administration and the dhcp(7) reference page.
The bootpd daemon implements an Internet Boot Protocol server as defined in RFC 951, RFC 1532, and RFC 1533.
BOOTP is an extensible UDP/IP-based protocol that allows a booting host to configure itself dynamically without having to rely on user intervention. The BOOTP protocol assigns IP addresses to hosts, makes available a file containing a boot program that can be downloaded from a server, provides the address of that server, and if present the address of an Internet gateway.
Like DHCP, the BOOTP protocol supports the centralized management of network addresses.
The extensible SNMP agent in Digital UNIX Version 4.0 permits the dynamic addition of supported Management Information Bases (MIBs) on any Digital UNIX host. The MIB support that ships as part of the operating system allows management operations on the objects described in the following RFCs:
The master agent, API, and base operating system MIB support are all contained in the standard networking subset (CLINET).
The extensible SNMP development tools are contained in the optional programming subset (PGMR).
The gated daemon allows any host with multiple network interfaces to function as an IP router by participating in various IP routing protocols (for example, RIP, OSPF, EGP, and BGP). Digital UNIX Version 4.0 supports the GateD Release 3.5 gated daemon from the Gatedaemon Project at Cornell University, which contains support for the following:
Stipulates the proper subsuming of host routes, split horizon without poison reverse, and graceful shutdowns.
Stipulates using IP Multicast where available; supports classless routing; uses next hop (if different).
Uses local-wire IP Multicast support, MIB support (RFC 1253), and reconfiguration.
A complete implementation of the specification, with optimizations for MILNET.
Complete implementations of specifications; BGP MIB (RFC 1269); AS path pattern matching RFC 1164); and OSPF/BGP Interaction (RFC 1403).
Proper subsuming of host routes; split horizon without poison reverse.
Based on BSD 4.3 Reno radix tree, gated implements filtered routing based on policy. This allows network administrators to control the import and export of routing information by individual protocol, by source and destination autonomous system, source and destination interface, previous hop router, and specific destination address.
Network administrators can also specify a preference level for each combination of routing information being imported by using a flexible masking capability. Once the preference levels are assigned, gated decides which route to use independent of the protocols involved.
For more information on gated, see the gated(8) and gated.conf(8) reference pages. Also, for a complete description of the gated.conf options, see the EGate Daemon Configuration Guide, which is accessible from the Digital UNIX Documentation Library page on the Digital UNIX Documentation CD-ROM.
The screend daemon is used in conjunction with the gateway screen facility to decide which IP packets should be forwarded when the system is acting as an IP gateway.
The gateway packet screening facility, on a Digital UNIX system acting as a gateway, allows the system manager to control which packets are forwarded or rejected. As a result, the gateway packet screening facility can be used as one part of a comprehensive network security policy. The facility consists of a kernel-resident mechanism and a user-level daemon, /usr/sbin/screend. When a packet is ready to be forwarded, the kernel mechanism submits the packet's headers to the daemon. The screend daemon then examines the headers and tells the kernel to forward or reject the packet, based on a set of rules defined in the configuration file, /etc/screend.conf. Optionally, some or all decisions can be logged allowing the network manager to detect improper configurations or potential security problems.
The UNIX-to-UNIX Copy Program (UUCP) program is actually a group of programs that supports communications between two computers running UNIX operating systems.
DEC OSF/1 supports the HoneyDanBer version of UUCP. The UUCP system enables batched, error-free file transfer and remote command execution between two UNIX systems. The UUCP system is most frequently used to transfer electronic mail, network news, and public domain software over low-speed, low-cost communications links.
A worldwide network that functions through the informal cooperation of the user community has grown up around UUCP. The UUCP network is a series of point-to-point links, with the majority of sites located in Europe and North America.
The UUCP protocol supports only direct connections between two systems. However, electronic news and mail delivery depend on third-party forwarding. To facilitate mail and news delivery, most connected sites are willing to relay files for other sites. The UUCP network depends on direct distance dialing networks and off-peak long distance rates for its continued functioning. For more information on UUCP, see uucp_setup(8).
Local Area Transport (LAT) is a Digital protocol that supports communications between host computer systems and terminal servers with terminals, PCs, printers, modems and other devices over local area networks (LANs). LAT software has the features required for a host to function as a service node, so requests for connections can be made by server users. The software also permits host applications to initiate connections to server ports, designated as application ports, to access remote devices. In Digital UNIX, the LAT driver is STREAMS-based and supports up to 4000 incoming connections, with a theoretical limit of 5000 users.
Note
In Digital UNIX, LAT supports both SVR4 and BSD-style tty devices. Integral serial tty devices and serial tty options share the same BSD tty namespace as LAT, which means that if users allocate special files for serial lines, those special files will reduce the number of BSD LAT devices that can be configured.
For more information on LAT, see the lat_intro(7) reference page and the System Administration guide .
Digital UNIX Version 4.0 supports the following distributed naming services:
The library routines in /usr/lib/libc.a allow transparent access to BIND, NIS, and local /etc files. The name services configuration file, /etc/svc.conf, dictates which naming services are queried, and in what order, for a particular database.
The Digital UNIX Version 4.0 software allows you to convert from an NIS-distributed environment to a BIND-distributed environment, or to run both services in the same environment. Because the source files for both BIND and NIS can be /etc- style files, a distributed Berkeley Software Distribution (BSD) source area can be shared between the two services by means of symbolic links.
The Berkeley Internet Name Domain (BIND) service is a host name and address lookup service for the Internet network. The BIND service is based on the client-server model. It allows client systems to obtain host names and addresses from BIND servers. Digital UNIX Version 4.0 only supports the hosts database.
Note
Depending on which naming services your LAN is running, the hosts file can be located in /etc, /var/yp/src, or /etc/namedb/src.
You can use the BIND service to replace or supplement the host table mapping provided by the local /etc/hosts file or NIS.
Digital UNIX Version 4.0 supports BIND 4.9.3.
The Network Information Service (NIS) is a distributed name service that allows participating hosts to share access to a common set of system and network files. NIS allows the system administrator to manage these shared files on a single system.
NIS is intended for use in a secure environment only, where gateways do not allow outside access from the Internet to the NIS protocol.
Digital UNIX Version 4.0 supports the following time services:
Because it can be traced to clocks of high absolute accuracy, NTP provides a more accurate time service than TSP. By contrast, TSP synchronizes time to the average of the network host times. TSP is an acceptable time service if your system is not on the Internet and does not have access to a highly accurate time server; otherwise, NTP is recommended.
The Network Time Protocol (NTP) provides accurate, dependable, and synchronized time for hosts on both wide area networks (like the Internet) and local area networks. In particular, NTP provides synchronization traceable to clocks of high absolute accuracy, and avoids synchronization to clocks keeping bad time.
Digital UNIX Version 4.0 supports NTP Version 3, based on RFC 1305, which contains the following enhancements to Version 2:
Hosts running NTP periodically exchange datagrams querying each other about their current estimate of the time. Using the round-trip time of the packet, a host can estimate the one-way delay to the other. (The assumption is that the delay is roughly equal in both directions.) By measuring the one-way delay and examining the timestamps that are returned with the NTP packet, a host computes the difference between its clock time and that of the host it queried.
A host queries a remote host several times over a period and feeds the results from the multiple samples to a digital-filtering algorithm. The algorithm provides a more accurate estimate of the delay, clock offset, and clock stability than could be obtained with a single sample.
NTP messages also contain information about the accuracy and reliability of the time sources. An NTP host connected directly to a highly accurate time source, such as a radio receiver tuned to a time code signal broadcast by a government agency, is called a stratum 1 server. Every other NTP host adopts a stratum number that is one higher than the host from which it sets its own time. For example, a host synchronized to a stratum 1 server becomes a stratum 2 host. Stratum determination is done automatically, and the stratum of a host can vary as its connectivity changes.
A host running NTP combines various information to decide which of the hosts it queried provides the time it believes to be the most accurate. This information includes the output of the digital-filtering algorithm and the stratum numbers of the hosts it queried. By communicating with several other hosts, an NTP host can usually detect those hosts that are keeping bad time, and is able to stay synchronized even if some of the other hosts become unavailable for long periods.
In practice, NTP is able to synchronize clocks to within a few tens of milliseconds even over wide area networks spanning thousands of miles.
For detailed information on NTP, see RFC 1305: Internet Time Synchronization: the Network Time Protocol.
The Time Synchronization Protocol (TSP) is the protocol used by the /usr/sbin/timed daemon. In its simplest application, the TSP servers on a broadcast network (for example, an Ethernet) periodically broadcast TSP packets. The hosts on the network elect one of the hosts on the network running TSP as a master. The master then controls the further operation of the protocol until it fails and a new master is elected. The master collects time values from the other hosts and computes the average of all the times reported. It then sets its own clock to this average, and tells the other hosts to synchronize their clocks with it.
TSP quickly synchronizes all participating hosts. However, because TSP does not trace time back to sources of known accuracy, it is unable to correct for systematic errors. If a clock drifts significantly, or if a mistake is made in setting the time on a participating host, the average time calculated and distributed by the master can be affected significantly.