| Previous | Contents | Index |
The Data Link layer of the TCP/IP model (sometimes called the network interface layer) is responsible for properly sending and receiving communications signals between two communicating hosts through their network interfaces. This layer includes the device driver and the corresponding network interface.
The device driver, also called the network interface, is a software component that communicates with the TCP/IP software and the network interface card (the hardware connection between a computer system and a network).
Individual host computers can have multiple network interface cards per computer. Such a computer is called multihomed. These physical interfaces may be connected to different types of networks such as Ethernet, FDDI, Token Ring, and asynchronous transfer mode (ATM), Gigabit Ethernet, and serial communications lines. Each physical interface is associated with one device driver (network interface). A single network interface can have more than one IP address.
The TCP/IP Services product provides a pseudo-device driver that handles the communication between the network interfaces and the TCP/IP Services software. This pseudo-device driver is called the BG driver. There may be several network interfaces, depending on the number of network interface cards you have installed on your computer, but only one BG driver.
With TCP/IP --- as with any layered networking protocol --- each layer adds header information to the data from the layer above. Each packet contains a header from the Network Interface layer, followed by a header from the Internet layer, followed by a header from the Transport layer, followed by the application data.
At the Network Interface layer, standard encapsulation of IP packets is defined for the various hardware types. Ethernet, for example, uses the Ethernet frame standard to enclose the data being sent with header fields. Serial line connections use either Serial Line Internet Protocol (SLIP or CSLIP) or Point-to-Point Protocol (PPP).
Serial Line Internet Protocol
SLIP is a simple packet framing protocol. It defines a sequence of characters that frame IP packets on a serial line. It provides no mechanisms for addressing, packet type identification, error detection/correction, or compression. Although limited in scope, SLIP is easy to implement, but transmission speeds are relatively slow. CSLIP (Compressed SLIP) allows for faster transmission by compressing the TCP/IP headers.
For more information on SLIP and CSLIP, see the DIGITAL TCP/IP Services for OpenVMS Management guide.
Point-to-Point Protocol
PPP is more complex than SLIP and CSLIP, but it offers much greater functionality. As described in RFC 1661, PPP consists of three main components:
For more information on PPP, see the DIGITAL TCP/IP Services for OpenVMS Management guide.
1.4 Internet Layer Protocols
The Internet layer (sometimes called the Network layer) provides a connectionless packet delivery service using IP (Internet Protocol). An IP datagram is a packet that has no delivery receipt and is called connectionless because IP does not maintain state information about successive datagrams. Each datagram is handled independently from all other datagrams.
Table 1-2 describes the Internet layer protocols available in the TCP/IP Services product.
| Protocol | Description |
|---|---|
| Internet Protocol (IP) | IP sends or routes data across the network from its source to its destination by means of internet addressing (an IP address). The IP address identifies the connection between the network controller of a host and the network cable. IP then receives data bits from the network hardware, assembles the bits into an IP datagram, and chooses the best route to send the packet to its destination. IP also fragments and reassembles packets during the routing process. |
| Internet Control Message Protocol (ICMP) | ICMP provides a number of diagnostic functions and handles error and control messages. ICMP reports problems with data delivery to gateways and hosts. |
| Address Resolution Protocol (ARP) | ARP dynamically maps an IP address to a physical hardware address of the broadcast medium such as Ethernet, FDDI, and Token Ring. ARP is limited to a single physical network and to networks that support hardware broadcast. |
The routing of packets also occurs in the Internet layer. Table 1-3 describes the routing protocols supported in the TCP/IP Services product. These protocols build and update the routing table used by the Internet layer.
| Protocol | Description |
|---|---|
| Routing Information Protocol (RIP) Versions 1 and 2 | RIP is a commonly used interior protocol that selects the route with the lowest metric (hop count) as the best route. |
| Open Shortest Path First (OSPF) Version 2 | Another interior routing protocol, OSPF is a link-state protocol (shortest path first) and is better suited than RIP for use in complex networks with many routers. |
| Exterior Gateway Protocol (EGP) | EGP exchanges reachability information between autonomous systems. An autonomous system is usually defined as a set of routers under a single administration, using an interior gateway protocol and common metric to route packets. Autonomous systems use exterior routing protocols to route packets to other autonomous systems. |
| Border Gateway Protocol (BGP) | Like EGP, BGP exchanges reachability information between autonomous systems but supports nonhierarchical topologies. BGP uses path attributes to provide more information about each route. Path attributes can include, for example, administrative preferences based on political, organizational, or security considerations. |
| Router Discovery | This protocol is used to inform hosts of the availability of other hosts it can send packets to, and to supplement a statically configured default router. |
The Transport layer protocols provide either connection-oriented or connectionless data transmission from one host to another. The Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP) form the bridge between the Application layer functions and Internet layer protocols such as IP.
The DIGITAL TCP/IP Services for OpenVMS product supports both TCP and UDP.
TCP provides connection-oriented, reliable, sequenced data transfers between local or remote hosts. Before transmitting data, participants must establish a connection. TCP guarantees that data reaches its destination, and retransmits any data that does not get through.
UDP provides connectionless data transfers between local and remote
hosts. It allows application programs to send and receive datagrams to
applications that reside on a different host. UDP adds a checksum and
addressing information, then uses IP to deliver the datagrams. UDP
provides fast communications for applications that do not require
delivery receipts at the Transport layer.
1.6 Application Layer
At the Application layer, data is received as commands from the user application at the other end of the connection. TCP/IP applications often communicate in client/server pairs at this layer.
Because of the large number of Application layer protocols supported by the DIGITAL TCP/IP for OpenVMS product, it is useful to group them in five general categories:
Sections 1.6.1 through 1.6.5 include summaries of each of
the primary Application level components included in the product. See
the DIGITAL TCP/IP Services for OpenVMS User's Guide for detailed user information about remote computing,
file transfer, resource sharing, and electronic mail components. Refer
to the the DIGITAL TCP/IP Services for OpenVMS Management guide for information about network services
and tools.
1.6.1 Remote Computing
Remote computing applications enable networked users to run software on remote systems. The product includes the following remote computing application components:
TELNET is a standard protocol that provides remote terminal connection or login service. TELNET enables users at one site to interact with a remote system at another site, as if the user terminals were connected directly to the remote system.
The DIGITAL TCP/IP Services for OpenVMS product implements TELNET to provide:
The remote commands, called R commands, enable users to work in accounts on remote internet hosts that also run an implementation of TCP/IP and the R commands. The DIGITAL TCP/IP Services for OpenVMS software supports the RLOGIN, RSH, REXEC, and RMT/RCD commands, as explained below. Users issue these commands at the system command line prompt ($).
| Remote Command | Function |
|---|---|
| RLOGIN | Allows users of one system to log into other systems across an internet and interact as if they were directly connected. RLOGIN offers the same service as TELNET, except it also passes information about the user's environment, such as the user identification, to the remote host. |
| RSH | Allows users to send a command, shell script, or command procedure to a remote host for execution. RSH does not require login to the remote host to execute commands. |
| REXEC | Based on password information stored in the user authentication file (UAF), authenticates the users and then executes the R commands the user issues. |
| RMT/RCD | Allows remote users to access magnetic tape and CD-ROM drives. |
For detailed information about the RLOGIN, RSH, and REXEC commands, see the DIGITAL TCP/IP Services for OpenVMS User's Guide. For information about RMT/RCD, see the DIGITAL TCP/IP Services for OpenVMS Management guide.
The Finger utility is implemented by the FINGER command, which displays information about users on the local or remote host. By default, information about each user on the host is displayed.
When you specify a user name or a list of user names with the FINGER command, the Finger utility returns the following information:
If you do not specify a host, the information listed is about users on
the local host; otherwise, the information is about users at the
specified host. You can specify a user on a remote host by using the
form user@host. If you specify @host, the standard
format listing is displayed on the remote host. The specified host must
have the Finger service enabled.
1.6.2 File Transfer
The DIGITAL TCP/IP Services for OpenVMS product includes the following file transfer components that let users transfer data files between local and remote hosts:
FTP is a TCP/IP standard, high-level protocol used to transfer files bi-directionally. FTP enables users to interactively access files, list directories on a remote host, delete and rename files on the remote host, and transfer files between hosts.
FTP also provides authentication control, which requires users or clients to correctly enter a login name and password to the server before requesting file transfers. The server can refuse access due to invalid login and password combinations.
FTP allows users who do not have a login name or a password to access certain files on a system using an anonymous login name. This functionality is called anonymous FTP and may include the following restrictions:
Trivial File Transfer Protocol
TFTP provides a simple, unsophisticated file transfer service. It is intended for applications that do not need complex interactions between a client and server. TFTP is small and can be hardcoded in read-only memory to execute a network bootstrap program. TFTP allows the bootstrap program to use the same underlying protocols that the operating system uses once it begins execution. This makes it possible for one host to boot from a server on another physical network.
The DIGITAL TCP/IP Services for OpenVMS product supports downloading of
system images and other types of information for client hosts with TFTP.
1.6.3 Resource Sharing
Resource sharing lets users access remote system resources such as disk storage space or printers as if they were directly connected to the user's local systems. With resource sharing, users can access these resources directly after the initial connection is made. This is different from file transfer programs where files must be completely transferred from the remote system before they can be used.
The resource-sharing components of DIGITAL TCP/IP Services for OpenVMS include:
Line Printer Protocol and Line Printer Daemon Protocol
The DIGITAL TCP/IP Services for OpenVMS software provides network printing through LPR/LPD. LPD provides remote printing services for UNIX and OpenVMS client hosts. Each print queue is either local or remote. Local print queues handle inbound jobs. Remote print queues handle outbound jobs for remote printers.
The print setup utility (TCPIP$LPRSETUP) provides the following capabilities:
To print, users at an OpenVMS client issue the DCL PRINT command.
Users working on UNIX clients typically issue the lpr command.
The TELNET print symbiont (TELNETSYM) provides remote printing using the TELNET protocol. With TELNETSYM, the local OpenVMS system drives a remote printer as if it were directly connected. The remote printer may either be a print server directly connected to the network or may be a printer connected to a terminal server.
The TELNET print symbiont has the following functions:
TELNET does not work with terminal servers that use only the local area transport (LAT) protocol. The terminal server must support TCP/IP. |
The system that originates the print jobs handles the standard print control functions, such as header page generation, pagination, queuing, and handling of multiple forms.
TELNET printing allows the standard OpenVMS output format features not available with the LPR/LPD service. The /ON=TCPIP$QUEUE=name qualifier to the DCL INITIALIZE/QUEUE command allows you to requeue a print job to another local OpenVMS queue after formatting, rather than using TELNET to send the print job across the network.
For detailed information on configuring and managing TELNETSYM, see the DIGITAL TCP/IP Services for OpenVMS Management guide.
NFS is a protocol developed by Sun Microsystems, Inc., that allows computers to access remote files as if they were local files. With NFS, when you access files and directories from a remote system, they appear to reside on your local system regardless of operating system, hardware type, or architectural differences between the local and remote systems.
This is accomplished in a client/server environment where specific implementations of NFS exist on both the client and the server machines. In its simplest form, here is how it works: When an application program executes, it calls the operating system to open a file. If the file does not reside on the local system, the request is passed to the NFS client, which knows how to contact the NFS server on the remote machine. The remote machine then performs the requested operation and replies to the client software.
In addition to NFS server and NFS client software, the TCP/IP Services product includes a PC-NFS daemon that allows PC-NFS clients access to a TCP/IP Services NFS server. The NFS server, NFS client, and PC-NFS are summarized in Table 1-4.
| NFS Component | Function |
|---|---|
| NFS server |
Enables remote users to access files that physically reside on an
OpenVMS system running DIGITAL TCP/IP Services for OpenVMS software.
The remote host must support an NFS client.
UNIX supports only sequential, byte-stream file formats. OpenVMS supports index, relative, and sequential files that have various record formats. The DIGITAL TCP/IP Services for OpenVMS implementation of NFS allows access to the following record formats:
|
| NFS client | Accepts file operation requests from the operating system and contacts the appropriate NFS server on the remote system to perform the requested operation. Supports STREAM_LF formatted files. |
| PC-NFS daemon |
Enables access to the NFS server from a personal computer by providing
authentication services to PC-NFS clients.
The PC-NFS daemon software provides:
|
| Previous | Next | Contents | Index |