Adapting to Changes Adapting to Changes in the Network in the Network

4.4.6 Adapting to Changes Adapting to Changes in the Networkin the Network

As suggested in the preceding section, RSVP handles problems during the estab- lishment of an RSVP flow by resending its Path and Resv messages periodically. This feature is even more important in the context of changes to the topology and routes of a network.

The initial Path message is propagated through the network according to the forwarding tables installed at the ingress and transit nodes. At each RSVP router, the Path is packaged into an IP header, addressed to the egress/destination host, and forwarded to the next router. The Resv is returned hop-by-hop along the path of the Path without any routing between nodes. The reservations are, therefore, made along the path that the Path message followed, which will be the path that IP data also traverses.

But what would happen if there were a change in the network so that IP data followed a new route? The reservations would remain on the old path, but the data would flow through other routers where no reservations had been made. This serious issue is resolved by having each node retransmit (refresh) its Path message periodically—each message is subject to the routing process and will be passed to the new next hop and so onward to the same egress. The Resv is now sent back hop-by-hop along the new path, and reservations are made along the new path to support the data flow that is using it.

Of course, the process described would leave unused resources allocated on the old path, which is not good because those resources could not be used to

support other flows. This problem is countered by having the nodes on the old path timeout when they do not receive a Path after a period (generally 51

/ 4 times

the retransmission period to allow for occasional packet loss). When a node times out, it knows that there is some problem with the upstream node—maybe the link from the upstream node is broken, or perhaps the ingress has simply lost interest in the reservation, or the Path could have been routed another way. When a node stops receiving Path messages it stops forwarding Path and Resv messages and removes the Path state associated with the flow.

Resv messages are similarly refreshed. This provides for survival of packet loss and guarantees cleanup of the Resv state and the allocated resources in the event of a network failure or a change in the Path.

Message refresh processing and rerouting is illustrated in Figure 4.11. Step 1 shows normal Path and Resv exchange from Host A to Host F through Routers C and E (the shortest path). Step 2 indicates refresh processing as Path and Resv messages are resent between the routers, but Host A now routes the Path message to Router B and so through Router D to Router E. Router E (step 4) is a merge point for the old and new flows and sends the new Path message on to the egress (Host F) resulting in a new Resv from Host F (steps 5 and 6). Note that the merge point (Router E) may decide to handle the merging of the flows itself by sending an Resv back to Router D without sending a Path on to the destination, Host F.

Router E can now make a reservation on the interface from Router D and send an Resv to Router D. The Resv follows its new path back to Host A through Router B (step 7) and all reservations are now in place on the new path. Note that data is already flowing along the new path and was as soon as the change in the routing table took effect—this was before the Path refresh was sent on the new route. This means that for a while the data was flowing down a path for which it had no specific reservation, highlighting the fact that RSVP is a best-effort reservation process.

Step 8 indicates the refresh process on the new path and on the fragments of the old path that are still in place. Each node sends a Path and an Resv to its neighbor, with the exception that Host A sends a Path only to Router B.

After a while, Router C notices that it has not seen a Path message from Host A (step 9). It may simply remove state and allow the state to timeout downstream or, as in this case, it may send a PathTear to clean up. When the merge point, Router E, receives the PathTear (step 10) it must not propagate it to the egress as this would remove the reservation for the whole flow. Instead, it removes the reservation on the interface (from Router C) on which the PathTear was received and notices that it still has an incoming flow (from router D) so does not forward the message.

At step 11, Host A notices that it hasn’t received a Resv from Router C and cleans up any remaining resources.

Because the state messages (Path and Resv) must be periodically resent to keep the RSVP state active, RSVP is known as a soft state protocol. The protocol over-

4.4

90

90 CHAPTER 4CHAPTER 4 IP Service Management

Host A Router B Router D Host F

Router E Router C Path Path Resv Resv Resv Resv Path Resv Path Resv Path Path Resv Resv Path Path Resv Resv Path Resv Path Path Path Tear Resv Resv Path Path Path Path Resv Resv Resv Resv 1 7 8 11 3 2 9 6 4 10 5 FIGURE 4.11 FIGURE 4.11

heads of a soft state have been the cause of many heated debates within the IETF. The concern is that the number of flows in a network may reach a point at which all of the bandwidth on a link, or all of the processing power of a router, will be used up sending Path and Resv refresh messages, leaving no capacity for data forwarding. Several solutions to reduce the impact of refresh processing have been developed and are covered in a separate RFC ( RFC 2961 ). They are described in Section 4.4.12.

Even when RSVP messages are being refreshed, there is some risk that during network overload RSVP packets will be dropped too often, resulting in the soft state timing out. For this reason, routers are recommended to give priority to IP packets that indicate that they are carrying RSVP messages.