First, this is pretty ugly and I'm not saying it SHOULD be done... but
it is an option if we get burned by fragmentation.
Ok, so the problem is how to add an encapsulating header AND the source
route data without making the packet any bigger (assuming its already at
1460bytes on ethernet)
To make things simple, lets start assuming that this is a one hop route.
Now we don't need a source route header because the encapsulating header
holds all the information you need. However, you still have this 20
byte encapsulating header you need to get rid of. First, lets remind
ourselves why we need the encapsulating header. The only reason we need
it is to select the next hop in the virtual network. So, broadly
speaking, we only care about the destination IP address field... the
rest is superfluous. Ok, so lets eliminate the encapsulating header and
just overwrite the real destination IP address with the next hop
destination IP address. The packet is the same size... no
fragmentation. The only problem is that we've lost the real
destination... admittedly a problem for the egress node. However, if we
could stick the extra 32 bits somewhere in the packet, we'd be golden.
On UDP this is easy... we simply write over the 16 bit UDP length and
UDP checksum fields. On the egress end we put the dest ip address back
in place, and re-calculate the UDP fields (we can just write 0 in the
UDP checksum... this is an experiment after all. On TCP we have a
number of options.
1) we can take advantage of the fact that most TCP traffic isn't
"two-way" (ie doesn't have data and acks together) and overload the
acknowledgement number to hold the destination IP address. We could do
the same thing with the sequence number in the ACK direction, but its
unlikely that these packets will be MTU sized.
2) As with UDP, we can overwrite the checksum and urgent pointer
(generally, only small packets have the urgent pointer set anyway).
Then we use one of the unused flags in the IP header or TCP header to
indicate that this is a "special" packet with reduced encapsulation.
Now, what if we have a source route of size more than one? Do we need
another 32 bits for each one? No. Because Detour will have a small
number of nodes (10's) and those nodes are well known, its possible to
compress the source route into a detour router index number, whose IP
address can be regenerated on each hop. For 16 detour routers (more
than we'll have any time soon) you only need 4 bits per hop. These can
be stuck in any of these left over spaces:
8 bit TOS in ip header
16 bit length in ip header (can be computed from MAC layer)
16 bit header checksum in ip header
16 bit identification & 13 bit frag offset (if we ensure that
MSS=MTU-40)
6 bit reserved field in TCP header
So, it seems quite feasible that we can source route paths of length 1-5
without fragmenting maximum sized packets.
- Stefan