![[Contents]](icons/contents.gif){kind=icon}
![[Index]](icons/index.gif){kind=icon}
![[Next]](icons/next.gif){kind=icon}
This guide describes the standard VxWorks network stack, which is based on the 4.4 BSD TCP/IP release. Chapters two through nine explain how to configure VxWorks to include or to exclude a particular network protocol or utility. They also describe how to set any configuration parameters associated with the supplied protocols. If your application can use the supplied protocols and drivers as shipped, you need read only these chapters.
The remaining chapters and appendices are intended for developers who need to add a new data link layer driver or network service. This information comes from the VxWorks Network Protocol Toolkit Programmer's Guide, which is merged with this manual now that the Network Protocol Toolkit is bundled with the standard VxWorks stack.
|
|||||||||||||||||||
The protection domain feature was introduced to VxWorks with Tornado 3.0. Using protection domains, it is possible to create protected groupings of system resources such as tasks, code modules, semaphores, message queues, as well as physical and virtual memory pages. Sharing resources between protection domains is supported and expected, but it is possible only under very controlled circumstances. This control, enforced using the memory management unit, lets you insulate and protect sensitive elements of a VxWorks system from errant code and other misbehaviors.
VxWorks under Tornado 2.0.2 and recent Tornado 2.n releases do not support protection domains. However, the network stack implementation that follows the Tornado 2.0.2 and Tornado 3.1 releases is identical. Thus, this manual is appropriate for network programmers working with either Tornado/VxWorks variant.
Developers working with versions of VxWorks that support protection domains should note that direct access to some network stack features is limited to the kernel protection domain, the protection domain that hosts the network stack. Whenever such a limit applies, this manual notes the fact. If you are working with a non-AE version of VxWorks, you can ignore these notes.
After the stack overview in 2. The VxWorks Network Stack, chapters three through nine describe individual network components. The remaining chapters focus on adding new drivers and services to the existing network stack.
3. Data Link Layer Components discusses the data link layer, its general configuration needs, and network drivers. These drivers handle the specifics of communicating over networking hardware, such as an Ethernet board, or even the shared-memory backplane. These drivers are the foundation of the network stack. This chapter also discusses the Berkeley Packet Filter.
|
|
NOTE:
The bundled PPP, SLIP and CSLIP implementations previously described in this chapter are now deprecated for future use and will be removed from the next major release of Tornado. In anticipation of this change, the configuration information for the bundled PPP, SLIP and CSLIP implementations has been moved to C. Bundled PPP, SLIP, and CSLIP. For more information on the discontinuance of these features, please contact your local Wind River account manager.
If you require a PPP solution, please ask your Wind River account manager about WindNet PPP. WindNet PPP is a reliable and manageable PPP solution built upon an extensible Remote Access Framework. |
||||||||||||||||||
4. Configuring the Network Stack introduces the TCP/IP protocol suite. In particular, this chapter focuses on components such as TCP/IP itself, as well as UDP, ARP, IGMP, and the use of IP over unnumbered interfaces.
VxWorks uses the MUX interface to communicate with the data link layer. The purpose of the MUX is to decouple the data link and network layers. This makes it easier to add new network drivers under an existing protocol. It also makes it easier for an alternative protocol to run over the VxWorks data link layer. For more information on the MUX, see 10. Integrating a New Network Interface Driver.
The discussion of IP, TCP, and UDP presented in 4. Configuring the Network Stack is a simple overview that prepares you for a discussion of their configuration needs under VxWorks. It is not a primer on these protocols, which are thoroughly described in a variety of published works (see 1.4 Recommended Reading, p.11).
The discussion of ARP and proxy ARP are somewhat more detailed. ARP provides dynamic mapping from an IP address to the corresponding media address. Using ARP, VxWorks implements a proxy ARP scheme that can make distinct networks appear to be one logical network. This proxy ARP scheme is an alternative to the use of explicit subnets for accessing the shared-memory network. This helps conserve IP addresses. So too does the use of unnumbered interfaces on point-to-point links (see 4.9 Using Unnumbered Interfaces, p.90).
IGMP supports the correct delivery of multicast packets for TCP/IP. The standard VxWorks stack supports both the host-side and the router-side of the IGMP v2 protocol, as specified in RFC 2236. For more information, see 4.6 IGMP under VxWorks, p.71.
5. Network Configuration Protocols discusses the network configuration protocols:
VxWorks can use either DHCP or BOOTP to set up and maintain its network configuration information. At boot time, both DHCP and BOOTP can provide the client with IP addresses and related information. However, BOOTP assigns IP addresses permanently. DHCP extends BOOTP to support the leasing of IP addresses. If necessary, the lease need not time out, but if the client will need the IP address for a limited time, you can limit the length of the lease appropriately.
When the lease expires, the IP address is available for use by another client. If the original client still needs an IP address when the lease expires, the client must renegotiate the lease. Because of the need for lease renegotiation, a DHCP client remains active during run-time. This is not the case for the BOOTP client.
Although SNMP can provide network configuration information, it differs significantly from BOOTP and DHCP in that it was not designed for use at boot time. Instead, you use it to set up a network management station (NMS) from which you can remotely configure, monitor, and control network-connected devices called agents. Thus, SNMP is a network configuration protocol, but in a very different sense of the term.
6. Dynamic Routing Protocols discusses RIP, the Routing Information Protocol. RIP maintains routing information within small inter-networks. The RIP server provided with VxWorks is based on the 4.4 BSD routed program. The VxWorks RIP server supports three modes of operation: Version 1 RIP, Version 2 RIP with multicasting, and Version 2 RIP with broadcasting. The RIP implementation also supports an interface exclusion list that you can use to exclude RIP from specific interfaces as they are brought on line.
7. Sockets under VxWorks discusses the VxWorks implementation of sockets. Using sockets, applications can communicate across a backplane, within a single CPU, across an Ethernet, or across any connected combination of networks. Socket communications can occur between any combination of VxWorks tasks and host system processes. VxWorks supports a standard BSD socket interface to TCP and UDP. Using these standard BSD sockets, you can:
In addition to the standard BSD socket interface, VxWorks also supports zbuf sockets--an alternative set of socket calls based on a data abstraction called the zbuf (the zero-copy buffer). Using zbuf sockets, you share data buffers (or portions of data buffers) between separate software modules on a VxWorks target. Because zbuf sockets share data buffers, you can avoid time-consuming data copies. The zbuf socket interface is WRS-specific, but visible only to applications running on the VxWorks target. The other end of the socket connection can use a standard BSD socket interface.
|
|
NOTE:
VxWorks also supports a registration mechanism that you can use to add a socket back end for protocols that you have ported to VxWorks. For more information, see 11. Integrating a New Network Service.
|
||||||||||||||||||
8. Remote Access Applications discusses the applications that provide remote access to network-connected resources. VxWorks supports the following:
9. DNS and SNTP provides information on how to configure and use DNS and SNTP under VxWorks.
DNS is a distributed database that most TCP/IP applications can use to translate host names to IP addresses and back. DNS uses a client/server architecture. The client side is known as the resolver. The server side is called the name server. VxWorks provides the resolver functionality in resolvLib. For detailed information on DNS, see RFC-1034 and RFC-1035.
SNTP is a Simple Network Time Protocol. Using an SNTP client, a target can maintain the accuracy of its internal clock based on time values reported by one or more remote sources. Using an SNTP server, the target can provide time information to other systems.
10. Integrating a New Network Interface Driver describes how to integrate new network interface drivers with the MUX. The purpose of the MUX is to provide an interface that insulates network services from the particulars of network interface drivers and vice versa.
Currently, the MUX supports two network driver interface styles, the END interface and the Network Protocol Toolkit (NPT) driver interface. ENDs are frame-oriented drivers that exchange frames with the MUX. All drivers now shipped with the standard network stack are ENDs. The NPT style drivers are packet-oriented drivers that exchange packets with the MUX.
The muxDevLoad( ) routine loads network devices into the system. This function returns a cookie that identifies the device and that is used thereafter in all other calls that refer to that device. The system automatically calls muxDevLoad( ) for each of the interfaces defined in the system device table. For information on how to set up this table, see Adding an NPT Driver to VxWorks, p.206 or Adding an END to VxWorks, p.191.
After a network device loads successfully, VxWorks uses muxDevStart( ) to activate it (see Launching the Driver, p.207).
11. Integrating a New Network Service tells you how to integrate a new network service with MUX and thus with VxWorks.
This manual defines a network service as an implementation of the network and transport layers of the OSI network model. Under VxWorks, network services communicate with the data link layer through the MUX interface. Part of porting a new network service to VxWorks is porting its data link layer access code to use the MUX interface.
To give applications access to your network service, the VxWorks socket interface provides sockLibAdd( ). This registration function simplifies adding socket back ends for your network service. The standard socket interface is designed to support the coexistence of distinct socket back ends for each protocol layer implementation. Thus, adding your socket library does not interfere with the socket back end for any other network service. A layered architecture makes this possible (see Figure 1-1).
Because adding a new network service might change your address mapping needs, the VxWorks network stack also includes a registration mechanism for address mapping services.
To configure service address mapping (such as address resolution and multicast mapping functions) with the MUX, use functions such as muxAddrResFuncAdd( ) and muxMCastAddrAdd( ). Register service address mapping functions for every pairing of a network service type and a network driver type for which service address mapping functions will be needed. The network service will then retrieve these registered functions from the MUX when they are needed. See B.2.1 muxAddrResFuncAdd( ), p.272 and B.2.13 muxMCastAddrAdd( ), p.278.
Typically, a network service provides a routine that assigns the service to a network interface. Internally, this routine must bind the service to a network driver interface using the muxTkBind( ) routine. After this step is taken, the network service is ready to send and receive packets over the corresponding device. See B.2.16 muxTkBind( ), p.280.
|
|
|||||||||||||||||||
A. Using netBufLib provides advice on how to use netBufLib to create and manage memory pools. Currently, the default VxWorks stack includes two memory pools. Managing these pools is described in 4.3.3 Network Memory Pool Configuration, p.50. However, if you need to create a totally new memory pool for a new network driver or protocol, you need to read A. Using netBufLib.
Some schematic diagrams in this guide use a form of Unified Modeling Language (UML) notation. This section gives an overview of this UML dialect.
Figure 1-2 shows how a class is represented in UML notation, along with its data members and functional methods. In the VxWorks stack, classes are implemented as data structures.
Figure 1-3 shows class inheritance in UML notation. In the VxWorks stack, class inheritance is implemented by making the first member of the structure that represents the subclass be a structure of the superclass. In UML notation, a subclass points to its superclass with a closed arrowhead at the end of a solid line.
Figure 1-4 shows interface implementation and use in UML notation. Interfaces are represented in much the same way as classes, except that their names are in italics and they always have empty "Attributes" sections. Classes that implement an interface point to that interface with a closed arrowhead at the end of a dashed line. Classes that use an interface that another class implements point to that interface with an open arrowhead at the end of a dashed line.
Figure 1-5 shows how class relationships are represented in UML. A solid line between two classes indicates that one of the classes has a reference to one or more objects of the other class (or that the classes mutually reference objects of each other's class). This relationship can be made more explicit with additional notation.
An open arrowhead indicates that the object of the class doing the pointing knows about the link between the two and should know which object or objects of the other class make up the relationship. Numbers, ranges of numbers (such as 1..5), or an asterisk (meaning any value) show how many objects are in the relationship.
A circle at the end of the line indicating the relationship can indicate how closely coupled the objects of the two classes are. If object A creates and holds a reference to object B, and then deletes object B as part of its own delete processing, this can be indicated by putting a black circle at the class A side of the line connecting class A and class B. If the two objects are created and deleted independently of one another, a white circle can be used to indicate this.
The focus of this manual is the configuration of the VxWorks network stack. Although this manual includes some networking background information, it is beyond the scope of this manual to provide a thorough description of socket usage, routing, protocol implementation, and how to write a network interface driver. For information of that sort, consider the following sources:
