Transcript Chapter 8
Internet Protocol: Error and Control Messages (ICMP)
Chapter 8
We have
Unreliable
Connectionless datagram delivery… Need a way to inform original source if:
Router cannot forward or deliver a datagram
Router detects unusual condition affecting the ability to forward a datagram Original source will need to avoid or correct the problem
Internet Control Message Protocol
Routers operate autonomously If everything works correctly, all ok. But:
Communication lines fail
Processors fail Destination machines get disconnected from the network TTL counters expire
Intermediate routers get congested
In an internet, no special hardware mechanisms to inform hosts of problems
Don’t know if failure is local or remote problem
Debugging is difficult
IP has nothing itself to help out Added special-purpose message mechanism
Internet Control Message Protocol (ICMP)
Considered a required part of IP
ICMP messages travel in data portion of IP datagrams ICMP:
Allows sending of error or control messages to other routers or hosts
Provides communication between IP software on one machine and IP software on another ICMP module handles ICMP messages Any machine can send an ICMP message
Error Reporting vs Correction
ICMP is technically a reporting mechanism
ICMP only reports error condition to source
Source must relate error to a specific application program or take other action Most errors stem from original source
Some do not
ICMP only informs original source
Source may not be able to determine problem
Have to restrict communication to original source:
Datagrams don’t usually record complete route Can’t know path taken to a given router
So cannot inform intermediate routers Inform original source
Hope host administrators and network administrators will cooperate to solve problem
ICMP Message Delivery
ICMP uses two levels of encapsulation
ICMP message in
datagram
data portion
Datagram in
frame
data portion Datagrams carrying ICMP messages:
Are forwarded the same way as others
May themselves get lost or discarded
May cause further congestion
Figure 8.1
Exception for error messages
ICMP messages not generated if error results from datagram carrying ICMP error message ICMP not a higher-level protocol
It is a required part of IP
IP used to carry because messages may have to travel across several networks
Cannot be delivered by physical transport alone
ICMP Message Format
Each ICMP message has own format But, all begin with three fields:
8-bit integer message TYPE
8-bit CODE field
16-bit CHECKSUM Also includes first 64 data bits of datagram causing the problem
Echo Reply and Request (0 & 8)
Command on many systems is ping Sends echo request to a machine
Receiver sends echo reply to sender Tests if destination is reachable & responding
Verifies source, outbound path, destination, and return path
Sophisticated versions send a series of requests and provide statistics about datagram loss
C:\>ping google.com
Pinging google.com [64.233.187.99] with 32 bytes of data: Reply from 64.233.187.99: bytes=32 time=31ms TTL=239 Reply from 64.233.187.99: bytes=32 time=32ms TTL=239 Reply from 64.233.187.99: bytes=32 time=31ms TTL=239 Reply from 64.233.187.99: bytes=32 time=30ms TTL=239 Ping statistics for 64.233.187.99: Packets: Sent = 4, Received = 4, Lost = 0 (0% loss), Approximate round trip times in milli-seconds: Minimum = 30ms, Maximum = 32ms, Average = 31ms C:\>
Echo request and reply message format: 0 8 16 31 Type (8 or 0) Code (0) Checksum Identifier Sequence Number Optional Data . . .
Unreachable Destination (3)
Sent when router cannot forward or deliver a datagram 0 8 16 31 Type (3) Code (0-12) Checksum Unused (must be zero) Internet header + first 64 bits of datagram . . .
Discarding datagrams not taken lightly Messages sent when router determines destination unreachable
Network unreachable: usually forwarding failure
Host unreachable: usually delivery failure
13 types possible; specified in CODE field
However, routers cannot know all delivery failures Destination on Ethernet Network HW doesn’t provide acknowledgements
Source Quench (4)
Congestion: routers overrun with traffic Can happen for two reasons:
High-speed computer generate traffic too fast for network to handle Many computers sending thru same router Datagrams buffered if arrive too fast
Helps with small burst If continues, memory gets exhausted
Source quench used to report congestion
Requests source to reduce rate of transmission
Usually one message per discarded datagram
May be more sophisticated Quench source with highest transmission rate Avoid congestion by sending before overflow 0 8 16 31 Type (4) Code (0) Checksum Unused (must be zero) Internet header + first 64 bits of datagram . . .
Redirect (Route Change)(5)
Routers are assumed to know correct routes Hosts begin with minimal forwarding info
Usually know the address of single router
Learn new routes from routers
One way is the ICMP
redirect
message Router detects host using a non-optimal route Redirect requests the host change its route Host routing table stays small but optimal
Limitation:
Only have interactions between directly connected host and router Later routers cannot send ICMP redirect Don’t know non-directly connected router’s address Redirect not used to solve general problem of propagating routing information 0 8 16 31 Type (5) Code (0 to 3) Checksum Router Internet Address Internet header + first 64 bits of datagram . . .
Code 0: redirect for net Code 1: redirect for host Code 2: redirect for TOS and net Code 3: redirect for TOS and host
Figure 8.7
Time Exceeded (11)
Can get routing cycles
R1 sends datagrams for D to R2
R2 sends datagrams for D to R1 TTL (hop count) timer used to stop circle ICMP time exceeded message:
Sent when datagram discarded due to TTL=0
Or, when timed out waiting for datagram fragments
0 8 16 31 Type (11) Code (0 or 1) Checksum Unused (must be zero) Internet header + first 64 bits of datagram . . .
Code 0: TTL count exceeded Code 1: Fragment reassembly time exceeded
Parameter Problem (12)
Problem exists with a datagram
Severe enough to cause it to be discarded
Uses pointer to ID octet that caused the problem 0 8 16 31 Type (12) Code (0 or 1) Checksum Pointer Unused (must be zero) Internet header + first 64 bits of datagram . . .
Code 1: required option is missing (pointer field not used)
Timestamp Request & Reply (13 or 14)
Can have clock synchronization problem
Widely different clocks can confuse operations
Several protocols exist to synchronize clocks
One of simplest: Machine sends ICMP timestamp request message Receiver returns a timestamp reply
0 8 16 31 Type (13 or 14) Code (0) Checksum Identifier Sequence Number Originate Timestamp Receive Timestamp Transmit Timestamp From originate time: - can compute total time From receive & transmit times: - can compute network transit time Then estimate differences in clocks
Information Request and Reply (15 or 16) *OBSOLETE* Intended to allow hosts to discover internet address at startup Made obsolete by DHCP
Address Mask Request & Reply (17 or 18) *OBSOLETE*
Chap 9 – motivation for subnets
Understand for now:
Some bits in hostid identify a physical network
Host needs to know:
Which bits correspond to the physical network Which bits correspond to the host identifiers
Subnet mask
:
32-bit quantity allowing address interpretation Intended to allow host to obtain the address mask used on the local network Made obsolete by DHCP
Router Solicitation & Advertisement *OBSOLETE*
Intended to allow a host to discover routers available on the local network Made obsolete by DHCP
Two differences from DHCP: Host got info directly from router Prevented hosts from retaining routes after a router crashes (soft state technique)
Routers advertise their information periodically Host discards route when timer for it expires
Summary
Routers may need to communicate with network software on a particular host
Report abnormal condition Send control information Internet Control Message Protocol is used
Travels in data area of IP datagram Three fixed-length fields at the beginning Message type determines rest of format