Internet Control Message Protocol

The Internet Control Message Protocol (ICMP) is one of the core protocols of the Internet protocol suite. It is chiefly used by networked computers’ operating systems to send error messages—indicating, for instance, that a requested service is not available or that a host or router could not be reached.

ICMP differs in purpose from TCP and UDP in that it is not used to send and receive data between end systems. It is usually not used directly by user network applications, with some notable exceptions being the ping tool and traceroute.
Internet control message protocol is part of the Internet protocol suite as defined in RFC 792. ICMP messages are typically generated in response to errors in IP datagrams (as specified in RFC 1122) or for diagnostic or routing purposes.

The version of ICMP for Internet Protocol version 4 is also known as ICMPv4, as it is part of IPv4. IPv6 has an equivalent protocol, ICMPv6.

ICMP messages are constructed at the IP layer, usually from a normal IP datagram that has generated an ICMP response. IP encapsulates the appropriate ICMP message with a new IP header (to get the ICMP message back to the original sending host) and transmits the resulting datagram in the usual manner.

For example, every machine (such as intermediate routers) that forwards an IP datagram has to decrement the time to live (TTL) field of the IP header by one; if the TTL reaches 0, an ICMP Time to live exceeded in transit message is sent to the source of the datagram.

Each ICMP message is encapsulated directly within a single IP datagram, and thus, like UDP, ICMP is unreliable.

Although ICMP messages are contained within standard IP datagrams, ICMP messages are usually processed as a special case, distinguished from normal IP processing, rather than processed as a normal sub-protocol of IP. In many cases, it is necessary to inspect the contents of the ICMP message and deliver the appropriate error message to the application that generated the original IP packet, the one that prompted the sending of the ICMP message.

Many commonly-used network utilities are based on ICMP messages. The traceroute command is implemented by transmitting UDP datagrams with specially set IP TTL header fields, and looking for ICMP Time to live exceeded in transit (above) and “Destination unreachable” messages generated in response. The related ping utility is implemented using the ICMP “Echo request” and “Echo reply” messages.

Links:

http://candle.ctit.utwente.nl/wp5/tel-sys/exercises/icmp/icmp.html

http://en.wikipedia.org/wiki/Internet_Control_Message_Protocol

Connecting Embedded Applications to the Internet

Where the Internet may have been a dedicated network for computer data
exchange in it’s infant years, today more and more small (non-PC based)
intelligent “machines” are connected to the Network of Networks. The
prediction is that by 2005, the amount of non-PC users on the Internet will far
exceed the amount of PC’s!
Today, a highly integrated microcontroller can handle the functional control of
these machines. To connect the microcontroller to the Internet, one must
implement a protocol stack on the device. To function, this protocol usually
requires a powerful processor, a complete operating system, and a large
amount of memory. In this case, the implementation of a stand-alone Internet
protocol stack could be a solution.
In order to design an embedded system, one must design both the hardware
around a microcontroller and the software. Depending on the target hardware
as well as the complexity of the problem, the developer has to decide whether
to use an operating system. According to market analysis, more than 75% of
the embedded applications use a proprietary or free operating system, about
25% do not use an operating system. Big operating systems usually have
Internet protocols already built-in, whereas deeply embedded systems do not
yet provide a TCP/IP (Transmission Control Protocol/Internet Protocol) stack.
However, a 8- or 16-bit microcontroller may not have enough resources for the
implementation of an operating system. Software implementations without
operating systems can be found in less complex applications often using small
microcontrollers with strict hardware and runtime restrictions. The choice of
writing standalone code is often made because of the need to optimize memory
usage, code size, and run-time behavior. Since the writing of this standalone
code is target specific, it is often not portable to other targets.

Links:   

http://www.freescale.com/files/microcontrollers/doc/app_note/AN2304.pdf

User Datagram Protocol (UDP)

 When it comes to moving all that information across the Internet there is not only one choice when it comes to transport protocols. There are two. Namely, TCP and UDP. In this article we will look at the User Datagram Protocol, aka UDP.

Most everyone is already familiar with TCP as a transport protocol. Please refer to my previous posts for TCP/IP protocol and TCP/IP for Microcontrollers.  Not as many though are as knowledgeable with UDP as a transport protocol. That is for a good reason. Almost every piece of data out there whether it be application, session, or other layer is transported via trusty old TCP. This brings to mind another thing I hear quite often from people, “Yes, TCP is guaranteed to get there, you know.” This statement, in fact, is quite wrong.

TCP or Transmission Control Protocol is only connection oriented. UDP or User Datagram Protocol however is connectionless. What does that mean exactly? Well, if you have read the articles of mine on TCP you will have noted that TCP has a great many metrics included in its header. These very same metrics, i.e.: TCP sequence number, acknowledgement number, are what makes it connection oriented. Lastly, TCP had a standard header length of twenty bytes, vice eight for UDP.

User Datagram Protocol (UDP) is one of the core protocols of the Internet protocol suite. Using UDP, programs on networked computers can send short messages sometimes known as datagrams (using Datagram Sockets) to one another. UDP is sometimes called the Universal Datagram Protocol.

 Links:

http://erg.abdn.ac.uk/users/gorry/course/inet-pages/udp.html

http://www.windowsnetworking.com/articles_tutorials/Understanding-UDP-Protocol.html

http://en.wikipedia.org/wiki/User_Datagram_Protocol

TCP/IP Protocol

 An increasing number of people are using the Internet and, many for the first time, are using the tools and utilities that at one time were only available on a limited number of computer systems (and only for really intense users!). One sign of this growth in use has been the significant number of TCP/IP and Internet books, articles, courses, and even TV shows that have become available in the last several years; there are so many such books that publishers are reluctant to authorize more because bookstores have reached their limit of shelf space! This memo provides a broad overview of the Internet and TCP/IP, with an emphasis on history, terms, and concepts. It is meant as a brief guide and starting point, referring to many other sources for more detailed information.

While the TCP/IP protocols and the Internet are different, their histories are most definitely intertwingled! This section will discuss some of the history. For additional information and insight, readers are urged to read two excellent histories of the Internet: Casting The Net: From ARPANET to INTERNET and beyond… by Peter Salus (Addison-Wesley, 1995) and Where Wizards Stay Up Late: The Origins of the Internet by Katie Hafner and Mark Lyon (Simon & Schuster, 1997). In addition, the Internet Society maintains a number of on-line “Internet history” papers at http://www.isoc.org/internet/history/. 

 Links:

http://www.protocols.com/pbook/tcpip1.htm

http://www.isoc.org/internet/history/