3    Networking

This chapter describes the components of Tru64 UNIX that enable a wide variety of networking capabilities. The first section provides a brief networking overview (Section 3.1), after which the following topics are discussed:

3.1    Overview

The networking components of Tru64 UNIX come primarily from OSF/1 Version 1.0. Certain modules, such as System V Release 4.0 STREAMS which was unavailable in OSF/1 Version 1.0, were taken from the OSF/1 Version 1.2 code base. Other functions, such as IP Multicasting and the packet filter applications, were 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 Microsystems' Open Network Computing (ONC) Version 4.2.

Functions that Compaq has licensed and enhanced, such as Yellow Pages and the Network Information Service, licensed from Sun Microsystems, were ported to Tru64 UNIX from ULTRIX, Compaq's earlier version of the UNIX operating system. Although conforming to the OSF/1 Version 1.2 standards, these components were determined to be more robust than those in the corresponding code from the OSF.

Like all subsystems in the operating system, the networking subsystem is designed to provide a standardized programming interface to enable third-party vendors to develop and port their networking applications with a minimum of difficulty. To this end, Tru64 UNIX supports the following:

3.2    The Internet Protocol Suite

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.

Figure 3-1:  TCP/IP Protocols

Applications programs send messages (streams or blocks of data) to transport protocols -- UDP and 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 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 to the application layer.

3.2.1    Application-Layer Protocols

When an application needs to send data to an application on another host, the application sends the information through transport layer protocols to prepare the information for transmission. These protocols include DNS, EGP, BGP, RIP, OSPF, FTP, NFS, TELNET, TFTP, FINGER, SMTP, and SNMP.

3.2.1.1    Domain Name Service Protocol

The Domain Name Service (DNS) allows one or more hosts in a domain to act as a name server for other hosts within the domain. DNS 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 DNS; however, if the UDP response is truncated, TCP can be used.

In the Tru64 UNIX environment, the Berkeley Internet Name Domain (BIND) naming service uses the Domain Name Service 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 DNS name server.

3.2.1.2    Routing Protocols

Routing Protocols allow systems on either internal or external LANs to share routing information. In addition to the Exterior Gateway Protocol (EGP), Tru64 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 v3.5A11 routing daemon from the Merit GateD Consortium. (For more information on gated, see Section 3.5.6). See the Tru64 UNIX Software Product Description for a list of supported routing protocols.

Exterior Gateway Protocol (EGP)

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.

Border Gateway Protocol

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 operates with more capability, greater flexibility, and less required bandwidth than EGP. 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 Tru64 UNIX implementation of BGP supports three versions of the BGP protocol (versions 2, 3, and 4). BGP Versions 2 and 3 are similar in capability and function. They will propagate only classed network routes, and the AS path is a simple array of AS numbers. BGP Version 4 will propagate fully general address-and-mask routes, and the AS path has some structure to represent the results of aggregating dissimilar routes.

Routing Information Protocol (RIP)

The Routing Information Protocol (RIP) is an implementation of a distance-vector or Bellman-Ford routing protocol for local networks. In Tru64 UNIX it is contained in the gated daemon from the Merit GateD Consortium. 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. 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 Ethernet connections 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 First

Open Shortest Path First (OSPF) routing protocol is a shortest path first 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 simultaneously by more than one network interface.

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 paths have destinations within the same area and inter-area paths have 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.

3.2.1.3    File Transfer Protocol

File Transfer Protocol (FTP) allows hosts to transfer files, and provides 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 daemon.

3.2.1.4    Network File System Protocol over UDP transport

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 handle 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 reexecuted 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 Section 4.5.

3.2.1.5    Network File System Protocol over TCP transport

Tru64 UNIX contains NFS support over the TCP transport. UDP may still be the preferred transport in local area networks, but for NFS access over wide area, congested, or lossy networks, TCP may perform better.

Separate threads are used to maintain performance optimizations made to the UDP code paths. The nfsiod daemon spawns kernel threads, instead of forking multiple processes. Each nfsiod thread can handle UDP or TCP mounts, so the nfsiod command accepts one argument.

For more information on NFS, see Section 4.5.

3.2.1.6    Telnet Protocol

The Telnet Protocol (TELNET) provides a standard method for terminal devices and terminal-oriented processes to communicate. 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.

TCP/IP implements TELNET in the telnet user command and the telnetd daemon.

3.2.1.7    Trivial File Transfer Protocol

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 usually can be written or retrieved only in public directories.

TCP/IP implements TFTP in the tftp user command and in the tftpd daemon.

3.2.1.8    Finger Protocol

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.

3.2.1.9    Simple Mail Transfer 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 user interface.

3.2.1.10    Simple Network Management Protocol

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 information by accessing Management Information Bases (MIBs). The snmpd(8) reference page discusses the configuration, security, cluster support, and supported RFCs for the SNMP agent.

Tru64 UNIX supports both industry standard (IETF RFCs) and Compaq enterprise-specific MIBs. See Section 3.5.5 for more details. Compaq enterprise-specific MIB specifications are located in the /usr/share/sysman/mibs directory.

The daemons that provide MIB support are /usr/sbin/os_mibs, /usr/sbin/srvSystem_mib, /usr/sbin/svrMgt_mib, /usr/sbin/cpq_mibs, and /usr/sbin/clu_mibs.

Tru64 UNIX includes Compaq Insight Manager, which uses Web-based access to SNMP MIB data. Section 2.5.1 discusses Compaq Insight Manager.

See Section 3.4.7 for information about the extensible SNMP programming interface.

3.2.1.11    POP3

Tru64 UNIX supports Version 3 of the Post Office Protocol (POP3) as described in RFC 1939. POP3 is a client/server protocol from Qualcomm, Inc. that allows users to download their email from a mail server to a remote client. After messages are delivered to a server, the user connects to the server and downloads the messages to the client machine (a desktop or laptop computer running Windows, MacOS, UNIX, or another operating system). Thereafter, all message processing is local to the client machine and environment. This is the protocol used widely today by Internet Service Providers (ISP) to provide email services for their consumers. For more information, see the Network Administration guide.

3.2.1.12    IMAP4

Tru64 UNIX supports Version 4 of the Internet Message Access Protocol (IMAP4) as described in RFC 2060. IMAP4 is a client/server protocol, based on the Cyrus IMAP4 Revision 1 server from Carnegie Mellon University, that allows mail clients to access mail messages on a server. With it, a user can access his or her mail folders and manipulate the contents remotely without having to log in to the server. The protocol allows clients to create, delete, and rename mail folders, to check for new messages and remove old messages, and to retrieve messages selectively for local viewing. In addition, the user can select messages by attributes and parse messages in the RFC 822 and MIME formats. For more information, see the Network Administration guide.

3.2.1.13    Resource Reservation Protocol

The Resource Reservation Protocol (RSVP) is an Internet network layer defined in RFC 2205. It is one of the components in the management of network bandwidth, and provides a mechanism in which quality-of-service requests for specific application data streams or flows, simplex unicast or multicast, can be sent and received through a network. If accepted, these requests reserve a specific amount of network bandwidth for the flow.

Applications can use the RSVP API (RAPI) to request enhanced quality-of-service when the default best effort delivery is unacceptable; for example, for video and audio. The types of quality-of-service that applications may request are defined by Internet Integrated Services (RFC 1633 and RFC 2210).

RSVP on Tru64 UNIX supports FDDI and Ethernet interfaces and unicast and multicast data flows. For more information, see the Network Programmer's Guide.

3.2.2    Transport-Level Protocols

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.

3.2.2.1    User Datagram Protocol

The User Datagram Protocol (UDP) uses datagrams to communicate 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 Internet Protocol 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.

3.2.2.2    Transmission Control Protocol

The Transmission Control Protocol (TCP) provides reliable stream delivery of data between Internet hosts. Like UDP, TCP relies on the underlying Internet 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, application programmers are not required to build communication 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:

3.2.3    Internet Network-Level Protocols

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.

3.2.3.1    Internet Protocol

The Internet Protocol (IP) is the primary network-level protocol and 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.

IP Multicasting

The operating system supports IP Multicasting on a Local Area Network (LAN), as described in RFC 1112, and also supports Version 3.5 of the IP multicast kernel 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 much network bandwidth, because 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 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, and is supported on all Ethernet and FDDI adapters.

Serial Line IP and Compressed Serial Line IP

The operating system 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 to improve performance.

The SLIP/CSLIP code is from OSF/1 Version 1.0. However, because the OSF/1 code did not provide a way to access the CSLIP feature, Compaq modified the slattach command to provide the necessary access to CSLIP.

Point-to-Point Protocol

Tru64 UNIX 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 supports only 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 were 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.

3.2.3.2    Address Resolution Protocol

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 addresses.

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.

3.2.3.3    Internet Control Message Protocol

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:

3.3    Network Transports

Tru64 UNIX supports the following network transports:

3.3.1    Asynchronous Transfer Mode

Tru64 UNIX supports PCI and TURBOchannel machines on 155.5 Mb per second Asynchronous Transfer Mode (ATM) networks; there is also an adapter for the PCI bus that supports 622 Mb 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.

The Tru64 UNIX 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; ATM Forum Integrated Local Management Interface (ILMI) for dynamic network address registration; Classical IP (as defined by RFC 1577, RFC 1483, and RFC 1626); and LAN Emulation over ATM (as defined by The ATM Forum Version 1 standard). For more information on ATM, see Asynchronous Transfer Mode and Network Administration guides.

3.3.2    Ethernet Networks

Tru64 UNIX supports 10 MB per second Ethernet networks.

At the physical and IP levels, Tru64 UNIX supports an Ethernet network with a Maximum Transfer Unit (MTU) of 1500 bytes at a maximum of 10 MB per second.

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.

In conformance with Ethernet standards, Tru64 UNIX always ensures a minimum packet size of 60 bytes.

3.3.3    Fast Ethernet Networks

Tru64 UNIX supports 100 MB per second Fast Ethernet (IEEE 802.3 100Base-TX) networks.

MTU sizes at the physical and IP levels are the same as those for regular 10 MB per second Ethernet.

3.3.4    Gigabit Ethernet Networks

Tru64 UNIX supports 1000 MB per second Gigabit Ethernet (IEEE 802.3z 1000Base-T) networks on all PCI-based Alpha hardware platforms.

MTU sizes at the physical and IP levels are the same as those for regular Ethernet networks, although this value can be changed using the ifconfig command.

3.3.5    Fiber Distributed Data Interface Networks

Tru64 UNIX supports 100 MB per second Fiber Distributed Data Interface (FDDI) networks in conformance with RFC 1042 and RFC 1188 on all Alpha hardware platforms.

At the physical level, Tru64 UNIX 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 4,352 bytes at a maximum of 100 MB per second, although this value can be decreased using the ifconfig command.

3.3.6    Token Ring Networks

Tru64 UNIX supports 4 MB per second and 16 MB per second Token Ring networks and source routing in conformance with RFC 1042.

At the physical level, Tru64 UNIX 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.

3.3.7    Multiple Adapter Support

Tru64 UNIX provides support for a single system to have multiple active network adapters in the same subnet; for example, consider tu0 configured with IP address 192.24.156.20 and tu1 configured with IP address 192.24.156.21, both with the same netmask.

On connection establishment, the kernel chooses the interface that has the fewest number of connections. This connection-balancing effect could lead to greater throughput than on a system with just one network adapter per subnet. See the Network Administration guide for information on configuring multiple adapter support.

3.3.8    NetRAIN

Tru64 UNIX provides support for detecting the physical loss of network connectivity, and subsequent automatic switch over to a working network interface. This feature is called Redundant Array of Independent Network adapters (NetRAIN).

The NetRAIN virtual interface configures two or more interfaces on the same LAN segment into a single interface. One of the physical interfaces is always active while the others remain idle. All interfaces, including the idle interfaces, are constantly monitored to ensure that traffic can flow on each.

If the active interface fails or loses network connectivity, NetRAIN switches network traffic to the next available, working interface. All the context of the previous interface is maintained (for example, hardware address and multicast addresses). The actual failover time is adjustable depending on your network configuration and operation.

See the Network Administration manual, and the nr(7) and ifconfig(8) reference pages for information on NetRAIN configuration.

3.4    Application Programming Interfaces

The network programming environment includes the programming interfaces for application, kernel, and driver developers who write network applications and implement network protocols. It also 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.

The following sections briefly discuss the supported application programming interfaces:

For more information on the network programming environment, see the Network Programmer's Guide.

3.4.1    X/Open Transport Interface

The X/Open Transport Interface (XTI) defines a transport layer application interface that is independent of any transport provider. This means that applications 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.

Figure 3-2 illustrates the interaction between XTI and the STREAMS and sockets frameworks.

Figure 3-2:  Frameworks XTI, STREAMS and Sockets Interactions

Depending on the transport provider specified by the application, data can flow along one of two paths:

3.4.2    Sockets

Sockets are the industry standard programming interface. In Tru64 UNIX, sockets are the interface to the Internet Protocol suite; for example, TCP, UDP, IP, ARP, ICMP, and SLIP. Tru64 UNIX supports the 4.3BSD (the default), 4.4BSD, XNS5.0, XNS4.0, and POSIX 1003.1g Draft 6.6 interfaces.

The sockets framework consists of a series of system and library calls, header files, and data structures. Applications can access networking protocols through socket system calls and can use socket library calls to manipulate network information. For example, the getservent library call maps service names to service numbers and the htonl library call translates the byte order of incoming data to that appropriate for the local system's architectures.

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 the network.

For more information on sockets, see the Network Programmer's Guide, X/Open CAE Specification, Networking Services (XNS), Issue 5; X/Open CAE Specification, Networking Services, Issue 4 (XNS4.0); Protocol Independent Interfaces (POSIX 1003.1g Draft 6.6, Section 5); and the netintro(7) reference page.

3.4.3    STREAMS

The STREAMS framework provides an alternative to sockets. The STREAMS interface 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.

Tru64 UNIX supports System V Release 4.0 STREAMS from the OSF/1 Version 1.2 code base, which provides support for the STREAMS tty interface (although Tru64 UNIX continues to support the existing CLIST and Berkeley-based tty interface). For more information on STREAMS, see the Network Programmer's Guide.

3.4.4    Sockets and STREAMS Interaction

Tru64 UNIX provides the ifnet STREAMS module to allow programs using BSD-based TCP/IP to access STREAMS-based drivers. The module provides the Data Link Bridge (DLB) pseudodriver to allow programs using a STREAMS-based protocol stack to access BSD-based drivers.

3.4.5    Data Link Interface

The Data Link Interface (DLI) is provided as a backward compatibility feature to the ULTRIX operating system. DLI support 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.

3.4.6    Data Link Provider Interface

The Data Link Provider Interface (DLPI) is a kernel-level interface that maps to the data link layer of the OSI reference model. DLPI frees 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 modules that use or provide data link services.

Tru64 UNIX supports only a partial subset of the DLPI interface. For more information, see the Network Programmer's Guide.

3.4.7    Extensible SNMP Interface

Tru64 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 Tru64 UNIX host system.

User programs (subagents) can dynamically register SNMP MIB objects with the eSNMP master agent (/usr/sbin/snmpd), and can 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. The eSNMP API (libesnmp.so) uses RFC 2257 (AgentX) to communicate with snmpd. This backward compatible change permits subagents to interoperate with any RFC 2257 conforming SNMP agent.

The extensible SNMP development tools are contained in the optional programming subset (PMR). For more information, see the Network Programmer's Guide.

3.5    Network Administration Software

Tru64 UNIX supports a variety of network administration software, which is briefly described in the following sections.

3.5.1    Networking Commands and Utilities

Tru64 UNIX supports the entire suite of networking commands from OSF/1 Version 1.2, including finger, ftp, rdump, rdist, routed and gated, telnet, and tftp. The bootpd functions have been folded into the joind daemon, which provides configurations to clients using either the DHCP or BOOTP protocol.

Additionally, Tru64 UNIX supports the following Open Network Computing (ONC) Version 4.2 utility programs, which are invoked by the inetd daemon: rusers and rusersd, rwall and rwalld, spray and rsprayd, rup and rstatd, rquotad, and pcnfsd.

3.5.2    Ethernet Packet Filter and Packet Filter Applications

The Ethernet packet filter is a software driver interface that demultiplexes networking packet headers, as well as provides reception and transmission of packets containing user-defined network protocols. The packet filter can function also as an Ethernet monitor when used to filter specific network protocols.

Note

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.

Tru64 UNIX supports the following packet filter applications:

3.5.3    Dynamic Host Configuration Protocol

Tru64 UNIX supports the Dynamic Host Configuration Protocol (DHCP) based on JOIN Server Version 4.1 from JOIN Systems, Inc.; it is 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 DNS 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.

With DHCP, customers with hundreds of clients no longer have to worry about the assignment of IP addresses; DHCP automatically assigns IP addresses and requires no intervention by a system administrator.

Figure 3-3 illustrates an example configuration.

Figure 3-3:  Dynamic Host Configuration Protocol

For more information on DHCP, see the Network Administration guide and the dhcp(7) reference page.

3.5.4    The Internet Boot Protocol Daemon

The Internet boot protocol daemon, bootpd, implements an Internet boot protocol (BOOTP) 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 the address of an Internet gateway, if one is present.

Like DHCP, the BOOTP protocol supports the centralized management of network addresses.

The joind daemon provides the bootpd functions; the joind daemon also provides DHCP services.

3.5.5    SNMP Agent

The SNMP agent for Tru64 UNIX provides access to a great deal of management information typically used in network administration:

The extensible SNMP agent permits the dynamic addition of supported Management Information Bases (MIBs) on any Tru64 UNIX host.

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).

3.5.6    The gated Daemon

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). Tru64 UNIX supports the GateD Release 3.5 gated daemon from the Merit GateD Consortium, which contains support for the following:

For more information on the gated daemon, see the gated(8), gated.conf(4), gated.control(4), gated.proto(4), and gated_intro(7) reference pages.

3.5.7    The screend Daemon

The screend daemon is used 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 Tru64 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, therefy enabling the network manager to detect improper configurations or potential security problems.

3.5.8    UNIX-to-UNIX Copy Program

Tru64 UNIX supports the HoneyDanBer version of the UNIX-to-UNIX Copy Program (UUCP), which is a group of programs that supports communications between two computers running UNIX operating systems. The UUCP enables batched, error-free file transfer and remote command execution between two UNIX systems. The UUCP is most frequently used to transfer electronic mail, network news, and public domain software over low-speed, low-cost communications links.

The UUCP supports only direct connections between two systems; 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 the uucp_setup(8) reference page.

3.5.9    Local Area Transport

Local Area Transport (LAT) is a 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. The LAT driver is STREAMS-based and supports up to 4000 incoming connections, with a theoretical limit of 5000 users.

In Tru64 UNIX, LAT supports both SVR4 and BSD-style terminal devices. Integral serial terminal devices and serial terminal options share the same BSD tty namespace as LAT, which means that if special files are allocated 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.

3.5.10    Network Interface Monitoring

The niffconfig command arranges for one or more network interfaces to be monitored for possible loss of connectivity. Timing parameters that govern how quickly an interface can be declared suspect or dead can be manipulated with this command.

Once an interface has been specified for monitoring, the kernel Traffic Monitor Thread (TMT) checks the connectivity of the monitored interface and, if necessary, informs the Network Interface Failure Finder daemon (niffd) to generate traffic for the network interface that has been classified inactive. The niffd daemon's purpose is to get the interface packet counters to increment, signifying the interface is still alive and well.

See the Network Administration guide, and the niffconfig(8), niffd(8), and niffmt(7) reference pages.

3.6    Naming Services

Tru64 UNIX supports the following distributed naming services:

The library routines in /usr/lib/libc.so allow transparent access to DNS, 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.

Tru64 UNIX allows you to convert from an NIS-distributed environment to a DNS-distributed environment, or to run both services in the same environment. Because the source files for both DNS 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.

3.6.1    Domain Name Service

The Domain Name Service (DNS) is a mechanism for resolving unknown host names and Internet Protocol (IP) addresses that originate from sites on your company's intranet or the Internet.

The implementation of DNS in Tru64 UNIX is based on the Berkeley Internet Name Domain (BIND) service, which is supported by the Internet Software Consortium. BIND service is a client/server model that allows client systems to obtain host names and addresses from DNS servers.

Tru64 UNIX supports BIND Version 8.1.2, which includes the following features:

You can use DNS to replace or supplement the host table mapping provided by the local /etc/host file or NIS. You should use NIS for all other distributed database applications.

For more information about the DNS environment, DNS planning and configuration, and DNS management, see the Network Administration guide, the BIND Configuration File Guide, and the bind_intro(7) reference page.

3.6.2    Network Information Service

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 system administrators 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.

3.7    Time Services

Tru64 UNIX supports the following time services:

Because NTP can be traced to clocks of high absolute accuracy, it 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.

3.7.1    Network Time Protocol

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.

Tru64 UNIX 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 delay is assumed to be 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 collects information to decide which of the hosts it queries provides the most accurate time. 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 can stay synchronized even if some of the other hosts become unavailable for long periods.

In practice, NTP can 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.

3.7.2    Time Synchronization 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 that master 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.