idnits 2.17.1 draft-ietf-rap-cops-rsvp-00.txt: -(141): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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-26) 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 6 months document validity. ** 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. == There are 3 instances of lines with non-ascii characters in the document. == 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 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 373 has weird spacing: '...utgoing inter...' -- 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 (August 19, 1998) is 9382 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: 'MD5' is mentioned on line 262, but not defined == Unused Reference: 'RSVP' is defined on line 483, but no explicit reference was found in the text == Outdated reference: A later version (-06) exists of draft-ietf-rap-rsvp-ext-00 -- Possible downref: Normative reference to a draft: ref. 'UserID' -- Possible downref: Non-RFC (?) normative reference: ref. 'RAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jim Boyle 3 Expiration: Feb 1999 L3 4 File: draft-ietf-rap-cops-rsvp-00.txt Ron Cohen 5 Cisco 6 David Durham 7 Intel 8 Shai Herzog 9 IPHighway 10 Raju Rajan 11 IBM 12 Arun Sastry 13 Cisco 15 COPS usage for RSVP 17 Last Updated: August 19, 1998 19 Status of this Memo 21 This document is an Internet Draft. Internet Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its Areas, 23 and its Working Groups. Note that other groups may also distribute 24 working documents as Internet Drafts. 26 Internet Drafts are draft documents valid for a maximum of six 27 months. Internet Drafts may be updated, replaced, or obsoleted by 28 other documents at any time. It is not appropriate to use Internet 29 Drafts as reference material or to cite them other than as a 30 "working draft" or "work in progress". 32 To learn the current status of any Internet-Draft, please check the 33 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 34 Directories on ftp.ietf.org, nic.nordu.net, ftp.isi.edu, or 35 munnari.oz.au. 37 A revised version of this draft document will be submitted to the 38 RFC editor as a Proposed Standard for the Internet Community. 39 Discussion and suggestions for improvement are requested. This 40 document will expire before June 1998. Distribution of this draft is 41 unlimited. 43 Abstract 45 This document describes usage directives for supporting COPS policy 46 services in RSVP environments. 48 1. Introduction 50 The Common Open Policy Service (COPS) protocol is a query response 51 protocol used to exchange policy information between a network 52 policy server and a set of clients [COPS]. COPS is being developed 53 within the RSVP Admission Policy Working Group (RAP WG) of the IETF, 54 primarily for use as a mechanism for providing policy-based 55 admission control over requests for network resources [RAP]. 57 This document is based on and assumes prior knowledge of RAP 58 framework [RAP] and the basic COPS [COPS] protocol. It provides 59 specific usage directives for using COPS in outsourcing policy 60 control decisions by RSVP clients (PEPs) to policy servers (PDPs). 62 Given the COPS protocol design, client specific functionality is 63 mainly limited to interoperability usage guidelines as well as 64 client specific examples. 66 2. RSVP values for COPS objects 68 The format and usage of several COPS objects is affected when used 69 for client type RSVP. This section describes these objects and the 70 usage. 72 2.1. Context Object (Context) 74 The semantics of the Context object for RSVP is as follows: 76 R-Type (Request Type Flag) 78 0x01 = Incoming-Message request 79 The arrival of an incoming RSVP message 81 Allows processing of incoming policy information as well as 82 the decision whether to accept an incoming message. If It is 83 rejected, the message is treated as if it never Arrived. 85 0x02 = Resource-Allocation request 86 Applies only for Resv messages. 88 The decision whether to admit a reservation and commit local 89 resources to it is performed for the merge of all 90 reservations that arrived on a particular interface 91 (potentially from several Previous Hops). 93 0x04 = Outgoing-Message request 94 The forwarding of an outgoing RSVP message. 96 The Decision whether to allow the forwarding of an outgoing 97 RSVP message as well as providing the relevant outgoing 98 policy information. 100 M-Type (Message Type) 102 The M-Type field in the Context Object may have one of the 103 Following values that correspond to supported RSVP messages 104 In COPS: 106 1 = Path 107 2 = Resv 108 3 = PathErr 109 4 = ResvErr 111 Note: The PathTear, ResvTear, and the Resv Confirm message types are 112 not supported. 114 2.2. Client Specific Information (ClientSI) 116 All objects contained within RSVP messaging are encapsulated inside 117 the Client Specific Information Object without alteration. The 118 multiple RSVP objects are simply contained within a single Signalled 119 Client Specific Information Object (Signaled ClientSI) exchanged 120 between the PEP and remote PDP. 122 To prevent ambiguity, the number of object instances appearing in 123 the ClientSI are restricted by the rules native to RSVP. For 124 example, it is forbidden to include two different FlowSpec objects 125 in one ClientSI encapsulation, while perfectly legal to include 126 multiple FilterSpecs for a WF or SE reservation. 128 For applicability example, see Section 3.6. 130 2.3. Decision Object (Decision) 132 COPS allows PDP to control RSVP�s response to messages. Beyond 133 traditional accept/deny, PDPs may use the Trigger Error flag to 134 allow a request yet trigger a warning at the same time. To allow 135 resource allocation yet deny forwarding of a message, etc. 137 Replacement Data 139 The Replacement object may contain multiple RSVP objects to be 140 replaced (from the original RSVP request). Typical replacement is 141 performed on the �Forward Outgoing� request (for instance, replacing 142 outgoing Policy Data), but is not limited to this context flag. 143 Another example, for controlling resources across a trusted zone 144 (with PIN nodes) the RSVP FlowSpec object may need to be replaced. 146 Currently, RSVP clients are only required to allow replacement of 147 two objects: Policy Data and FlowSpec. 149 Client Specific decision Object 151 In support of the verification integrity of incoming RSVP messages, 152 the COPS protocol may optionally return a security key in the Client 153 Specific Decision Data object (C-Type = 4) useful for future 154 integrity checks by the PEP. Refer to the document on User Identity 155 Representation for RSVP [UserID] for details on the format and 156 application of this security key when supported by the PEP. 158 3. Operation of COPS for Policy Control Over RSVP 160 3.1. RSVP flows 162 Policy Control is performed per RSVP flow. An RSVP flow corresponds 163 to an atomic unit of reservation as identified by RSVP (TC 164 reservation). It should be noted that RSVP allows multiple flows to 165 be packed (which is different from merged) into a single FF Resv 166 message. To support such messages a separate COPS request must be 167 issued for each of the packed flows as if they were individual RSVP 168 messages. 170 3.2. Expected Associations for RSVP Requests 172 RSVP signaling requires the participation of both senders and 173 receivers. RSVP processing rules define what is the subset of the 174 Path state that matches each Resv state. In the common unicast case, 175 the RSVP session includes one Path state and one Resv state. In 176 multicast cases the correspondence might be many to many. Since the 177 decision to admit a reservation for a session may depend on 178 information carried both in Path and Resv messages, we term the Path 179 States that match with a single Resv state as its associated states. 180 It is assumed that the PDP is capable of determining these 181 associations based on the RSVP message processing rules given the 182 RSVP objects expressed in the COPS Client Specific Information 183 Object. 185 3.3. RSVP's Capacity Admission Control: Commit and Delete 187 In RSVP, the admission of a new reservation requires both an 188 administrative approval (policy control) and capacity admission 189 control. Once local admission control accepts the reservation, the 190 PEP notifies the remote PDP by sending a report message specifying 191 the Commit type. The Commit type report message is to be used to 192 signify when billing should effectively begin, and performing 193 heavier operations (e.g., debiting a credit card) is permissible. 195 If instead a reservation approved by the PDP fails admission due to 196 lack of resources, the PEP must resort to its previous state 197 (previously installed reservation). If none was previously 198 installed, the PEP should issue a delete. Otherwise, it should issue 199 a report no-commit and then send a request update for the previously 200 allocated reservation state. 202 3.4. Policy Control Over Path and Resv Tear 204 Path and Resv Tear messages are not controlled by this policy 205 architecture. This relies on two assumptions: First, that MD-5 206 authentication verifies that the Tear is received from the same node 207 that sent the initial reservation, and second, that it is 208 functionally equivalent to that node holding-off refreshes for this 209 reservation. When a Resv or Path Tear is received at the PEP, all 210 affected states installed on the PDP should either be deleted or 211 updated by the PEP. 213 3.5. PEP Caching COPS Decisions 215 Because COPS is a stateful protocol, refreshes for RSVP Path and 216 Resv messages need not be constantly sent to the remote PDP. Once a 217 decision has been returned for a request, the PEP can cache that 218 decision and apply it to future refreshes. The PEP is only 219 responsible for updating a request state if there is a change 220 detected in the corresponding Resv or Path message. 222 If the connection is lost between the PEP and the PDP, the cached 223 RSVP state may be retained for the RSVP timeout interval. If no 224 connection can be reestablished with the PDP or a backup PDP, the 225 RSVP PEP is expected to default back to using its LDP. Additionally, 226 the LDP is to be used for the admission control of any new RSVP 227 messages that may have arrived while connectivity was lost. If any 228 such messages were admitted by the LDP, the PEP is expected to issue 229 requests to the PDP for them once a connection is reestablished and 230 a COPS session for RSVP is opened. 232 3.6. Using Multiple Context Flags in a single query 234 RSVP is a store-and-forward control protocol where messages are 235 processed in three distinctive steps (input, output and resource 236 allocation). Each step requires a separate policy decision as 237 indicated by context flags (see Section 2.1). In many cases, setting 238 multiple context flags can serve as a mean for bundling two of three 239 operations together in one request (for instance, validating both an 240 incoming message as well as allocating resources for it). 242 The following rules apply when multiple Context flags are set: 244 a. Multiple context flags can be set simultaneously when their merge 245 doesn�t create ambiguity in ClientSI interpretation. Two context 246 flags become mutually exclusive for a specific REQ or DEC message 247 when identical ClientSI objects carry different values for each 248 of them. 250 b. The DEC message contains a context object that correspond to all 251 or a subset of the context flags set in original REQ. A DEC is 252 assumed to be complete (as far as reuse of handles) only when all 253 flags have been replied to (set in the following DEC message). 255 c. The PEP may act based on partial (context subset) decision and is 256 not required to wait for the others, although it may. Consistency 257 is an issue for the PDP to worry about. 259 3.7. Trusted zones and secure policy tunneling 261 Security for RSVP messages is provided by inter-router MD5 262 authentication [MD5], assuming a chain-of-trust model. 263 A possible deployment scenario calls for PEPs to be deployed at the 264 network edge (boundary nodes) while PINs are deployed in the core of 265 the network (backbone). In this case, MD5 trust (authentication) must 266 be established between boundary (non-neighboring) PEPs, which is 267 achieved through internal signing of the Policy Data object. [RSVP- 268 EXT]. 270 4. Illustrative Examples, Using COPS for RSVP 272 This section details both typical unicast and multicast scenarios. 274 4.1. Unicast Flow Example 276 This section details the steps in using COPS for controlling a 277 Unicast RSVP flow. It details the contents of the COPS messages 278 with respect to the following figure. 280 PEP (router) 281 +-----------------+ 282 | | 283 R1 ------------+if1 if3+------------ S1 284 | if2 | 285 +--------+--------+ 286 | 287 | 288 PDP (server) 290 figure 1: Unicast Example: a single router view 292 The PEP router has three interfaces (1,2,3). Sender S1 sends to 293 receiver R1. 295 A Path message arrives from S1: 297 PEP --> PDP REQ := 298 299 301 PDP --> PEP DEC := > 302 304 A Resv message arrives from R1: 306 PEP --> PDP REQ := 307 308 310 PDP --> PEP DEC := 311 312 315 PEP --> PDP RPT := 316 318 Time Passes, the PDP changes its decision: 320 PDP --> PEP DEC := 321 322 325 Because the priority is too low, the PEP preempts the flow: 327 PEP --> PDP DRQ := 328 330 Time Passes, the sender S1 ceases to send Path messages: 332 PEP --> PDP DRQ := 333 335 4.2. Shared Multicast Flows 337 This section details the steps in using COPS for controlling a 338 multicast RSVP flow. It details the contents of the COPS messages 339 with respect to the following figure. 341 ----------------- 342 r1 | | 343 H1-------------|i1 | r4 344 | o1 |---------------- S1 345 r2 | Router | 346 H2 ------------|i2 | 347 | | o2 |---------------- S2 348 | r3 | | 349 | ----------------- 350 H3 352 figure 1: 2 senders and 3 receivers 354 Figure 1 shows an RSVP router which has two senders and three 355 receivers for the same multicast session. Interface i2 is connected 356 to a shared media. H1, H2, and H3 are all receivers that send the 357 corresponding reservations r1, r2, and r3 for the flows for senders 358 S1 & S2. 360 First detailed is the request message content for a Path sent by 361 sender S1, assuming that both receivers have already joined the 362 multicast session, but haven't sent a Resv message as yet. Assume 363 sender S2 has not yet sent a path message. The Path message arrives 364 on interface o1: 366 PEP -----> PDP REQ := 367 369 PDP -----> PEP DEC := 370 372 Here the PDP decides to allow the Path message. Next, the Router 373 consults its forwarding table, and finds two outgoing interfaces, 374 i1 and i2, for the path. The exchange below is for interface i1, 375 another exchange would likewise be completed for i2 using the new 376 handle B2. 378 PEP -----> PDP REQ := 379 381 PDP -----> PEP DEC := 382 383 386 Here, the PDP decided to allow the forwarding of the Path message 387 via interface i1, and determined the appropriate policy objects for 388 the message going out on this interface. 390 Next, the receiver r2 sends a Resv message of WF style. The Resv 391 arrives on interface i2. Here the PEP queries the PDP which decides 392 to accept this reservation with priority 5 as shown below. 394 PEP -----> PDP REQ := 395 397 PDP -----> PEP DEC := 398 400 This assumes the PEP is not itself capable of merging priority 401 information, and, thus, must make another query for the incoming 402 interface merge. 404 PEP -----> PDP REQ := 405 407 PDP -----> PEP DEC := 408 410 After PEP successfully admitted the reservation it sends a report 411 message that signals to the PDP that it can start an accounting log 412 for this reservation. 414 PEP -----> PDP RPT := 415 417 The reservation r2 needs to be sent upstream towards sender S1 out 418 interface o1. An outgoing Resv request is made which carries the 419 associated handle of the Path message for which this Resv is being 420 forwarded. 422 PEP -----> PDP REQ := 423 425 PDP -----> PEP DEC := 426 429 Next, receiver H3 sends the Resv message r3. The PEP sends an 430 incoming request for handle F and the PDP decides to accept the Resv 431 (as before). The new reservation also requires the PEP to update the 432 merged request (handle D) due to the modified flowspec. The PDP now 433 gives this request priority 7. If accepted by local admission 434 control, a report is again sent. 436 PEP -----> PDP REQ := 437 441 PDP -----> PEP DEC := 442 443 PEP -----> PDP RPT := 444 446 Now the outgoing request for handle E is reissued for the merged (R2 447 & R3) outgoing Resv to be sent towards sender S1 due to a modified 448 flowspec. 450 PEP -----> PDP REQ := 451 454 PDP -----> PEP DEC := 455 458 When S2 joins the session by sending a Path message, incoming and 459 outgoing Path requests are issued for the new Path. The two incoming 460 Resv requests may then be reissued for handle C and handle E if 461 there is a change in their shared sender filter list (e.g. if this 462 was a SE filter example) specifying the new sender. A new outgoing 463 Resv request would then be issued for the Resv to be sent to s2 out 464 interface o2. 466 5. References 468 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", 469 Internet-Draft, draft-ietf-rap-rsvp-ext-00.txt, Apr. 1998. 471 [UserID] Yadav, S., Pabbati, R., Ford, P., Herzog, S., "User 472 Identity Representation for RSVP", Internet-Draft, draft- 473 ietf-rap-user-identity-00.txt, March 1998. 475 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 476 Control",IETF , November, 477 1997. 479 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 480 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 481 IETF , Aug. 1998. 483 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., 484 "Resource Reservation Protocol (RSVP) Version 1 Functional 485 Specification", IETF RFC 2205, Proposed Standard, September 1997. 487 6. Author Information and Acknowledgments 488 Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar, 489 Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, 490 and Dimitrios Pendarakis for their valuable contributions. 492 Jim Boyle Ron Cohen 493 Level 3 Communications CISCO Systems 494 1450 Infinite Drive13 Hasadna St. 495 Louisville, CO 80027 Ra'anana 43650 Israel 496 303.926.3100 972.9.7462020 497 email: jboyle@l3.net ronc@cisco.com 499 David Durham Raju Rajan 500 Intel IBM T.J. Watson Research Cntr 501 2111 NE 25th Avenue P.O. Box 704 502 Hillsboro, OR 97124 Yorktown Heights, NY 10598 503 503.264.6232 914.784.7260 504 David_Durham@mail.intel.com raju@watson.ibm.com 506 Shai Herzog Arun Sastry 507 IPHighway Cisco Systems 508 2055 Gateway Pl., Suite 400 506210 W Tasman Drive 509 San Jose, CA 95110 San Jose, CA 95134 510 408.390.3045 408.526.7685 511 herzog@iphighway.com asastry@cisco.com 513 Table of Contents 515 Abstract..............................................................1 516 1. Introduction.....................................................2 517 2. RSVP values for COPS objects.....................................2 518 2.1. Context Object (Context)........................................2 519 2.2. Client Specific Information (ClientSI)..........................3 520 2.3. Decision Object (Decision)......................................3 521 3. Operation of COPS for Policy Control Over RSVP...................4 522 3.1. RSVP flows......................................................4 523 3.2. Expected Associations for RSVP Requests.........................4 524 3.3. RSVP's Capacity Admission Control: Commit and Delete............4 525 3.4. Policy Control Over Path and Resv Tear..........................5 526 3.5. PEP Caching COPS Decisions......................................5 527 3.6. Using Multiple Context Flags in a single query..................5 528 3.7. Trusted zones and secure policy tunneling.......................6 529 4. Illustrative Examples, Using COPS for RSVP.......................6 530 4.1. Unicast Flow Example............................................6 531 4.2. Shared Multicast Flows..........................................7 532 5. References......................................................10 533 6. Author Information and Acknowledgments..........................10