diff options
Diffstat (limited to 'doc/rfc/rfc2209.txt')
| -rw-r--r-- | doc/rfc/rfc2209.txt | 1403 |
1 files changed, 1403 insertions, 0 deletions
diff --git a/doc/rfc/rfc2209.txt b/doc/rfc/rfc2209.txt new file mode 100644 index 0000000..20d495c --- /dev/null +++ b/doc/rfc/rfc2209.txt @@ -0,0 +1,1403 @@ + + + + + + +Network Working Group R. Braden +Request For Comments: 2209 ISI +Category: Informational L. Zhang + UCLA + September 1997 + + Resource ReSerVation Protocol (RSVP) -- + Version 1 Message Processing Rules + +Status of this Memo + + + This memo provides information for the Internet community. It does + not specify an Internet standard of any kind. Distribution of this + memo is unlimited. + +Abstract + + This memo contains an algorithmic description of the rules used by an + RSVP implementation for processing messages. It is intended to + clarify the version 1 RSVP protocol specification. + + This memo provides a generic description of the rules for the + operation of Version 1 of RSVP [RFC 2205]. It is intended to outline + a set of algorithms that will accomplish the needed function, + omitting many details. + +1. GENERIC DATA STRUCTURES + + This memo assumes the generic interface calls defined in [RFC 2005] + and the following data structures. An actual implementation may use + additional or different data structures and interfaces. The data + structure fields that are shown are required unless they are + explicitly labelled as optional. + + o PSB -- Path State Block + + Each PSB holds path state for a particular (session, sender) + pair, defined by SESSION and SENDER_TEMPLATE objects, + respectively, received in a PATH message. + + + + + + + + + + + +Braden & Zhang Informational [Page 1] + +RFC 2209 RSVP-Message Processing September 1997 + + + PSB contents include the following values from a PATH message: + + - Session + + - Sender_Template + + - Sender_Tspec + + - The previous hop IP address and the Logical Interface + Handle (LIH) from a PHOP object + + - The remaining IP TTL + + - POLICY_DATA and/or ADSPEC objects (optional) + + - Non_RSVP flag + + - E_Police flag + + - Local_Only flag + + In addition, the PSB contains the following information provided + by routing: OutInterface_list, which is the list of outgoing + interfaces for this (sender, destination), and IncInterface, + which is the expected incoming interface. For a unicast + destination, OutInterface_list contains one entry and + IncInterface is undefined. + + Note that there may be more than one PSB for the same (session, + sender) pair but different incoming interfaces. At most one of + these, which will have the Local_Only flag off, will be the PSB + used for forwarding PATH messages downstream; we will refer to + it as the "forwarding PSB" in the following. The other PSB's + will have the Local_Only flag on and an empty + OutInterface_list.h The Local_Only flag is needed to correctly + match PSB's against RSB's, by the rules of [RFC 2205]. + + o RSB -- Reservation State Block + + Each RSB holds a reservation request that arrived in a + particular RESV message, corresponding to the triple: (session, + next hop, Filter_spec_list). Here "Filter_spec_list" may be a + list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF + style), or empty (WF style). We define the virtual object type + "FILTER_SPEC*" for such a data structure. + + + + + + +Braden & Zhang Informational [Page 2] + +RFC 2209 RSVP-Message Processing September 1997 + + + RSB contents include: + + - Session specification + + - Next hop IP address + + - Filter_spec_list + + - The outgoing (logical) interface OI on which the + reservation is to be made or has been made. + + - Style + + - Flowspec + + - A SCOPE object (optional, depending upon style) + + - RESV_CONFIRM object that was received (optional) + + o TCSB -- Traffic Control State Block + + Each TCSB holds the reservation specification that has been + handed to traffic control for a specific outgoing interface. In + general, TCSB information is derived from RSB's for the same + outgoing interface. Each TCSB defines a single reservation for + a particular triple: (session, OI, Filter_spec_list). TCSB + contents include: + + - Session + + - OI (Outgoing Interface) + + - Filter_spec_list + + - TC_Flowspec, the effective flowspec, i.e., the LUB over the + corresponding FLOWSPEC values from matching RSB's. + TC_Flowspec is passed to traffic control to make the actual + reservation. + + - Fwd_Flowspec, the updated object to be forwarded + after merging. + + - TC_Tspec, equal to Path_Te, the effective sender Tspec. + + - Police Flags + + The flags are E_Police_Flag, M_Police_Flag, and + B_Police_Flag. + + + +Braden & Zhang Informational [Page 3] + +RFC 2209 RSVP-Message Processing September 1997 + + + - Rhandle, F_Handle_list + + Handles returned by the traffic control interface, + corresponding to a flowspec and perhaps a list of filter + specs. + + - A RESV_CONFIRM object to be forwarded. + + o BSB -- Blockade State Block + + Each BSB contains an element of blockade state. Depending upon + the reservation style in use, the BSB's may be per (session, + sender_template) pair or per (session, PHOP) pair. In practice, + an implementation might embed a BSB within a PSB; however, for + clarity we describe BSB's independently. + + The contents of a BSB include: + + - Session + + - Sender_Template (which is also a filter spec) + + - PHOP + + - FLOWSPEC Qb + + - Blockade timer Tb + + The following Boolean Flag variables are used in this section: + Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, + Need_Scope, B_Merge, and NeworMod. Refresh_PHOP_list is a + variable-length list of PHOPs to be refreshed. + +2. PROCESSING RULES + + MESSAGE ARRIVES + + Verify version number and RSVP checksum, and discard message if any + mismatch is found. + + If the message type is not PATH or PTEAR or RACK and if the IP + destination address does not match any of the addresses of the local + interfaces, then forward the message to IP destination address and + return. + + Parse the sequence of objects in the message. If any required + objects are missing or the length field of the common header does not + match an object boundary, discard the message and return. + + + +Braden & Zhang Informational [Page 4] + +RFC 2209 RSVP-Message Processing September 1997 + + + Verify the INTEGRITY object, if any. If the check fails, discard the + message and return. + + Verify the consistent use of port fields. If the DstPort in the + SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or + FILTER_SPEC object is non-zero, then the message has a "conflicting + source port" error; silently discard the message and return. + + Processing of POLICY_DATA objects will be specified in the future. + + Further processing depends upon message type. + + PATH MESSAGE ARRIVES + + Assume the PATH message arrives on interface InIf. + + Process the sender descriptor object sequence in the message as + follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags are + initially off. + + o Search for a path state block (PSB) whose (session, + sender_template) pair matches the corresponding objects in the + message, and whose IncInterface matches InIf. + + During this search: + + 1. If a PSB is found whose session matches the + DestAddress and Protocol Id fields of the received + SESSION object, but the DstPorts differ and one is + zero, then build and send a "Conflicting Dst Port" + PERR message, drop the PATH message, and return. + + 2. If a PSB is found with a matching sender host but the + Src Ports differ and one of the SrcPorts is zero, then + build and send an "Ambiguous Path" PERR message, drop + the PATH message, and return. + + 3. If a forwarding PSB is found, i.e., a PSB that matches + the (session, sender_template) pair and whose + Local_Only flag is off, save a pointer to it in the + variable fPSB. If none is found, set fPSB to NULL. + + o If there was no matching PSB, then: + + 1. Create a new PSB. + + 2. Copy contents of the SESSION, SENDER_TEMPLATE, + SENDER_TSPEC, and PHOP (IP address and LIH) objects + + + +Braden & Zhang Informational [Page 5] + +RFC 2209 RSVP-Message Processing September 1997 + + + into the PSB. + + 3. If the sender is from the local API, set + OutInterface_List to the single interface whose + address matches the sender address, and make + IncInterface undefined. Otherwise, turn on the + Local_Only flag. + + 4. Turn on the Path_Refresh_Needed flag. + + o Otherwise (there is a matching PSB): + + - If the PHOP IP address, the LIH, or Sender_Tspec + differs between the message and the PSB, copy the new + value into the PSB and turn on the Path_Refresh_Needed + flag. If the PHOP IP address or the LIH differ, also + turn on the Resv_Refresh_Needed flag. + + o Call the resulting PSB the "current PSB" (cPSB). Update + the cPSB, as follows: + + - Start or Restart the cleanup timer for the PSB. + + - If the message contains an ADSPEC object, copy it into + the PSB. + + - Copy E_Police flag from SESSION object into PSB. + + - Store the received TTL into the PSB. + If the received TTL differs from Send_TTL in the RSVP + common header, set the Non_RSVP flag on in the PSB. + + o If the PSB is new or if there is no route change + notification in place, then perform the following routing + manipulations, but not if the cPSB is from the local API. + + 1. Invoke the appropriate Route_Query routine using + DestAddress from SESSION and (for multicast routing) + SrcAddress from Sender_Template. + + Call the results (Rt_OutL, Rt_InIf). + + 2. If the destination is multicast and Rt_InIf differs + from IncInterface in the cPSB, but fPSB points to the + cPSB, then do the following. + + - Turn on the Local_Only flag and clear the + OutInterface_list of the fPSB. Set the fPSB + + + +Braden & Zhang Informational [Page 6] + +RFC 2209 RSVP-Message Processing September 1997 + + + pointer to NULL. + + - Search for a PSB for the same (session, + sender_template) pair whose IncInterface matches + Rt_InIf. If one is found, set fPSB to point to + it. + + 3. If the destination is multicast and Rt_InIf is the + same as IncInterface in the cPSB, but fPSB does not + point to the cPSB, then do the following. + + - Copy into the cPSB the OutInterface_list from the + PSB, if any, pointed to by fPSB. Clear + OutInterface_list and turn on the Local_Only flag + in the PSB pointed to by fPSB, if any. + + - Turn off the Local_Only flag in the cPSB and set + fPSB to point to cPSB. + + 4. If Rt_OutL differs from OutInterface_list of the PSB + pointed to by fPSB, then: + + - Update the OutInterface_list of the PSB from + Rt_OutL, and then execute the PATH LOCAL REPAIR + event sequence below. + + o If the Path_Refresh_Needed flag is now off, drop the PATH + message and return. + + Otherwise (the path state is new or modified), do + refreshes, upcalls, and state updates as follows. + + 1. If this PATH message came from a network interface and + not from a local application, make a Path Event upcall + for each local application for this session: + + Call: <Upcall_Proc>( session-id, PATH_EVENT, + flags, sender_tspec, sender_template + [ , ADSPEC] [ , POLICY_DATA] ) + + 2. If OutInterface_list is not empty, execute the PATH + REFRESH event sequence (below) for the sender defined + by the PSB. + + 3. Search for any matching reservation state, i.e., an + RSB whose Filter_spec_list includes a FILTER_SPEC + matching the SENDER_TEMPLATE and whose OI appears in + the OutInterface_list, and make this the `active RSB'. + + + +Braden & Zhang Informational [Page 7] + +RFC 2209 RSVP-Message Processing September 1997 + + + If none is found, drop the PATH message and return. + + 4. Execute the RESV REFRESH sequence (below) for the PHOP + in the PSB. + + 5. Execute the event sequence UPDATE TRAFFIC CONTROL to + update the local traffic control state if necessary. + This sequence will turn on the Resv_Refresh_Needed + flag if the traffic control state has been modified in + a manner that should trigger a reservation refresh. + If so, execute the RESV REFRESH sequence for the PHOP + in the PSB. + + o Drop the PATH message and return. + + PTEAR MESSAGE ARRIVES + + o Search for a PSB whose (Session, Sender_Template) pair + matches the corresponding objects in the message. If no + matching PSB is found, drop the PTEAR message and return. + + o Forward a copy of the PTEAR message to each outgoing + interface listed in OutInterface_list of the PSB. + + o Find each RSB that matches this PSB, i.e., whose + Filter_spec_list matches Sender_Template in the PSB and + whose OI is included in OutInterface_list. + + 1. If the RSB style is explicit, then: + - Delete from Filter_spec_list the FILTER_SPEC that + matches the PSB. + + - if Filter_spec_list is now empty, delete the RSB. + + 2. Otherwise (RSB style is wildcard) then: + + - If this RSB matches no other PSB, then delete the + RSB. + + 3. If an RSB was found, execute the event sequence UPDATE + TRAFFIC CONTROL (below) to update the traffic control + state to be consistent with the current reservation + and path state. + + o Delete the PSB. + + o Drop the PTEAR message and return. + + + + +Braden & Zhang Informational [Page 8] + +RFC 2209 RSVP-Message Processing September 1997 + + + PERR MESSAGE ARRIVES + + o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair + matches the corresponding objects in the message. If no + matching PSB is found, drop the PERR message and return. + + o If the previous hop address in the PSB is the local API, + make an error upcall to the application: + + Call: <Upcall_Proc>( session-id, PATH_ERROR, + Error_code, Error_value, Node_Addr, + Sender_Template [ , Policy_Data] ) + + Any SENDER_TSPEC or ADSPEC object in the message is + ignored. + + Otherwise, send a copy of the PERR message to the PHOP IP + address. + + o Drop the PERR message and return. + + RESV MESSAGE ARRIVES + + Initially, Refresh_PHOP_list is empty and the + Resv_Refresh_Needed and NeworMod flags are off. These variables + are used to control immediate reservation refreshes. + + o Determine the Outgoing Interface OI + + The logical outgoing interface OI is taken from the LIH in + the NHOP object. (If the physical interface is not implied + by the LIH, it can be learned from the interface matching + the IP destination address). + + o Check the path state + + 1. If there are no existing PSB's for SESSION then build + and send a RERR message (as described later) + specifying "No path information", drop the RESV + message, and return. + + 2. If a PSB is found with a matching sender host but the + SrcPorts differ and one of the SrcPorts is zero, then + build and send an "Ambiguous Path" PERR message, drop + the RESV message, and return. + + + + + + +Braden & Zhang Informational [Page 9] + +RFC 2209 RSVP-Message Processing September 1997 + + + o Check for incompatible styles. + + If any existing RSB for the session has a style that is + incompatible with the style of the message, build and send + a RERR message specifying "Conflicting Style", drop the + RESV message, and return. + + Process the flow descriptor list to make reservations, as + follows, depending upon the style. The following uses a filter + spec list struct Filtss of type FILTER_SPEC* (defined earlier). + + For FF style: execute the following steps independently for each + flow descriptor in the message, i.e., for each (FLOWSPEC, + Filtss) pair. Here the structure Filtss consists of the + FILTER_SPEC from the flow descriptor. + + For SE style, execute the following steps once for (FLOWSPEC, + Filtss), with Filtss consisting of the list of FILTER_SPEC + objects from the flow descriptor. + + For WF style, execute the following steps once for (FLOWSPEC, + Filtss), with Filtss an empty list. + + o Check the path state, as follows. + + 1. Locate the set of PSBs (senders) that route to OI and + whose SENDER_TEMPLATEs match a FILTER_SPEC in Filtss. + + If this set is empty, build and send an error message + specifying "No sender information", and continue with + the next flow descriptor in the RESV message. + + 2. If the style has explicit sender selection (e.g., FF + or SE) and if any FILTER_SPEC included in Filtss + matches more than one PSB, build and send a RERR + message specifying "Ambiguous filter spec" and + continue with the next flow descriptor in the RESV + message. + + 3. If the style is SE and if some FILTER_SPEC included in + Filtss matches no PSB, delete that FILTER_SPEC from + Filtss. + + 4. Add the PHOP from the PSB to Refresh_PHOP_list, if the + PHOP is not already on the list. + + + + + + +Braden & Zhang Informational [Page 10] + +RFC 2209 RSVP-Message Processing September 1997 + + + o Find or create a reservation state block (RSB) for + (SESSION, NHOP). If the style is distinct, Filtss is also + used in the selection. Call this the "active RSB". + + o If the active RSB is new: + + 1. Set the session, NHOP, OI and style of the RSB from + the message. + + 2. Copy Filtss into the Filter_spec_list of the RSB. + + 3. Copy the FLOWSPEC and any SCOPE object from the + message into the RSB. + + 4. Set NeworMod flag on. + + o If the active RSB is not new, check whether Filtss from the + message contains FILTER_SPECs that are not in the RSB; if + so, add the new FILTER_SPECs and turn on the NeworMod flag. + + o Start or restart the cleanup timer on the active RSB, or, + in the case of SE style, on each FILTER_SPEC of the RSB + that also appears in Filtss. + + o If the active RSB is not new, check whether STYLE, FLOWSPEC + or SCOPE objects have changed; if so, copy changed object + into RSB and turn on the NeworMod flag. + + o If the message contained a RESV_CONFIRM object, copy it + into the RSB and turn on NeworMod flag. + + o If the NeworMod flag is off, continue with the next flow + descriptor in the RESV message, if any. + + o Otherwise (the NeworMod flag is on, i.e., the active RSB is + new or modified), execute the UPDATE TRAFFIC CONTROL event + sequence (below). If the result is to modify the traffic + control state, this sequence will turn on the + Resv_Refresh_Needed flag and make a RESV_EVENT upcall to + any local application. + + If the UPDATE TRAFFIC CONTROL sequence fails with an error, + then delete a new RSB but restore the original reservation + in an old RSB. + + o Continue with the next flow descriptor. + + + + + +Braden & Zhang Informational [Page 11] + +RFC 2209 RSVP-Message Processing September 1997 + + + o When all flow descriptors have been processed, check the + Resv_Refresh_Needed flag. If it is now on, execute the + RESV REFRESH sequence (below) for each PHOP in + Refresh_PHOP_list. + + o Drop the RESV message and return. + + If processing a RESV message finds an error, a RERR message + is created containing flow descriptor and an ERRORS object. + The Error Node field of the ERRORS object is set to the IP + address of OI, and the message is sent unicast to NHOP. + + RTEAR MESSAGE ARRIVES + + Processing of a RTEAR message roughly parallels the processing + of the corresponding RESV message + + A RTEAR message arrives with an IP destination address matching + outgoing interface OI. Flag Resv_Refresh_Needed is initially + off and Refresh_PHOP_list is empty. + + o Determine the Outgoing Interface OI + + The logical outgoing interface OI is taken from the LIH in + the NHOP object. (If the physical interface is not implied + by the LIH, it can be learned from the interface matching + the IP destination address). + + o Process the flow descriptor list in the RTEAR message to + tear down local reservation state, as follows, depending + upon the style. The following uses a filter spec list + struct Filtss of type FILTER_SPEC* (defined earlier). + + For FF style: execute the following steps independently for + each flow descriptor in the message, i.e., for each + (FLOWSPEC, Filtss) pair. Here the structure Filtss + consists of the FILTER_SPEC from the flow descriptor. + + For SE style, execute the following steps once for + (FLOWSPEC, Filtss), with Filtss consisting of the list of + FILTER_SPEC objects from the flow descriptor. + + For WF style, execute the following steps once for + (FLOWSPEC, Filtss), with Filtss an empty list. + + + + + + + +Braden & Zhang Informational [Page 12] + +RFC 2209 RSVP-Message Processing September 1997 + + + 1. Find an RSB matching (SESSION, NHOP). If the style is + distinct, Filtss is also used in the selection. Call + this the "active RSB". If no active RSB is found, + continue with next flow descriptor. + + 2. Check the style + + If the active RSB has a style that is incompatible + with the style of the message, drop the RTEAR message + and return. + + 3. Delete from the active RSB each FILTER_SPEC that + matches a FILTER_SPEC in Filtss. + + 4. If all FILTER_SPECs have now been deleted from the + active RSB, delete the active RSB. + + 5. Execute the UPDATE TRAFFIC CONTROL event sequence + (below) to update the traffic control state to be + consistent with the reservation state. If the result + is to modify the traffic control state, the + Resv_Refresh_Needed flag will be turned on and a + RESV_EVENT upcall will be made to any local + application. + + 6. Continue with the next flow descriptor. + + o All flow descriptors have been processed. + + Build and send any RTEAR messages to be forwarded, in the + following manner. + + 1. Select each PSB that routes to the outgoing interface + OI, and, for distinct style, that has a + SENDER_TEMPLATE matching Filtss. + + 2. Select a flow descriptor (Qj,Fj) (where Fj may be a + list) in the RTEAR message whose FILTER_SPEC matches + the SENDER_TEMPLATE in the PSB. If not match is + found, return for next PSB. + + - Search for an RSB (for any outgoing interface) to + which the PSB routes and whose Filter_spec_list + includes the SENDER_TEMPLATE from the PSB. + + - If an RSB is found, add the PHOP of the PSB to + the Refresh_PHOP_list. + + + + +Braden & Zhang Informational [Page 13] + +RFC 2209 RSVP-Message Processing September 1997 + + + - Otherwise (no RSB is found), add the flow + descriptor (Qj,Fj) to the new RTEAR message being + built, in a manner appropriate to the style. + + - Continue with the next PSB. + + 3. If the next PSB is for a different PHOP or the last + PSB has been processed, forward any RTEAR message that + has been built. + + o If any PSB's were found in the preceding step, and if the + Resv_Refresh_Needed flag is now on, execute the RESV + REFRESH sequence (below) for each PHOP in + Refresh_PHOP_list. + + o Drop the RTEAR message and return. + + RERR MESSAGE ARRIVES + + A RERR message arrives through the (real) incoming interface + In_If. + + o If there is no path state for SESSION, drop the RERR + message and return. + + o If the Error Code = 01 (Admission Control failure), do + special processing as follows: + + 1. Find or create a Blockade State Block (BSB), in the + following style-dependent manner. + + For WF (wildcard) style, there will be one BSB per + (session, PHOP) pair. + + For FF style, there will be one BSB per (session, + filter_spec) pair. Note that an FF style RERR message + carries only one flow descriptor. + + For SE style, there will be one BSB per (session, + filter_spec), for each filter_spec contained in the + filter spec list of the flow descriptor. + + 2. For each BSB in the preceding step, set (or replace) + its FLOWSPEC Qb with FLOWSPEC from the message, and + set (or reset) its timer Tb to Kb*R seconds. If the + BSB is new, set its PHOP value, and set its + Sender_Template equal to the appropriate filter_spec + from the message. + + + +Braden & Zhang Informational [Page 14] + +RFC 2209 RSVP-Message Processing September 1997 + + + 3. Execute the RESV REFRESH event sequence (shown below) + for the previous hop PHOP, but only with the B_Merge + flag off. That is, if processing in the RESV REFRESH + sequence reaches the point of turning the B_Merge flag + on (because all matching reservations are blockaded), + do not turn it on but instead exit the REFRESH + sequence and return here. + + o Execute the following for each RSB for this session whose + OI differs from In_If and whose Filter_spec_list has at + least one filter spec in common with the FILTER_SPEC* in + the RERR message. For WF style, empty FILTER_SPEC* + structures are assumed to match. + + 1. If Error_Code = 01 and the InPlace flag in the + ERROR_SPEC is 1 and one or more of the BSB's + found/created above has a Qb that is strictly greater + than Flowspec in the RSB, then continue with the next + matching RSB, if any. + + 2. If NHOP in the RSB is the local API, then: + + - If the FLOWSPEC in the RERR message is strictly + greater than the RSB Flowspec, then turn on the + NotGuilty flag in the ERROR_SPEC. + + - Deliver an error upcall to application: + + Call: <Upcall_Proc>( session-id, RESV_ERROR, + Error_code, Error_value, + Node_Addr, Error_flags, + Flowspec, Filter_Spec_List + [ , Policy_data] ) + + and continue with the next RSB. + + 3. If the style has wildcard sender selection, use the + SCOPE object SC.In from the RERR message to construct + a SCOPE object SC.Out to be forwarded. SC.Out should + contain those sender addresses that appeared in SC.In + and that route to OI, as determined by scanning the + PSB's. If SC.Out is empty, continue with the next + RSB. + + 4. Create a new RERR message containing the error flow + descriptor and send to the NHOP address specified by + the RSB. Include SC.Out if the style has wildcard + sender selection. + + + +Braden & Zhang Informational [Page 15] + +RFC 2209 RSVP-Message Processing September 1997 + + + 5. Continue with the next RSB. + + o Drop the RERR message and return. + + RESV CONFIRM ARRIVES + + o If the (unicast) IP address found in the RESV_CONFIRM + object in the RACK message matches an interface of the + node, a confirmation upcall is made to the matching + application: + + Call: <Upcall_Proc>( session-id, RESV_CONFIRM, + Error_code, Error_value, Node_Addr, + LUB-Used, nlist, Flowspec, + Filter_Spec_List, NULL, NULL ) + + o Otherwise, forward the RACK message to the IP address in + its RESV_CONFIRM object. + + Drop the RACK message and return. + + UPDATE TRAFFIC CONTROL + + The sequence is invoked by many of the message arrival sequences + to set or adjust the local traffic control state in accordance + with the current reservation and path state. An implicit + parameter of this sequence is the `active' RSB. + + If the result is to modify the traffic control state, this + sequence notifies any matching local applications with a + RESV_EVENT upcall. If the state change is such that it should + trigger immediate RESV refresh messages, it also turns on the + Resv_Refresh_Needed flag. + + o Compute the traffic control parameters using the following + steps. + + 1. Initially the local flag Is_Biggest is off. + + 2. Consider the set of RSB's matching SESSION and OI from + the active RSB. If the style of the active RSB is + distinct, then the Filter_spec_list must also be + matched. + + - Compute the effective kernel flowspec, + TC_Flowspec, as the LUB of the FLOWSPEC values in + these RSB's. + + + + +Braden & Zhang Informational [Page 16] + +RFC 2209 RSVP-Message Processing September 1997 + + + - Compute the effective traffic control filter spec + (list) TC_Filter_Spec* as the union of the + Filter_spec_lists from these RSB's. + + - If the active RSB has a FLOWSPEC larger than all + the others, turn on the Is_Biggest flag. + + 3. Scan all RSB's matching session and Filtss, for all + OI. Set TC_B_Police_flag on if TC_Flowspec is smaller + than, or incomparable to, any FLOWSPEC in those RSB's. + + 4. Locate the set of PSBs (senders) whose + SENDER_TEMPLATEs match Filter_spec_list in the active + RSB and whose OutInterface_list includes OI. + + 5. Set TC_E_Police_flag on if any of these PSBs have + their E_Police flag on. Set TC_M_Police_flag on if it + is a shared style and there is more than one PSB in + the set. + + 6. Compute Path_Te as the sum of the SENDER_TSPEC objects + in this set of PSBs. + + o Search for a TCSB matching SESSION and OI; for distinct + style (FF), it must also match Filter_spec_list. + + If none is found, create a new TCSB. + + o If TCSB is new: + + 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the + police flags into TCSB. + + 2. Turn the Resv_Refresh_Needed flag on and make the + traffic control call: + + TC_AddFlowspec( OI, TC_Flowspec, + Path_Te, police_flags) + -> Rhandle, Fwd_Flowspec + + 3. If this call fails, build and send a RERR message + specifying "Admission control failed" and with the + InPlace flag off. Delete the TCSB, delete any + RESV_CONFIRM object from the active RSB, and return. + + + + + + + +Braden & Zhang Informational [Page 17] + +RFC 2209 RSVP-Message Processing September 1997 + + + 4. Otherwise (call succeeds), record Rhandle and + Fwd_Flowspec in the TCSB. For each filter_spec F in + TC_Filter_Spec*, call: + + TC_AddFilter( OI, Rhandle, Session, F) + -> Fhandle + + and record the returned Fhandle in the TCSB. + + o Otherwise, if TCSB is not new but no effective kernel + flowspec TC_Flowspec was computed earlier, then: + + 1. Turn on the Resv_Refresh_Needed flag. + + 2. Call traffic control to delete the reservation: + + TC_DelFlowspec( OI, Rhandle ) + + 3. Delete the TCSB and return. + + o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te, + and/or police flags just computed differ from corresponding + values in the TCSB, then: + + 1. If the TC_Flowspec and/or Path_Te values differ, turn + the Resv_Refresh_Needed flag on. + + 2. Call traffic control to modify the reservation: + + TC_ModFlowspec( OI, Rhandle, TC_Flowspec, + Path_Te, police_flags ) + -> Fwd_Flowspec + + 3. If this call fails, build and send a RERR message + specifying "Admission control failed" and with the + InPlace bit on. Delete any RESV_CONFIRM object from + the active RSB and return. + + 4. Otherwise (the call succeeds), update the TCSB with + the new values and save Fwd_Flowspec in the TCSB. + + o If the TCSB is not new but the TC_Filter_Spec* just + computed differs from the FILTER_SPEC* in the TCSB, then: + + 1. Make an appropriate set of TC_DelFilter and + TC_AddFilter calls to transform the Filter_spec_list + in the TCSB into the new TC_Filter_Spec*. + + + + +Braden & Zhang Informational [Page 18] + +RFC 2209 RSVP-Message Processing September 1997 + + + 2. Turn on the Resv_Refresh_Needed flag. + + o If the active RSB contains a RESV_CONFIRM object, then: + + 1. If the Is_Biggest flag is on, move the RESV_CONFIRM + object into the TCSB and turn on the + Resv_Refresh_Needed flag. (This will later cause the + RESV REFRESH sequence to be invoked, which will either + forward or return the RESV_CONFIRM object, deleting it + from the TCSB in either case). + + 2. Otherwise, create and send a RACK message to the + address in the RESV_CONFIRM object. Include the + RESV_CONFIRM object in the RACK message. The RACK + message should also include an ERROR_SPEC object whose + Error_Node parameter is IP address of OI from the TCSB + and that specifies "No Error". + + o If the Resv_Refresh_Needed flag is on and the RSB is not + from the API, make a RESV_EVENT upcall to any matching + application: + + Call: <Upcall_Proc>( session-id, RESV_EVENT, + style, Flowspec, Filter_spec_list [ , + POLICY_DATA] ) + + where Flowspec and Filter_spec_list come from the TCSB and + the style comes from the active RSB. + + o Return to the event sequence that invoked this one. + + PATH REFRESH + + This sequence sends a path refresh for a particular sender, + i.e., a PSB. This sequence may be entered by either the + expiration of a refresh timer or directly as the result of the + Path_Refresh_Needed flag being turned on during the processing + of a received PATH message. + + o Insert TIME_VALUES object into the PATH message being + built. Compute the IP TTL for the PATH message as one less + than the TTL value received in the message. However, if + the result is zero, return without sending the PATH + message. + + o Create a sender descriptor containing the SENDER_TEMPLATE, + SENDER_TSPEC, and POLICY_DATA objects, if present in the + PSB, and pack it into the PATH message being built. + + + +Braden & Zhang Informational [Page 19] + +RFC 2209 RSVP-Message Processing September 1997 + + + o Send a copy of the PATH message to each interface OI in + OutInterface_list. Before sending each copy: + + 1. If the PSB has the E_Police flag on and if interface + OI is not capable of policing, turn the E_Police flag + on in the PATH message being built. + + 2. Pass the ADSPEC object and Non_RSVP flag present in + the PSB to the traffic control call TC_Advertise. + Insert the modified ADSPEC object that is returned + into the PATH message being built. + + 3. Insert into its PHOP object the interface address and + the LIH for the interface. + + RESV REFRESH + + This sequence sends a reservation refresh towards a particular + previous hop with IP address PH. This sequence may be entered + by the expiration of a refresh timer, or invoked from the PATH + MESSAGE ARRIVES, RESV MESSAGE ARRIVES, RTEAR MESSAGE ARRIVES, or + RERR MESSAGE ARRIVES sequence. + + In general, this sequence considers each of the PSB's with PHOP + address PH. For a given PSB, it scans the TCSBs for matching + reservations and merges the styles, FLOWSPECs and + Filter_spec_list's appropriately. It then builds a RESV message + and sends it to PH. The details depend upon the attributes of + the style(s) included in the reservations. + + Initially the Need_Scope flag is off and the new_SCOPE object is + empty. + + o Create an output message containing INTEGRITY (if + configured), SESSION, RSVP_HOP, and TIME_VALUES objects. + + o Determine the style for these reservations from the first + RSB for the session, and move the STYLE object into the + proto-message. (Note that the present set of styles are + never themselves merged; if future styles can be merged, + these rules will become more complex). + + o If style is wildcard and if there are PSB's from more than + one PHOP and if the multicast routing protocol does not use + shared trees, set the Need_Scope flag on. + + + + + + +Braden & Zhang Informational [Page 20] + +RFC 2209 RSVP-Message Processing September 1997 + + + o Select each sender PSB whose PHOP has address PH. Set the + local flag B_Merge off and execute the following steps. + + 1. Select all TCSB's whose Filter_spec_list's match the + SENDER_TEMPLATE object in the PSB and whose OI appears + in the OutInterface_list of the PSB. + + 2. If the PSB is from the API, then: + + - If TCSB contains a CONFIRM object, then create + and send a RACK message containing the object and + delete the CONFIRM object from the TCSB. + + - Continue with next PSB. + + 3. If B_Merge flag is off then ignore a blockaded TCSB, + as follows. + + - Select BSB's that match this TCSB. If a selected + BSB is expired, delete it. If any of the + unexpired BSB's has a Qb that is not strictly + larger than TC_Flowspec, then continue processing + with the next TCSB. + + However, if steps 1 and 2 result in finding that all + TCSB's matching this PSB are blockaded, then: + + - If this RESV REFRESH sequence was invoked from + RESV ERROR RECEIVED, then return to the latter. + + - Otherwise, turn on the B_Merge flag and restart + at step 1, immediately above. + + 4. Merge the flowspecs from this set of TCSB's, as + follows: + + - If B_Merge flag is off, compute the LUB over the + flowspec objects. From each TCSB, use the + Fwd_Flowspec object if present, else use the + normal Flowspec object. + + + + + + + + + + + +Braden & Zhang Informational [Page 21] + +RFC 2209 RSVP-Message Processing September 1997 + + + While computing the LUB, check for a RESV_CONFIRM + object in each TCSB. If a RESV_CONFIRM object is + found: + + - If the flowspec (Fwd_Flowspec or Flowspec) + in that TCSB is larger than all other (non- + blockaded) flowspecs being compared, then + save this RESV_CONFIRM object for forwarding + and delete from the TCSB. + + - Otherwise (the corresponding flowspec is not + the largest), create and send a RACK message + to the address in the RESV_CONFIRM object. + Include the RESV_CONFIRM object in the RACK + message. The RACK message should also + include an ERROR_SPEC object whose + Error_Node parameter is IP address of OI + from the TCSB and specifying "No Error". + + - Delete the RESV_CONFIRM object from the + TCSB. + + - Otherwise (B_Merge flag is on), compute the GLB + over the Flowspec objects of this set of TCSB's. + + While computing the GLB, delete any RESV_CONFIRM + object object in any of these TCSB's. + + 5. (All matching TCSB's have been processed). The next + step depends upon the style attributes. + + Distinct reservation (FF) style + + Use the Sender_Template as the merged + FILTER_SPEC. Pack the merged (FLOWSPEC, + FILTER_SPEC, F_POLICY_DATA) triplet into the + message as a flow descriptor. + + Shared wildcard reservation (WF) style + + There is no merged FILTER_SPEC. Merge (compute + the LUB of) the merged FLOWSPECS from the TCSB's, + across all PSB's for PH. + + + + + + + + +Braden & Zhang Informational [Page 22] + +RFC 2209 RSVP-Message Processing September 1997 + + + Shared distinct reservation (SE) style + + Using the Sender_Template as the merged + FILTER_SPEC, form the union of the FILTER_SPECS + obtained from the TCSB's. Merge (compute the LUB + of) the merged FLOWSPECS from the TCSB's, across + all PSB's for PH. + + 6. If the Need_Scope flag is on and the sender specified + by the PSB is not the local API: + + - Find each RSB that matches this PSB, i.e., whose + Filter_spec_list matches Sender_Template in the + PSB and whose OI is included in + OutInterface_list. + + - If the RSB either has no SCOPE list or its SCOPE + list includes the sender IP address from the PSB, + insert the sender IP address into new_SCOPE. + + o (All PSB's for PH have been processed). Finish the RESV + message. + + 1. If Need_Scope flag is on but new_SCOPE is empty, no + RESV message should be sent; return. Otherwise, if + Need_Scope is on, move new_SCOPE into the message. + + 2. If a shared reservation style is being built, move the + final merged FLOWSPEC object and filter spec list into + the message. + + 3. If a RESV_CONFIRM object was saved earlier, move it + into the new RESV message. + + 4. Set the RSVP_HOP object in the message to contain the + IncInterface address through which it will be sent and + the LIH from (one of) the PSB's. + + o Send the message to the address PH. + + ROUTE CHANGE NOTIFICATION + + This sequence is triggered when routing sends a route change + notification to RSVP. + + o Each PSB is located whose SESSION matches the destination + address and whose SENDER_TEMPLATE matches the source + address (for multicast). + + + +Braden & Zhang Informational [Page 23] + +RFC 2209 RSVP-Message Processing September 1997 + + + 1. If the OutInterface_list from the notification differs + from that in the PSB, execute the PATH LOCAL REPAIR + sequence. + + 2. If the IncInterface from the notification differs from + that in the PSB, update the PSB. + + PATH LOCAL REPAIR + + The sequence is entered to effect local repair after a route + change for a given PSB. + + o Wait for a delay time of W seconds. + + o Execute the PATH REFRESH event sequence (above) for the + PSB. + +References + + [Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in + Progress. + + + [RFC 2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and + S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 + FunctionalSpecification", RFC 2205, September 1997. + + [RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC + IPv4 Data Flows", RFC 2207, September 1997. + + [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. + Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE + Network, September 1993. + +Security Considerations + + Processing the RSVP INTEGRITY object [Baker96] is only mentioned in + this memo, because the processing rules are described here only in + general terms. The RSVP support for IPSEC [RFC 2207] will imply + modifications that have not yet been incorporated into these + processing rules. + + + + + + + + + + +Braden & Zhang Informational [Page 24] + +RFC 2209 RSVP-Message Processing September 1997 + + +Authors' Addresses + + Bob Braden + USC Information Sciences Institute + 4676 Admiralty Way + Marina del Rey, CA 90292 + + Phone: (310) 822-1511 + EMail: Braden@ISI.EDU + + + Lixia Zhang + UCLA Computer Science Department + 4531G Boelter Hall + Los Angeles, CA 90095-1596 USA + + Phone: 310-825-2695 + EMail: lixia@cs.ucla.edu + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Braden & Zhang Informational [Page 25] + |