idnits 2.17.1 draft-ietf-rsvp-procrules-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' SCOPE object SC.In from the RERR message to construct' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([RSVPspec96]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 29, 1996) is 10040 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Missing reference section? 'RSVPspec96' on line 1114 looks like a reference -- Missing reference section? 'Baker96' on line 1129 looks like a reference -- Missing reference section? 'IPSEC96' on line 1131 looks like a reference -- Missing reference section? 'RSVP93' on line 1123 looks like a reference Summary: 9 errors (**), 0 flaws (~~), 1 warning (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft R. Braden 3 Expiration: May 1997 ISI 4 File: draft-ietf-rsvp-procrules-00.txt L. Zhang 5 PARC 7 Resource ReSerVation Protocol (RSVP) -- 9 Version 1 Message Processing Rules 11 October 29, 1996 13 Status of Memo 15 This document is an Internet-Draft. Internet-Drafts are working 16 documents of the Internet Engineering Task Force (IETF), its areas, 17 and its working groups. Note that other groups may also distribute 18 working documents as Internet-Drafts. 20 Internet-Drafts are draft documents valid for a maximum of six months 21 and may be updated, replaced, or obsoleted by other documents at any 22 time. It is inappropriate to use Internet-Drafts as reference 23 material or to cite them other than as "work in progress." 25 To learn the current status of any Internet-Draft, please check the 26 "1id-abstracts.txt" listing contained in the Internet- Drafts Shadow 27 Directories on ds.internic.net (US East Coast), nic.nordu.net 28 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 29 Rim). 31 Abstract 33 This memo contains an algorithmic description of the rules used by an 34 RSVP implementation for processing messages. It is intended to 35 clarify the version 1 RSVP protocol specification. 37 This memo provides a generic description of the rules for the operation 38 of Version 1 of RSVP [RSVPspec96]. It is intended to outline a set of 39 algorithms that will accomplish the needed function, omitting many 40 details. 42 1. GENERIC DATA STRUCTURES 44 This memo assumes the generic interface calls defined in [RSVPspec96] 45 and the following data structures. An actual implementation may use 46 additional or different data structures and interfaces. The data 47 structure fields that are shown are required unless they are 48 explicitly labelled as optional. 50 o PSB -- Path State Block 52 Each PSB holds path state for a particular (session, sender) 53 pair, defined by SESSION and SENDER_TEMPLATE objects, 54 respectively, received in a PATH message. 56 PSB contents include the following values from a PATH message: 58 - Session 60 - Sender_Template 62 - Sender_Tspec 64 - The previous hop IP address and the Logical Interface 65 Handle (LIH) from a PHOP object 67 - The remaining IP TTL 69 - POLICY_DATA and/or ADSPEC objects (optional) 71 - Non_RSVP flag 73 - E_Police flag 75 - Local_Only flag 77 In addition, the PSB contains the following information provided 78 by routing: OutInterface_list, which is the list of outgoing 79 interfaces for this (sender, destination), and IncInterface, 80 which is the expected incoming interface. For a unicast 81 destination, OutInterface_list contains one entry and 82 IncInterface is undefined. 84 Note that there may be more than one PSB for the same (session, 85 sender) pair but different incoming interfaces. At most one of 86 these, which will have the Local_Only flag off, will be the PSB 87 used for forwarding PATH messages downstream; we will refer to 88 it as the "forwarding PSB" in the following. The other PSB's 89 will have the Local_Only flag on and an empty OutInterface_list. 90 The Local_Only flag is needed to correctly match PSB's against 91 RSB's, by the rules of [RSVPspec96]. 93 o RSB -- Reservation State Block 95 Each RSB holds a reservation request that arrived in a 96 particular RESV message, corresponding to the triple: (session, 97 next hop, Filter_spec_list). Here "Filter_spec_list" may be a 98 list of FILTER_SPECs (for SE style), a single FILTER_SPEC (FF 99 style), or empty (WF style). We define the virtual object type 100 "FILTER_SPEC*" for such a data structure. 102 RSB contents include: 104 - Session specification 106 - Next hop IP address 108 - Filter_spec_list 110 - The outgoing (logical) interface OI on which the 111 reservation is to be made or has been made. 113 - Style 115 - Flowspec 117 - A SCOPE object (optional, depending upon style) 119 - RESV_CONFIRM object that was received (optional) 121 o TCSB -- Traffic Control State Block 123 Each TCSB holds the reservation specification that has been 124 handed to traffic control for a specific outgoing interface. In 125 general, TCSB information is derived from RSB's for the same 126 outgoing interface. Each TCSB defines a single reservation for 127 a particular triple: (session, OI, Filter_spec_list). TCSB 128 contents include: 130 - Session 132 - OI (Outgoing Interface) 133 - Filter_spec_list 135 - TC_Flowspec, the effective flowspec, i.e., the LUB over the 136 corresponding FLOWSPEC values from matching RSB's. 137 TC_Flowspec is passed to traffic control to make the actual 138 reservation. 140 - Fwd_Flowspec, the updated object to be forwarded after 141 merging. 143 - TC_Tspec, equal to Path_Te, the effective sender Tspec. 145 - Police Flags 147 The flags are E_Police_Flag, M_Police_Flag, and 148 B_Police_Flag. 150 - Rhandle, F_Handle_list 152 Handles returned by the traffic control interface, 153 corresponding to a flowspec and perhaps a list of filter 154 specs. 156 - A RESV_CONFIRM object to be forwarded. 158 o BSB -- Blockade State Block 160 Each BSB contains an element of blockade state. Depending upon 161 the reservation style in use, the BSB's may be per (session, 162 sender_template) pair or per (session, PHOP) pair. In practice, 163 an implementation might embed a BSB within a PSB; however, for 164 clarity we describe BSB's independently. 166 The contents of a BSB include: 168 - Session 170 - Sender_Template (which is also a filter spec) 172 - PHOP 174 - FLOWSPEC Qb 176 - Blockade timer Tb 178 The following Boolean Flag variables are used in this section: 179 Path_Refresh_Needed, Resv_Refresh_Needed, Tear_Needed, Need_Scope, 180 B_Merge, and NeworMod. Refresh_PHOP_list is a variable-length list 181 of PHOPs to be refreshed. 183 2. PROCESSING RULES 185 MESSAGE ARRIVES 187 Verify version number and RSVP checksum, and discard message if any 188 mismatch is found. 190 If the message type is not PATH or PTEAR or RACK and if the IP 191 destination address does not match any of the addresses of the local 192 interfaces, then forward the message to IP destination address and 193 return. 195 Parse the sequence of objects in the message. If any required 196 objects are missing or the length field of the common header does not 197 match an object boundary, discard the message and return. 199 Verify the INTEGRITY object, if any. If the check fails, discard the 200 message and return. 202 Verify the consistent use of port fields. If the DstPort in the 203 SESSION object is zero but the SrcPort in a SENDER_TEMPLATE or 204 FILTER_SPEC object is non-zero, then the message has a "conflicting 205 source port" error; silently discard the message and return. 207 Processing of POLICY_DATA objects will be specified in the future. 209 Further processing depends upon message type. 211 PATH MESSAGE ARRIVES 213 Assume the PATH message arrives on interface InIf. 215 Process the sender descriptor object sequence in the message as 216 follows. The Path_Refresh_Needed and Resv_Refresh_Needed flags 217 are initially off. 219 o Search for a path state block (PSB) whose (session, 220 sender_template) pair matches the corresponding objects in 221 the message, and whose IncInterface matches InIf. 223 During this search: 225 1. If a PSB is found whose session matches the 226 DestAddress and Protocol Id fields of the received 227 SESSION object, but the DstPorts differ and one is 228 zero, then build and send a "Conflicting Dst Port" 229 PERR message, drop the PATH message, and return. 231 2. If a PSB is found with a matching sender host but the 232 SrcPorts differ and one of the SrcPorts is zero, then 233 build and send an "Ambiguous Path" PERR message, drop 234 the PATH message, and return. 236 3. If a forwarding PSB is found, i.e., a PSB that matches 237 the (session, sender_template) pair and whose 238 Local_Only flag is off, save a pointer to it in the 239 variable fPSB. If none is found, set fPSB to NULL. 241 o If there was no matching PSB, then: 243 1. Create a new PSB. 245 2. Copy contents of the SESSION, SENDER_TEMPLATE, 246 SENDER_TSPEC, and PHOP (IP address and LIH) objects 247 into the PSB. 249 3. If the sender is from the local API, set 250 OutInterface_List to the single interface whose 251 address matches the sender address, and make 252 IncInterface undefined. Otherwise, turn on the 253 Local_Only flag. 255 4. Turn on the Path_Refresh_Needed flag. 257 o Otherwise (there is a matching PSB): 259 - If the PHOP IP address, the LIH, or Sender_Tspec 260 differs between the message and the PSB, copy the new 261 value into the PSB and turn on the Path_Refresh_Needed 262 flag. If the PHOP IP address or the LIH differ, also 263 turn on the Resv_Refresh_Needed flag. 265 o Call the resulting PSB the "current PSB" (cPSB). Update 266 the cPSB, as follows: 268 - Start or Restart the cleanup timer for the PSB. 270 - If the message contains an ADSPEC object, copy it into 271 the PSB. 273 - Copy E_Police flag from SESSION object into PSB. 275 - Store the received TTL into the PSB. 277 If the received TTL differs from Send_TTL in the RSVP 278 common header, set the Non_RSVP flag on in the PSB. 280 o If the PSB is new or if there is no route change 281 notification in place, then perform the following routing 282 manipulations, but not if the cPSB is from the local API. 284 1. Invoke the appropriate Route_Query routine using 285 DestAddress from SESSION and (for multicast routing) 286 SrcAddress from Sender_Template. 288 Call the results (Rt_OutL, Rt_InIf). 290 2. If the destination is multicast and Rt_InIf differs 291 from IncInterface in the cPSB, but fPSB points to the 292 cPSB, then do the following. 294 - Turn on the Local_Only flag and clear the 295 OutInterface_list of the fPSB. Set the fPSB 296 pointer to NULL. 298 - Search for a PSB for the same (session, 299 sender_template) pair whose IncInterface matches 300 Rt_InIf. If one is found, set fPSB to point to 301 it. 303 3. If the destination is multicast and Rt_InIf is the 304 same as IncInterface in the cPSB, but fPSB does not 305 point to the cPSB, then do the following. 307 - Copy into the cPSB the OutInterface_list from the 308 PSB, if any, pointed to by fPSB. Clear 309 OutInterface_list and turn on the Local_Only flag 310 in the PSB pointed to by fPSB, if any. 312 - Turn off the Local_Only flag in the cPSB and set 313 fPSB to point to cPSB. 315 4. If Rt_OutL differs from OutInterface_list of the PSB 316 pointed to by fPSB, then: 318 - Update the OutInterface_list of the PSB from 319 Rt_OutL, and then execute the PATH LOCAL REPAIR 320 event sequence below. 322 o If the Path_Refresh_Needed flag is now off, drop the PATH 323 message and return. 325 Otherwise (the path state is new or modified), do 326 refreshes, upcalls, and state updates as follows. 328 1. If this PATH message came from a network interface and 329 not from a local application, make a Path Event upcall 330 for each local application for this session: 332 Call: ( session-id, PATH_EVENT, 333 flags, sender_tspec, sender_template 334 [ , ADSPEC] [ , POLICY_DATA] ) 336 2. If OutInterface_list is not empty, execute the PATH 337 REFRESH event sequence (below) for the sender defined 338 by the PSB. 340 3. Search for any matching reservation state, i.e., an 341 RSB whose Filter_spec_list includes a FILTER_SPEC 342 matching the SENDER_TEMPLATE and whose OI appears in 343 the OutInterface_list, and make this the `active RSB'. 344 If none is found, drop the PATH message and return. 346 4. Execute the RESV REFRESH sequence (below) for the PHOP 347 in the PSB. 349 5. Execute the event sequence UPDATE TRAFFIC CONTROL to 350 update the local traffic control state if necessary. 351 This sequence will turn on the Resv_Refresh_Needed 352 flag if the traffic control state has been modified in 353 a manner that should trigger a reservation refresh. 354 If so, execute the RESV REFRESH sequence for the PHOP 355 in the PSB. 357 o Drop the PATH message and return. 359 PTEAR MESSAGE ARRIVES 361 o Search for a PSB whose (Session, Sender_Template) pair 362 matches the corresponding objects in the message. If no 363 matching PSB is found, drop the PTEAR message and return. 365 o Forward a copy of the PTEAR message to each outgoing 366 interface listed in OutInterface_list of the PSB. 368 o Find each RSB that matches this PSB, i.e., whose 369 Filter_spec_list matches Sender_Template in the PSB and 370 whose OI is included in OutInterface_list. 372 1. If the RSB style is explicit, then: 374 - Delete from Filter_spec_list the FILTER_SPEC that 375 matches the PSB. 377 - if Filter_spec_list is now empty, delete the RSB. 379 2. Otherwise (RSB style is wildcard) then: 381 - If this RSB matches no other PSB, then delete the 382 RSB. 384 3. If an RSB was found, execute the event sequence UPDATE 385 TRAFFIC CONTROL (below) to update the traffic control 386 state to be consistent with the current reservation 387 and path state. 389 o Delete the PSB. 391 o Drop the PTEAR message and return. 393 PERR MESSAGE ARRIVES 395 o Search for a PSB whose (SESSION, SENDER_TEMPLATE) pair 396 matches the corresponding objects in the message. If no 397 matching PSB is found, drop the PERR message and return. 399 o If the previous hop address in the PSB is the local API, 400 make an error upcall to the application: 402 Call: ( session-id, PATH_ERROR, 403 Error_code, Error_value, 404 Node_Addr, Sender_Template 405 [ , Policy_Data] ) 407 Any SENDER_TSPEC or ADSPEC object in the message is 408 ignored. 410 Otherwise, send a copy of the PERR message to the PHOP IP 411 address. 413 o Drop the PERR message and return. 415 RESV MESSAGE ARRIVES 416 Initially, Refresh_PHOP_list is empty and the 417 Resv_Refresh_Needed and NeworMod flags are off. These variables 418 are used to control immediate reservation refreshes. 420 o Determine the Outgoing Interface OI 422 The logical outgoing interface OI is taken from the LIH in 423 the NHOP object. (If the physical interface is not implied 424 by the LIH, it can be learned from the interface matching 425 the IP destination address). 427 o Check the path state 429 1. If there are no existing PSB's for SESSION then build 430 and send a RERR message (as described later) 431 specifying "No path information", drop the RESV 432 message, and return. 434 2. If a PSB is found with a matching sender host but the 435 SrcPorts differ and one of the SrcPorts is zero, then 436 build and send an "Ambiguous Path" PERR message, drop 437 the RESV message, and return. 439 o Check for incompatible styles. 441 If any existing RSB for the session has a style that is 442 incompatible with the style of the message, build and send 443 a RERR message specifying "Conflicting Style", drop the 444 RESV message, and return. 446 Process the flow descriptor list to make reservations, as 447 follows, depending upon the style. The following uses a filter 448 spec list struct Filtss of type FILTER_SPEC* (defined earlier). 450 For FF style: execute the following steps independently for each 451 flow descriptor in the message, i.e., for each (FLOWSPEC, 452 Filtss) pair. Here the structure Filtss consists of the 453 FILTER_SPEC from the flow descriptor. 455 For SE style, execute the following steps once for (FLOWSPEC, 456 Filtss), with Filtss consisting of the list of FILTER_SPEC 457 objects from the flow descriptor. 459 For WF style, execute the following steps once for (FLOWSPEC, 460 Filtss), with Filtss an empty list. 462 o Check the path state, as follows. 464 1. Locate the set of PSBs (senders) that route to OI and 465 whose SENDER_TEMPLATEs match a FILTER_SPEC in Filtss. 467 If this set is empty, build and send an error message 468 specifying "No sender information", and continue with 469 the next flow descriptor in the RESV message. 471 2. If the style has explicit sender selection (e.g., FF 472 or SE) and if any FILTER_SPEC included in Filtss 473 matches more than one PSB, build and send a RERR 474 message specifying "Ambiguous filter spec" and 475 continue with the next flow descriptor in the RESV 476 message. 478 3. If the style is SE and if some FILTER_SPEC included in 479 Filtss matches no PSB, delete that FILTER_SPEC from 480 Filtss. 482 4. Add the PHOP from the PSB to Refresh_PHOP_list, if the 483 PHOP is not already on the list. 485 o Find or create a reservation state block (RSB) for 486 (SESSION, NHOP). If the style is distinct, Filtss is also 487 used in the selection. Call this the "active RSB". 489 o If the active RSB is new: 491 1. Set the session, NHOP, OI and style of the RSB from 492 the message. 494 2. Copy Filtss into the Filter_spec_list of the RSB. 496 3. Copy the FLOWSPEC and any SCOPE object from the 497 message into the RSB. 499 4. Set NeworMod flag on. 501 o If the active RSB is not new, check whether Filtss from the 502 message contains FILTER_SPECs that are not in the RSB; if 503 so, add the new FILTER_SPECs and turn on the NeworMod flag. 505 o Start or restart the cleanup timer on the active RSB, or, 506 in the case of SE style, on each FILTER_SPEC of the RSB 507 that also appears in Filtss. 509 o If the active RSB is not new, check whether STYLE, FLOWSPEC 510 or SCOPE objects have changed; if so, copy changed object 511 into RSB and turn on the NeworMod flag. 513 o If the message contained a RESV_CONFIRM object, copy it 514 into the RSB and turn on NeworMod flag. 516 o If the NeworMod flag is off, continue with the next flow 517 descriptor in the RESV message, if any. 519 o Otherwise (the NeworMod flag is on, i.e., the active RSB is 520 new or modified), execute the UPDATE TRAFFIC CONTROL event 521 sequence (below). If the result is to modify the traffic 522 control state, this sequence will turn on the 523 Resv_Refresh_Needed flag and make a RESV_EVENT upcall to 524 any local application. 526 If the UPDATE TRAFFIC CONTROL sequence fails with an error, 527 then delete a new RSB but restore the original reservation 528 in an old RSB. 530 o Continue with the next flow descriptor. 532 o When all flow descriptors have been processed, check the 533 Resv_Refresh_Needed flag. If it is now on, execute the 534 RESV REFRESH sequence (below) for each PHOP in 535 Refresh_PHOP_list. 537 o Drop the RESV message and return. 539 If processing a RESV message finds an error, a RERR message is 540 created containing flow descriptor and an ERRORS object. The 541 Error Node field of the ERRORS object is set to the IP address 542 of OI, and the message is sent unicast to NHOP. 544 RTEAR MESSAGE ARRIVES 546 Processing of a RTEAR message roughly parallels the processing 547 of the corresponding RESV message 549 A RTEAR message arrives with an IP destination address matching 550 outgoing interface OI. Flag Resv_Refresh_Needed is initially 551 off and Refresh_PHOP_list is empty. 553 o Determine the Outgoing Interface OI 555 The logical outgoing interface OI is taken from the LIH in 556 the NHOP object. (If the physical interface is not implied 557 by the LIH, it can be learned from the interface matching 558 the IP destination address). 560 o Process the flow descriptor list in the RTEAR message to 561 tear down local reservation state, as follows, depending 562 upon the style. The following uses a filter spec list 563 struct Filtss of type FILTER_SPEC* (defined earlier). 565 For FF style: execute the following steps independently for 566 each flow descriptor in the message, i.e., for each 567 (FLOWSPEC, Filtss) pair. Here the structure Filtss 568 consists of the FILTER_SPEC from the flow descriptor. 570 For SE style, execute the following steps once for 571 (FLOWSPEC, Filtss), with Filtss consisting of the list of 572 FILTER_SPEC objects from the flow descriptor. 574 For WF style, execute the following steps once for 575 (FLOWSPEC, Filtss), with Filtss an empty list. 577 1. Find an RSB matching (SESSION, NHOP). If the style is 578 distinct, Filtss is also used in the selection. Call 579 this the "active RSB". If no active RSB is found, 580 continue with next flow descriptor. 582 2. Check the style 584 If the active RSB has a style that is incompatible 585 with the style of the message, drop the RTEAR message 586 and return. 588 3. Delete from the active RSB each FILTER_SPEC that 589 matches a FILTER_SPEC in Filtss. 591 4. If all FILTER_SPECs have now been deleted from the 592 active RSB, delete the active RSB. 594 5. Execute the UPDATE TRAFFIC CONTROL event sequence 595 (below) to update the traffic control state to be 596 consistent with the reservation state. If the result 597 is to modify the traffic control state, the 598 Resv_Refresh_Needed flag will be turned on and a 599 RESV_EVENT upcall will be made to any local 600 application. 602 6. Continue with the next flow descriptor. 604 o All flow descriptors have been processed. 606 Build and send any RTEAR messages to be forwarded, in the 607 following manner. 609 1. Select each PSB that routes to the outgoing interface 610 OI, and, for distinct style, that has a 611 SENDER_TEMPLATE matching Filtss. 613 2. Select a flow descriptor (Qj,Fj) (where Fj may be a 614 list) in the RTEAR message whose FILTER_SPEC matches 615 the SENDER_TEMPLATE in the PSB. If not match is 616 found, return for next PSB. 618 - Search for an RSB (for any outgoing interface) to 619 which the PSB routes and whose Filter_spec_list 620 includes the SENDER_TEMPLATE from the PSB. 622 - If an RSB is found, add the PHOP of the PSB to 623 the Refresh_PHOP_list. 625 - Otherwise (no RSB is found), add the flow 626 descriptor (Qj,Fj) to the new RTEAR message being 627 built, in a manner appropriate to the style. 629 - Continue with the next PSB. 631 3. If the next PSB is for a different PHOP or the last 632 PSB has been processed, forward any RTEAR message that 633 has been built. 635 o If any PSB's were found in the preceding step, and if the 636 Resv_Refresh_Needed flag is now on, execute the RESV 637 REFRESH sequence (below) for each PHOP in 638 Refresh_PHOP_list. 640 o Drop the RTEAR message and return. 642 RERR MESSAGE ARRIVES 644 A RERR message arrives through the (real) incoming interface 645 In_If. 647 o If there is no path state for SESSION, drop the RERR 648 message and return. 650 o If the Error Code = 01 (Admission Control failure), do 651 special processing as follows: 653 1. Find or create a Blockade State Block (BSB), in the 654 following style-dependent manner. 656 For WF (wildcard) style, there will be one BSB per 657 (session, PHOP) pair. 659 For FF style, there will be one BSB per (session, 660 filter_spec) pair. Note that an FF style RERR message 661 carries only one flow descriptor. 663 For SE style, there will be one BSB per (session, 664 filter_spec), for each filter_spec contained in the 665 filter spec list of the flow descriptor. 667 2. For each BSB in the preceding step, set (or replace) 668 its FLOWSPEC Qb with FLOWSPEC from the message, and 669 set (or reset) its timer Tb to Kb*R seconds. If the 670 BSB is new, set its PHOP value, and set its 671 Sender_Template equal to the appropriate filter_spec 672 from the message. 674 3. Execute the RESV REFRESH event sequence (shown below) 675 for the previous hop PHOP, but only with the B_Merge 676 flag off. That is, if processing in the RESV REFRESH 677 sequence reaches the point of turning the B_Merge flag 678 on (because all matching reservations are blockaded), 679 do not turn it on but instead exit the REFRESH 680 sequence and return here. 682 o Execute the following for each RSB for this session whose 683 OI differs from In_If and whose Filter_spec_list has at 684 least one filter spec in common with the FILTER_SPEC* in 685 the RERR message. For WF style, empty FILTER_SPEC* 686 structures are assumed to match. 688 1. If Error_Code = 01 and the InPlace flag in the 689 ERROR_SPEC is 1 and one or more of the BSB's 690 found/created above has a Qb that is strictly greater 691 than Flowspec in the RSB, then continue with the next 692 matching RSB, if any. 694 2. If NHOP in the RSB is the local API, then: 696 - If the FLOWSPEC in the RERR message is strictly 697 greater than the RSB Flowspec, then turn on the 698 NotGuilty flag in the ERROR_SPEC. 700 - Deliver an error upcall to application: 702 Call: ( session-id, RESV_ERROR, 703 Error_code, Error_value, 704 Node_Addr, Error_flags, 705 Flowspec, Filter_Spec_List 706 [ , Policy_data] ) 708 and continue with the next RSB. 710 3. If the style has wildcard sender selection, use the 711 SCOPE object SC.In from the RERR message to construct 712 a SCOPE object SC.Out to be forwarded. SC.Out should 713 contain those sender addresses that appeared in SC.In 714 and that route to OI, as determined by scanning the 715 PSB's. If SC.Out is empty, continue with the next 716 RSB. 718 4. Create a new RERR message containing the error flow 719 descriptor and send to the NHOP address specified by 720 the RSB. Include SC.Out if the style has wildcard 721 sender selection. 723 5. Continue with the next RSB. 725 o Drop the RERR message and return. 727 RESV CONFIRM ARRIVES 729 o If the (unicast) IP address found in the RESV_CONFIRM 730 object in the RACK message matches an interface of the 731 node, a confirmation upcall is made to the matching 732 application: 734 Call: ( session-id, RESV_CONFIRM, 735 Error_code, Error_value, Node_Addr, 736 LUB-Used, nlist, Flowspec, 737 Filter_Spec_List, NULL, NULL ) 739 o Otherwise, forward the RACK message to the IP address in 740 its RESV_CONFIRM object. 742 o Drop the RACK message and return. 744 UPDATE TRAFFIC CONTROL 745 The sequence is invoked by many of the message arrival sequences 746 to set or adjust the local traffic control state in accordance 747 with the current reservation and path state. An implicit 748 parameter of this sequence is the `active' RSB. 750 If the result is to modify the traffic control state, this 751 sequence notifies any matching local applications with a 752 RESV_EVENT upcall. If the state change is such that it should 753 trigger immediate RESV refresh messages, it also turns on the 754 Resv_Refresh_Needed flag. 756 o Compute the traffic control parameters using the following 757 steps. 759 1. Initially the local flag Is_Biggest is off. 761 2. Consider the set of RSB's matching SESSION and OI from 762 the active RSB. If the style of the active RSB is 763 distinct, then the Filter_spec_list must also be 764 matched. 766 - Compute the effective kernel flowspec, 767 TC_Flowspec, as the LUB of the FLOWSPEC values in 768 these RSB's. 770 - Compute the effective traffic control filter spec 771 (list) TC_Filter_Spec* as the union of the 772 Filter_spec_lists from these RSB's. 774 - If the active RSB has a FLOWSPEC larger than all 775 the others, turn on the Is_Biggest flag. 777 3. Scan all RSB's matching session and Filtss, for all 778 OI. Set TC_B_Police_flag on if TC_Flowspec is smaller 779 than, or incomparable to, any FLOWSPEC in those RSB's. 781 4. Locate the set of PSBs (senders) whose 782 SENDER_TEMPLATEs match Filter_spec_list in the active 783 RSB and whose OutInterface_list includes OI. 785 5. Set TC_E_Police_flag on if any of these PSBs have 786 their E_Police flag on. Set TC_M_Police_flag on if it 787 is a shared style and there is more than one PSB in 788 the set. 790 6. Compute Path_Te as the sum of the SENDER_TSPEC objects 791 in this set of PSBs. 793 o Search for a TCSB matching SESSION and OI; for distinct 794 style (FF), it must also match Filter_spec_list. 796 If none is found, create a new TCSB. 798 o If TCSB is new: 800 1. Store TC_Flowspec, TC_Filter_Spec*, Path_Te, and the 801 police flags into TCSB. 803 2. Turn the Resv_Refresh_Needed flag on and make the 804 traffic control call: 806 TC_AddFlowspec( OI, TC_Flowspec, 807 Path_Te, police_flags) 808 -> Rhandle, Fwd_Flowspec 810 3. If this call fails, build and send a RERR message 811 specifying "Admission control failed" and with the 812 InPlace flag off. Delete the TCSB, delete any 813 RESV_CONFIRM object from the active RSB, and return. 815 4. Otherwise (call succeeds), record Rhandle and 816 Fwd_Flowspec in the TCSB. For each filter_spec F in 817 TC_Filter_Spec*, call: 819 TC_AddFilter( OI, Rhandle, Session, F) 820 -> Fhandle 822 and record the returned Fhandle in the TCSB. 824 o Otherwise, if TCSB is not new but no effective kernel 825 flowspec TC_Flowspec was computed earlier, then: 827 1. Turn on the Resv_Refresh_Needed flag. 829 2. Call traffic control to delete the reservation: 831 TC_DelFlowspec( OI, Rhandle ) 833 3. Delete the TCSB and return. 835 o Otherwise, if TCSB is not new but the TC_Flowspec, Path_Te, 836 and/or police flags just computed differ from corresponding 837 values in the TCSB, then: 839 1. If the TC_Flowspec and/or Path_Te values differ, turn 840 the Resv_Refresh_Needed flag on. 842 2. Call traffic control to modify the reservation: 844 TC_ModFlowspec( OI, Rhandle, TC_Flowspec, 845 Path_Te, police_flags ) 846 -> Fwd_Flowspec 848 3. If this call fails, build and send a RERR message 849 specifying "Admission control failed" and with the 850 InPlace bit on. Delete any RESV_CONFIRM object from 851 the active RSB and return. 853 4. Otherwise (the call succeeds), update the TCSB with 854 the new values and save Fwd_Flowspec in the TCSB. 856 o If the TCSB is not new but the TC_Filter_Spec* just 857 computed differs from the FILTER_SPEC* in the TCSB, then: 859 1. Make an appropriate set of TC_DelFilter and 860 TC_AddFilter calls to transform the Filter_spec_list 861 in the TCSB into the new TC_Filter_Spec*. 863 2. Turn on the Resv_Refresh_Needed flag. 865 o If the active RSB contains a RESV_CONFIRM object, then: 867 1. If the Is_Biggest flag is on, move the RESV_CONFIRM 868 object into the TCSB and turn on the 869 Resv_Refresh_Needed flag. (This will later cause the 870 RESV REFRESH sequence to be invoked, which will either 871 forward or return the RESV_CONFIRM object, deleting it 872 from the TCSB in either case). 874 2. Otherwise, create and send a RACK message to the 875 address in the RESV_CONFIRM object. Include the 876 RESV_CONFIRM object in the RACK message. The RACK 877 message should also include an ERROR_SPEC object whose 878 Error_Node parameter is IP address of OI from the TCSB 879 and that specifies "No Error". 881 o If the Resv_Refresh_Needed flag is on and the RSB is not 882 from the API, make a RESV_EVENT upcall to any matching 883 application: 885 Call: ( session-id, RESV_EVENT, 886 style, Flowspec, Filter_spec_list 887 [ , POLICY_DATA] ) 889 where Flowspec and Filter_spec_list come from the TCSB and 890 the style comes from the active RSB. 892 o Return to the event sequence that invoked this one. 894 PATH REFRESH 896 This sequence sends a path refresh for a particular sender, 897 i.e., a PSB. This sequence may be entered by either the 898 expiration of a refresh timer or directly as the result of the 899 Path_Refresh_Needed flag being turned on during the processing 900 of a received PATH message. 902 o Insert TIME_VALUES object into the PATH message being 903 built. Compute the IP TTL for the PATH message as one less 904 than the TTL value received in the message. However, if 905 the result is zero, return without sending the PATH 906 message. 908 o Create a sender descriptor containing the SENDER_TEMPLATE, 909 SENDER_TSPEC, and POLICY_DATA objects, if present in the 910 PSB, and pack it into the PATH message being built. 912 o Send a copy of the PATH message to each interface OI in 913 OutInterface_list. Before sending each copy: 915 1. If the PSB has the E_Police flag on and if interface 916 OI is not capable of policing, turn the E_Police flag 917 on in the PATH message being built. 919 2. Pass the ADSPEC object and Non_RSVP flag present in 920 the PSB to the traffic control call TC_Advertise. 921 Insert the modified ADSPEC object that is returned 922 into the PATH message being built. 924 3. Insert into its PHOP object the interface address and 925 the LIH for the interface. 927 RESV REFRESH 929 This sequence sends a reservation refresh towards a particular 930 previous hop with IP address PH. This sequence may be entered 931 by the expiration of a refresh timer, or invoked from the PATH 932 MESSAGE ARRIVES, RESV MESSAGE ARRIVES, RTEAR MESSAGE ARRIVES, or 933 RERR MESSAGE ARRIVES sequence. 935 In general, this sequence considers each of the PSB's with PHOP 936 address PH. For a given PSB, it scans the TCSBs for matching 937 reservations and merges the styles, FLOWSPECs and 938 Filter_spec_list's appropriately. It then builds a RESV message 939 and sends it to PH. The details depend upon the attributes of 940 the style(s) included in the reservations. 942 Initially the Need_Scope flag is off and the new_SCOPE object is 943 empty. 945 o Create an output message containing INTEGRITY (if 946 configured), SESSION, RSVP_HOP, and TIME_VALUES objects. 948 o Determine the style for these reservations from the first 949 RSB for the session, and move the STYLE object into the 950 proto-message. (Note that the present set of styles are 951 never themselves merged; if future styles can be merged, 952 these rules will become more complex). 954 o If style is wildcard and if there are PSB's from more than 955 one PHOP and if the multicast routing protocol does not use 956 shared trees, set the Need_Scope flag on. 958 o Select each sender PSB whose PHOP has address PH. Set the 959 local flag B_Merge off and execute the following steps. 961 1. Select all TCSB's whose Filter_spec_list's match the 962 SENDER_TEMPLATE object in the PSB and whose OI appears 963 in the OutInterface_list of the PSB. 965 2. If the PSB is from the API, then: 967 - If TCSB contains a CONFIRM object, then create 968 and send a RACK message containing the object and 969 delete the CONFIRM object from the TCSB. 971 - Continue with next PSB. 973 3. If B_Merge flag is off then ignore a blockaded TCSB, 974 as follows. 976 - Select BSB's that match this TCSB. If a selected 977 BSB is expired, delete it. If any of the 978 unexpired BSB's has a Qb that is not strictly 979 larger than TC_Flowspec, then continue processing 980 with the next TCSB. 982 However, if steps 1 and 2 result in finding that all 983 TCSB's matching this PSB are blockaded, then: 985 - If this RESV REFRESH sequence was invoked from 986 RESV ERROR RECEIVED, then return to the latter. 988 - Otherwise, turn on the B_Merge flag and restart 989 at step 1, immediately above. 991 4. Merge the flowspecs from this set of TCSB's, as 992 follows: 994 - If B_Merge flag is off, compute the LUB over the 995 flowspec objects. From each TCSB, use the 996 Fwd_Flowspec object if present, else use the 997 normal Flowspec object. 999 While computing the LUB, check for a RESV_CONFIRM 1000 object in each TCSB. If a RESV_CONFIRM object is 1001 found: 1003 - If the flowspec (Fwd_Flowspec or Flowspec) 1004 in that TCSB is larger than all other (non- 1005 blockaded) flowspecs being compared, then 1006 save this RESV_CONFIRM object for forwarding 1007 and delete from the TCSB. 1009 - Otherwise (the corresponding flowspec is not 1010 the largest), create and send a RACK message 1011 to the address in the RESV_CONFIRM object. 1012 Include the RESV_CONFIRM object in the RACK 1013 message. The RACK message should also 1014 include an ERROR_SPEC object whose 1015 Error_Node parameter is IP address of OI 1016 from the TCSB and specifying "No Error". 1018 - Delete the RESV_CONFIRM object from the 1019 TCSB. 1021 - Otherwise (B_Merge flag is on), compute the GLB 1022 over the Flowspec objects of this set of TCSB's. 1024 While computing the GLB, delete any RESV_CONFIRM 1025 object object in any of these TCSB's. 1027 5. (All matching TCSB's have been processed). The next 1028 step depends upon the style attributes. 1030 Distinct reservation (FF) style 1032 Use the Sender_Template as the merged 1033 FILTER_SPEC. Pack the merged (FLOWSPEC, 1034 FILTER_SPEC, F_POLICY_DATA) triplet into the 1035 message as a flow descriptor. 1037 Shared wildcard reservation (WF) style 1039 There is no merged FILTER_SPEC. Merge (compute 1040 the LUB of) the merged FLOWSPECS from the TCSB's, 1041 across all PSB's for PH. 1043 Shared distinct reservation (SE) style 1045 Using the Sender_Template as the merged 1046 FILTER_SPEC, form the union of the FILTER_SPECS 1047 obtained from the TCSB's. Merge (compute the LUB 1048 of) the merged FLOWSPECS from the TCSB's, across 1049 all PSB's for PH. 1051 6. If the Need_Scope flag is on and the sender specified 1052 by the PSB is not the local API: 1054 - Find each RSB that matches this PSB, i.e., whose 1055 Filter_spec_list matches Sender_Template in the 1056 PSB and whose OI is included in 1057 OutInterface_list. 1059 - If the RSB either has no SCOPE list or its SCOPE 1060 list includes the sender IP address from the PSB, 1061 insert the sender IP address into new_SCOPE. 1063 o (All PSB's for PH have been processed). Finish the RESV 1064 message. 1066 1. If Need_Scope flag is on but new_SCOPE is empty, no 1067 RESV message should be sent; return. Otherwise, if 1068 Need_Scope is on, move new_SCOPE into the message. 1070 2. If a shared reservation style is being built, move the 1071 final merged FLOWSPEC object and filter spec list into 1072 the message. 1074 3. If a RESV_CONFIRM object was saved earlier, move it 1075 into the new RESV message. 1077 4. Set the RSVP_HOP object in the message to contain the 1078 IncInterface address through which it will be sent and 1079 the LIH from (one of) the PSB's. 1081 o Send the message to the address PH. 1083 ROUTE CHANGE NOTIFICATION 1085 This sequence is triggered when routing sends a route change 1086 notification to RSVP. 1088 o Each PSB is located whose SESSION matches the destination 1089 address and whose SENDER_TEMPLATE matches the source 1090 address (for multicast). 1092 1. If the OutInterface_list from the notification differs 1093 from that in the PSB, execute the PATH LOCAL REPAIR 1094 sequence. 1096 2. If the IncInterface from the notification differs from 1097 that in the PSB, update the PSB. 1099 PATH LOCAL REPAIR 1101 The sequence is entered to effect local repair after a route 1102 change for a given PSB. 1104 o Wait for a delay time of W seconds. 1106 o Execute the PATH REFRESH event sequence (above) for the 1107 PSB. 1109 References 1111 [Baker96] Baker, F., "RSVP Cryptographic Authentication", Work in 1112 Progress, February 1996. 1114 [RSVPspec96] Braden, R., Ed, Zhang, L., Berson, S., Herzog, S., and S. 1116 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 Functional 1117 Specification", Work in progress, November 1996. 1119 [IPSEC96] Berger, L. and T. O'Malley, "RSVP Extensions for IPSEC IPv4 1120 Data Flows", Internet Draft, , 1121 Integrated Services Working Group, June 1996. 1123 [RSVP93] Zhang, L., Deering, S., Estrin, D., Shenker, S., and D. 1124 Zappala, "RSVP: A New Resource ReSerVation Protocol", IEEE Network, 1125 September 1993. 1127 Security Considerations 1129 Processing the RSVP INTEGRITY object [Baker96] is only mentioned in 1130 this memo, because the processing rules are described here only in 1131 general terms. The RSVP support for IPSEC [IPSEC96] will imply 1132 modifications that have not yet been incorporated into these 1133 processing rules. 1135 Authors' Addresses 1137 Bob Braden 1138 USC Information Sciences Institute 1139 4676 Admiralty Way 1140 Marina del Rey, CA 90292 1142 Phone: (310) 822-1511 1143 EMail: Braden@ISI.EDU 1145 Lixia Zhang 1146 Xerox Palo Alto Research Center 1147 3333 Coyote Hill Road 1148 Palo Alto, CA 94304 1150 Phone: (415) 812-4415 1151 EMail: Lixia@PARC.XEROX.COM