3.1.8 Resv Error Messages

ResvErr (reservation error) messages report errors in processing Resv messages, or they may report the spontaneous disruption of a reservation, e.g., by administrative preemption.

ResvErr messages travel downstream towards the appropriate receivers, routed hop-by-hop using the reservation state. At each hop, the IP destination address is the unicast address of a next-hop node.

           <ResvErr Message> ::= <Common Header> [ <INTEGRITY> ]

                                      <SESSION>  <RSVP_HOP>

                                      <ERROR_SPEC>  [ <SCOPE> ]

                                      [ <POLICY_DATA> ...]

                                    <STYLE> [ <error flow descriptor> ]

The ERROR_SPEC object specifies the error and includes the IP address of the node that detected the error (Error Node Address). One or more POLICY_DATA objects may be included in an error message to provide relevant information (e.g.,, when a policy control error is being reported). The RSVP_HOP object contains the previous hop address, and the STYLE object is copied from the Resv message in error. The use of the SCOPE object in a ResvErr message is defined below in Section 3.4. The object order requirements are as given for Resv messages, but the above order is recommended.

The following style-dependent rules define the composition of a valid error flow descriptor; the object order requirements are as given earlier for flow descriptor.

• WF Style:

                    <error flow descriptor> ::= <WF flow descriptor>
  

• FF style:

                    <error flow descriptor> ::= <FF flow descriptor>
  

  Each flow descriptor in a FF-style Resv message must be processed independently, and a separate ResvErr message must be generated for each one that is in error.

• SE style:

                    <error flow descriptor> ::= <SE flow descriptor>
  

  An SE-style ResvErr message may list the subset of the filter specs in the corresponding Resv message to which the error applies.

Note that a ResvErr message contains only one flow descriptor. Therefore, a Resv message that contains N > 1 flow descriptors (FF style) may create up to N separate ResvErr messages.

Generally speaking, a ResvErr message should be forwarded towards all receivers that may have caused the error being reported. More specifically:

• The node that detects an error in a reservation request sends a ResvErr message to the next hop node from which the erroneous reservation came.

  This ResvErr message must contain the information required to define the error and to route the error message in later hops. It therefore includes an ERROR_SPEC object, a copy of the STYLE object, and the appropriate error flow descriptor. If the error is an admission control failure while attempting to increase an existing reservation, then the existing reservation must be left in place and the InPlace flag bit must be on in the ERROR_SPEC of the ResvErr message.

• Succeeding nodes forward the ResvErr message to next hops that have local reservation state. For reservations with wildcard scope, there is an additional limitation on forwarding ResvErr messages, to avoid loops; see Section 3.4. There is also a rule restricting the forwarding of a Resv message after an Admission Control failure; see Section 3.5.

  A ResvErr message that is forwarded should carry the FILTER_SPEC(s) from the corresponding reservation state.

• When a ResvErr message reaches a receiver, the STYLE object, flow descriptor list, and ERROR_SPEC object (including its flags) should be delivered to the receiver application.