Download TCP/IP Stack Library Overview

TMS320C6000 TCP/IP Stack Library
Architecture Overview
TCP/IP Architecture Overview
• TCP/IP Stack Library Overview
• Network Application Overview
• Porting to New Hardware
• TCP/IP Stack Platform Environments
2
TCP/IP Stack Library Overview
• Design Features
• Programming Features
• Service Features
• TCP/IP Stack Library Components
3
Design Features
Small Memory Footprint
A system using the stack with around a dozen tasks (telnet, DHCP, DNS, etc.) requires around
200K to 250K of program memory and 95K of data memory. Stack size is dependent on the
type of build, and which features are bound into the libraries. Options like Network Address
Translation and Point to Point Protocol can be purged from the build.
Strong Checking and Efficient Build Models
In the strong checking build, every data type is an object handle that can be verified and errors
are flagged immediately, resulting in faster debug. When the application is debugged, the
efficient build can be used where object handles are treated as pointers to data structures.
This saves the overhead of additional function calls and decreases code size.
Efficient Use of Memory Buffers
• UDP and RAW sockets do not use additional send or receive buffers to hold data.
• Optional "non-copy" TCP socket type and socket API eliminates data copy on TCP receive.
• Ethernet packet processing is performed without data copy.
• Bucket based memory manager eliminates memory fragmentation and tracks memory leaks.
Fully Adaptable OS
OS adaptation layer allows the system programmer to build a custom OS API on top of the
stack and DSP/BIOS.
4
Programming Features
OS Abstraction Interchangeable with DSP/BIOS
The OS adaptation layer allows developers to program using a compact OS
abstraction that guarantees network applications will be compatible across different
OS adaptations, but also allows programmers to make direct use of the DSP/BIOS
API. DSP application programmers use CCS and DSP/BIOS.
File Descriptor Based Stream IO Support
The stack adds a new stream IO file descriptor system to the native operating
environment. This allows standard applications to be developed or ported to the
operating system without giving up the feel of a descriptor based environment. Full
duplex pipes enable connection oriented inter-task communications without
resorting to TCP.
High Level Berkeley Sockets Compatibility
The system provides the applications developer with nearly all the standard sockets
functions, including RAW sockets. Any application that uses the standard sockets
API can execute on this stack. (Only the sendmsg() and recvmsg() functions not
supported.)
5
Service Features
Addressable Configuration
The configuration of the stack and its related services can be programmed though a
configuration interface in the form of a database addressable by identification and instance
tags. Tags make the configuration easy to search and easy to walk. The configuration
database can also be converted from its native form to a linear block of data for easy storage
in non-volatile memory.
Home Networks
When acting as a router, the software supports the creation of virtual home networks. This
allows a user to operate a home network that is independent of that provided by the ISP.
Isolation provides protection, and allows multiple devices to share the same public Internet
address.
Network Related Services
• Full Routing Support
• Telnet Server
• DHCP Server and Client
• DNS Server for home network
• PPP Client and Server support
• Serial Port / HDLC support
• Home/Virtual network support with NAT
• HTTP Server
• TFTP Client
• DNS client
• PPPoE Client and Sever support
6
TCP/IP Stack Components
OS
Adaptation
Layer
H
T
T
P
End-user
Applications
T
F
T
P
T
E
L
N
E
T
D
H
C
P
D
N
S
Standard BSD Sockets Interface
UDP
Network
Service
Manager
Network
Initialization
Route
Manager
IF
Manager
TCP
ICMP
IP
NAT
ARP
PPP
Ethernet IF
Serial IF
Network Control Library
C
O
N
F
I
G
U
R
A
T
I
O
N
OS Library
HAL Library
Net Tools Library
Hardware Abstraction Layer
Stack Event
Scheduler
Ethernet
Packet
Driver
Timer
Driver
Serial
Port
Driver
TCP/IP Stack Components
TCP/IP Stack Library
7
Library Components
Source Code Available
Application programmer can customize
system initialization and task scheduling.
Network Control Library
System programmer can customize OS API
and kernel exclusion methods.
OS Library
OEM can adapt to new hardware platform or
add new hardware device types.
HAL Library
Network services can be added and existing
services purged without modifying library.
Net Tools Library
Standard TCP/IP Stack library is compatible
with all C6000 environments.
TCP/IP Stack Library
Source Code Restricted
8
Library Components
Source Code Available
TCP/IP NDK
Application programmer can customize
system initialization and task scheduling.
Network Control Library
System programmer can customize OS API
and kernel exclusion methods.
OS Library
OEM can adapt to new hardware platform or
add new hardware device types.
HAL Library
Network services can be added and existing
services purged without modifying library.
Net Tools Library
TCP/IP Stack Porting Kit
Standard TCP/IP Stack library is compatible
with all C6000 environments.
TCP/IP Stack Library
Source Code Restricted
9
TCP/IP Architecture Overview
• TCP/IP Stack Library Overview
• Network Application Overview
• Porting to New Hardware
• TCP/IP Stack Platform Environments
10
Network Application Overview
• DSP Application Integration Criteria
• Network Control Module (NETCTRL)
• Network System Initialization
• Task Initialization via Callback Functions
• Event Scheduling
• Network Configuration System
• Service Callback Function
• File Descriptor Environment
11
DSP Application Integration:
Compatibility Criteria
Custom Scheduling
DSP applications schedule their operations by interrupts, timers, and semaphores,
or by calling each DSP task in a static scheduling loop.
Task Priority
DSP/BIOS allows for 15 different task priority levels. Applications rely on task
priority to make sure important operations are performed first. However, there is
no standard method of defining relative priority levels.
Chip Support Library
DSP application programmers have come to rely on the C6000 Chip Support
Library (CSL) to provide consistent access to DSP peripherals. Some addition
functions (like DMA based memory copy) are also provided.
Built on DSP/BIOS
DSP/BIOS is just what the name implies - a BIOS. Application programmers use
DSP/BIOS as a starting block for building more complex operating systems.
Unfortunately, each resulting custom OS will defer slightly from the next.
12
Network Control Module Diagram
NETCTRL is the Heart of the Network Application:
Network
Application
NETTOOLS
Configuration
Manager
NETCTRL
Initialization
OS
Adaptation
Layer
Low Level Support
(HAL) Library
NETCTRL
Scheduler
TCP/IP Stack
Library
13
Network Control Module
The Network Control Module (NETCTRL) is always provided
in source form. This module is forms the heart of the system
and performs the following tasks:
• Initialize the TCP/IP stack and low level drivers.
• Open and maintain high level device drivers.
• Boot and maintain system configuration
• Interface to device drivers and schedule driver events
• Interface to TCP/IP stack and kernel level mode switch
• Unload system configuration and cleanup drivers on exit
14
NETCTRL: System Initialization
Proper system initialization is comprised of several steps, but the
NETCTRL module offloads much of the common initialization work.
Network application initialization includes:
• Call the NETCTRL NC_SystemOpen() function to prepare for startup.
• Create and load a configuration using the Configuration Manager.
• Call the NETCTRL NC_NetStart() function to startup the network.
(passes in handle to configuration and pointers to callback functions)
• The return code from NC_NetStart() is the calling argument from
NC_NetStop(). It can be used to determine if NC_NetStart() should
be called again for reboot.
•
After all resources are freed, NC_SystemClose() completes shutdown.
15
NETCTRL: Callback Functions
The Network Control Module (NETCTRL) supplies a set of system
callback messages made for the following reasons:
System Initialization (NetStartCb)
This initialization call is made when the system is initialized and ready for
network applications. All task threads should be created at this time.
System Shutdown (NetStopCb)
The shutdown call is made after the system has shutdown, and the
configuration has been unloaded. All task threads should be destroyed as
this time.
IP Addressing Change (NetIPCb)
This call is made whenever an IP address is added or removed from the
system. This is useful in detecting addressing changes in dynamic
environments like PPP.
16
NETCTRL: Event Scheduling
The NETCTRL module acts as the interface between the HAL and
the rest of the system. It is in charge of checking for HAL events,
and calling the drivers to process events in kernel mode.
• Simple “infinite” loops waits for NC_NetStop() to be called.
• Device checking is done continuously (polling mode), or when a wellknown global semaphore is signaled by a HAL device from an ISR
(interrupt mode).
• NETCTRL tracks HAL events, switches into kernel mode, and
then calls the HAL to process indicated events.
• Source code to NETCTRL allows drivers in the HAL to be changed
without altering the TCP/IP stack libraries.
17
NETCTRL Scheduling : Polling
Main
Application
- NETCTRL runs main
polling loop
- All DSP tasks are also called
from this loop
Ethernet Driver
(HAL) Library
NETCTRL
Initialization
TCP/IP Stack
Library
NETCTRL
Scheduler
Polling
Loop
DSP Task
DSP Task
DSP Task
18
NETCTRL Scheduling : Interrupts
Main
Application
- NETCTRL waits on global
semaphore
- Data arrives via ISR and HAL
signals semaphore
Ethernet Driver
(HAL) Library
NETCTRL
Initialization
TCP/IP Stack
Library
NETCTRL
Scheduler
Event
Handler
Semaphore
- Event Handler returns from
semaphore and calls HAL to
send data to the stack
- Other DSP tasks are run from
other semaphores, or POLL in
a lower priority loop.
19
NETCTRL Kernel Exclusion
The Network Control Module enters an exclusive Kernel mode
before calling the HAL to send data to the TCP/IP stack. Two
different methods are available to prevent other modules from
reentering the stack.
Task Priority Method
The fastest method for maintaining exclusivity in Kernel mode is to raise
the priority of the task thread. It does not need to be the highest priority in
the system, but it must be a higher priority than any other task that can
potentially call into the stack.
Semaphore Method
A slightly less efficient method requires that a task get a semaphore
“token” (via SEM_wait()) before entering Kernel mode, and then to release
the token (via SEM_post()) when exiting. This method allows the stack to
operate independently of task priority, but is a little slower.
20
Network Configuration System
The entire network system is maintained via a central addressable
configuration system, and configuration manager programming API.
• Configurations can be created at run time, or loaded from memory
buffer.
• Changes to active configurations are immediately reflected in the
system via service callback functions.
• Callback functions are user maintainable and expandable.
• Current configuration entries include:
•
•
•
•
Services (DHCP, DNS, HTTP, etc.)
IP Networks and gateway routes
DHCP and PPP client records
Other system information
21
Net Configuration Example 1
Problem: Add the following static network binding for
physical network interface “1”:
Domain Name: “sample.net”
IP address: “192.168.1.12”
Netmask: “255.255.255.0”
CI_IPNET NA;
// Manually configure our local IP address
bzero( &NA, sizeof(NA) );
NA.IPAddr = inet_addr(“192.168.1.12”);
NA.IPMask = inet_addr(“255.255.255.0”);
strcpy( NA.Domain, “sample.net” );
NA.NetType = 0;
// Standard Network (no flags)
// Add the address to interface 1
CfgAddEntry( hCfg, CFGTAG_IPNET, 1, 0, sizeof(CI_IPNET), (UINT8 *)&NA, 0 );
22
Net Configuration Example 2
Problem: Add the following “default” route to the system:
IP address: “0.0.0.0”
Netmask: “0.0.0.0”
IP Gateway: “192.168.1.1”
CI_ROUTE RT;
// Add the default gateway.
bzero( &RT, sizeof(RT) );
RT.IPDestAddr = inet_addr(“0.0.0.0”);
RT.IPDestMask = inet_addr(“0.0.0.0”);
RT.IPGateAddr = inet_addr(“192.168.1.1”);
CfgAddEntry( hCfg, CFGTAG_ROUTE, 0, 0, sizeof(CI_ROUTE), (UINT8 *)&RT, 0 );
23
Net Configuration Example 3
Problem: Use DHCP protocol to automatically create
a binding for network interface “1”.
CI_SERVICE_DHCPC DHCPC;
// Specify DHCP Service on IF-1
bzero( &DHCPC, sizeof(DHCPC) );
DHCPC.cisargs.Mode
= CIS_FLG_IFIDXVALID;
DHCPC.cisargs.IfIdx = 1;
DHCPC.cisargs.pCbSrv = &ServiceReport;
CfgAddEntry( hCfg, CFGTAG_SERVICE, CFGITEM_SERVICE_DHCPCLIENT, 0,
sizeof(CI_SERVICE_DHCPC), (UINT8 *)&DHCPC, 0 );
24
Service Callback Function
The configuration service provider supplies a network
service callback function to report the status of individual
network services launched via the system configuration.
• All the standard network services report their status to this single
callback function (DHCP, Telnet, HTTP, etc.).
• The application supplied callback function can act on the network
service status changes as they happen.
// Example Service Status Report Callback
static char *TaskName[] = { "Telnet","HTTP","NAT","DHCPS","DHCPC","DNS" };
static char *StatusStr[] = { "Disabled","Waiting","IPTerm","Failed","Enabled" };
static char *ReportStr[] = { "","Running","Updated","Complete","Fault" };
static void ServiceReport( uint Item, uint Status, uint Report, HANDLE h )
{
printf( "Service Status: %-9s: %-9s: %-9s: %03d\n",
TaskName[Item-1], StatusStr[Status],
ReportStr[Report/256], Report&0xFF );
}
25
File Descriptor Environment
The TCP/IP Stack Library provides its own file descriptor
environment for sockets and full duplex pipes. Each task
thread allocates its own private file descriptor table.
• Allocate a file descriptor table with fdOpenSession(), and free
it with fdCloseSession().
• Some addition “standard API” descriptor based functions are
provided because they have become a defacto part of the
sockets programming API: ( fdSelect(), fdClose(), fdError() )
• Functions are provided to convert integer descriptors into global
file handles for transfer to another task ( fdGetFileHanlde(),
FileHandleGetFd() ).
• Standard sockets API for socket operation.
• Connection oriented pipes for non-TCP inter-task communication.
26
CSL and DSP/BIOS
In order to be compatible with all DSP application frameworks, the
TCP/IP stack software must be compatible with CSL, and allow itself to
be adapted to different DSP/BIOS based OS environments.
CSL Compatibility
The only stack components to touch the DSP peripherals are the HAL
device drivers and OS adaptation layer. Both are compatible with the latest
release of CSL.
DSP/BIOS Based OS Compatibility
In order to remain compatible with the various DSP/BIOS based operating
environments, the TCP/IP stack uses a thin OS adaptation layer. This
allows a system programmer to adapt the stack to run in any DSP/BIOS
based environment by adjusting the adaptation layer.
27
TCP/IP Architecture Overview
• TCP/IP Stack Library Overview
• Network Application Overview
• Porting to New Hardware
• TCP/IP Stack Platform Environments
28
Porting to New Hardware
¾ All low level hardware devices are isolated in a
separate HAL layer (packet, timer, serial port).
¾ Packet and serial port low level drivers are comprised
of hardware independent API’s and hardware specific
“mini-drivers”. The amount of “new” code in a driver is
small.
¾ The HAL layer mainly interacts with the NETCTRL
layer. User has access to both layers and can
customize the interface as necessary.
29
TCP/IP Architecture Overview
• TCP/IP Stack Library Overview
• Network Application Overview
• Porting to New Hardware
• TCP/IP Stack Platform Environments
30
TCP/IP Stack Platforms
The Stack Library's OS Adaptation Layer Allows for a Variety of
System Software Environments
Direct DSPBIOS Port
In a direct port, applications can all the stack's OS abstraction layer or
the DSPBIOS API interchangeably.
Custom OS API
For environments that require more application control and uniformity,
a custom OS API can be built on top of the OS adaptation layer and
DSPBIOS API to provide a seamless programming environment.
Extended BIOS / Framework API
Standardizing a custom API as a DSPBIOS extension and adding
system support for DAIS frameworks provides a standard platform on
which to build network ready DAIS framework applications.
31
Direct DSP/BIOS Port
Network applications call OS adaptation
layer, or DSP/BIOS interchangeably.
Network Application
NETTOOLS
Services Library
DSPBIOS
Operating
System
Adaptation
Layer
TCP/IP Stack
Library
Low Level Support
(HAL) Library
TCP/IP Stack Package
32
Custom OS API
Network applications call custom Vendor
OS, which is built up from DSP/BIOS
Network Application
NETTOOLS
Services Library
Vendor OS API
OS Adaptation
Layer
TCP/IP Stack
Library
DSPBIOS
Low Level Support
(HAL) Library
TCP/IP Stack Package
33
Extended BIOS / Framework API
TCP/IP can be integrated with with DSP/BIOS to form a
BIOS/Framework API to act as a standard DAIS
Framework Platform.
DAIS Algorithm
DAIS Algorithm
DAIS Algorithm
DAIS Algorithm
Network / Framework
Application
NETTOOLS
Services Library
Extended BIOS / Framework API
OS Adaptation
Layer
DSPBIOS
TCP/IP Stack
Library
HAL
Library
Standard Device
Interface Layer
34