draft-ietf-rsvp-procrules-00.txt   rfc2209.txt 
Internet Draft R. Braden Network Working Group R. Braden
Expiration: May 1997 ISI Request For Comments: 2209 ISI
File: draft-ietf-rsvp-procrules-00.txt L. Zhang Category: Informational L. Zhang
PARC UCLA
September 1997
Resource ReSerVation Protocol (RSVP) -- Resource ReSerVation Protocol (RSVP) --
Version 1 Message Processing Rules Version 1 Message Processing Rules
October 29, 1996 Status of this Memo
Status of Memo
This document is an Internet-Draft. Internet-Drafts are working
documents of the Internet Engineering Task Force (IETF), its areas,
and its working groups. Note that other groups may also distribute
working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
To learn the current status of any Internet-Draft, please check the This memo provides information for the Internet community. It does
"1id-abstracts.txt" listing contained in the Internet- Drafts Shadow not specify an Internet standard of any kind. Distribution of this
Directories on ds.internic.net (US East Coast), nic.nordu.net memo is unlimited.
(Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
Rim).
Abstract Abstract
This memo contains an algorithmic description of the rules used by an This memo contains an algorithmic description of the rules used by an
RSVP implementation for processing messages. It is intended to RSVP implementation for processing messages. It is intended to
clarify the version 1 RSVP protocol specification. clarify the version 1 RSVP protocol specification.
This memo provides a generic description of the rules for the operation This memo provides a generic description of the rules for the
of Version 1 of RSVP [RSVPspec96]. It is intended to outline a set of operation of Version 1 of RSVP [RFC 2205]. It is intended to outline
algorithms that will accomplish the needed function, omitting many a set of algorithms that will accomplish the needed function,
details. omitting many details.
1. GENERIC DATA STRUCTURES 1. GENERIC DATA STRUCTURES
This memo assumes the generic interface calls defined in [RSVPspec96] This memo assumes the generic interface calls defined in [RFC 2005]
and the following data structures. An actual implementation may use and the following data structures. An actual implementation may use
additional or different data structures and interfaces. The data additional or different data structures and interfaces. The data
structure fields that are shown are required unless they are structure fields that are shown are required unless they are
explicitly labelled as optional. explicitly labelled as optional.
o PSB -- Path State Block o PSB -- Path State Block
Each PSB holds path state for a particular (session, sender) Each PSB holds path state for a particular (session, sender)
pair, defined by SESSION and SENDER_TEMPLATE objects, pair, defined by SESSION and SENDER_TEMPLATE objects,
respectively, received in a PATH message. respectively, received in a PATH message.
skipping to change at page 3, line 8 skipping to change at page 2, line 38
interfaces for this (sender, destination), and IncInterface, interfaces for this (sender, destination), and IncInterface,
which is the expected incoming interface. For a unicast which is the expected incoming interface. For a unicast
destination, OutInterface_list contains one entry and destination, OutInterface_list contains one entry and
IncInterface is undefined. IncInterface is undefined.
Note that there may be more than one PSB for the same (session, Note that there may be more than one PSB for the same (session,
sender) pair but different incoming interfaces. At most one of sender) pair but different incoming interfaces. At most one of
these, which will have the Local_Only flag off, will be the PSB these, which will have the Local_Only flag off, will be the PSB
used for forwarding PATH messages downstream; we will refer to used for forwarding PATH messages downstream; we will refer to
it as the "forwarding PSB" in the following. The other PSB's it as the "forwarding PSB" in the following. The other PSB's
will have the Local_Only flag on and an empty OutInterface_list. will have the Local_Only flag on and an empty
The Local_Only flag is needed to correctly match PSB's against OutInterface_list.h The Local_Only flag is needed to correctly
RSB's, by the rules of [RSVPspec96]. match PSB's against RSB's, by the rules of [RFC 2205].
o RSB -- Reservation State Block o RSB -- Reservation State Block
Each RSB holds a reservation request that arrived in a Each RSB holds a reservation request that arrived in a
particular RESV message, corresponding to the triple: (session, particular RESV message, corresponding to the triple: (session,
next hop, Filter_spec_list). Here "Filter_spec_list" may be a next hop, Filter_spec_list). Here "Filter_spec_list" may be a
list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF
style), or empty (WF style). We define the virtual object type style), or empty (WF style). We define the virtual object type
"FILTER_SPEC*" for such a data structure. "FILTER_SPEC*" for such a data structure.
skipping to change at page 4, line 4 skipping to change at page 3, line 36
Each TCSB holds the reservation specification that has been Each TCSB holds the reservation specification that has been
handed to traffic control for a specific outgoing interface. In handed to traffic control for a specific outgoing interface. In
general, TCSB information is derived from RSB's for the same general, TCSB information is derived from RSB's for the same
outgoing interface. Each TCSB defines a single reservation for outgoing interface. Each TCSB defines a single reservation for
a particular triple: (session, OI, Filter_spec_list). TCSB a particular triple: (session, OI, Filter_spec_list). TCSB
contents include: contents include:
- Session - Session
- OI (Outgoing Interface) - OI (Outgoing Interface)
- Filter_spec_list - Filter_spec_list
- TC_Flowspec, the effective flowspec, i.e., the LUB over the - TC_Flowspec, the effective flowspec, i.e., the LUB over the
corresponding FLOWSPEC values from matching RSB's. corresponding FLOWSPEC values from matching RSB's.
TC_Flowspec is passed to traffic control to make the actual TC_Flowspec is passed to traffic control to make the actual
reservation. reservation.
- Fwd_Flowspec, the updated object to be forwarded after - Fwd_Flowspec, the updated object to be forwarded
merging. after merging.
- TC_Tspec, equal to Path_Te, the effective sender Tspec. - TC_Tspec, equal to Path_Te, the effective sender Tspec.
- Police Flags - Police Flags
The flags are E_Police_Flag, M_Police_Flag, and The flags are E_Police_Flag, M_Police_Flag, and
B_Police_Flag. B_Police_Flag.
- Rhandle, F_Handle_list - Rhandle, F_Handle_list
skipping to change at page 4, line 49 skipping to change at page 4, line 33
- Session - Session
- Sender_Template (which is also a filter spec) - Sender_Template (which is also a filter spec)
- PHOP - PHOP
- FLOWSPEC Qb - FLOWSPEC Qb
- Blockade timer Tb - Blockade timer Tb
The following Boolean Flag variables are used in this section: The following Boolean Flag variables are used in this section:
Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, Need_Scope, Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed,
B_Merge, and NeworMod. Refresh_PHOP_list is a variable-length list Need_Scope, B_Merge, and NeworMod. Refresh_PHOP_list is a
of PHOPs to be refreshed. variable-length list of PHOPs to be refreshed.
2. PROCESSING RULES 2. PROCESSING RULES
MESSAGE ARRIVES MESSAGE ARRIVES
Verify version number and RSVP checksum, and discard message if any Verify version number and RSVP checksum, and discard message if any
mismatch is found. mismatch is found.
If the message type is not PATH or PTEAR or RACK and if the IP 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 destination address does not match any of the addresses of the local
skipping to change at page 5, line 36 skipping to change at page 5, line 19
SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or
FILTER_SPEC object is non-zero, then the message has a "conflicting FILTER_SPEC object is non-zero, then the message has a "conflicting
source port" error; silently discard the message and return. source port" error; silently discard the message and return.
Processing of POLICY_DATA objects will be specified in the future. Processing of POLICY_DATA objects will be specified in the future.
Further processing depends upon message type. Further processing depends upon message type.
PATH MESSAGE ARRIVES PATH MESSAGE ARRIVES
Assume the PATH message arrives on interface InIf. Assume the PATH message arrives on interface InIf.
Process the sender descriptor object sequence in the message as Process the sender descriptor object sequence in the message as
follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags are
are initially off. initially off.
o Search for a path state block (PSB) whose (session, o Search for a path state block (PSB) whose (session,
sender_template) pair matches the corresponding objects in sender_template) pair matches the corresponding objects in the
the message, and whose IncInterface matches InIf. message, and whose IncInterface matches InIf.
During this search: During this search:
1. If a PSB is found whose session matches the 1. If a PSB is found whose session matches the
DestAddress and Protocol Id fields of the received DestAddress and Protocol Id fields of the received
SESSION object, but the DstPorts differ and one is SESSION object, but the DstPorts differ and one is
zero, then build and send a "Conflicting Dst Port" zero, then build and send a "Conflicting Dst Port"
PERR message, drop the PATH message, and return. PERR message, drop the PATH message, and return.
2. If a PSB is found with a matching sender host but the 2. If a PSB is found with a matching sender host but the
SrcPorts differ and one of the SrcPorts is zero, then Src Ports differ and one of the SrcPorts is zero, then
build and send an "Ambiguous Path" PERR message, drop build and send an "Ambiguous Path" PERR message, drop
the PATH message, and return. the PATH message, and return.
3. If a forwarding PSB is found, i.e., a PSB that matches 3. If a forwarding PSB is found, i.e., a PSB that matches
the (session, sender_template) pair and whose the (session, sender_template) pair and whose
Local_Only flag is off, save a pointer to it in the Local_Only flag is off, save a pointer to it in the
variable fPSB. If none is found, set fPSB to NULL. variable fPSB. If none is found, set fPSB to NULL.
o If there was no matching PSB, then: o If there was no matching PSB, then:
skipping to change at page 8, line 12 skipping to change at page 7, line 40
o If the Path_Refresh_Needed flag is now off, drop the PATH o If the Path_Refresh_Needed flag is now off, drop the PATH
message and return. message and return.
Otherwise (the path state is new or modified), do Otherwise (the path state is new or modified), do
refreshes, upcalls, and state updates as follows. refreshes, upcalls, and state updates as follows.
1. If this PATH message came from a network interface and 1. If this PATH message came from a network interface and
not from a local application, make a Path Event upcall not from a local application, make a Path Event upcall
for each local application for this session: for each local application for this session:
Call: <Upcall_Proc>( session-id, PATH_EVENT, Call: <Upcall_Proc>( session-id, PATH_EVENT,
flags, sender_tspec, sender_template flags, sender_tspec, sender_template
[ , ADSPEC] [ , POLICY_DATA] ) [ , ADSPEC] [ , POLICY_DATA] )
2. If OutInterface_list is not empty, execute the PATH 2. If OutInterface_list is not empty, execute the PATH
REFRESH event sequence (below) for the sender defined REFRESH event sequence (below) for the sender defined
by the PSB. by the PSB.
3. Search for any matching reservation state, i.e., an 3. Search for any matching reservation state, i.e., an
RSB whose Filter_spec_list includes a FILTER_SPEC RSB whose Filter_spec_list includes a FILTER_SPEC
matching the SENDER_TEMPLATE and whose OI appears in matching the SENDER_TEMPLATE and whose OI appears in
the OutInterface_list, and make this the `active RSB'. the OutInterface_list, and make this the `active RSB'.
If none is found, drop the PATH message and return. If none is found, drop the PATH message and return.
4. Execute the RESV REFRESH sequence (below) for the PHOP 4. Execute the RESV REFRESH sequence (below) for the PHOP
in the PSB. in the PSB.
5. Execute the event sequence UPDATE TRAFFIC CONTROL to 5. Execute the event sequence UPDATE TRAFFIC CONTROL to
update the local traffic control state if necessary. update the local traffic control state if necessary.
This sequence will turn on the Resv_Refresh_Needed This sequence will turn on the Resv_Refresh_Needed
flag if the traffic control state has been modified in flag if the traffic control state has been modified in
a manner that should trigger a reservation refresh. a manner that should trigger a reservation refresh.
skipping to change at page 9, line 35 skipping to change at page 9, line 14
PERR MESSAGE ARRIVES PERR MESSAGE ARRIVES
o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair
matches the corresponding objects in the message. If no matches the corresponding objects in the message. If no
matching PSB is found, drop the PERR message and return. matching PSB is found, drop the PERR message and return.
o If the previous hop address in the PSB is the local API, o If the previous hop address in the PSB is the local API,
make an error upcall to the application: make an error upcall to the application:
Call: <Upcall_Proc>( session-id, PATH_ERROR, Call: <Upcall_Proc>( session-id, PATH_ERROR,
Error_code, Error_value, Error_code, Error_value, Node_Addr,
Node_Addr, Sender_Template Sender_Template [ , Policy_Data] )
[ , Policy_Data] )
Any SENDER_TSPEC or ADSPEC object in the message is Any SENDER_TSPEC or ADSPEC object in the message is
ignored. ignored.
Otherwise, send a copy of the PERR message to the PHOP IP Otherwise, send a copy of the PERR message to the PHOP IP
address. address.
o Drop the PERR message and return. o Drop the PERR message and return.
RESV MESSAGE ARRIVES RESV MESSAGE ARRIVES
skipping to change at page 12, line 31 skipping to change at page 12, line 12
o Continue with the next flow descriptor. o Continue with the next flow descriptor.
o When all flow descriptors have been processed, check the o When all flow descriptors have been processed, check the
Resv_Refresh_Needed flag. If it is now on, execute the Resv_Refresh_Needed flag. If it is now on, execute the
RESV REFRESH sequence (below) for each PHOP in RESV REFRESH sequence (below) for each PHOP in
Refresh_PHOP_list. Refresh_PHOP_list.
o Drop the RESV message and return. o Drop the RESV message and return.
If processing a RESV message finds an error, a RERR message is If processing a RESV message finds an error, a RERR message
created containing flow descriptor and an ERRORS object. The is created containing flow descriptor and an ERRORS object.
Error Node field of the ERRORS object is set to the IP address The Error Node field of the ERRORS object is set to the IP
of OI, and the message is sent unicast to NHOP. address of OI, and the message is sent unicast to NHOP.
RTEAR MESSAGE ARRIVES RTEAR MESSAGE ARRIVES
Processing of a RTEAR message roughly parallels the processing Processing of a RTEAR message roughly parallels the processing
of the corresponding RESV message of the corresponding RESV message
A RTEAR message arrives with an IP destination address matching A RTEAR message arrives with an IP destination address matching
outgoing interface OI. Flag Resv_Refresh_Needed is initially outgoing interface OI. Flag Resv_Refresh_Needed is initially
off and Refresh_PHOP_list is empty. off and Refresh_PHOP_list is empty.
skipping to change at page 16, line 7 skipping to change at page 15, line 37
- If the FLOWSPEC in the RERR message is strictly - If the FLOWSPEC in the RERR message is strictly
greater than the RSB Flowspec, then turn on the greater than the RSB Flowspec, then turn on the
NotGuilty flag in the ERROR_SPEC. NotGuilty flag in the ERROR_SPEC.
- Deliver an error upcall to application: - Deliver an error upcall to application:
Call: <Upcall_Proc>( session-id, RESV_ERROR, Call: <Upcall_Proc>( session-id, RESV_ERROR,
Error_code, Error_value, Error_code, Error_value,
Node_Addr, Error_flags, Node_Addr, Error_flags,
Flowspec, Filter_Spec_List Flowspec, Filter_Spec_List
[ , Policy_data] ) [ , Policy_data] )
and continue with the next RSB. and continue with the next RSB.
3. If the style has wildcard sender selection, use the 3. If the style has wildcard sender selection, use the
SCOPE object SC.In from the RERR message to construct SCOPE object SC.In from the RERR message to construct
a SCOPE object SC.Out to be forwarded. SC.Out should a SCOPE object SC.Out to be forwarded. SC.Out should
contain those sender addresses that appeared in SC.In contain those sender addresses that appeared in SC.In
and that route to OI, as determined by scanning the and that route to OI, as determined by scanning the
PSB's. If SC.Out is empty, continue with the next PSB's. If SC.Out is empty, continue with the next
RSB. RSB.
skipping to change at page 16, line 35 skipping to change at page 16, line 16
o Drop the RERR message and return. o Drop the RERR message and return.
RESV CONFIRM ARRIVES RESV CONFIRM ARRIVES
o If the (unicast) IP address found in the RESV_CONFIRM o If the (unicast) IP address found in the RESV_CONFIRM
object in the RACK message matches an interface of the object in the RACK message matches an interface of the
node, a confirmation upcall is made to the matching node, a confirmation upcall is made to the matching
application: application:
Call: <Upcall_Proc>( session-id, RESV_CONFIRM, Call: <Upcall_Proc>( session-id, RESV_CONFIRM,
Error_code, Error_value, Node_Addr, Error_code, Error_value, Node_Addr,
LUB-Used, nlist, Flowspec, LUB-Used, nlist, Flowspec,
Filter_Spec_List, NULL, NULL ) Filter_Spec_List, NULL, NULL )
o Otherwise, forward the RACK message to the IP address in o Otherwise, forward the RACK message to the IP address in
its RESV_CONFIRM object. its RESV_CONFIRM object.
o Drop the RACK message and return. Drop the RACK message and return.
UPDATE TRAFFIC CONTROL UPDATE TRAFFIC CONTROL
The sequence is invoked by many of the message arrival sequences The sequence is invoked by many of the message arrival sequences
to set or adjust the local traffic control state in accordance to set or adjust the local traffic control state in accordance
with the current reservation and path state. An implicit with the current reservation and path state. An implicit
parameter of this sequence is the `active' RSB. parameter of this sequence is the `active' RSB.
If the result is to modify the traffic control state, this If the result is to modify the traffic control state, this
sequence notifies any matching local applications with a sequence notifies any matching local applications with a
RESV_EVENT upcall. If the state change is such that it should RESV_EVENT upcall. If the state change is such that it should
trigger immediate RESV refresh messages, it also turns on the trigger immediate RESV refresh messages, it also turns on the
Resv_Refresh_Needed flag. Resv_Refresh_Needed flag.
skipping to change at page 18, line 19 skipping to change at page 17, line 42
o If TCSB is new: o If TCSB is new:
1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the
police flags into TCSB. police flags into TCSB.
2. Turn the Resv_Refresh_Needed flag on and make the 2. Turn the Resv_Refresh_Needed flag on and make the
traffic control call: traffic control call:
TC_AddFlowspec( OI, TC_Flowspec, TC_AddFlowspec( OI, TC_Flowspec,
Path_Te, police_flags) Path_Te, police_flags)
-> Rhandle, Fwd_Flowspec -> Rhandle, Fwd_Flowspec
3. If this call fails, build and send a RERR message 3. If this call fails, build and send a RERR message
specifying "Admission control failed" and with the specifying "Admission control failed" and with the
InPlace flag off. Delete the TCSB, delete any InPlace flag off. Delete the TCSB, delete any
RESV_CONFIRM object from the active RSB, and return. RESV_CONFIRM object from the active RSB, and return.
4. Otherwise (call succeeds), record Rhandle and 4. Otherwise (call succeeds), record Rhandle and
Fwd_Flowspec in the TCSB. For each filter_spec F in Fwd_Flowspec in the TCSB. For each filter_spec F in
TC_Filter_Spec*, call: TC_Filter_Spec*, call:
TC_AddFilter( OI, Rhandle, Session, F) TC_AddFilter( OI, Rhandle, Session, F)
-> Fhandle -> Fhandle
and record the returned Fhandle in the TCSB. and record the returned Fhandle in the TCSB.
o Otherwise, if TCSB is not new but no effective kernel o Otherwise, if TCSB is not new but no effective kernel
flowspec TC_Flowspec was computed earlier, then: flowspec TC_Flowspec was computed earlier, then:
1. Turn on the Resv_Refresh_Needed flag. 1. Turn on the Resv_Refresh_Needed flag.
2. Call traffic control to delete the reservation: 2. Call traffic control to delete the reservation:
TC_DelFlowspec( OI, Rhandle ) TC_DelFlowspec( OI, Rhandle )
skipping to change at page 19, line 13 skipping to change at page 18, line 35
o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te, o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te,
and/or police flags just computed differ from corresponding and/or police flags just computed differ from corresponding
values in the TCSB, then: values in the TCSB, then:
1. If the TC_Flowspec and/or Path_Te values differ, turn 1. If the TC_Flowspec and/or Path_Te values differ, turn
the Resv_Refresh_Needed flag on. the Resv_Refresh_Needed flag on.
2. Call traffic control to modify the reservation: 2. Call traffic control to modify the reservation:
TC_ModFlowspec( OI, Rhandle, TC_Flowspec, TC_ModFlowspec( OI, Rhandle, TC_Flowspec,
Path_Te, police_flags ) Path_Te, police_flags )
-> Fwd_Flowspec -> Fwd_Flowspec
3. If this call fails, build and send a RERR message 3. If this call fails, build and send a RERR message
specifying "Admission control failed" and with the specifying "Admission control failed" and with the
InPlace bit on. Delete any RESV_CONFIRM object from InPlace bit on. Delete any RESV_CONFIRM object from
the active RSB and return. the active RSB and return.
4. Otherwise (the call succeeds), update the TCSB with 4. Otherwise (the call succeeds), update the TCSB with
the new values and save Fwd_Flowspec in the TCSB. the new values and save Fwd_Flowspec in the TCSB.
o If the TCSB is not new but the TC_Filter_Spec* just o If the TCSB is not new but the TC_Filter_Spec* just
skipping to change at page 20, line 7 skipping to change at page 19, line 27
address in the RESV_CONFIRM object. Include the address in the RESV_CONFIRM object. Include the
RESV_CONFIRM object in the RACK message. The RACK RESV_CONFIRM object in the RACK message. The RACK
message should also include an ERROR_SPEC object whose message should also include an ERROR_SPEC object whose
Error_Node parameter is IP address of OI from the TCSB Error_Node parameter is IP address of OI from the TCSB
and that specifies "No Error". and that specifies "No Error".
o If the Resv_Refresh_Needed flag is on and the RSB is not 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 from the API, make a RESV_EVENT upcall to any matching
application: application:
Call: <Upcall_Proc>( session-id, RESV_EVENT, Call: <Upcall_Proc>( session-id, RESV_EVENT,
style, Flowspec, Filter_spec_list style, Flowspec, Filter_spec_list [ ,
[ , POLICY_DATA] ) POLICY_DATA] )
where Flowspec and Filter_spec_list come from the TCSB and where Flowspec and Filter_spec_list come from the TCSB and
the style comes from the active RSB. the style comes from the active RSB.
o Return to the event sequence that invoked this one. o Return to the event sequence that invoked this one.
PATH REFRESH PATH REFRESH
This sequence sends a path refresh for a particular sender, This sequence sends a path refresh for a particular sender,
i.e., a PSB. This sequence may be entered by either the i.e., a PSB. This sequence may be entered by either the
skipping to change at page 22, line 32 skipping to change at page 22, line 9
- If B_Merge flag is off, compute the LUB over the - If B_Merge flag is off, compute the LUB over the
flowspec objects. From each TCSB, use the flowspec objects. From each TCSB, use the
Fwd_Flowspec object if present, else use the Fwd_Flowspec object if present, else use the
normal Flowspec object. normal Flowspec object.
While computing the LUB, check for a RESV_CONFIRM While computing the LUB, check for a RESV_CONFIRM
object in each TCSB. If a RESV_CONFIRM object is object in each TCSB. If a RESV_CONFIRM object is
found: found:
- If the flowspec (Fwd_Flowspec or Flowspec) - If the flowspec (Fwd_Flowspec or Flowspec)
in that TCSB is larger than all other (non- in that TCSB is larger than all other (non-
blockaded) flowspecs being compared, then blockaded) flowspecs being compared, then
save this RESV_CONFIRM object for forwarding save this RESV_CONFIRM object for forwarding
and delete from the TCSB. and delete from the TCSB.
- Otherwise (the corresponding flowspec is not - Otherwise (the corresponding flowspec is not
the largest), create and send a RACK message the largest), create and send a RACK message
to the address in the RESV_CONFIRM object. to the address in the RESV_CONFIRM object.
Include the RESV_CONFIRM object in the RACK Include the RESV_CONFIRM object in the RACK
message. The RACK message should also message. The RACK message should also
include an ERROR_SPEC object whose include an ERROR_SPEC object whose
Error_Node parameter is IP address of OI Error_Node parameter is IP address of OI
from the TCSB and specifying "No Error". from the TCSB and specifying "No Error".
- Delete the RESV_CONFIRM object from the - Delete the RESV_CONFIRM object from the
TCSB. TCSB.
- Otherwise (B_Merge flag is on), compute the GLB - Otherwise (B_Merge flag is on), compute the GLB
over the Flowspec objects of this set of TCSB's. over the Flowspec objects of this set of TCSB's.
While computing the GLB, delete any RESV_CONFIRM While computing the GLB, delete any RESV_CONFIRM
object object in any of these TCSB's. object object in any of these TCSB's.
5. (All matching TCSB's have been processed). The next 5. (All matching TCSB's have been processed). The next
step depends upon the style attributes. step depends upon the style attributes.
Distinct reservation (FF) style Distinct reservation (FF) style
Use the Sender_Template as the merged Use the Sender_Template as the merged
FILTER_SPEC. Pack the merged (FLOWSPEC, FILTER_SPEC. Pack the merged (FLOWSPEC,
FILTER_SPEC, F_POLICY_DATA) triplet into the FILTER_SPEC, F_POLICY_DATA) triplet into the
message as a flow descriptor. message as a flow descriptor.
skipping to change at page 24, line 46 skipping to change at page 24, line 24
The sequence is entered to effect local repair after a route The sequence is entered to effect local repair after a route
change for a given PSB. change for a given PSB.
o Wait for a delay time of W seconds. o Wait for a delay time of W seconds.
o Execute the PATH REFRESH event sequence (above) for the o Execute the PATH REFRESH event sequence (above) for the
PSB. PSB.
References References
[Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in [Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in
Progress, February 1996. Progress.
[RSVPspec96] Braden, R., Ed, Zhang, L., Berson, S., Herzog, S., and S.
Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional [RFC 2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and
Specification", Work in progress, November 1996. S. Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1
FunctionalSpecification", RFC 2205, September 1997.
[IPSEC96] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC IPv4 [RFC 2207] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC
Data Flows", Internet Draft, <draft-ietf-rsvp-ext-04.txt>, IPv4 Data Flows", RFC 2207, September 1997.
Integrated Services Working Group, June 1996.
[RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D.
Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE
September 1993. Network, September 1993.
Security Considerations Security Considerations
Processing the RSVP INTEGRITY object [Baker96] is only mentioned in Processing the RSVP INTEGRITY object [Baker96] is only mentioned in
this memo, because the processing rules are described here only in this memo, because the processing rules are described here only in
general terms. The RSVP support for IPSEC [IPSEC96] will imply general terms. The RSVP support for IPSEC [RFC 2207] will imply
modifications that have not yet been incorporated into these modifications that have not yet been incorporated into these
processing rules. processing rules.
Authors' Addresses Authors' Addresses
Bob Braden Bob Braden
USC Information Sciences Institute USC Information Sciences Institute
4676 Admiralty Way 4676 Admiralty Way
Marina del Rey, CA 90292 Marina del Rey, CA 90292
Phone: (310) 822-1511 Phone: (310) 822-1511
EMail: Braden@ISI.EDU EMail: Braden@ISI.EDU
Lixia Zhang Lixia Zhang
Xerox Palo Alto Research Center UCLA Computer Science Department
3333 Coyote Hill Road 4531G Boelter Hall
Palo Alto, CA 94304 Los Angeles, CA 90095-1596 USA
Phone: (415) 812-4415 Phone: 310-825-2695
EMail: Lixia@PARC.XEROX.COM EMail: lixia@cs.ucla.edu
 End of changes. 36 change blocks. 
90 lines changed or deleted 76 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/