ST AN3000 Application note

AN3000

Application note

Configuring the NicheLite™ TCP/IP stack for the STM32F107xx microcontroller

Introduction

STM32F107xx connectivity line microcontrollers feature a complete 10/100 Ethernet MAC supporting MII and RMII with hardware support for the IEEE1588 precise time protocol, enabling Ethernet connectivity for real-time applications.

The NicheLite TCP/IP stack, from InterNiche Technologies, supports STM32F107xx connectivity line microcontrollers and is provided free-of-charge to ST customers. This stack is a scaled down version of the full stack available from InterNiche. For download information, please refer to STMicroelectronics web site www.st.com

The objective of this application note is to introduce the NicheLite stack for STM32F107xx and describe the integration considerations to be taken into account when developing a user application including the performance and memory size aspects.

This application note is structured as follows:

■A short glossary is provided in Section 1

■A general introduction to TCP/IP is presented in Section 2

■The Section 3 introduces the NicheLite stack

■Section 4 and 5 describe the NicheLite stack configuration and optimization

■NicheLite stack debugging tips are given in Section 6

■Section 7 presents the NicheTask OS and how to use it in your application

■Lastly, Section 8 describes the NicheLite package for STM32F107xx and the available demonstrations

This application note is intended to complement the documentation provided by InterNiche, which should be referred to for detailed information.

August 2009

Doc ID 15903 Rev 1

1/54

www.st.com

Contents	AN3000

Contents

1	Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		6
2	TCP/IP introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		7
	2.1	TCP/IP a layered protocol stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	7

2.1.1 The application layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.2 The transport layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 2.1.3 The Internet layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.4 Link layer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.1.5 Example of network devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 The protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 2.3 Introduction to some TCP/IP protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

	2.3.1	IP: Internet protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	11
	2.3.2	ARP: address resolution protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	12
	2.3.3	ICMP: internet control message protocol . . . . . . . . . . . . . . . . . . . . . . . .	12
	2.3.4	UDP: user datagram protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	13
	2.3.5	TCP: transmission control protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . .	14
	2.3.6	BOOTP: bootstrap protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	14
	2.3.7	DHCP: dynamic host configuration protocol . . . . . . . . . . . . . . . . . . . . .	15
	2.3.8	TFTP: trivial file transfer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	15
	2.3.9	FTP: file transfer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	15
	2.3.10	PPP: point-to-point protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	15
	2.3.11	SMTP: simple mail transfer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . .	15
	2.3.12	POP3: post office protocol version 3 . . . . . . . . . . . . . . . . . . . . . . . . . . .	16
	2.3.13	SNMP: simple network management protocol . . . . . . . . . . . . . . . . . . . .	16
	2.3.14	HTTP: hypertext transfer protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	16
	2.3.15	Telnet: remote terminal protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	16
3	NicheLite TCP/IP stack overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		17

3.1 Stack structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 3.2 NicheLite protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 3.3 NicheLite implementation introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 21

3.3.1 Packet demultiplexing flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22 3.3.2 Packet buffer memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 3.3.3 Memory management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27

2/54	Doc ID 15903 Rev 1

AN3000 Contents

4	NicheLite TCP/IP stack configuration . . . . . . . . . . . . . . . . . . . . . . . . . .		29
	4.1	NicheLite modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	29
	4.2	IP address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	29
	4.3	MAC address . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	30
	4.4	Keepalive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	30

4.4.1 Enabling Keepalive in NicheLite . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30 4.4.2 Keepalive timeout tuning in NicheLite . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5	NicheLite TCP/IP stack optimization . . . . . . . . . . . . . . . . . . . . . . . . . . .		32
6	Debug tips . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		35
	6.1	NicheTool diagnostic console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	35
	6.2	Network statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	36
	6.3	Packet debugging . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	37
	6.4	Socket and packet queues . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	38
7	NicheTask OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		40
	7.1	Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	40

7.1.1 Superloop (OS disabled) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40 7.1.2 Multitasking system (OS enabled) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

7.2 Configuring the NicheTask OS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 7.3 Implementing your own system menus and tasks . . . . . . . . . . . . . . . . . . 42

		7.3.1	Task declaration (in demo_server.c file) . . . . . . . . . . . . . . . . . . . . . . . .	42
		7.3.2	Task function definition (in demo_server.c file) . . . . . . . . . . . . . . . . . . .	43
		7.3.3	Task creation (in tk_misc.c file) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	44
8	NicheLite package for STM32F107xx . . . . . . . . . . . . . . . . . . . . . . . . . .			45
	8.1	File structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		45
	8.2	Description of available demonstration programs . . . . . . . . . . . . . . . . . .		46
	8.3	UDP/TCP client/server demo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .		47
		8.3.1	Client processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	47
		8.3.2	Server processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	50
9	Revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .			53

Doc ID 15903 Rev 1

3/54

List of tables	AN3000

List of tables

Table 1. ICMP errors and queries. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 Table 2. SMTP commands . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 Table 3. Mini-socket and BSD socket APIs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21 Table 4. Document revision history . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

4/54	Doc ID 15903 Rev 1

AN3000	List of figures

List of figures

Figure 1.	Protocol stack layers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	. 7
Figure 2.	Network devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	. 8
Figure 3.	Protocol interconnections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	. 9
Figure 4.	User data path example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	10
Figure 5.	Data encapsulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	11
Figure 6.	IP protocol transmission and reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	12
Figure 7.	UDP datagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	13
Figure 8.	UDP protocol transmission and reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	13
Figure 9.	TCP protocol transmission and reception. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	14
Figure 10.	Connectivity application layers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	17
Figure 11.	Stack components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	18
Figure 12.	Protocols available in NicheLite stack . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	19
Figure 13.	Demos available in STM32 package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	19
Figure 14.	Packet demultiplexing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	22
Figure 15.	Buffer management (1). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	23
Figure 16.	Buffer management (2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	24
Figure 17.	Buffer management (3). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	24
Figure 18.	Buffer management (4). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	25
Figure 19.	Buffer management (5). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	26
Figure 20.	Buffer management (6). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	27
Figure 21.	Memory management: a serious situation that may become critical . . . . . . . . . . . . . . . . .	28
Figure 22.	Memory management: a critical situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	28
Figure 23.	NicheTool console . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	36
Figure 24.	Packet log . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	37
Figure 25.	NicheLite package file structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	45
Figure 26.	Client task processing. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	49
Figure 27.	Server task processing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .	52

Doc ID 15903 Rev 1

5/54

Glossary	AN3000

1Glossary

●ARP Address resolution protocol

●BSD Berkeley software distribution

●BOOTP Bootstrap protocol

●DHCP Dynamic host configuration protocol

●DNS Domain name System

●FTP File transfer protocol

●HTTP Hypertext transfer protocol

●ICMP Internet control message protocol

●IP Internet protocol

●POP3 Post office protocol version 3

●PPP Point to point protocol

●SMTP Simple mail transfer protocol

●SNMP Simple network management protocol

●Socket A socket is a combination of an IP address and a port number which is mapped to the application protocol.

●TCP Transmission control protocol

●Telnet Remote terminal protocol

●TFTP Trivial file transfer protocol

●UDP User datagram protocol

6/58	Doc ID 15903 Rev 1

AN3000	TCP/IP introduction

2 TCP/IP introduction

2.1TCP/IP a layered protocol stack

The TCP/IP stack is organized in several layers. Figure 1 below presents this layered architecture.

Figure 1. Protocol stack layers

	!PPLICATION LAYER
	4HEHMAIN INTERFACE FOR THE USER	0ORT NUMBER AND OR R
	(IGHER LEVEL PROTOCOLSOSUCH ASS4&40 FORRFILEETRANSFERRARE	OTHERHSESSIONNIDENTIFIERS
	IMPLEMENTEDMAT THIS LAYER
	4RANSPORT ,AYER	0ORT NUMBER
	%ND TO END CONNECTIONS 5$0IANDN4#0 AND RELIABILITY 4#0
	)NTERNET ,AYER	)0 !DDRESS
	4RANSFERRDATA FROMOSOURCE TO DESTINATION INO GUARANTEE OF DELIVERY

	-!# ,AYER
	-!#!!DDRESS
	-ANAGE COMMUNICATIONOBETWEEN NETWORK ENTITIES
$ATA ,INK	PHYSICAL LAYER S FRAME MANAGEMENT TPHYSICAL LAYER S ERROR DETECTION
,AYER
	0HYSICALL,AYER
	4RANSPORTTTHEHDATAAON THE PHYSICAL SUPPORT ELECTRIC SIGNAL

AI

2.1.1The application layer

All the upper layer protocols such as HTTP and FTP are located in this layer, these protocols offer higher level features such as file transfer, configuration, network management to the user application. Depending of their characteristics, these protocols rely on UDP, TCP or other protocols

2.1.2The transport layer

The transport layer provides an end to end connection service. End to end communication means that one (or more) applications on one device can send data to one (or more) applications on other device(s).

One or more port numbers are assigned to each application allowing the transport layer to differentiate the applications running on the same device. The device is identified using the IP address (see internet layer description), the combination of IP address + port number (also called a socket) allows data to be addressed to a specific application running on a specific device.

Unlike the UDP protocol that does not guarantee the delivery; the TCP protocol ensures the reliability of the connection with re-sequencing and flow control mechanisms.

Note:	A socket is a combination of an IP address and a port number which is mapped to the
	application protocol.

Doc ID 15903 Rev 1

7/58

TCP/IP introduction	AN3000

2.1.3The Internet layer

This layer allows transferring data from a source to a destination on separate networks, to perform this inter-network communication this layer uses the IP address (named after the IP protocol). The IP protocol provides a way to send data from a source to a destination but does not guarantee the delivery of the data, it is called a connectionless service.

2.1.4Link layer

The Link layer can be subdivided in 2 parts, the Media Access Layer (MAC) and the physical layer that transports the data on the physical medium (electrical signal...)

The MAC layer handles the physical layer's error detection and manages the communication between network entities using a dedicated address called the MAC address.

The Link layer is usually fully implemented in hardware, in the STM32F107xx the MAC layer features are implemented in an Ethernet controller embedded in the MCU, while the physical layer is handled by an external chip (PHY).

2.1.5Example of network devices

This part presents some network devices, starting with devices operating at the link layer, and then giving examples of devices operating at the layers above.

Figure 2. Network devices

!PPLICATION LAYER
4HEHMAIN INTERFACE FOR THE USER			0ORT NUMBEREAND ORO
(IGHER LEVELLPROTOCOLSOSUCH ASS4&40 FORRFILEETRANSFER			OTHERHSESSIONNIDENTIFIERS
ARERIMPLEMENTED ATATHIS LAYER
4RANSPORT LAYER
%ND TO END CONNECTIONS 5$0IANDN4#0			0ORT NUMBER
ANDNRELIABILITYT 4#0
)NTERNET LAYER,
4RANSFER DATA FROMOSOURCE TO DESTINATION			)0 ADDRESS
NO GUARANTEE OF DELIVERY
		-!# LAYER,
		-ANAGE COMMUNICATIONOBETWEEN NETWORK ENTITIES
		PHYSICAL LAYER S FRAME MANAGEMENT T -!#!ADDRESS
$ATA ,INK LAYER		PHYSICAL LAYER S ERROR DETECTION
		0HYSICALLLAYER
		4RANSPORTSTHEHDATAAON THE PHYSICAL SUPPORT
		ELECTRICAL SIGNALL

2OUTERS

3WITCHES

2EPEATING HUBS

AI

●A repeater hub is a simple device inserted between 2 parts of a network. It operates at the electrical signal level. It forwards all the signals received from one connector to the other connectors. In a half duplex network it manages the collision detection as well.

This device is transparent to the network.

●Switches and bridges operate at the data link layer. Switches are used in a single network like repeater Hubs but are more intelligent. A switch is able to use the source and destination MAC Addresses contained in the Ethernet header of a packet to forward it appropriately.

8/58	Doc ID 15903 Rev 1

AN3000	TCP/IP introduction

●Contrary to switches and hubs, routers are able to interconnect several networks by operating at the network layer and using the IP addresses of the packets.

These are simple examples, many products operate at different layers. For example “layer 3 switches” are able to perform some router operations by using IP addresses (layer 3 or network layer) while also performing their data link layer operations (also called layer 2 operations).

2.2The protocols

If we put all this information together and add the main protocols of each layer we get the diagram shown in Figure 3.

Figure 3. Protocol interconnections

%XAMPLE 4#0 )0 -ODEL				0ROTOCOLS
DEVICES	)DENTIFIER 4YPE
	!PPLICATION ,AYER	EMAIL			/THER			#ONFIGURATION
		3-40	0/0	4ELNET		3YS,OG		$(#0 C
	0ORT NUMBER	777					.ETWORK	"//40
	AND OR ROTHERE
	SESSIONN	(440					MANAGEMENT
							3.-0
	IDENTIFIERS			&ILE 4RANSFER				$OMAIN .AMES
		0ING		&40		4&40		$.3
	4RANSPORTO,AYER		4#0				5$0
	0ORT NUMBER
2OUTERST	)NTERNET ,AYER	)#-0					)0
	)0 !DDRESS
							!20
3WITCHES	,INK ,AYER	-EDIA !CCESS #ONTROL				%THERNET
							000		/THER
	-!#!!DDRESS		-!#
2EPEATING		0HYSICAL ,AYER 0(9					0HYSICAL
(UBS							,AYER
									AI

On the right part of Figure 3 you can see which layer the most common protocols operate at and what the interconnections are between these protocols.

To illustrate this further we can follow the “path” of some user data, a user file for example, to be sent over the network from a device A (MAC Address = AA-AA-AA-AA-AA-AA / IP address = 128.128.128.128) to a device B (MAC Address = BB-BB-BB-BB-BB-BB / IP address = 129.129.129.129). This is shown in Figure 4.

Note:	Please note that these MAC and IP addresses may be invalid, they are just chosen for this
	example.

Doc ID 15903 Rev 1

9/58

TCP/IP introduction	AN3000

Figure 4.	User data path example
%XAMPLE 4#0 )0-ODEL				0ROTOCOLS
DEVICES	)DENTIFIER 4YPE
	!PPLICATION ,AYER	EMAIL			/THER		#ONFIGURATION
		3-40	0/0	4ELNET	3YS,OG		$(#0 C
	0ORT NUMBER	777			5SER	.ETWORK	"//40
	AND OR OTHER
	SESSIONN	(440				MANAGEMENT
				&ILE4RANSFER		3.-0
	IDENTIFIERS						$OMAIN .AMES
		0ING		&40	4&40		$.3
	4RANSPORTO,AYER		4#0			5$0
	0ORT NUMBER
	)NTERNET ,AYER
2OUTERST		)##-0				)0
	)0 !DDRESS
						!20
3WITCHES	,INK ,AYER	-EDIA !CCESS #ONTROL			%THERNET
						000		/THER
		0HYSICAL ,AYER 0(9
	-!# !DDRESS		-!#
2EPEATING						0HYSICAL
(UBS						,AYER
							AI

Here is a simplified description of the path:

1.The user application uses the TFTP service to send its file.

2.The TFTP uses the UDP service to send a TFTP header and some data, the port used by the UDP is port 69 (reserved for TFTP).

3.The UDP protocol adds a UDP header to the previous data and uses the IP service to send this updated data to device B. The IP address of B is provided to the IP service.

4.The IP protocol appends to the data an IP header containing the source IP address 128.128.128.128 and destination IP address 129.129.129.129 as well as other information. The IP protocol then uses the data link service to send this data to the physical layer.

5.The Data link layer builds an Ethernet frame containing the previously described data and a header containing the MAC address of device A and the MAC address of the destination address B.

BUT, there is a problem here: How does the TCP/IP stack know the MAC address of the destination? Either the MAC address is already known (stored in a table) or the TCP/IP stack has to find out the MAC address from the IP address. This is done using the ARP protocol (Address Resolution Protocol).

Therefore in order to send its data, the TCP/IP stack may have to send some ARP Ethernet frames first to get the MAC address of the destination. Once the stack knows the destination MAC address, it can complete step 5 above.

In this example we can see that each layer adds some information (header) to the data received from the layer above before using the layer below, this is called encapsulation.

10/58

Doc ID 15903 Rev 1

AN3000	TCP/IP introduction

Figure 5. Data encapsulation

5SER
					5SER $ATA
!PPLICATION LAYER
				4&40 (EADER	5SER $ATA
4RANSPORT ,AYER
	0ORT NUMBER		5$0$(EADER	4&40 (EADER	5SER $ATA
)NTERNET ,AYER
	)0 !DDRESS	)0 (EADER	5$0$(EADER	4&40 (EADER	5SER $ATA
$ATA	-!#!
,INK
	!DDRESS
,AYER
	%THERNET (EADER	)0 (EADER	5$0$(EADER	4&40 (EADER	5SER $ATA	%THERNET 4RAILER
						AI

2.3Introduction to some TCP/IP protocols

This section briefly describes the different protocols. The introduction order may seem more or less arbitrary as different applications use different protocols, but the intention is to start with a description of the most important protocols before covering the less commonly used ones.

2.3.1IP: Internet protocol

This protocol is one of the core protocols of the stack, most of the datagrams (TCP, UDP, ICMP, HTTP...) are transmitted using this protocol. IP provides a service for sending data from one identified network entity to another entity that may be located on a distant network. IP addresses are used to identify the source and destination devices.

While allowing data to be sent to devices over the networks, the IP protocol does not guarantee the delivery of this data, IP is a connectionless protocol.

Doc ID 15903 Rev 1

11/58

TCP/IP introduction	AN3000

Figure 6. IP protocol transmission and reception

3OURCE DEVICE		)0 PACKET !
3OURCEC)0 ADDRESS
4RANSMISSION ORDER		)0 PACKET "
	0ACKET !		)NTERMEDIATE
	0ACKET "
			NETWORK NODE
	0ACKET #	)0 PACKET #
		)NTERMEDIATE	)NTERMEDIATE
		NETWORK NODE	NETWORK NODE
$ESTINATIONNDEVICE
$ESTINATION )0)ADDRESS		)0 PACKET #	)NTERMEDIATE
2ECEPTIONNORDERR			NETWORK NODE
		)0 PACKET !
	0ACKET #
	0ACKET !
	0ACKET ! DUPLICATED	)0 PACKETE!
			AI

As shown in Figure 6, IP datagrams can be lost, duplicated, or received in any order... It is a “best effort delivery” mechanism, the reliability of the communication (retransmission, reordering of the packets) is not handled at this layer.

2.3.2ARP: address resolution protocol

The ARP is also a key element of the Internet protocol suite. As shown in Figure 6, the IP only uses IP addresses to identify the source and destination, but the physical layer requires a MAC address to transmit the data. The Address Resolution Protocol allows an emitting device to get the MAC address of the destination by knowing its IP address. These ARP requests and answers are sent by the stack itself, but the user application sometimes has to be aware of this mechanism (for example, the API may return a code like “ARP request sent”).

2.3.3ICMP: internet control message protocol

The ICMP protocol allows the communication of error messages and queries between entities over the network; it is actually a very important protocol, although it is less known. ICMP messages are encapsulated in a IP datagram for transmission.

Table 1 gives some examples of queries and error messages that can be sent by ICMP. These messages are acted on by the IP and the higher level protocols.

12/58

Doc ID 15903 Rev 1

AN3000			TCP/IP introduction
	Table 1.	ICMP errors and queries
		Errors	Queries
	Protocol unreachable		Echo request
	Port unreachable		Echo reply
	TTL (time to live) reaches 0 during transit		....
	...

2.3.4UDP: user datagram protocol

UDP is a simple datagram service allowing data to be sent over the network, it relies on IP. The UDP packet is very simple; it contains an 8-byte header and the data. The header just adds a source port and destination port number.

Figure 7. UDP datagram

5	$0	BIT SOURCECPORT NUMBER		BIT DESTINATION PORTINUMBER
(EADER			BIT 5$0 LENGTH	BIT 5$0 CHECKSUM
			DATA IF ANY

AI

The UDP is a connectionless protocol and has the same drawbacks as the IP layer. It is still used by a lot of protocols and applications. The simplicity of UDP is an advantage for applications where the upper layers already implement mechanisms that ensure the reliability of the communication, or for protocols that do not require this reliability.

Figure 8. UDP protocol transmission and reception

5$0$0ROTOCOL		5$0$PACKET !
5$0$SOURCECPORT		5$0$PACKET "
		5$0$PACKET #
)0 0ROTOCOL		)0 5$0 PACKETE!
3OURCEC)0 ADDRESS		)0 5$0 PACKET "			)NTERMEDIATE
		)0 5$0 PACKET #			NETWORK NODE
				)NTERMEDIATE	)NTERMEDIATE
					NETWORK NODE
)0 0ROTOCOL		)0 5$0 PACKET #
$ESTINATION		)0 5$0 PACKET !			)NTERMEDIATE
)0 ADDRESS	)0 0 5$0$PACKET !				NETWORK NODE
5$0$0ROTOCOL		5$0$PACKET #
5$0$$ESTINATION PORT 5$0$PACKET !
		5$0$PACKET !

AI

Doc ID 15903 Rev 1

13/58

TCP/IP introduction	AN3000

2.3.5TCP: transmission control protocol

The transmission protocol is one of the key elements of the Internet Protocol Suite. Unlike the IP and UDP protocols it provides a “connection oriented” service, allowing reliable communication between 2 devices on different networks. TCP relies on the IP service for the transmission of the data over the networks.

Figure 9. TCP protocol transmission and reception

	4#0#0ROTOCOL			!CKNOWLEDGE
				4#0#PACKET !
	4#0#SRCPORT	$ATA		4#0#PACKET
	4IMEOUTT RETRANSMISSION
				PACKETE!
				PACKET
				PACKET
		PACKETE"T RETRANSMITTED
	)0 0ROTOCOL		)0 5$0 PACKET
	$ESTINATION		)0 5$0 PACKET
			)0 0 5$0$PACKET
	)0 ADDRESS
	)0 5$0 PACKETE"T RETRANSMITTED
	4#0#0ROTOCOL			4#0#PACKET
	4#0#$EST	$ATA		4#0#PACKET
				4#0#PACKET
	PORT
	5$0 PACKETE" RETRANSMITTED
				!CKNOWLEDGE

AI

This reliability is achieved with the following mechanisms implemented in the TCP:

●A checksum to check the validity of the datagram like other protocols

●An acknowledge mechanism for the receiver to confirm to the sender the proper reception of a packet. If the sender does not receive this acknowledge after a timeout it resends the packet.

●If needed, the data to send over TCP is split in segments, each segment being transmitted in a separate TCP packet, the receiver has a re-sequencing mechanism to reorder packets if they are received out of order.

●Duplicated packets are identified and discarded by the TCP protocol

●A TCP window mechanism to allow a device to specify the buffer size available and prevent another device from sending more data than it can handle.

2.3.6BOOTP: bootstrap protocol

The Bootstrap protocol allows a device to get an IP address from a configuration server. It relies on the UDP service to operate. This protocol is embedded, for example, in the BIOS of some network devices to allow these devices to boot from the network.

14/58

Doc ID 15903 Rev 1

AN3000	TCP/IP introduction

2.3.7DHCP: dynamic host configuration protocol

DHCP also offers some of the services of the BOOTP protocol. It allows a device to get an IP address from a configuration server. Newer than the bootstrap protocol, the DHCP has more advanced features. Many devices now implement the DHCP client to retrieve an IP address, fewer device implement the server service that allocates the IP addresses. One of the advanced features of DHCP over BOOTP is the ability to allocate an IP address to a client for a limited time (the BOOTP allocation being unlimited). The DHCP supports the Bootstrap protocol.

2.3.8TFTP: trivial file transfer protocol

First defined in 1980, the TFTP protocol has a client/server architecture and allows file transfer over UDP using a simple mechanism allowing easy implementation in memory constrained devices.

To overcome the limitation of UDP that does not guarantee packet delivery, the receiver sends an acknowledge packet after reception of a packet. Only one packet (either data or acknowledge) is sent over the network at a time, reducing the performance compared to FTP protocol for example.

To summarize, the main advantage of TFTP is its simplicity, the drawback being its performance on high latency networks. This protocol is used for example to download boot loaders.

2.3.9FTP: file transfer protocol

FTP allows file transfer via the TCP protocol, and therefore it inherits its connection oriented characteristics. It also takes advantage of the window mechanism and reordering abilities of the TCP protocol, so that several packets can be sent over the network simultaneously increasing the performance. This client-server protocol uses 2 ports, one for data, the other one for control information.

FTP supports password based connections or anonymous users. Please note that FTP doesn't include an encryption mechanism, so the user name and password are sent over the network in clear text.

2.3.10PPP: point-to-point protocol

The point-to-point protocol (PPP) provides a standard method of transporting multiprotocol datagrams over point-to-point links. It is used over many types of physical networks including serial lines and Ethernet.

2.3.11SMTP: simple mail transfer protocol

The SMTP is a standard protocol used to transmit electronic mails across networks. It relies on the connection oriented TCP protocol. Like most network protocols it has a client/server architecture. The commands are coded in ASCII, making the frames easier to understand. Each command from the client is followed by an answer from the server.

Table 2 lists the commands supported by SMTP:

Doc ID 15903 Rev 1

15/58

TCP/IP introduction			AN3000
	Table 2.	SMTP commands
		Command	Description
	HELO or EHLO		Commands used by the client to identify itself
	MAIL FROM:		Identifies the originator of the message
	RCPT TO:		Identifies the recipient of the message
	DATA		Command used to send the content of the message
	QUIT		Terminate the email exchange

SMTP is a protocol for transmitting emails between devices that are always connected to the networks. It has no features for retrieving messages from a server (see POP3)

2.3.12POP3: post office protocol version 3

POP3 (Post Office Protocol version 3) is a protocol designed to retrieve emails from an account (mailbox) on a server (post office). It has no features for sending messages to servers (see SMTP).

2.3.13SNMP: simple network management protocol

This protocol relies on UDP to offer a coherent framework for managing networks. This is necessary, as networks are growing in size, complexity and diversity. It is a client /server (also called agent/manager) architecture.

This protocol has a 2 way communication scheme, the manager being able to ask the agent for some information, the agent also being able report events.

2.3.14HTTP: hypertext transfer protocol

HTTP is the protocol used by the World Wide Web; it has client/server architecture and uses a request/response mechanism to operate.

Once the connection is opened, the HTTP client (usually your browser) sends a request message to an HTTP server. The server returns a response message that usually contains the requested resource (an html file for example). The connection is then closed. The HTTP protocol does not maintain the connection between transactions.

2.3.15Telnet: remote terminal protocol

The Telnet protocol gets its name from Telecommunication network. The purpose of this protocol is to provide a bidirectional communication service on the Internet or on local area networks. Telnet can be used to access a remote host with a terminal. Telnet relies on the connection oriented TCP protocol.

16/58

Doc ID 15903 Rev 1

AN3000	NicheLite TCP/IP stack overview

3 NicheLite TCP/IP stack overview

This section provides an overview of the NicheLite TCP/IP stack. Section 3.1 introduces the structure of the stack. Section 3.2 describes the protocols available in the stack. Section 3.1 gives an introduction to the NicheLite stack implementation including packet demultiplexing and buffer management.

3.1Stack structure

As shown in Figure 10, a connectivity application can usually be divided in several parts:

●The application layers

●The TCP/IP stack layers

●The hardware abstraction layer, mainly containing the low level driver

Figure 10. Connectivity application layers

!PPLICATION

4#0 )0 3TACK

(ARDWARE AND $RIVERS

AI

A more detailed diagram is shown in Figure 11.

Doc ID 15903 Rev 1

17/58