Routing protocols distribute information that reflect dynamic network conditions and update the routing table accordingly. Dynamic routing tables use information received by means of routing protocol updates; when routes change, the routing protocol can switch to a backup route and can determine the best route to a given destination.

Routing daemons implement a routing policy, that is, the set of rules that decide which routes go into the routing table. A routing daemon writes routing messages to a routing socket causing the kernel to add a new route, delete an existing route, or modify an existing route.

The kernel also generates routing messages that can be read by any routing socket when events occur that may be of interest to the process, for example, the interface has gone down or a redirect has been received.

The TCP/IP Services product implements two routing daemons, the Routing Daemon (ROUTED) and the Gateway Routing Daemon (GATED).

2.5.2.1 The Routing Daemon (ROUTED)

Using the RIP Version 1 protocol, ROUTED listens on a User Datagram Protocol (UDP) socket for packets with routing information. If the host is a gateway (internet router), it periodically supplies copies of its routing tables to directly connected hosts or networks.

When the dynamic routing server is started, it finds all active internet interfaces (except those marked in loopback). If multiple interfaces are present, the dynamic router assumes that the host forwards packets between networks. ROUTED then transmits a RIP request packet on each interface. If the interface supports broadcast packets, ROUTED sends a broadcast packet. Otherwise, it sends a normal packet and listens for a RIP request and RIP response packets from other hosts.

When a RIP request packet is received, ROUTED formulates a reply based on the information maintained in its internal tables. The RIP response packet generated by the server contains a list of known routes, each marked with a hop count metric. The hop count is the number of hops between two hosts, based on the number of different routers needed to traverse the distance between the two hosts. A hop count of 16 or greater is considered infinite.

If one or more of the following conditions exist, the RIP response packets received by ROUTED are used to update the internet routing tables:

• No routing table entry exists for the destination network or host, and the metric indicates the destination is reachable. (That is, the hop count is not infinite.)
• The source host of the packet is the same as the gateway (router) in the existing routing table entry. That is, updated information is being received from the gateway (internet router) through which packets for the destination are being routed.
• The existing entry in the routing table has not been updated for some time (defined as 90 seconds) and the route is at least as cost effective as the current route.
• The new route describes a shorter route to the destination than the one currently stored in the routing tables. To decide this, the hop count metric of the new route is compared to the one stored in the gateway's internal routing tables.

When an update is applied, ROUTED records the change in its internal tables and generates a RIP response packet to all hosts and networks to which it is directly connected. ROUTED waits a short period of time (no more than 30 seconds) before modifying the internet routing tables to allow possible unstable situations to be resolved.

In addition to processing incoming packets, ROUTED periodically checks the internet routing table entries. If an entry has not been updated for 3 minutes, the entry's metric is set to infinity and marked for deletion. Deletions are delayed an additional 60 seconds to ensure that the invalidation is propagated throughout the internet.

Hosts that act as routers supply their routing tables to all directly connected hosts and networks every 30 seconds. The RIP response is sent to either the broadcast destination, an address on a point-to-point link, or the gateway's address on other networks. The normal routing tables are bypassed when sending RIP response packets.

The reception of RIP response packets on a network is used to determine whether that network and interface are functioning correctly. If no RIP response packet is received on an interface, another path may be chosen to route around the interface, or the route may be dropped if no alternative is available.

2.5.2.2 Gateway Routing Daemon (GATED)

In contrast to ROUTED, which handles only the RIP Version 1 protocol, GATED handles multiple routing protocols: RIP V1 and V2, OSPF, EGP, and BGP. GATED can be configured to handle all supported protocols or any subset. In many environments, GATED will replace ROUTED because it provides the following benefits:

• For systems using more than one routing protocol, GATED combines the routing information it learns from each and selects the "best" routes.
• External announcements can adjust dynamically when interior routes are changed.
• Routing protocols are easily configured from a single file called TCPIP$GATED.CONF.

Each routing protocol has its own metric (for example, a hop count, or delay) for determining the best route. GATED uses these metrics when it advertises routes. For example, when announcing a route via OSPF, GATED used a valid OSPF metric; when announcing a route via RIP, GATED uses a valid RIP metric.

When GATED receives a route from two of these protocols, it combines the metric information from both protocols and applies its own value, known as preference, to update the routing table.

Preference is used only to help combine routing information from several sources into one routing table. Preference determines the order of routes to the same destination. Preference values range from 0 to 255, with the lowest number indicating the most preferred route, and are set in the configuration file. Use preference to specify one network interface over another, one protocol over another, or one remote gateway over another.

2.5.3 Fragmentation and Path MTU

Most types of networks have an upper limit on the number of bytes of data that can be transmitted at one time. This limit is called the MTU, or maximum transmission unit. If a datagram is larger that the MTU, IP performs fragmentation, breaking a large datagram into fragments so that each fragment is smaller than the MTU. The fragment format is designed so that the destination IP layer can reassemble fragments into their original form before delivering the complete datagram to a user.

Fragmentation is used, for example, when the datagram originates in a network that allows large packets, but to reach its destination, the packet must cross a network that supports a smaller packet size. Fragmentation is also used when there is no router, but applications send messages that are longer than the Network Interface layer supports. For example, the NFS server transfers information in 8000-byte packets, but Ethernet only supports 1500-byte packets. Therefore, IP fragments the 8000-byte datagram into 6 fragments of no more than 1500 bytes each.

A router can break up an internet datagram into smaller internet datagram fragments. The fragments can be further broken into smaller fragments at subsequent routers. When two hosts are communicating across multiple networks, it is important to know the smallest MTU of any data link between the two hosts. This is called path MTU. Because the path MTU between hosts can change at any time, a path MTU discovery mechanism is employed to determine the path MTU at any given time.

Knowing the current path MTU value allows a host to limit the size of packets it transmits, thereby avoiding fragmentation by intervening routers. The TCP/IP Services product performs path MTU discovery and limits the size of its TCP packets.

2.6 Ports

As explained in Section 2.4, each host on an internet is identified by a unique IP address. However, because numerous processes run concurrently, a client process on a local host needs more than just the remote host's IP address to connect to a server process on the remote host.

In addition to the IP address, the client process must specify the port number of the server process to which it wants to connect. The combination of an IP address and a port number identifies the unique connection point of the requested process. Port numbers range from 1 to 65535.

Every client and server process has an associated port number. The UDP header and TCP header each contain the source port number and the destination port number. Because the IP header specifies the protocol, TCP ports are independent of the UDP ports. TCP port 1035, for example, is different from UDP port 1035.

There are numerous advantages to using ports instead of attempting to send messages directly to receiving processes with process names or identification numbers:

• Heterogeneous operating systems define processes differently. To use process names requires that the internet architecture include a definition of each process or process name.
• Not all senders have enough information to identify a particular process on another host.
• Process IDs change.

By convention, port numbers 1 to 1023 are called well-known ports and are assigned to specific applications on all servers running TCP/IP. For example, some of the most common well-known port numbers are:

Port Number	Application
21	FTP (File Transfer Protocol)
23	TELNET
25	SMTP (Simple Mail Transfer Protocol)
69	TFTP (Trivial File Transfer Protocol)
80	HTTP (Hypertext Transfer Protocol)
110	POP (Post Office Protocol)

2.6.2 Privileged Ports

In addition to well-known ports, port numbers 256 to 1023 are called privileged ports. This meaning of privilege depends on the operating system. In general, when a host receives a message from a privileged port on a remote sender, the local host assumes that the remote host has checked the security or authenticated the application using the port. The remote host is responsible for ensuring that only privileged applications or users can access privileged ports.

Before requesting a process from a server, a client process is assigned an unused port number (usually ports 1024 to 5000) from its local host. This temporary port number is contained in the header information along with the IP address.

After the server completes the request, it can reply to the client using the port and IP address information contained in the requesting header.

Because the port number assigned to the client process is temporary, it is called an ephemeral port number. When the first client process is finished, the port number is free to be assigned to another process.

2.6.4 Port Binding

To communicate through either TCP or UDP, a process must be bound to a port. This means that the sending and receiving processes establish a connection and exchange command requests. A port that is bound to a process is known as an active port. A process can bind to any number of ports.

2.6.5 Port Assignment

Ports can be permanently associated with specific servers provided by specific image files. An association between a port and an image file is called a port assignment. To create a port assignment, the system manager or a process assigns the port to a server. If the service is to be started by the Auxiliary server, the service must have an entry in the service database (TCPIP$SERVICE.DAT).

The server's entry in the DIGITAL TCP/IP Services for OpenVMS service database contains the following information:

• Server file name
• Protocol used by the server (TCP or UDP)
• Port number
• Startup information
• Logging information
• Access information

For more information, see the SET SERVICE command in the DIGITAL TCP/IP Services for OpenVMS Management Command Reference manual.

2.7 Sockets

As explained in Section 2.6, the unique connection point of a process is identified by the IP address and port number. This point is called a socket. Because network communication consists of two connection points (source and destination), a socket pair fully describes the connection:

{source_IP_address, source_port, destination_IP_address, destination_port}

For example, the following is a valid socket pair:

{192.43.235.2, 1500, 192.43.235.6, 21}

where 192.43.235.2 is the source IP address and 1500 is the source port number, and 192.43.235.6 is the destination IP address and 21 is the destination port number. (It's also interesting to note that 1500 is an ephemeral port number and 21 is the well-known port number for FTP.)

2.7.1 Socket APIs

The concept of a socket is important to creating networking applications. The BSD socket API consists of calls that programmers use to write application programs that transfer data between two hosts. Each application generally needs to contain both client and server functionality.

The following is a typical sequence of socket calls a client process could use to access a server:

• Create a socket with a call to socket().
• Connect the socket to the server with a call to connect().
• Send and receive data with calls to send() and recv().
• Shut down the connection with a call to shutdown() and close().

A server process needs to prepare itself before it can accept clients. To do this, it might use a sequence of calls such as the following:

• Create a socket with a call to socket().
• Register the socket with a well-known port address with a call to bind().
• Create a queue where clients can place connection requests with a call to listen().
• Accept client requests with a call to accept().
• Receive and send data with calls to recv() and send().

For more detailed information about socket calls, see the DIGITAL TCP/IP Services for OpenVMS System Services and C Socket Programming manual.

The DIGITAL TCP/IP Services for OpenVMS product supports two socket communication APIs:

• OpenVMS QIO system services
• BSD socket interface

In both of these APIs, three characteristics may be specified to create a socket:

• Address family
• Protocol type
• Protocol

An address family is the set of collective common properties of processes that communicate through sockets. The DIGITAL TCP/IP Services for OpenVMS product supports the Internet (AF_INET) address family.

2.7.1.2 Socket Type

Socket types are the communication properties visible to the user. Normally, processes communicate only between sockets of the same type. The available socket types are: stream, datagram, and raw.

• A stream socket (that uses TCP) supports a bidirectional, reliable, and sequenced flow of data without record boundaries. The data is guaranteed to arrive at the receiving processes in sequence, without duplication.
• A datagram socket (that uses UDP) provides a bidirectional flow of data that does not guarantee the receiving process gets the messages in sequence, without duplication, or at all. The record boundaries of the data are preserved.
• A raw socket (that uses RAW IP) provides access to the underlying communication protocols that support sockets. Users developing new communication protocols, for example, can take advantage of raw sockets to provide direct access to the IP protocol.

In most cases, the socket protocol properties are either TCP or UDP. TCP is used for connection-oriented sockets. It is more complex than UDP, which uses connectionless sockets with low overhead. This parameter is usually omitted.

See the DIGITAL TCP/IP Services for OpenVMS System Services and C Socket Programming manual for detailed information.

2.8 NTP Concepts

Time synchronization is important in client/server computing. For example, systems that share common databases require coordinated transaction processing and timestamping of instrumental data. The Network Time Protocol (NTP) provides synchronization traceable to clocks of high, absolute accuracy and avoids synchronization to clocks with incorrect time.

2.8.1 Synchronized Timekeeping

Synchronized time keeping means that hosts with accurate system timestamps send time quotes to each other. Hosts running NTP may be either time servers or clients although they are often both servers and clients.

NTP does not attempt to synchronize clocks to each other. Rather, each server attempts to synchronize to Universal Coordinated Time (UTC) using the best available source and best available transmission paths to that source. NTP expects that the time being distributed from the synchronization root is derived from an external source of UTC, such as a radio clock.

If your network is isolated and you cannot access other NTP servers on the internet, you can designate one of your hosts as the reference clock to which all other hosts will synchronize.

2.8.2 How Hosts Negotiate Synchronization

Each host has its identifying stratum number encoded within UDP datagrams. Peers communicate by exchanging these timestamped UDP datagrams. NTP uses these exchanges to construct a list of possible synchronization sources then sorts them based on the results of complex filtering and selection algorithms. Peers are accepted or rejected leaving only the most accurate and precise sources.

NTP evaluates any new peer to determine if it qualifies as a new (more suitable) synchronization source.

NTP rejects the peer under the following conditions:

• The peer is not synchronized.
• The stratum is higher than the current source's stratum.
• The peer is synchronized to the local node.

NTP accepts the peer under the following conditions:

• There is no current time source.
• The current source is unreachable.
• The current source is not synchronized
• The new source's stratum is lower than the current source.
• The new source's stratum is the same as the current source, but its distance is closer to the synchronization source by more than 50%.