idnits 2.17.1 draft-ietf-rsvp-policy-lpm-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-03-29) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 13 longer pages, the longest (page 2) being 60 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 15 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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 document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 31 instances of too long lines in the document, the longest one being 4 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 61 has weird spacing: '...Section provi...' == Line 98 has weird spacing: '... Figure illus...' == Line 160 has weird spacing: '...Section for m...' -- 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 (June 12, 1996) is 10152 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. 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: 'Note 1' is mentioned on line 118, but not defined == Missing Reference: 'Note 2' is mentioned on line 246, but not defined == Missing Reference: 'Note 3' is mentioned on line 343, but not defined == Missing Reference: 'Note 4' is mentioned on line 386, but not defined == Missing Reference: 'Note 5' is mentioned on line 433, but not defined == Missing Reference: 'Note 6' is mentioned on line 558, but not defined == Unused Reference: 'HER96c' is defined on line 622, but no explicit reference was found in the text == Unused Reference: 'HER96b' is defined on line 625, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-rsvp-md5-02 == Outdated reference: A later version (-05) exists of draft-ietf-rsvp-policy-ext-00 -- Possible downref: Normative reference to a draft: ref. 'HER96c' -- Possible downref: Normative reference to a draft: ref. 'HER96b' Summary: 10 errors (**), 0 flaws (~~), 16 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Shai Herzog 3 Expiration: December 1996 USC/ISI 4 File: draft-ietf-rsvp-policy-lpm-00.txt 6 Local Policy Modules (LPM): 8 Policy Enforcement for Resource Reservation Protocols 10 June 12, 1996 12 Status of Memo 14 This document is an Internet-Draft. Internet-Drafts are working 15 documents of the Internet Engineering Task Force (IETF), its areas, 16 and its working groups. Note that other groups may also distribute 17 working documents as Internet-Drafts. 19 Internet-Drafts are draft documents valid for a maximum of six months 20 and may be updated, replaced, or obsoleted by other documents at any 21 time. It is inappropriate to use Internet-Drafts as reference 22 material or to cite them other than as "work in progress." 24 To learn the current status of any Internet-Draft, please check the 25 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 26 Directories on ds.internic.net (US East Coast), nic.nordu.net 27 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 28 Rim). 30 Abstract 32 This memo describes a set of building blocks for policy based 33 admission control in RSVP and similar resource reservation protocols. 34 We describe an interface between RSVP and Local Policy Modules (LPM); 35 this interface provides RSVP with policy related information, and 36 allows local policy modules to support various accounting and access 37 control policies. 39 1. Introduction 41 The current admission process in RSVP uses resource (capacity) based 42 admission control; we expand this model to include policy based 43 admission control as well, in one atomic operation. Policy admission 44 control is enforced at border/policy nodes by Local Policy Modules 45 (LPMs). LPMs based their admission decision, among other factors, on 46 the contents of POLICY_DATA objects that are carried inside RSVP 47 messages. LPMs are responsible for receiving, processing, and 48 forwarding POLICY_DATA objects. Subject to the applicable bilateral 49 agreements, and local policies, LPMs may also rewrite and modify the 50 POLICY_DATA objects as the pass through policy nodes. 52 In this document, we describe the range of policies that can be 53 supported, however, we recommend that you read this document along 54 side with its policy reference document~[HER96b]. This document 55 describes a generic framework for policy enforcement; we do not 56 advocate any specific access control policies since we believe that 57 standardization of policies (as opposed to the framework) may require 58 significantly more research and better understanding of the 59 tradeoffs. 61 Section provides a general description of the RSVP/LPM interface, 62 Section~ specified the internal representation of POLICY_ELEMENT 63 objects, Section~ describes the detailed interface between RSVP and 64 the LPM, and Section~ provides a peek into some of the more important 65 LPM implementation internals. 67 2. The RSVP/LPM interface 69 Unless we are willing to declare a single monolithic access policy we 70 need to accommodate varying, independent access control mechanisms in 71 RSVP (e.g., over different regions of the Internet, internal 72 accounting vs. inter-provider accounting, quota vs. advanced 73 reservations, etc.). Each mechanism can have its own, type-specific 74 internal format, can be configured for local needs (e.g., policy data 75 rewrite (conversion) table, etc.), and can be added and removed from 76 nodes with little or no impact on other mechanisms. 78 2.1 POLICY_DATA objects 80 RSVP messages may carry optional POLICY_DATA objects. Policy data 81 objects are a general container for policy related information 82 that could assist local RSVP nodes along the reserved path in 83 their policy decisions. Policy information may originate from 84 end-users, however, it can also be created or converted at the 85 core of the network. POLICY_DATA objects contain an optional list 86 of FILTER_SPEC objects which identify the flows it is associated 87 with: we expect that some access control mechanisms to use session 88 POLICY_DATA objects (with wildcard FILTER_SPEC) while others may 89 require the full power of per-flow object semantics. Generally, we 90 assume that POLICY_DATA objects can be carried by any RSVP 91 message, (e.g., Path, Resv, ResvErr, etc.). 93 2.2 Modular Context 95 Before RSVP accepts a reservation it must check for access 96 authorization. This is where local policy modules take effect, 97 verifying access rights to local resources (i.e. links, clouds, 98 etc.). Figure illustrates the context for the proposed design: 99 RSVP interfaces to the LPM to handle input and output of 100 POLICY_DATA objects and to check the status of reservations. 101 Conceptually, a reservation must be accepted both physically and 102 administratively; physically, by traditional admission control 103 (based on congestion) and administratively by the local access 104 policy enforced by the LPM. This dual admission must be atomic and 105 this atomicity is represented by the "accept/reject" module. In 106 this document, we concentrate only on the highlighted modules: the 107 RSVP and the LPM interfaces. The RSVP interface is defined by 108 describing the functionality that is expected from RSVP in order 109 to support access control. It includes the handling of incoming 110 messages, scheduling outgoing messages, and performing status 111 checks. The LPM interface describes the services the LPM 112 provides, through a set of LPM functions. However, we do not 113 define how RSVP should check the status of reservations (it could 114 be done by calling the LPM directly, through an accept/reject 115 module, or in other ways). [Note 1] 117 _________________________ 118 [Note 1] The RSVP admission process is unidirectional and does not 119 include upcalls to RSVP, e.g., there is no upcall to notify RSVP that a 120 previously made reservation was canceled or preempted. We do however 121 anticipate that once the initial access control architecture is in 122 place, later changes to the RSVP spec, would define an "accept/reject" 123 module, and associated status update upcalls to RSVP. 125 +--------------------+ 126 | RSVP | 127 +--------------------+ 128 /|\ /|\ 129 Resv. status | | In/Outgoing objects 130 \|/ \|/ 131 +---------------+ +---------------+ 132 | Accept/Reject |<---->| LPM | 133 +---------------+ +---------------+ 134 /|\ 135 | 136 \|/ 137 +---------------+ 138 | Ad. Control | 139 +---------------+ 140 Figure 1: The modular context of access control 142 2.3 Local Policy Modules 144 Local Policy Modules (LPMs) can be configured locally, to a 145 particular access policy. LPMs have three basic functions: first, 146 to receive incoming policy data objects, second, to update the 147 access/accounting status of reservations, and third, to build 148 accounting/policy data objects for outgoing RSVP messages (The LPM 149 message flow outline is illustrated in figure ). LPMs maintain 150 local access state for supporting the LPM operations, and this 151 state must remain consistent with RSVP's state. 153 2.3.1 Processing incoming messages 155 RSVP calls the LPM for object processing each time it receives 156 a POLICY_DATA object. The LPM processes, stores the object's 157 information, and returns a status code to RSVP. The status code 158 reports the success/failure of object processing, but does not 159 reflect the acceptance of the reservation. The status of a 160 reservation must be checked separately (see Section for more 161 details). 163 +----------------------------------------------+ 164 | RSVP | 165 | | 166 ************** ************************************> 167 <=============*========*======== ===================== 168 | * * || || | 169 | * * ***||******||******************> 170 | * * * || || =============== 171 +--------*--------*--*----||------||----||-----+ 172 * * * || || || 173 \*/ ** || \||/ \||/ 174 +--------*--------*-------||------||----||-----+ 175 | ********** +==============+ 176 | LPM: Common Layer | 177 +----------------------------------------------+ 178 /|\ /|\ /|\ 179 | | | 180 \|/ \|/ \|/ 181 +-----------+ +-----------+ +-----------+ 182 | Handler 0 | | Handler 1 |<----+ Handler 2 | 183 +-----------+ +-----------+ +-----------+ 184 Figure 2: LPM and RSVP: message flow outline 186 2.3.2 Processing outgoing messages 188 When RSVP generates an outgoing message it calls the LPM. The 189 LPM assembles the outgoing policy data objects and hands them 190 to RSVP for placing inside the outgoing message. 192 2.3.3 Reservation status updates 194 The concept of access control assumes that even previously 195 admitted reservations are conditional, in a sense that changes 196 in access status may trigger some action against the associated 197 reservation (i.e., cancel it, allow its preemption, etc.). 198 Therefore, the access control mechanism must periodically check 199 for reservation status changes (like quota exhaustion) and take 200 the appropriate measures. Reservation status should also be 201 checked when system events require it, (e.g., the arrival of a 202 new policy data object with updated information). Status 203 checks may be limited to the scope of the change (e.g., only 204 the interface from which the new RSVP message arrived). 206 2.3.4 Optional debiting for Reservations 208 The simplest form of access control performs a binary task: 209 accept or reject a reservation. More advanced policies may 210 require the LPM to perform book keeping (i.e., usage quota 211 enforcement or even cost recovery). To achieve such tasks, the 212 LPM can be configured to perform debiting. Debiting is not 213 part of the LPM interface, and can be configured as an option 214 into the status update: when RSVP queries the LPM about the 215 status of a reservation, the LPM may perform debiting, and 216 update the status of the reservation according to the debiting 217 result. The debiting process is based on two separate 218 functions: determining "cost", and actual debiting. These two 219 functions can be fully independent from each other, and most 220 likely be carried out by different handlers. 222 In multicast environments, with upstream merging, it is very 223 likely that a reservation will be debited against multiple 224 network entities that represent the aggregated credentials of 225 the downstream receivers. This raises the issue of the "sharing 226 model". The sharing model defines how the reservation is 227 shared among the different policy data objects. [Note 2] 229 The sharing model, and the selection of cost allocation and 230 actual debiting mechanisms is an issue of LPM local 231 configuration, and is not discussed in this document. 233 2.3.5 Security issues 235 Hop-by-hop authentication mechanism: 237 The RSVP security mechanism proposed in [BAK96] relies on hop- 238 by-hop authentication. This form of authentication creates 239 a chain of trust that is only as strong as its weakest 240 element (in our case, the weakest router). As long as we 241 believe that all RSVP nodes are policy nodes as well, then 242 RSVP security is sufficient for the entire RSVP message, 243 including POLICY_DATA objects. This however is not the 244 case when policy is only enforced at boundary nodes. 245 _________________________ 246 [Note 2] Sharing model examples: (1) Each policy object is allocated the 247 full cost, (2) The cost is divided equally between the different objects 248 (3) The cost is attributed to an arbitrary object (4) The cost allocated 249 relative to some criteria like the number of downstream receivers, the 250 size of the organization, the amount of pre-purchased capacity 251 (remaining quota), etc. 253 Security over clouds: 255 If policies are only enforced at cloud entry and exit 256 points, then RSVP's security is insufficient to protect 257 policy objects, since from a policy enforcement 258 perspective, the in-cloud nodes are unsecured. We propose 259 a "policy data tunneling" approach, where the logical 260 policy topology is discovered automatically, and security 261 is enforced over the logical topology. When policy 262 objects are created at border routers, they are 263 encapsulated in a security envelope (described in Sections 264 and ref security-issues). The envelop is forwarded as-is 265 over the cloud, and is only removed by the cloud border 266 (exit) node. 268 2.4 Default handling of policy data objects 270 Because we do not expect (or desire) that every RSVP node will be 271 capable of processing all types of policy data objects, it is 272 essential that RSVP define default handling of such unrecognized 273 objects, and that this default handling be required from any 274 RSVP/LPM implementation. The general concept is that RSVP play 275 the role of a repeater (or a tunnel) by forwarding the received 276 objects without modification. Implementation details are an part 277 of the internal LPM architecture, described in Section . 279 3. POLICY_ELEMENT objects: internal representation 281 The contents of the POLICY_ELEMENT is opaque to RSVP; the format we 282 describe here is only visible to the LPM. POLICY_ELEMENT objects are 283 made of a list of policy particles. Policy particles have a length, a 284 policy type (PType) and a type specific format. 286 +-------------+-------------+-------------+-------------+ 287 | Length | 20 | CType | 288 +---------------------------+-------------+-------------+ 289 | Policy Particles (list) | 290 +-------------------------------------------------------+ 292 Individual policy particle has the following format 294 +---------------------------+---------------------------+ 295 | Length | PType | 296 +---------------------------+---------------------------+ 297 | Ptype specific format | 298 +-------------------------------------------------------+ 300 4. LPM calls 302 The LPM maintains access control state per flow. This state is 303 complementary to the RSVP state, and both are semantically attached 304 by flow handles, for all the LPM calls. 306 4.1 Success codes 308 All the LPM calls report success/failure status. This report is 309 made of three components: (1) a return code of the lpm function, 310 that reports the general success of the call (2) a global variable 311 "lpm_errno" that reports specific reason code (similar to the 312 errno in Unix), and (3) a global variable "lpm_eflgs" used for 313 flags set by the LPM call. 315 4.2 Flow handles (fh) 317 The LPM uses Flow Handles (fh) to associate RSVP flows with LPM 318 state. RSVP obtains flow handles by calling "lpm_open()", which 319 is called only once for each session or flow, upon the first 320 arrival of a POLICY_DATA object associated with that flow or 321 session. RSVP obtains the flow handle and stores it in the flow's 322 data structures, for future lpm calls. 324 When an RSVP message is fragmented, POLICY_DATA objects may be out 325 of order, and may reside in separate packets. The responsibility 326 of associating a POLICY_DATA object with a particular flow (and 327 its flow handles (fh)) lies "always" with RSVP. The FILTER_SPEC 328 object inside the POLICY_DATA object is visible to RSVP, and 329 should be used by it to aid in this classification. [Note 3] 331 It is important to note that under no circumstances should this 332 classification be left to the LPM. 334 4.3 Associating source and receiver objects 336 The access status of a reservation may depend on policy data 337 objects originating from the source, receivers or both. For 338 instance, a lecture can be sponsored by the source that would 339 provide the necessary credentials. If the LPM architecture is to 340 support source based policies, it must be able to associate source 341 objects with reservation state. Some associations are trivial 342 _________________________ 343 [Note 3] The FILTER_SPEC object is opaque to the LPM and the only reason 344 it is included inside the POLICY_DATA object is to allow RSVP to 345 associate the object with its corresponding flow. 347 (like in the case of fixed filter (FF) reservation style) but some 348 are more complicated (as in WF reservations). Since the LPM 349 architecture associates flow handles with individual source state, 350 it is the responsibility of RSVP to map reservations to their list 351 of associated sources. The list takes the form of a list of flow 352 handles, and can be passed on to LPM functions through a pair of 353 parameters, "int fh_num" and "int *fn_vec"). 355 4.4 LPM calls format 357 lpm_open (int *fh) 359 When RSVP first encounters POLICY_DATA objects, it calls the LPM's 360 "lpm_open" routine. The LPM builds internal control blocks and 361 places the flow handle value in fh, for future reference. 363 All incoming POLICY_DATA objects are passed by RSVP to the LPM: 365 lpm_in (int fh_num, int *fh_vec, int vif, RSVP_HOP *hop, int 366 mtype, POLICY_DATA *polp, int ttd) 368 Parameter "vif" describes the input virtual interface [Note 4] 369 from which the RSVP message was received, "hop" describes the 370 node that sent the RSVP message (previous hop/next hop), and 371 "mtype" describes the type (and implicitly, the direction) of the 372 RSVP message (i.e., Path, Resv etc.). Parameter "polp" points to 373 the policy data object, and "ttd" provides a timeout (time to die) 374 value for the policy data object. 376 When RSVP is ready for output, it queries the LPM: 378 lpm_out (int fh_num, int *fh_vec, int vif, RSVP_HOP *hop, int 379 mtype, POLICY_DATA **polp) 381 The parameters are similar to those for "lpm_in". A successful 382 call places a pointer to the outgoing POLICY_DATA object in 383 "polp"; Notice that the output process is performed separately for 384 each outgoing RSVP message, but is required to maintain 385 _________________________ 386 [Note 4] The term Virtual Interface (vif) is borrowed from DVMRP 387 terminology, although, for LPM purposes it can be any integer index that 388 RSVP associates with specific interfaces, independently from any routing 389 protocol. 391 consistency and atomicity even if some LPM status had changed in 392 between outputs of different outgoing RSVP messages. Notice that 393 there is no formal limit on the size of the resulting POLICY_DATA 394 object. If the resulting object is too large to be sent in a 395 single RSVP message it is RSVP's responsibility to perform 396 semantic fragmentation because it has the unique knowledge about 397 available message space. An alternative solution would be to 398 provide an lpm_fragment() service to help RSVP in this task. 400 Checking the status of an existing reservation is done by calling: 402 lpm_status (int fh_session, int fh_num, int *fh_vec, int vif, int 403 cur_time, int phy_resv_handle, Object_header 404 *phy_resv_flwspec, int ind) 406 Status is checked individually for each outgoing (reserved) link. 407 Parameter "fh_session" specifies the flow handle associated with 408 the session, "phy_resv_handle" identifies the physical reservation 409 (e.g., ISPS, etc.), and "phy_resv_flwspec" describes the current, 410 merged FlowSpec of the reservation. The value of "cur_time" 411 describe the current RSVP time, which allows the LPM to timeout 412 old state (state with earlier time to die values). Parameter 413 "ind" is used to have different flavors of status checks: 414 "LPM_STATF_AGE": setting this flag ages (and times 415 out) LPM state associated with the specified fh. Status checks may 416 be periodic or event driven; this flag is set only for periodic 417 status checks. "LPM_STATF_RECALC": Status checks may involve 418 calculations over multiple outgoing interfaces, and thus need only 419 be done once for all interfaces before individual per-interface 420 status is reported. This bit is set on for the first vif checked 421 and is reset for the rest. [Note 5] 423 Status checks with "ind" set to 0 simply report values that were 424 already calculated before and do not age the LPM state. 426 If RSVP prunes branches from the reservation tree, it must notify 427 the LPM by calling: 429 lpm_prune (int fh_num, int *fh_vec, int vif, RSVP_HOP *hop, int 430 mtype) 432 _________________________ 433 [Note 5] This is an optimization. While useless, there should be no harm 434 in recalculating status parameters, for each outgoing interface. 436 (The details of this call is described in Section ). 438 When RSVP deletes an entire flow state, it must notify the LPM: 440 lpm_close (int fh) 442 Upon this notification, the LPM finishes its accounting for this 443 reservation (final debits/credits) and deletes all internal state 444 associated with fh. 446 Initializing the LPM is done once only, in the initialization 447 phase of RSVP, by calling. 449 lpm_config (void) 451 4.5 State Maintenance 453 LPM state must remain consistent with the corresponding RSVP 454 state. State is created when POLICY_DATA objects are passed to the 455 LPM and can be updated or removed through several possible 456 mechanisms that correspond to RSVP's state management mechanisms: 458 Timeout: 460 When new POLICY_DATA objects cease to arrive (as a result of 461 either change of policy or fragmentation loss) the locally 462 stored state begins to age. Each POLICY_ELEMENT/FILTER_SPEC 463 pair is subject to a timer, and when the timer goes off, the 464 state should be deleted. The timer mechanism should be 465 similar to that of RSVP and both should remained synchronized 466 in the following way: each time RSVP hands over a policy 467 object to the LPM (lpm_in()) it provides the LPM with time- 468 to-die value ("current-timer + time-to-live) ". Each time 469 RSVP verifies the status of a reservation (lpm_status()), it 470 provides the current timer value, forcing all pieces of 471 information with an earlier timeout value to be purged. 473 Teardown 475 From a network security standpoint, creating new policy state 476 requires the similar integrity protection as tearing it down. 477 We propose a very simple mechanism for tearing down state: 478 the state created by sending POLICY_ELEMENT Pe_i is torn down 479 by sending -Pe_i (the same object marked as teardown). In 480 this case, the LPM would locate the original state, compare 481 it with the teardown object, if a match is found, tear it 482 down. We define each POLICY_ELEMENT as a pair of two CTypes, 483 thus effectively splitting the CType range of POLICY_ELEMENT 484 objects in two. Given a POLICY_ELEMENT i, Pe_i represents an 485 updated state, while Pe_i+1 represents teardown state of 486 CType i (-Pe_i). 488 Pruning When the shape of the reserved tree changes due to routing 489 updates or RSVP teardown messages, RSVP purges the state of 490 the pruned link, and must also call "lpm_prune()" to purge 491 the corresponding LPM state. 493 Closing: The call "lpm_close(fh)" purges all the state associated 494 with the handle fh. Closing a flow handle is done when RSVP 495 no longer maintains any state associated with that flow (a 496 sender quits, the session is over, etc.). 498 5. LPM internals 500 This section describes the current internal design of the LPM. While 501 this design is not part of the mandatory specification we recommend 502 following it. 504 5.1 LPM configurations 506 LPM configuration can be general, for all handlers, but can also 507 be type/handler specific. (e.g., a specific handler's rewrite 508 conversion table for policy data objects). Configuration may be 509 expressed in a simple configuration file or even through a 510 configuration language. 512 +-----------------------------------------------------------+ 513 | RSVP | 514 | Incoming Resv: Resv-header,LPM-header,P1,P2,P3,P4 | 515 | | | 516 +-----------------------------------------+-----------------+ 517 | LPM: Common Layer \|/ | 518 | lpm_in() +-------- LPM-header,P1,P2,P3,P4 | 519 | / / | \ | 520 +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ 521 | | P1| | P2| | P3| | P4| | 522 | | \|/ | \|/ | \|/ | \|/ | 523 | | | | | | 524 | Handler 0 | Handler 1 | Handler 2 | Handler 4 | Handler 5 | 525 +-----------+-----------+-----------+-----------+-----------+ 526 Figure 3: Disassembly of an incoming Resv message with POLICY_DATA 527 objects 529 5.2 The LPM layered Design 531 The internal format of POLICY_DATA objects is PType specific, 532 allowing up to 65535 independent types. Our design allow each 533 specific PType to be handled by a separate handler, and allow such 534 handlers to be added and configured independently. Clearly, 535 handlers are allowed to handler more than one PTypes. 537 The LPM is divided into two layers: a PType specific layer and a 538 common layer (figure ). The PType specific layer provides a set 539 of locally configured independent handlers, one for each PType 540 supported by the local node. The common layer provides the glue 541 between RSVP and the PType specific layer by multiplexing RSVP's 542 lpm calls into individual, PType specific calls. 544 On input, the common layer disassembles the incoming POLICY_DATA 545 object, dispatches the internal objects to their PType specific 546 handlers, and aggregates the return code status (figure ). On 547 output, it collects the internal objects from all active handlers, 548 and assembles them into a single POLICY_DATA object (figure ). 550 On status queries, the common layer queries all the active 551 handlers, and combines their individual status responses into a 552 single status result. We use the following rule: a reservation is 553 approved by the common layer, if there is at least one handler 554 that approves it, and none other rejects it. PType specific 555 handlers can accept, reject or be neutral in their responses. 556 [Note 6] 557 _________________________ 558 [Note 6] A policy data object that determines cost is a good example for 559 +-----------------------------------------------------------+ 560 | RSVP | 561 | Outgoing Resv: Resv-header,LPM-header,P1,P2,P3,P4 | 562 | /|\ | 563 +-----------------------------------------+-----------------+ 564 | LPM: Common Layer | | 565 | lpm_out() +-------> LPM-header,P1,P2,P3,P4 | 566 | / / /|\ \ | 567 +-----------+-----+-----+-----+-----+-----+-----+-----+-----+ 568 | | P1| | P2| | P3| | P4| | 569 | | | | | | | | | | 570 | | | | | | 571 | Handler 0 | Handler 1 | Handler 2 | Handler 4 | Handler 5 | 572 +-----------+-----------+-----------+-----------+-----------+ 573 Figure 4: Assembly of POLICY_DATA objects for an outgoing Resv message 575 5.3 Interaction between handlers 577 It is reasonable to assume that independent PTypes may require 578 some interaction between their handlers. Consider the case where 579 policy object type-1 is a credential type (defines a user 580 identity) and a type-2 is an accounting type (determines cost), a 581 possible interaction could be to let type-2 determine the cost, 582 and let type-1 perform the actual debiting according to the user 583 identity. Such interaction has two basic requirements: order 584 dependency and export capability. Order dependency is required 585 because type-2 must calculate the cost before type-1. Export 586 capability is needed to allow type-2 to export the calculation 587 results to type-1. Our implementation allows the ordering or 588 handlers to be expressed as part of local LPM configuration. It 589 also provides internal support for function calls between 590 independent handlers (in order to obtain exported state). 592 Consider the case where type-3 and type-4 also perform accounting. 593 The proposed architecture is flexible enough to allow local 594 configuration to select the handler that determines the debited 595 cost: type-2, type-3 or type-4. 597 _________________________ 598 a neutral handler. It provide information about how much the flow costs, 599 but does not perform actual debiting. 601 5.4 Default handling of policy data objects 603 In~[HER96c] we define the default handling of unrecognized POLICY_DATA 604 objects. If an RSVP node is LPM capable, it may be more beneficial 605 for the LPM to take that burden off from RSVP and perform it 606 itself. We propose the use of CType 0 for default handling: In a 607 policy node, only unrecognized objects would be handled by handler 608 PType 0. In a non-policy node, all objects are unrecognized, and 609 therefore should all are handled as PType 0, regardless of their 610 actual PType. PType 0 is regarded as a reserved type. 612 6. Acknowledgment 614 This document incorporates inputs from Deborah Estrin, Scott Shenker 615 and Bob Braden and feedback from RSVP collaborators. 617 References 619 [BAK96] F. Baker. RSVP Cryptographic Authentication "Internet-Draft", 620 draft-ietf-rsvp-md5-02.txt, 1996. 622 [HER96c] RSVP Extensions for Policy Control. "Internet-Draft", draft- 623 ietf-rsvp-policy-ext-00.[ps,txt]. 625 [HER96b] Accounting and Access Control Policies for Resource 626 Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy- 627 arch-00.[ps,txt].