RFC relevance of reservation

As per Relevance of the word reservation, we have this rfc below:

Network Working Group R.
Request For Comments: 2209
Category: Informational L.

September 1997

Resource ReSerVation Protocol (RSVP) --
Version 1 Message Processing

Status of this

This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited

This memo contains an algorithmic description of the rules used by
RSVP implementation for processing messages. It is intended
clarify the version 1 RSVP protocol specification

This memo provides a generic description of the rules for
operation of Version 1 of RSVP [RFC 2205]. It is intended to
a set of algorithms that will accomplish the needed function
omitting many details

1. GENERIC DATA

This memo assumes the generic interface calls defined in [RFC 2005]
and the following data structures. An actual implementation may
additional or different data structures and interfaces. The
structure fields that are shown are required unless they
explicitly labelled as optional

o PSB -- Path State

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

-

- Sender_

- Sender_

- The previous hop IP address and the Logical
Handle (LIH) from a PHOP

- The remaining IP

- POLICY_DATA and/or ADSPEC objects (optional

- Non_RSVP

- E_Police

- Local_Only

In addition, the PSB contains the following information
by routing: OutInterface_list, which is the list of
interfaces for this (sender, destination), and IncInterface
which is the expected incoming interface. For a
destination, OutInterface_list contains one entry
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
these, which will have the Local_Only flag off, will be the
used for forwarding PATH messages downstream; we will refer
it as the "forwarding PSB" in the following. The other PSB'
will have the Local_Only flag on and an
OutInterface_list.h The Local_Only flag is needed to
match PSB's against RSB's, by the rules of [RFC 2205].

o RSB -- Reservation State

Each RSB holds a reservation request that arrived in
particular RESV message, corresponding to the triple: (session
next hop, Filter_spec_list). Here "Filter_spec_list" may be
list of FILTER_SPECs (for SE style), a single FILTER_SPEC (
style), or empty (WF style). We define the virtual object
"FILTER_SPEC*" for such a data structure

Braden & Zhang Informational [Page 2]

RFC 2209 RSVP-Message Processing September 1997

RSB contents include

- Session

- Next hop IP

- Filter_spec_

- The outgoing (logical) interface OI on which
reservation is to be made or has been made

-

-

- A SCOPE object (optional, depending upon style

- RESV_CONFIRM object that was received (optional

o TCSB -- Traffic Control State

Each TCSB holds the reservation specification that has
handed to traffic control for a specific outgoing interface.
general, TCSB information is derived from RSB's for the
outgoing interface. Each TCSB defines a single reservation
a particular triple: (session, OI, Filter_spec_list).
contents include

-

- OI (Outgoing Interface

- Filter_spec_

- TC_Flowspec, the effective flowspec, i.e., the LUB over
corresponding FLOWSPEC values from matching RSB's
TC_Flowspec is passed to traffic control to make the
reservation

- Fwd_Flowspec, the updated object to be
after merging

- TC_Tspec, equal to Path_Te, the effective sender Tspec

- Police

The flags are E_Police_Flag, M_Police_Flag,
B_Police_Flag

Braden & Zhang Informational [Page 3]

RFC 2209 RSVP-Message Processing September 1997

- Rhandle, F_Handle_

Handles returned by the traffic control interface
corresponding to a flowspec and perhaps a list of
specs

- A RESV_CONFIRM object to be forwarded

o BSB -- Blockade State

Each BSB contains an element of blockade state. Depending
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,
clarity we describe BSB's independently

The contents of a BSB include

-

- Sender_Template (which is also a filter spec

-

- FLOWSPEC

- Blockade timer

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
variable-length list of PHOPs to be refreshed

2. PROCESSING

MESSAGE

Verify version number and RSVP checksum, and discard message if
mismatch is found

If the message type is not PATH or PTEAR or RACK and if the
destination address does not match any of the addresses of the
interfaces, then forward the message to IP destination address
return

Parse the sequence of objects in the message. If any
objects are missing or the length field of the common header does
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
message and return

Verify the consistent use of port fields. If the DstPort in
SESSION object is zero but the SrcPort in a SENDER_TEMPLATE
FILTER_SPEC object is non-zero, then the message has a "
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

Assume the PATH message arrives on interface InIf

Process the sender descriptor object sequence in the message
follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags
initially off

o Search for a path state block (PSB) whose (session
sender_template) pair matches the corresponding objects in
message, and whose IncInterface matches InIf

During this search

1. If a PSB is found whose session matches
DestAddress and Protocol Id fields of the
SESSION object, but the DstPorts differ and one
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
Src Ports differ and one of the SrcPorts is zero,
build and send an "Ambiguous Path" PERR message,
the PATH message, and return

3. If a forwarding PSB is found, i.e., a PSB that
the (session, sender_template) pair and
Local_Only flag is off, save a pointer to it in
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)

Braden & Zhang Informational [Page 5]

RFC 2209 RSVP-Message Processing September 1997

into the PSB

3. If the sender is from the local API,
OutInterface_List to the single interface
address matches the sender address, and
IncInterface undefined. Otherwise, turn on
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_
differs between the message and the PSB, copy the
value into the PSB and turn on the Path_Refresh_
flag. If the PHOP IP address or the LIH differ,
turn on the Resv_Refresh_Needed flag

o Call the resulting PSB the "current PSB" (cPSB).
the cPSB, as follows

- Start or Restart the cleanup timer for the PSB

- If the message contains an ADSPEC object, copy it
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
common header, set the Non_RSVP flag on in the PSB

o If the PSB is new or if there is no route
notification in place, then perform the following
manipulations, but not if the cPSB is from the local API

1. Invoke the appropriate Route_Query routine
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
from IncInterface in the cPSB, but fPSB points to
cPSB, then do the following

- Turn on the Local_Only flag and clear
OutInterface_list of the fPSB. Set the

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
Rt_InIf. If one is found, set fPSB to point
it

3. If the destination is multicast and Rt_InIf is
same as IncInterface in the cPSB, but fPSB does
point to the cPSB, then do the following

- Copy into the cPSB the OutInterface_list from
PSB, if any, pointed to by fPSB.
OutInterface_list and turn on the Local_Only
in the PSB pointed to by fPSB, if any

- Turn off the Local_Only flag in the cPSB and
fPSB to point to cPSB

4. If Rt_OutL differs from OutInterface_list of the
pointed to by fPSB, then

- Update the OutInterface_list of the PSB
Rt_OutL, and then execute the PATH LOCAL
event sequence below

o If the Path_Refresh_Needed flag is now off, drop the
message and return

Otherwise (the path state is new or modified),
refreshes, upcalls, and state updates as follows

1. If this PATH message came from a network interface
not from a local application, make a Path Event
for each local application for this session

Call: ( session-id, PATH_EVENT
flags, sender_tspec, sender_
[ , ADSPEC] [ , POLICY_DATA] )

2. If OutInterface_list is not empty, execute the
REFRESH event sequence (below) for the sender
by the PSB

3. Search for any matching reservation state, i.e.,
RSB whose Filter_spec_list includes a FILTER_
matching the SENDER_TEMPLATE and whose OI appears
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
in the PSB

5. Execute the event sequence UPDATE TRAFFIC CONTROL
update the local traffic control state if necessary
This sequence will turn on the Resv_Refresh_
flag if the traffic control state has been modified
a manner that should trigger a reservation refresh
If so, execute the RESV REFRESH sequence for the
in the PSB

o Drop the PATH message and return

PTEAR MESSAGE

o Search for a PSB whose (Session, Sender_Template)
matches the corresponding objects in the message. If
matching PSB is found, drop the PTEAR message and return

o Forward a copy of the PTEAR message to each
interface listed in OutInterface_list of the PSB

o Find each RSB that matches this PSB, i.e.,
Filter_spec_list matches Sender_Template in the PSB
whose OI is included in OutInterface_list

1. If the RSB style is explicit, then
- Delete from Filter_spec_list the FILTER_SPEC
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
RSB

3. If an RSB was found, execute the event sequence
TRAFFIC CONTROL (below) to update the traffic
state to be consistent with the current
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

o Search for a PSB whose (SESSION, SENDER_TEMPLATE)
matches the corresponding objects in the message. If
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: ( session-id, PATH_ERROR
Error_code, Error_value, Node_Addr
Sender_Template [ , Policy_Data] )

Any SENDER_TSPEC or ADSPEC object in the message
ignored

Otherwise, send a copy of the PERR message to the PHOP
address

o Drop the PERR message and return

RESV MESSAGE

Initially, Refresh_PHOP_list is empty and
Resv_Refresh_Needed and NeworMod flags are off. These
are used to control immediate reservation refreshes

o Determine the Outgoing Interface

The logical outgoing interface OI is taken from the LIH
the NHOP object. (If the physical interface is not
by the LIH, it can be learned from the interface
the IP destination address).

o Check the path

1. If there are no existing PSB's for SESSION then
and send a RERR message (as described later
specifying "No path information", drop the
message, and return

2. If a PSB is found with a matching sender host but
SrcPorts differ and one of the SrcPorts is zero,
build and send an "Ambiguous Path" PERR message,
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
incompatible with the style of the message, build and
a RERR message specifying "Conflicting Style", drop
RESV message, and return

Process the flow descriptor list to make reservations,
follows, depending upon the style. The following uses a
spec list struct Filtss of type FILTER_SPEC* (defined earlier).

For FF style: execute the following steps independently for
flow descriptor in the message, i.e., for each (FLOWSPEC
Filtss) pair. Here the structure Filtss consists of
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_
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
whose SENDER_TEMPLATEs match a FILTER_SPEC in Filtss

If this set is empty, build and send an error
specifying "No sender information", and continue
the next flow descriptor in the RESV message

2. If the style has explicit sender selection (e.g.,
or SE) and if any FILTER_SPEC included in
matches more than one PSB, build and send a
message specifying "Ambiguous filter spec"
continue with the next flow descriptor in the
message

3. If the style is SE and if some FILTER_SPEC included
Filtss matches no PSB, delete that FILTER_SPEC
Filtss

4. Add the PHOP from the PSB to Refresh_PHOP_list, if
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)
(SESSION, NHOP). If the style is distinct, Filtss is
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
the message

2. Copy Filtss into the Filter_spec_list of the RSB

3. Copy the FLOWSPEC and any SCOPE object from
message into the RSB

4. Set NeworMod flag on

o If the active RSB is not new, check whether Filtss from
message contains FILTER_SPECs that are not in the RSB;
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
that also appears in Filtss

o If the active RSB is not new, check whether STYLE,
or SCOPE objects have changed; if so, copy changed
into RSB and turn on the NeworMod flag

o If the message contained a RESV_CONFIRM object, copy
into the RSB and turn on NeworMod flag

o If the NeworMod flag is off, continue with the next
descriptor in the RESV message, if any

o Otherwise (the NeworMod flag is on, i.e., the active RSB
new or modified), execute the UPDATE TRAFFIC CONTROL
sequence (below). If the result is to modify the
control state, this sequence will turn on
Resv_Refresh_Needed flag and make a RESV_EVENT upcall
any local application

If the UPDATE TRAFFIC CONTROL sequence fails with an error
then delete a new RSB but restore the original
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
Resv_Refresh_Needed flag. If it is now on, execute
RESV REFRESH sequence (below) for each PHOP
Refresh_PHOP_list

o Drop the RESV message and return

If processing a RESV message finds an error, a RERR
is created containing flow descriptor and an ERRORS object
The Error Node field of the ERRORS object is set to the
address of OI, and the message is sent unicast to NHOP

RTEAR MESSAGE

Processing of a RTEAR message roughly parallels the
of the corresponding RESV

A RTEAR message arrives with an IP destination address
outgoing interface OI. Flag Resv_Refresh_Needed is
off and Refresh_PHOP_list is empty

o Determine the Outgoing Interface

The logical outgoing interface OI is taken from the LIH
the NHOP object. (If the physical interface is not
by the LIH, it can be learned from the interface
the IP destination address).

o Process the flow descriptor list in the RTEAR message
tear down local reservation state, as follows,
upon the style. The following uses a filter spec
struct Filtss of type FILTER_SPEC* (defined earlier).

For FF style: execute the following steps independently
each flow descriptor in the message, i.e., for
(FLOWSPEC, Filtss) pair. Here the structure
consists of the FILTER_SPEC from the flow descriptor

For SE style, execute the following steps once
(FLOWSPEC, Filtss), with Filtss consisting of the list
FILTER_SPEC objects from the flow descriptor

For WF style, execute the following steps once
(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
distinct, Filtss is also used in the selection.
this the "active RSB". If no active RSB is found
continue with next flow descriptor

2. Check the

If the active RSB has a style that is
with the style of the message, drop the RTEAR
and return

3. Delete from the active RSB each FILTER_SPEC
matches a FILTER_SPEC in Filtss

4. If all FILTER_SPECs have now been deleted from
active RSB, delete the active RSB

5. Execute the UPDATE TRAFFIC CONTROL event
(below) to update the traffic control state to
consistent with the reservation state. If the
is to modify the traffic control state,
Resv_Refresh_Needed flag will be turned on and
RESV_EVENT upcall will be made to any
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
following manner

1. Select each PSB that routes to the outgoing
OI, and, for distinct style, that has
SENDER_TEMPLATE matching Filtss

2. Select a flow descriptor (Qj,Fj) (where Fj may be
list) in the RTEAR message whose FILTER_SPEC
the SENDER_TEMPLATE in the PSB. If not match
found, return for next PSB

- Search for an RSB (for any outgoing interface)
which the PSB routes and whose Filter_spec_
includes the SENDER_TEMPLATE from the PSB

- If an RSB is found, add the PHOP of the PSB
the Refresh_PHOP_list

Braden & Zhang Informational [Page 13]

RFC 2209 RSVP-Message Processing September 1997

- Otherwise (no RSB is found), add the
descriptor (Qj,Fj) to the new RTEAR message
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
PSB has been processed, forward any RTEAR message
has been built

o If any PSB's were found in the preceding step, and if
Resv_Refresh_Needed flag is now on, execute the
REFRESH sequence (below) for each PHOP
Refresh_PHOP_list

o Drop the RTEAR message and return

RERR MESSAGE

A RERR message arrives through the (real) incoming
In_If

o If there is no path state for SESSION, drop the
message and return

o If the Error Code = 01 (Admission Control failure),
special processing as follows

1. Find or create a Blockade State Block (BSB), in
following style-dependent manner

For WF (wildcard) style, there will be one BSB
(session, PHOP) pair

For FF style, there will be one BSB per (session
filter_spec) pair. Note that an FF style RERR
carries only one flow descriptor

For SE style, there will be one BSB per (session
filter_spec), for each filter_spec contained in
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,
set (or reset) its timer Tb to Kb*R seconds. If
BSB is new, set its PHOP value, and set
Sender_Template equal to the appropriate filter_
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_
flag off. That is, if processing in the RESV
sequence reaches the point of turning the B_Merge
on (because all matching reservations are blockaded),
do not turn it on but instead exit the
sequence and return here

o Execute the following for each RSB for this session
OI differs from In_If and whose Filter_spec_list has
least one filter spec in common with the FILTER_SPEC*
the RERR message. For WF style, empty FILTER_SPEC
structures are assumed to match

1. If Error_Code = 01 and the InPlace flag in
ERROR_SPEC is 1 and one or more of the BSB'
found/created above has a Qb that is strictly
than Flowspec in the RSB, then continue with the
matching RSB, if any

2. If NHOP in the RSB is the local API, then

- If the FLOWSPEC in the RERR message is
greater than the RSB Flowspec, then turn on
NotGuilty flag in the ERROR_SPEC

- Deliver an error upcall to application

Call: ( session-id, RESV_ERROR
Error_code, Error_value
Node_Addr, Error_flags
Flowspec, Filter_Spec_
[ , Policy_data] )

and continue with the next RSB

3. If the style has wildcard sender selection, use
SCOPE object SC.In from the RERR message to
a SCOPE object SC.Out to be forwarded. SC.Out
contain those sender addresses that appeared in SC.
and that route to OI, as determined by scanning
PSB's. If SC.Out is empty, continue with the
RSB

4. Create a new RERR message containing the error
descriptor and send to the NHOP address specified
the RSB. Include SC.Out if the style has
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

o If the (unicast) IP address found in the RESV_
object in the RACK message matches an interface of
node, a confirmation upcall is made to the
application

Call: ( 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
its RESV_CONFIRM object

Drop the RACK message and return

UPDATE TRAFFIC

The sequence is invoked by many of the message arrival
to set or adjust the local traffic control state in
with the current reservation and path state. An
parameter of this sequence is the `active' RSB

If the result is to modify the traffic control state,
sequence notifies any matching local applications with
RESV_EVENT upcall. If the state change is such that it
trigger immediate RESV refresh messages, it also turns on
Resv_Refresh_Needed flag

o Compute the traffic control parameters using the
steps

1. Initially the local flag Is_Biggest is off

2. Consider the set of RSB's matching SESSION and OI
the active RSB. If the style of the active RSB
distinct, then the Filter_spec_list must also
matched

- Compute the effective kernel flowspec
TC_Flowspec, as the LUB of the FLOWSPEC values
these RSB's

Braden & Zhang Informational [Page 16]

RFC 2209 RSVP-Message Processing September 1997

- Compute the effective traffic control filter
(list) TC_Filter_Spec* as the union of
Filter_spec_lists from these RSB's

- If the active RSB has a FLOWSPEC larger than
the others, turn on the Is_Biggest flag

3. Scan all RSB's matching session and Filtss, for
OI. Set TC_B_Police_flag on if TC_Flowspec is
than, or incomparable to, any FLOWSPEC in those RSB's

4. Locate the set of PSBs (senders)
SENDER_TEMPLATEs match Filter_spec_list in the
RSB and whose OutInterface_list includes OI

5. Set TC_E_Police_flag on if any of these PSBs
their E_Police flag on. Set TC_M_Police_flag on if
is a shared style and there is more than one PSB
the set

6. Compute Path_Te as the sum of the SENDER_TSPEC
in this set of PSBs

o Search for a TCSB matching SESSION and OI; for
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
police flags into TCSB

2. Turn the Resv_Refresh_Needed flag on and make
traffic control call

TC_AddFlowspec( OI, TC_Flowspec
Path_Te, police_flags
-> Rhandle, Fwd_

3. If this call fails, build and send a RERR
specifying "Admission control failed" and with
InPlace flag off. Delete the TCSB, delete
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
Fwd_Flowspec in the TCSB. For each filter_spec F
TC_Filter_Spec*, call

TC_AddFilter( OI, Rhandle, Session, F
->

and record the returned Fhandle in the TCSB

o Otherwise, if TCSB is not new but no effective
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
values in the TCSB, then

1. If the TC_Flowspec and/or Path_Te values differ,
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_

3. If this call fails, build and send a RERR
specifying "Admission control failed" and with
InPlace bit on. Delete any RESV_CONFIRM object
the active RSB and return

4. Otherwise (the call succeeds), update the TCSB
the new values and save Fwd_Flowspec in the TCSB

o If the TCSB is not new but the TC_Filter_Spec*
computed differs from the FILTER_SPEC* in the TCSB, then

1. Make an appropriate set of TC_DelFilter
TC_AddFilter calls to transform the Filter_spec_
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_
object into the TCSB and turn on
Resv_Refresh_Needed flag. (This will later cause
RESV REFRESH sequence to be invoked, which will
forward or return the RESV_CONFIRM object, deleting
from the TCSB in either case).

2. Otherwise, create and send a RACK message to
address in the RESV_CONFIRM object. Include
RESV_CONFIRM object in the RACK message. The
message should also include an ERROR_SPEC object
Error_Node parameter is IP address of OI from the
and that specifies "No Error".

o If the Resv_Refresh_Needed flag is on and the RSB is
from the API, make a RESV_EVENT upcall to any
application

Call: ( session-id, RESV_EVENT
style, Flowspec, Filter_spec_list [ ,
POLICY_DATA] )

where Flowspec and Filter_spec_list come from the TCSB
the style comes from the active RSB

o Return to the event sequence that invoked this one

PATH

This sequence sends a path refresh for a particular sender
i.e., a PSB. This sequence may be entered by either
expiration of a refresh timer or directly as the result of
Path_Refresh_Needed flag being turned on during the
of a received PATH message

o Insert TIME_VALUES object into the PATH message
built. Compute the IP TTL for the PATH message as one
than the TTL value received in the message. However,
the result is zero, return without sending the
message

o Create a sender descriptor containing the SENDER_TEMPLATE
SENDER_TSPEC, and POLICY_DATA objects, if present in
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
OutInterface_list. Before sending each copy

1. If the PSB has the E_Police flag on and if
OI is not capable of policing, turn the E_Police
on in the PATH message being built

2. Pass the ADSPEC object and Non_RSVP flag present
the PSB to the traffic control call TC_Advertise
Insert the modified ADSPEC object that is
into the PATH message being built

3. Insert into its PHOP object the interface address
the LIH for the interface

RESV

This sequence sends a reservation refresh towards a
previous hop with IP address PH. This sequence may be
by the expiration of a refresh timer, or invoked from the
MESSAGE ARRIVES, RESV MESSAGE ARRIVES, RTEAR MESSAGE ARRIVES,
RERR MESSAGE ARRIVES sequence

In general, this sequence considers each of the PSB's with
address PH. For a given PSB, it scans the TCSBs for
reservations and merges the styles, FLOWSPECs
Filter_spec_list's appropriately. It then builds a RESV
and sends it to PH. The details depend upon the attributes
the style(s) included in the reservations

Initially the Need_Scope flag is off and the new_SCOPE object
empty

o Create an output message containing INTEGRITY (
configured), SESSION, RSVP_HOP, and TIME_VALUES objects

o Determine the style for these reservations from the
RSB for the session, and move the STYLE object into
proto-message. (Note that the present set of styles
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
one PHOP and if the multicast routing protocol does not
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
local flag B_Merge off and execute the following steps

1. Select all TCSB's whose Filter_spec_list's match
SENDER_TEMPLATE object in the PSB and whose OI
in the OutInterface_list of the PSB

2. If the PSB is from the API, then

- If TCSB contains a CONFIRM object, then
and send a RACK message containing the object
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
BSB is expired, delete it. If any of
unexpired BSB's has a Qb that is not
larger than TC_Flowspec, then continue
with the next TCSB

However, if steps 1 and 2 result in finding that
TCSB's matching this PSB are blockaded, then

- If this RESV REFRESH sequence was invoked
RESV ERROR RECEIVED, then return to the latter

- Otherwise, turn on the B_Merge flag and
at step 1, immediately above

4. Merge the flowspecs from this set of TCSB's,
follows

- If B_Merge flag is off, compute the LUB over
flowspec objects. From each TCSB, use
Fwd_Flowspec object if present, else use
normal Flowspec object

Braden & Zhang Informational [Page 21]

RFC 2209 RSVP-Message Processing September 1997

While computing the LUB, check for a RESV_
object in each TCSB. If a RESV_CONFIRM object
found

- If the flowspec (Fwd_Flowspec or Flowspec
in that TCSB is larger than all other (non
blockaded) flowspecs being compared,
save this RESV_CONFIRM object for
and delete from the TCSB

- Otherwise (the corresponding flowspec is
the largest), create and send a RACK
to the address in the RESV_CONFIRM object
Include the RESV_CONFIRM object in the
message. The RACK message should
include an ERROR_SPEC object
Error_Node parameter is IP address of
from the TCSB and specifying "No Error".

- Delete the RESV_CONFIRM object from
TCSB

- Otherwise (B_Merge flag is on), compute the
over the Flowspec objects of this set of TCSB's

While computing the GLB, delete any RESV_
object object in any of these TCSB's

5. (All matching TCSB's have been processed). The
step depends upon the style attributes

Distinct reservation (FF)

Use the Sender_Template as the
FILTER_SPEC. Pack the merged (FLOWSPEC
FILTER_SPEC, F_POLICY_DATA) triplet into
message as a flow descriptor

Shared wildcard reservation (WF)

There is no merged FILTER_SPEC. Merge (
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)

Using the Sender_Template as the
FILTER_SPEC, form the union of the FILTER_
obtained from the TCSB's. Merge (compute the
of) the merged FLOWSPECS from the TCSB's,
all PSB's for PH

6. If the Need_Scope flag is on and the sender
by the PSB is not the local API

- Find each RSB that matches this PSB, i.e.,
Filter_spec_list matches Sender_Template in
PSB and whose OI is included
OutInterface_list

- If the RSB either has no SCOPE list or its
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
message

1. If Need_Scope flag is on but new_SCOPE is empty,
RESV message should be sent; return. Otherwise,
Need_Scope is on, move new_SCOPE into the message

2. If a shared reservation style is being built, move
final merged FLOWSPEC object and filter spec list
the message

3. If a RESV_CONFIRM object was saved earlier, move
into the new RESV message

4. Set the RSVP_HOP object in the message to contain
IncInterface address through which it will be sent
the LIH from (one of) the PSB's

o Send the message to the address PH

ROUTE CHANGE

This sequence is triggered when routing sends a route
notification to RSVP

o Each PSB is located whose SESSION matches the
address and whose SENDER_TEMPLATE matches the
address (for multicast).

Braden & Zhang Informational [Page 23]

RFC 2209 RSVP-Message Processing September 1997

1. If the OutInterface_list from the notification
from that in the PSB, execute the PATH LOCAL
sequence

2. If the IncInterface from the notification differs
that in the PSB, update the PSB

PATH LOCAL

The sequence is entered to effect local repair after a
change for a given PSB

o Wait for a delay time of W seconds

o Execute the PATH REFRESH event sequence (above) for
PSB

[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work
Progress

[RFC 2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S.,
S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
FunctionalSpecification", RFC 2205, September 1997.

[RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for
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",
Network, September 1993.

Security

Processing the RSVP INTEGRITY object [Baker96] is only mentioned
this memo, because the processing rules are described here only
general terms. The RSVP support for IPSEC [RFC 2207] will
modifications that have not yet been incorporated into
processing rules

Braden & Zhang Informational [Page 24]

RFC 2209 RSVP-Message Processing September 1997

Authors'

Bob
USC Information Sciences
4676 Admiralty
Marina del Rey, CA 90292

Phone: (310) 822-1511
EMail: Braden@ISI.

Lixia
UCLA Computer Science
4531G Boelter
Los Angeles, CA 90095-1596

Phone: 310-825-2695
EMail: lixia@cs.ucla.

Braden & Zhang Informational [Page 25]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX