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:
rarpd,
tcpdump,
tcpslice,
nfswatch,
nfslogsum)
screend
security policy daemon
(developed at Digital)
The following sections briefly discuss the networking functionality in Digital UNIX Version 4.0.
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:
timod
and
xtiso.
The appropriate socket layer routines are called and the data
is passed through the Internet protocols and
ifnet
layer to the BSD-based driver, which
puts it on to the network.
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:
rwall/rwalld
rusers/rusersd
spray/rsprayd
rup/rstatd
rquotad
pcnfsd
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:
/usr/sbin/rarpd
- Reverse ARP daemon
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.
/usr/sbin/tcpdump
- TCP/IP tracing and monitoring tool
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.
/usr/sbin/tcpslice
- Log file tool
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.
/usr/sbin/nfswatch
- NFS monitoring tool
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.
/usr/sbin/nfslogsum
- NFS log file summary tool
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
ttydevices. Integral serialttydevices and serialttyoptions share the same BSDttynamespace 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
hostsfile 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:
ntptrace
utility,
which
traces a chain of NTP hosts back to their master time source.
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.