Connected: An Internet Encyclopedia
2.6 Confirmation
Up:
Connected: An Internet Encyclopedia
Up:
Requests For Comments
Up:
RFC 2205
Up:
2. RSVP Protocol Mechanisms
Prev: 2.5 Errors
Next: 2.7 Policy Control
2.6 Confirmation
2.6 Confirmation
To request a confirmation for its reservation request, a receiver
Rj includes in the Resv message a confirmation-request object
containing Rj's IP address. At each merge point, only the largest
flowspec and any accompanying confirmation-request object is
forwarded upstream. If the reservation request from Rj is equal
to or smaller than the reservation in place on a node, its Resv is
not forwarded further, and if the Resv included a confirmation-
request object, a ResvConf message is sent back to Rj. If the
confirmation request is forwarded, it is forwarded immediately,
and no more than once for each request.
This confirmation mechanism has the following consequences:
- A new reservation request with a flowspec larger than any in
place for a session will normally result in either a ResvErr
or a ResvConf message back to the receiver from each sender.
In this case, the ResvConf message will be an end-to-end
confirmation.
- The receipt of a ResvConf gives no guarantees. Assume the
first two reservation requests from receivers R1 and R2
arrive at the node where they are merged. R2, whose
reservation was the second to arrive at that node, may
receive a ResvConf from that node while R1's request has not
yet propagated all the way to a matching sender and may still
fail. Thus, R2 may receive a ResvConf although there is no
end-to-end reservation in place; furthermore, R2 may receive
a ResvConf followed by a ResvErr.
Next: 2.7 Policy Control
Connected: An Internet Encyclopedia
2.6 Confirmation