Estructura patrimonial

4.4.2 RSVP Message FRSVP Message Flows for Resource Reservationlows for Resource Reservation

The steps to resource reservation in RSVP are path establishment and resource allocation. RSVP uses the Path message to establish a path from the source to the destination, and a Resv message to reserve the resources along the path. The source of the RSVP flow (the ingress ) sends a Path message targeted at the desti- nation of the flow (the egress ), and this message is passed from node to node through the network until it reaches the egress. The Path message is routed in the same way that IP traffic would be routed—the IP traffic would be addressed to the egress node, and by addressing the Path message in the same way, RSVP ensures that the reservations will be made using the same path and hops that will be used by the IP traffic.

The Path message carries a specification of the traffic that will constitute the flow (the traffic specification or TSpec ). It should be noted, however, that the traffic may already be flowing before the Path message is sent. That is, an RSVP- capable network also supports best effort traffic delivery and resource reservation may be applied at any stage to improve the likelihood of traffic delivery meeting required quality standards.

Each node that processes the Path message establishes control state for the message, verifies that it is happy to attempt to deliver the requested service (e.g., checking the authenticity of the message sender), and builds a Path message to send on toward the egress. The Path messages can collect information about the availability of resources along the path they traverse. The ingress advertises (in the Adspec ) its capabilities, and each node along the way can modify the reported capabilities to a subset of the srcinal Adspec so that by the time the Path reaches the egress the message contains a common subset of the capabilities of all routers on the path.

4.4

82

82 CHAPTER 4CHAPTER 4 IP Service Management

The egress computes what resources will need to be reserved in the network. These resources must satisfy the demands of the traffic that will be sent, as described by the TSpec, and must fit within the available resources reported by the Adspec. The egress responds to the Path message with an Resv message that requests the reservation of the computed resources by including an RSpec. The Resv is passed hop-by-hop back along the path traversed by the Path message and at each hop resources are reserved as requested. When the Resv reaches the ingress and has completed its resource allocations, the RSVP flow is fully provisioned.

In general, RSVP implementations follow the model described in RFC 2205. Control state is maintained separately for Path and Resv flows with only a loose coupling between them. This is not necessarily intuitive but it allows for advanced functions (described in Sections 4.4.6 and 4.4.7) where there may not be a one- to-one correspondence between Path messages and resource reservations, or where the Path may be rerouted while the reservation on the old path is still in

place.

Figure 4.7 shows the basic RSVP message flows. At step 1 the application at the ingress quantifies the traffic flow that it is going to send to an application of

Host A 1 Host D Router B Path Resv ResvConf PathTear Path Resv ResvConf PathTear Path Resv ResvConf PathTear Router C 2 5 4 3 9 12 6 7 8 10 11 FIGURE 4.7 FIGURE 4.7

Host D and requests reservations from the network. Host A builds and sends a PATH message addressed to Host D and this is routed to Router B. Router B (step 2) creates Path state and sends its own Path message toward Host D. When the Path message reaches Host D (step 3), it also creates its Path state, but recognizes that it is the destination of the flow and so delivers the resource request to the target application identified by a destination port ID contained in the Path message.

The target application converts the Path message, with its description of the traffic and the capabilities of the routers along the path, into a request for resource reservation. This request is passed to the RSVP component, which creates Resv state, reserves the requested resources on the local node, and sends an Resv message (step 4). The Resv message is not addressed to the ingress node, but is addressed hop-by-hop back along the path the Path message traversed. This ensures that the resources are reserved along the path that traffic will follow (i.e., along the path the Path message traversed) rather than along the shortest return path. Thus, at Router C (step 5), once the Resv state has been created and the resources reserved, a new Resv is sent out to Router B even if there is a direct route from Router C to Host A. When the Resv reaches Host A (step 6), the resources are reserved and an indication is delivered to the application to let it know that the reservations are in place.

Figure 4.7 also shows the ResvConf message sent by the ingress to the egress to confirm that the resources have been reserved. The ResvConf is sent hop-by- hop along the path of flow (steps 7 and 8) to the egress if, and only if, the egress requested confirmation when it sent the Resv (step 4). When the ResvConf reaches the egress (step 9) it knows that the reservation was successful; this may simplify processing at the egress, which can wait for a ResvConf or a ResvErr (see Section 4.4.5) to confirm or deny successful flow establishment.

When the ingress application no longer needs the reservations in place because it is stopping its transmission of traffic, it tears them down by sending a PathTear message. The PathTear is a one-shot message that traverses the path hop-by-hop (it is not addressed and routed to the egress) and lets each router know that it can release its Path and Resv state as well as any reserved resources. This is shown in Figure 4.7 at steps 10, 11, and 12.

Alternatively, the egress may determine that it can no longer support the res- ervations that are in place and can ask for them to be torn down. It may send a ResvTear message back toward the ingress along the path of the flow. Each router that receives a ResvTear releases the resources it has reserved for the flow and cleans up its Resv state before sending a ResvTear on toward the ingress. The Path state is, however still left in place since that refers to the request from the ingress. When the ResvTear reaches the ingress it may decide that the flow can no longer be supported with resource reservations and will send a PathTear, as shown in Figure 4.8.

Another alternative is for the ingress to modify the description of the traffic and send a new Path message to which the egress may respond with a new Resv.

4.4

84

84 CHAPTER 4CHAPTER 4 IP Service Management

Finally, the ingress may decide to do nothing, leaving its current request in place and hoping that the egress will have a change of heart and will assign new resources. In any event, after a ResvTear the traffic may continue to flow and be delivered in a best-effort manner.