Question 7.50 Copied directly from the CD supplied with the book.

Question 8.55


a) Since, no hierarchy or relationship between nodes is provided, we assume that all of them provide transit service to each other. In this case, the prefix will be announced over all the router pairs (i.e. R1-R2, R2-R3, R4-R5, R8-R9, R9-R7, R7-R6).
b)if R1-R2 fails then a loop between AS1, AS2, AS5, AS6 is avoided by (1)By examining the AS path to destination and discarding a route if an AS starts repeating (2) AS3 will advertise that R2-R1 does not exist anymore and within a few iterations others ASes will discard the route as well.

Question 8.57


a) Reverse path broadcasting (successive steps): (1) R7-R5, R7-R2, R7-R8 (2) R7-R5-R1, R7-R5-R6 (3) R7-R5-R1-R3, R7-R5-R1-R4 (Note: All edge routers multicast to the hosts that they are connected to, irrespective of whether or not they need to or not)
b)Same paths as above are used except that routers 2 and 8 do not multicast the information to their respective hosts.
c)Reverse path multicasting: (1)7-5 (2)7-5-1,7-5-6 (3)7-5-1-3 (Notice: the steps are not successive steps, the connections just show what nodes are connected in the mulitcast tree, this topology is realized only after the pruning messages have been sent out).

Question on Anycast:


Reading the paper will provide an answer to this question. The question is somewhat subjective and any reasonable answer is *correct*. A small overview of key features is provided below. GIA allows edge domain to discover store and maintain efficient routes to anycast groups accessed by users in the domain.
It allows anycast to be become more scalable by getting divided into various groups with different type of routing options. (a)Internal groups use the unicast intra-domain routing protocol, even though this increases the routing table size by one for each internal group added, it is assumed that the domain has control over these groups and hence can afford to *possibly manually* control this.
(b)Unpopular anycast groups are tackled by using inexpensive default routes to forward packets to them.
(c)Popular anycast groups have shortest path routes generated for them already and hence save on bandwidth.
Even though the proposal seems to be very beneficial for anycasting, it involves changes to a *large* number of routers in the internet (almost every edge router belonging to a domain needs to be changed) making it somewhat infeasible.

Question on IP-Mobility


If we are restricted to realizing mobility by modifying the 5 tuple (SrcIP, SrcPort, DstIP, DstPort, protocol) associated with the socket, then multiple schemes are possible. If we restrict to using *only* the 5 tuple, then there is not much that can be done. The Mobile Host (MH) will need to reconnect to the remote server using the new IP address and hence all the existing connections will be lost because the remote server will have no idea about the previous identity of the client. (Assumption: TCP header forces us to make the port numbers only 16 bits while protocol field is only 8 bits because of IP hence we can not use port numbers or protocol field for updating the remote server regarding the new IP address.) Also a rogue host can start spoofing the MHs old IP while continuing the connections which the MH had going on at the old IP. So essentially this approach is no better than the user just terminating all connections and restarting at a new location.

Another solution might be to use IP options to notify the remote server that the MH has a new IP address so that the remote server can start making use of the new address instead of old one while the connections can be easily continued on the new IP of the MH. This might involve the MH sending an update message in the first packet after it has got a new IP address. Obviously, the scheme has an almost fatal flaw because another *evil* node might impersonate the MH after MH has acquired a new IP address. This can be remedied by a challange-response authentication after which all previous connections from the MH can continue. This will lead to path shortening (as compared to mobile IP). It will also allow existing sessions to continue.