This guide describes the standard VxWorks network stack, which is based on the 4.4 BSD TCP/IP release.

Chapter Overview

The first several chapters in this guide describe the network protocols supported by the standard VxWorks network stack and explain how to configure VxWorks to include a particular protocol or utility and how to configure the protocol or utility itself.

Chapter 13. Booting over the Network explains how to boot VxWorks from the network. Included are instructions for booting over the Ethernet, the serial line (using PPP or SLIP), or the memory backplane.

Chapter 14. Upgrading 4.3 BSD Network Drivers describes the issues associated with porting a 4.3 BSD network driver to work within the VxWorks network stack. You can choose between two upgrade paths: you can do a simple upgrade of the driver to the standard 4.4 BSD network driver interface; or, if your driver needs to support features such as multiple protocols, it should be rewritten to use the MUX interface.

The standard VxWorks network stack includes support for the following protocols and utilities:

• SLIP, Serial Line IP

• CSLIP, Compressed Serial Line IP

• PPP, the Point-to-Point Protocol

• IP, Internet Protocol

• UDP, User Datagram Protocol

• TCP, Transmission Control Protocol

• DHCP, Dynamic Host Configuration Protocol

• BOOTP, Bootstrap Protocol

• DNS, Domain Name System

• ARP, Address Resolution Protocol, and Proxy ARP

• OSPF, Open Shortest Path First

• RIP, Routing Information Protocol

• Sockets (TCP, UPD, multicasting, routing, and Zbuf)

• RPC, Remote Procedure Calls

• RSH, Remote Shell

• FTP, File Transfer Protocol

• NFS, Network File System

• TFTP, Trivial File Transfer Protocol

• rlogin, Remote Login

• telnet, Remote Login

One key to VxWorks's effective relationship with host development machines is its extensive networking facilities. By providing a fast, easy-to-use connection between the target and host systems, the network allows full use of the host machine as a development system, as a debugging host, and as a provider of non-real-time services in a final system.

VxWorks currently supports loosely coupled network connections over serial lines (using SLIP, CSLIP, or PPP) or Ethernet networks (IEEE 802.3). It also supports tightly coupled connections over a backplane bus using shared memory. The standard VxWorks network stack uses the Internet protocols, based on the 4.4 BSD TCP/IP release, for all network communications.

In addition to the remote access provided by Tornado, VxWorks supports remote command execution, remote login, and remote source-level debugging. VxWorks also supports standard BSD socket calls, remote procedure calls, SNMP, remote file access, boot parameter access from a host, and proxy ARP networks.

MUX Interface

A standard BSD 4.3 network driver can be ported to VxWorks with little effort. However, VxWorks also supports an improved network driver interface. This interface, called the MUX¹ , adds support for advanced features such as multicasting, polled-mode Ethernet, and zero-copy transmission. This interface also decouples the network driver and network protocol layers, allowing you add new network drivers without the need to alter the network protocol, or to add a new network protocol without the need to modify the existing MUX-based network interface drivers.

Porting a driver to the MUX interface involves more work than a simple port to BSD 4.4, but it is worth it if your driver must support multicasting, polled-mode Ethernet, and other advanced features. More information about the process of adding new drivers and protocols to the VxWorks network stack can be found in the Network Protocol Toolkit User's Guide.

Sockets

VxWorks provides standard BSD socket calls, which allow real-time VxWorks tasks and other processes to communicate in any combination with each other over the network. There are two sets of VxWorks socket calls: you can use sockets that are source-compatible with BSD 4.4 UNIX, or you can use the zbuf socket interface to streamline throughput.²

Any task can open one or more sockets, to which other sockets can be connected. Data written to one socket of a connected pair is read, transparently, from the other socket. Because of this transparency, the two tasks do not necessarily know whether they are communicating with another process or VxWorks task on the same CPU or on another CPU, or with a process running under some other host operating system. Similarly, tasks using the zbuf socket interface are not aware of whether their communications partners are using standard sockets, or are also using the zbuf interface.

For information on sockets, see 2.6 Networking APIs, and the reference entries for sockLib and zbufSockLib.

Remote Procedure Calls (RPC)

Originally designed by Sun Microsystems using the Sun ONC standard and now available in the public domain, Remote Procedure Call (RPC) is a protocol that allows a process on one machine to call a procedure that is executed by another process on another machine. Thus with RPC, a VxWorks task or host machine process can invoke routines that are executed on other VxWorks or host machines, in any combination. For more information, see the RPC documentation (publicly and commercially available) and the reference entry for rpcLib.

Simple Network Management Protocol (WindNet SNMP)

The WindNet SNMPv1/v2c optional component allows VxWorks targets to be managed and configured remotely through SNMP (the Simple Network Management Protocol). Application developers can customize the SNMP management information base to include information specific to each application and environment.

For detailed information about WindNet SNMP, see the WindNet SNMPv1/v2c VxWorks Component Release Supplement.

Remote File Access: NFS, RSH, FTP, TFTP

Remote file access across the network is also available. A program running on VxWorks can use the host machine as a virtual file system. Files on any host machine can be accessed through the network as if they were local to the VxWorks system. A program running under VxWorks does not need to know where that file is, or how to access it. For example, /dk/file might be a file local to the VxWorks system, while host:file might be a file located on another machine entirely.

Conversely, VxWorks can allow host machines to use files maintained on VxWorks just as transparently - programs running on the host need not know that the files they use are maintained on the VxWorks system.

VxWorks includes the Sun Microsystems standard Network File System (NFS). VxWorks systems can run NFS clients, using files from other systems that export files over NFS, or run NFS servers, exporting files to other systems. Alternatively, VxWorks can use the following protocols to provide transparent remote file access:

• The Remote Shell protocol (RSH) can be used as a client, accessing files on UNIX host systems running an RSH server.

• The File Transfer Protocol (FTP) provides remote access to VxWorks files from other systems using FTP.

• The Trivial File Transfer Protocol (TFTP) provides read/write capability to and from a remote server.

See the reference entries for nfsLib, remLib, ftpLib, ftpdLib, tftpLib, and tftpdLib, and the following sections: 3.7.4 Network File System (NFS) Devices, 2.10 File Access Applications, and 3.7.5 Non-NFS Network Devices.

Boot Parameter Access from Host

BOOTP is a basic bootstrap protocol which allows a booting target to configure itself dynamically by obtaining the required parameters from the host via the network, instead of using information encoded in the target's non-volatile RAM or ROM. The actual transfer of the boot image is performed by a file transfer program. BOOTP and TFTP are commonly used together for network booting.

Proxy ARP Networks

Proxy ARP provides transparent network access by using Address Resolution Protocol (ARP) to make distinct networks appear as one logical network. The proxy ARP scheme implemented in VxWorks provides an alternative to the use of explicit subnets for access to the shared memory network.

With proxy ARP, nodes on different subnetworks are assigned addresses with the same subnet number. Because they appear to reside on the same network, and because they can communicate directly, they use ARP to resolve each other's hardware address. The gateway node that responds to ARP requests is called the proxy server.

1:  MUX: short for multiplexer, because it multiplexes access to physical network devices.

2:  The TCP subset of the zbuf interface is sometimes called "zero-copy TCP."