Internet Protocol

Service Model

The Internet Protocol (IP) is the result of years of experience with the ARPAnet. The designers of IP knew that what was needed was a very fast and reliable switching service that could support a wide variety of different types of hardware, software and needs. The service model that they chose was:

The justifications for all of these choices are easy to make given the time frame (late 1970's to early 1980's), but that is immaterial to our study. IP has been relatively stable since its introduction in 1982 and has had only one major revision, IP version 6 or IPv6, which occurred in 1999 and has yet to be implemented universally. In other words, it has worked very well during the time frame that global network use has increased exponentially. That indicates that the design good. Many of the changes in IPv6 are due to changing demands on data communications networks and they will be addressed in the next unit. For now, we will consider only IPv4.

The things of interest in IP are:

Packet Format

The packet format is:

IP Options

IP has a few options that are important not because they are widely used, but because they demonstrate some of the features of IP.

IP allows up to 40 bytes of option to be added to the header to specify packet handling properties for the routers.

There are only two classes:

And the options are:

Class
Option
Use
Function
0 0 End of options Indicate that there are no more options
0 1 NOOP Used to pad the options to a 32-bit boundary
0 2 Security Set security options
0 3 Loose source route Provides a path to follow that can be modified if necessary.
0 7 Record route Make a record of the path followed
0 9 Strict source route Provides a path to follow that must be followed.
2 4 Timestamp Places a timestamp in the packet.

From this you can see that the designers of IP wanted to allow for certain types of capabilities. The ability to require a specific type of handling for security reasons, such as going through only secured routers. The ability to specify a path for the packet to follow, either one that has to be followed or one that is not required. The ability to record a route to see what path has been followed and finally, the ability to include a timestamp.

A source route is simply a list of IP addresses to follow. At each hop, the router looks to see what router is next and forwards it. If the route is strict, the inability to forward it to the correct address results in an ICMP error being generated.

IP Addresses

Discussed in the text.

The Switching Model

Discussed in the text.

The Error Control Model

While IP is an unreliable protocol, that doesn't mean that ignores errors; it simply doesn't guarantee that no errors will occur. So IP has ICMP, which actually exists above IP in the protocol stack because it uses IP to deliver its messages. In the event of certain conditions, IP generates an error message and sends it to the original sender. Note that since IP doesn't use fixed paths, and it doesn't keep addresses as it is forwarded, the only place it can send errors is to the originator. IN practice that means that any type of error that can't be handled by the original sender probably won't be handled at all unless the routers have an error control protocol other than IP. In fact, this is quite common.

The format of an ICMP message is:

There are 23 error types, but these are the most interesting:

The specific format of some of the error types is useful in understanding how they are used and how IP functions.

Echo Request Reply

Echo requests or pings can help one node in an IP network find out if another node is active, and to measure the roundtrip time to send a message. Since a node might have several outstanding pings at any one time, the sender selects a random identifier for each request that is used to match the incoming replies.

Unreachable Destination

If IP can't deliver a packet, it drops the packet and sends an "Unreachable Destination" message to the original sender. In order to help the receiver identify the message, the initial part of the IP packet is returned. Remember, IP is connectionless and a sender could have many outstanding IP packets.

The codes (The reason for Destination Unreachable and other errors) tell you quite a bit about how IP operates, and the types of things that are critical in packet delivery. Each of these represents the reason why a packet wasn't deliverable. For example, the desired protocol or port isn't available on the receiving host; the strict source route given doesn't work; the address is bad and so on.

Congestion Control

If a router can't handle a packet because of a lack of internal resources (insufficient buffer space) or due to processing delays, it discards it and sends a Source Quench to the original sender. The original sender slows down and after a while, builds back up. This may not be optimal, but its the only information that the router has. As with the destination unreachable error, it returns enough information for the sender to figure out who is responsible for the message.

Route Redirect |
If a router detects that there is a better place to send packets for a given destination, it sends a redirect to the routing protocol.

The codes indicate why the direct it being made - a change in host address, a change in network address and possibly also, the combination of those and type of service. So if you decide that a particular network is unreliable, you could tell the router to redirect to a different network for certain types of service.

Fragmentation

Fragmentation was first introduced in the discussion of IEEE 802.11b. If an IP packet has to travel over a physical layer with maximum frame length that is longer than the current packet size, it has to do something. It can throw the packet away, and one of the fields in IP allows you to send messages that can't be fragmented. Or you can fragment the packet into smaller packets and send them on. An example is:

Once a packet is fragmented and forwarded across the network with the small frame size, should it be reassembled immediately, or should it be left as fragments. IP made the choice that it should be left as fragments rather than suffer the penalty of repeatedly fragmenting and reassembling a message.

IP has three fields in its header for fragmentation. The Offset field is used to carry the offset in the frame of the beginning of a fragment (the number of bytes from the beginning of the message to the beginning of the fragment); the MF (More Fragments) flag indicates that there are more fragments after this fragment (1) or that this is the last fragment (0); and the DF (Don't Fragment) flag indicates that the packet isn't supposed to be fragmented.

In the example above, assume that we have a frame arriving on the Frame Relay side with a length of 6000 bytes. This is 4 1500 byte packets, but the IP header for each frame has to be included (the header for any upper level protocol also has to be included, but we will assume that is included in the 6000 bytes). If we assume 20 bytes of header for each IP packet, then we need to break the packet into 1480 byte fragments. We end up with 4 packets with 1480 bytes and one packet with 80 bytes. Looking only at the pertinent parts of the header, we get the following 5 fragments, which are complete IP packets, but the IP layer has to reassemble them before they can be delivered to the upper layer at the receiver.