Lecture #2 - Ethernet, IP, ICMP, TCP and UDP

How TCP and Other Protocols are Delivered

Upper level protocols are carried by lower level protocols. Each layer addresses a different problem.

This really means that the Protocol Data Units (PDUs or "packets") of the higher level protocol are encapsulated (contained within) in the PDUs of the lower level protocol.

For example:

Ethernet and 802.3 Frame Format

Preamble	7 bytes of `10101010`
Start of Frame	1 byte, of `10101011`
Source and Destination Address	These consists of 3 bytes of "Manufacturer ID", allocated by the IEEE and 3 bytes of "serial number". They are usually written as colon-separated hexadecimal byte values, eg: 08:00:20:0c:a3:55
Type/Length field	If less than or equal to 1500 decimal (0x5DC), then this is the length of an 802.3 packet. If more than 1500, this is the type of an "DIX (DEC/Intel/Xerox) Ethernet V2" packet. For example, `0x0800` indicates that the Ethernet frame encapsulates an IP (Internet Protocol) packet.
Data field	From 46 (preserves CSMA/CD minimum frame size requirement) to 1500 bytes.

802.2 LLC

The IEEE 802 standards committee wanted a way of indicating what higher level protocol was carried by an 802.3 data packet (in Ethernet V2, the type field already carries this information). To allow this, a new Logical Link Control layer was created between the MAC layer and higher layers, thus:

802.2 LLC Frame Format

DSAP, SSAP are Service Access Point addresses which specify the network layer protocol which generated this frame (SSAP) and the protocol for which it is destined (DSAP). IEEE specifies that 0xFE is used for the OSI network layer.

802.2 defines a variety of services:

Type-1 Connectionless: Operates exactly like Ethernet V.2
Type-2 Acknowledged Connectionless: Received frames are acknowledged, but no initial connection protocol is used.
Type-3 Connection Oriented: Just like HDLC!

802.2 SNAP

It became obvious after a short time that the 8-bit DSAP/SSAP field was clearly inadequate for all the possible "higher layer" protocols which might wish to use 802.2 encapsulation.

IEEE solved this problem by defining the Sub Network Access Protocol (SNAP) subset of 802.2 type-1 service.

An 802.2 SNAP frame looks like:

Note that for IP encapsulation in 802.2/SNAP, the "Protocol/Org ID" field is all zeros, and the "Type" field is the standard Ethertype value, 0x0800.

For Appletalk, which uses 802.2 SNAP encapsulation exclusively, the SNAP field is 0x080007809B.

Ethernet Protocol Hierarchy

The IP Datagram

The version field specifies the protocol version in use - currently set to 4.
A datagram is always a multiple of 4 bytes (32 bits) in length. The Total Length field gives the overall datagram length in bytes: up to 65536 bytes.
The datagram header, whose length may vary depending on IP options used, is padded to a 4 byte boundary. The HLEN field gives the header length in 32-bit words. Most datagrams have no options, hence HLEN is 5 (20 bytes).

MTU Sizes and Fragmentation

An IP datagram is encapsulated in an underlying protocol frame (eg, MAC layer (Ethernet)) for delivery.

For local delivery the datagram is normally arranged to fit into a single frame: for example, for delivery on an Ethernet a datagram should be <1500 bytes. This is called the Maximum Transmission Unit (or MTU) of the network.

All IP gateways (routers) are required to support an MTU of at least 576 bytes on all of their interfaces.

Where the datagram has to cross an unknown number of routers to arrive at its destination, the MTU of each of the networks traversed will generally be unknown. The IP protocol uses the Identification, Fragment Offset and Flags fields to allow a datagram to be fragmented for delivery across a network having a smaller MTU than the size of the datagram. The fragments are reassembled at the final destination (host or end-node), not within the network itself.

Fragmentation Control

For example, the following datagram is to be transferred across a network having an MTU of 500 bytes:

This datagram is fragmented thus:

Note that each of the fragments has a full IP header; in fact, it is a datagram with a bit set in the Flags field set to indicate that it is a fragment. The Fragment Offset field specifies which part of the original datagram this fragment forms. The Identification field is the same for all of the fragments of a fragmented datagram.

Another Flag bit indicates the last fragment, and still another is set if this datagram is not permitted to be fragmented.

Other Datagram Header Fields

Time To Live: This field specifies (in seconds) that the datagram is permitted to exist in the internetwork. It is set to a suitable high value when the datagram is generated and is decremented by each router that processes the datagram. When it reaches zero, the datagram is discarded and an error message returned to the originating host. The TTL field is designed to stop datagrams from looping in an inappropriately configured internet.
Protocol: This field specifies which higher layer protocol is encapsulated within the datagram, typically TCP or UDP (see later).
Header Checksum: A 16-bit checksum. A ones complement addition of all the 16 bit words in the header of the datagram (but not the data).
Source and Destination IP Addresses: Each datagram carries both addresses, as required in a connectionless protocol such as IP.
Data: The data field is simply an un-differentiated block of bytes, as required by the principle of layering - its format is understood by the overlying protocol, typically TCP or UDP.
IP Options: Outside the scope of this subject.

IP: Connectionless Datagram Delivery

IP data transfer across an internet is based on three fundamental principles:

Unreliable Delivery: Delivery of data is not guaranteed. A packet of data may be lost in the network, may be duplicated (ie: delivered twice) or may be delivered out of order. The IP service will not detect such conditions, nor will it notify the sender or receiver if they occur.
Connectionless Delivery: Each packet is treated entirely independently of all others. No information is kept as to which packets have been forwarded, and packets may travel over different routes to the same destination.
Best-Effort Delivery: The packet delivery mechanism is engineered to deliver packets if possible. It will not gratuitously drop packets: unreliability should only occur when underlying resources (eg. buffer space) are exhausted.

These specifications allow the IP service to concentrate on its job: delivering packets. Higher level protocols (usually TCP) transform the IP service into a reliable, sequenced interprocess communications mechanism.

The ICMP Protocol

The Internet Control Message Protocol is used by the IP datagram delivery system to communicate with the IP delivery system on another host - its operation is internal to the IP software on the hosts.

A router can fail to deliver a datagram for several reasons, including:

The destination is temporarily or permanently disconnected. This is called an unreachable destination.
The Time To Live counter expires.
Routers become congested and cannot process incoming traffic.

The IP software encapsulates ICMP messages into the data field of an ordinary datagram. For example, when a router drops a datagram, it sends an ICMP message to the originator of the datagram explaining the reason. It is up to the originator to take appropriate action to ensure that subsequent datagrams are not droppped.

There are several ICMP message types. The echo request and echo reply types are used by the ping utility to test reachability. Ping is by far the single most valuable tool available to the network manager.

Datagram Delivery

A datagram can be delivered in two ways:

Direct Delivery: The destination host is connected to the same underlying network (an Ethernet, for example) as the source host. This means that the network (and subnet, if subnetting is in use) parts of their IP addresses are the same. The datagram is encapsulated in a frame addressed to the destination host and sent directly, using ARP to discover the destination MAC-layer address.

Indirect Delivery: If the network (or subnet) part of the destination address is different to that of the source host, the datagram is sent to a router (or IP gateway). Routers, in turn, may send the datagram to other routers as required, until the last router is reached: the one which is able to deliver the datagram directly.

Hosts need to know enough of the network structure to know which of several routers (if a choice is available) to use to deliver a datagram. Additionally, routers themselves need to know to which other router they should forward datagrams for delivery.

TCP

TCP provides an interprocess delivery system, so it needs to identify processes in the two "end systems" which it connects. To do this, it defines a port number.

Two processes can communicate by agreeing on the port numbers they will use for communication. Port numbers are the addresses of the TCP protocol - each segment contains port numbers for each of the sending and receiving processes.

In order to set up a TCP connection, a process notifies the TCP software that it is waiting for connections "at" some particular port number. By definition, such a process is called a server. A client process which needs to connect to the server asks its local TCP software to allocate an unused port number and establish the connection. Once the connection is established, the two processes can communicate.

In order to manage TCP connections, a group of port numbers (0 to 1023) have been defined to be used by processes providing well known services. Most UNIX systems provide server processes corresponding to all the well-known services.

TCP Segment

TCP associates a 32-bit sequence number with every single byte transmitted -- in the segment header, the sequence number is that of the last byte of data in this segment.
The Acknowledgement Number is one greater than the sequence number of the last byte to be received correctly.
The Window field controls end-to-end sliding window flow control.
A minimum TCP segment header (with no options) is 20 bytes in length.

User Datagram Protocol

UDP provides a connectionless alternative transport service to TCP for applications where reliable stream service is not needed. UDP datagrams can be droppped, duplicated or delivered out of order, exactly as for IP.

The UDP transport service add to IP the ability to deliver a datagram to a specified destination process using a port abstraction, in an analogous way to that used by TCP.

UDP Destination Port: Defines (or names) the process which is to receive this datagram on the destination host.
UDP Source Port: This field is optional: it may be zero, or have a non-zero value to indicate a port to which reply UDP datagrams may be directed.
UDP Message Length: Specifies the length of the UDP datagram, including the eight bytes of header.
UDP Checksum: A "pseudo header" is prefixed to the datagram, and the checksum covers this plus the entire datagram itself. This is similar to the technique used in TCP. Computation of a checksum is optional in UDP.