| Digital UNIX | ||
|---|---|---|
| Prev | Chapter 3. Networking | Next |
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:
Application-Level Protocols, such as DOMAIN, Gateway Protocols (EGP, BGP, RIP, and OSPF), File Transfer Protocol (FTP), FINGER, TELNET, Trivial File Transfer Protocol (TFTP), Simple Mail Transfer Protocol (SMTP), and Simple Network Management Protocol (SNMP).
Transport-Level Protocols, such as User Datagram Protocol (UDP) and Transmission Control Protocol (TCP)
Network-Level Protocols, such as Address Resolution Protocol (ARP), Internet Control Message Protocol (ICMP), and Internet Protocol (IP)
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 the section called The gated Daemon).
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:
Ask another exterior gateway to agree to exchange reachability information
Continually check to ensure that its EGP neighbors are responding
Allow EGP neighbors to exchange reachability information by passing routing update messages
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:
Basic Data Transfer
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.
Reliability
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.
Flow Control
To control how much data is sent, TCP returns the following information with every acknowledgment:
The sequence numbers it will accept next; these numbers are always greater than the number of the last segment that was successfully received.
The number of octets that the sender is allowed to transmit before receiving further permission.
Multiplexing
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.
Connections
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. [1] Certain sections of the PPP code was derived from the RSA Data Security, Inc., MD5 Message-Digest Algorithm.
[1] Copyright (c) 1993 The Australian National University. Copyright (c) 1989 Carnegie Mellon University. Copyright (c) 1991 Gregory M. Christy. Copyright (c) 1989 Regents of the University of California. Copyright (c) 1990 RSA Data Security, Inc.
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:
Tests whether a destination is alive and reachable
Reports parameter problems with a datagram header
Performs clock synchronization and transit time estimations
Obtains Internet addresses and subnet masks
Provides transport-level reachability information
Updates routing information
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:
When a packet cannot reach its destination
When a gateway host does not have the buffering capacity to forward a packet
When a gateway can direct a host to send traffic on a better route
| Prev | Home | Next |
| Networking | Up | Supported Networks |