idnits 2.17.1 draft-ietf-rsvp-policy-arch-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. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 6 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 7 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 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 35 has weird spacing: '...ment of suppo...' == Line 133 has weird spacing: '... Figure illus...' == Line 168 has weird spacing: '... figure we se...' -- 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 10179 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) == Unused Reference: 'HER96a' is defined on line 269, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'HER95' -- Possible downref: Normative reference to a draft: ref. 'HER96a' -- Possible downref: Non-RFC (?) normative reference: ref. 'SHE95' Summary: 10 errors (**), 0 flaws (~~), 7 warnings (==), 6 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-arch-00.txt 6 Accounting and Access Control Policies 7 for 8 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 provides insight into some possible generic approaches for 33 policy enforcement in resource reservation protocols. We present 34 sample scenarios for each of these approaches as a way to demonstrate 35 their feasibility, and to motivate the development of supporting 36 architectures. 38 1. Introduction 40 Reservation protocols, by definition, discriminate between users, by 41 providing some users with better service at the expense of others. 42 Therefore, it is reasonable to expect that these protocols be 43 accompanied by mechanisms for controlling and enforcing access and 44 usage policies. In this document, we refer to such policies as 45 "access control". The term "access control" is quite broad; it 46 ranges from simple access approval to sophisticated accounting and 47 debiting mechanisms For scaling reasons, we concentrate on policies 48 that follow the bilateral agreements model. The bilateral model 49 assumes that network clouds (providers) contract with their closest 50 point of contact (neighbor) to establish ground rules and 51 arrangements for access control and accounting. These contracts are 52 mostly local and do not rely on global agreements. The bilateral 53 model has similar scaling properties to multicast and is easier to 54 maintain in distributed environments. 56 Throughout this document we would use the terms "reservation 57 protocols" and RSVP interchangeably. However, the contents of this 58 document should be interpreted as applying to similar resource 59 reservation protocols as well. The current admission process in RSVP 60 uses resource (capacity) based admission control; we expand this 61 model to include policy based admission control as well, in one 62 atomic operation. Policy admission control is enforced locally at 63 border/policy nodes (also see~[HER96a]). Policy nodes are responsible 64 for receiving, processing, and forwarding POLICY_DATA objects. Subject 65 to the applicable bilateral agreements, and local policies, policy 66 nodes may also rewrite and modify the POLICY_DATA objects as the pass 67 through policy nodes. 69 In this document, we outline a few sample scenarios for access 70 control and accounting; we provide these scenarios as motivation and 71 as needed context for the development of policy control architectures 72 for resource reservation protocols. These scenarios are based on two 73 simple assumptions: (1) RSVP provides the needed transport service 74 of carrying access control state (POLICY_DATA objects), hop-by-hop. 75 (2) Access control policies are enforced locally, and can be based, 76 among other factors, on bilateral agreements between neighboring 77 providers, local policies and the contents of POLICY_DATA objects. 79 2. Simple access control 81 To provide simple access control, the local node attempts to match 82 incoming policy objects with one or more of the pre-configured 83 policies or bilateral agreements, in order to accept or reject the 84 reservation. 86 Consider the following network scenario: one receiver from ISI and 87 two from MIT listen to a PARC seminar. For simplicity of the 88 scenario, let us limit ourselves to a receiver based access control 89 scenario. 91 ........... ............. 92 . *ba* . *ba* . . 93 . S1------->A--------------->B---+ *mc* . 94 . . . | . 95 ........... ...C......... 96 PARC / BARRNet 97 *mc* / 98 / 99 ........ .............D..... ........ 100 . . . *ln+ne* / . . . 101 . *is* . *ln* . / . *ne* . *mi* . 102 . +----G------F<--------E-------->J------->K----+ . 103 . | . . *ln* *ne* .| . | . 104 ...H.... ................. | ....L... 105 Los | MCINet | | Near 106 Nettos| *is* *sp* / *mi* | Net 107 .......I.... / .......M... 108 . | . ......N.. .*r2*/ \*r3*. 109 . *r1*| . . *r4*| . . / \ . 110 . R1 . . R4 . . R2 R3 . 111 ............ ......... ........... 112 ISI Sprint MIT 114 LEGEND: 116 *xx* Credential 117 .... Cloud border 118 A..N Nodes 119 Si Sender i 120 Ri Receiver i 122 Figure 1: Simple access control 124 The bilateral agreements between each two neighboring providers 125 (e.g., R1, R2 with ISI, ISI with LosNettos,... BARRNet with PARC) are 126 simple: the first provider obtains a permission to make reservations 127 over the second provider's network. The notation PD(cr,uid) 128 represents a policy data object of type "cr" (credential) verifying 129 that the flow belongs to uid. Credentials can be hierarchical, and 130 may be rewritten on a hop by hop basis through a locally configured 131 conversion table. 133 Figure illustrates a reservation scenario. An typical example of a 134 bilateral agreement could be between MCI and LosNettos: MCI would 135 allow the LosNettos users to use its backbone. A policy data object 136 PD(cr, LosNettos) would be interpreted by MCI as a green light to 137 accept the reservation. In this scenario, reservations from R1, R2, 138 R3 carry policy data objects that propagate hop-by-hop (encapsulated 139 in reservation messages) toward S1. Assuming all nodes are 140 configured consistently, policy objects are rewritten in nodes 141 B,D,G,I,K,M, which are entry points to clouds). 143 The MCI cloud is interesting. E is not a border/policy node, but 144 still, it receives the following policy data objects: F->E: 145 PD(cr,LosNettos) and J->E: PD(cr,NearNet). Assuming E has no 146 authority to merge or rewrite these credentials, it must concatenate 147 the two objects and send PD(cr,LosNettos) + PD(cr,NearNet) to D. Let 148 us further assume that D is configured with the following conversion 149 table: 151 PD(cr, LosNettos) -> PD(cr, MCI) 152 PD(cr, NearNet) -> PD(cr, MCI) 154 Node D first checks if LosNettos and NearNet are authorized to 155 reserve on their corresponding links and responds accordingly. 156 Assuming authorization is cleared, it merges and rewrites these 157 policy objects as PD(cr, MCI) and forwards the reservation to C. 159 To complicate the example, assume the conversion table was: 161 PD(cr, LosNettos) -> PD(cr, MCI1) 162 PD(cr, NearNet) -> PD(cr, MCI2) 164 Then node D would forward PD(cr, MCI1) + PD(cr, MCI2) to C instead. 166 Local policies can also reject reservations: 168 In figure we see that a reservation made by R4 is rejected because 169 it arrives with insufficient credentials: the local policy in node J 170 accepts only traffic marked as PD(cr, NearNet), and R4's reservation 171 arrives with PD(cr, Sprint). 173 3. Advanced reservation and preemption control 175 Advanced reservation can be built on top of simple access control: 176 consider the case where every advanced reservation consists of a set 177 of bilateral agreements between different service providers, 178 reserving network capacity at some future period of time. When 179 advanced reservations are not public (i.e., only authorized users can 180 use them), three classes of reservations exist: (1) walk-ins (where 181 the conference itself does not have advanced reservations, (2) 182 advanced reservation with unauthorized users, and (3) advanced 183 reservation with authorized users. These numbers (1..3) can define a 184 "preemption priority" (i.e., walk-ins are preempted first, 185 unauthorized pre-reserved second, and authorized pre-reserved are 186 never preempted). 188 The advanced reservation scenario is almost identical to the simple 189 access control: let us assume that each bilateral pre-registration is 190 identified by a PRID (Pre-Registration confirmation ID). Policy data 191 objects of type AR (Advanced Reservation) would take the following 192 form: PD(ar, prid ,uid). When an AR object arrives, the local node 193 verifies the existence of pre-reservation prid, and checks that uid 194 is permitted to use it. Finally, the flow is classified to one of the 195 above three preemptive priorities and RSVP is notifies. 197 4. Quota enforcement/accounting/debiting 199 The next step is to allow for more sophisticated access control that 200 is based on usage feedback. Here we add two additional mechanisms 201 which (1) determine how much should be debited for a reservation and 202 (2) what debiting mechanism should be used (if any). The following 203 scenarios assume a pre-existing set of local accounts. These accounts 204 are established by bilateral agreements that pre-purchase network 205 capacity and set applicable debiting rules. The role of accounting 206 mechanism is to verify the availability of funds/quotas in these 207 accounts for maintaining the reservation. We consider several 208 accounting schemes and briefly describe three: simple debiting, 209 limited debiting, Edge Pricing, and MultiCost (MCost). 211 Simple debiting 213 Consider the following example: lets assume that LosNettos and 214 Nearnet each have a debit account (pre-purchased capacity) with MCI 215 for their traffic. When node E receives the following 216 PD(cr,LosNettos) and PD(cr,NearNet) for flow f, it must decide the 217 following: (1) How much should be debited for flow f, and (2) how 218 would that debit be shared between the account of LosNettos and 219 NearNet. These are local configuration issues left for service 220 providers. In this scenario, the local node would attempt to perform 221 the debiting, and would notify RSVP on success or failure. The other 222 aspects of the scenario (Merging policy data objects and forwarding 223 them) is identical to that of simple access control. 225 Limited debiting (willingness to pay) 226 Although we do not have a full understanding of the dynamics of 227 willingness-to-pay and its properties, we can outline the basic 228 scenario, as an extension of the simple debiting model. Willingness 229 to pay is manifested as a limit on the policy object that authorizes 230 the debit. For instance, PD(crwp,ISI,10% of unicast) would represent 231 a policy data object of type crwp (Credential, Willingness to Pay), 232 that authorizes debiting the ISI account up to 10% of the unicast 233 cost. Here, the basic idea is that market forces would be the driving 234 force behind what users specify as their willingness to pay. 236 Edge Pricing 238 Edge Pricing was presented in [SHE95]. This paradigm is based on the 239 assumption that network costs can be estimated and approximated at 240 the edge of the network, based on purely local information. Edge 241 Pricing is an extension of simple debiting: Edge Pricing can 242 determine how much is to be debited, and the set of credentials 243 associated with the reservation determines who (which account) should 244 be debited. 246 MultiCost (MCost) 248 MCost is an accounting scheme (and mechanism) that was introduced in 249 [HER95]. MCost has a unique feature: it takes into account the benefits 250 of sharing a multicast tree and distributes these savings among the 251 members of the multicast group, according to configurable policies, 252 basic fairness, and equality. 254 MCost computes the cost allocated to each user, and that cost can be 255 the basis for debiting. MCost can be combined with simple debiting in 256 a similar manner to Edge Pricing. 258 5. Acknowledgment 260 This document incorporates inputs from Deborah Estrin, Scott Shenker 261 and Bob Braden and feedback from RSVP collaborators. 263 References 265 [HER95] S. Herzog, S. Shenker and D. Estrin, Sharing the Cost of 266 Multicast Trees: An Axiomatic Analysis, "Proceedings of ACM/SIGCOMM 267 '95", Cambridge, MA, Aug. 1995 269 [HER96a] Local Policy Modules (LPM): Policy Enforcement for Resource 270 Reservation Protocols. "Internet-Draft", draft-ietf-rsvp-policy- 271 lpm-00.[ps,txt]. 273 [SHE95] S. Shenker, D. Clark, D. Estrin, and S. Herzog Pricing in 274 Computer Networks: Reshaping the Research Agenda, 275 "Telecommunications Policy", Vol. 20, No. 1, 1996 also published in 276 "Proceedings of the Twenty-Third Annual Telecommunications Policy 277 Research Conference", 1995.