idnits 2.17.1 draft-ietf-rap-cops-rsvp-01.txt: -(179): 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 5 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: ---------------------------------------------------------------------------- -- 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 (November 18, 1998) is 9291 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 320, but not defined == Unused Reference: 'RSVP' is defined on line 550, 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: Non-RFC (?) normative reference: ref. 'RAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jim Boyle 3 Expiration: Apr. 1999 Level3 4 File: draft-ietf-rap-cops-rsvp-01.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: November 18, 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 at the expiration date listed above. 41 Distribution of this draft is unlimited. 43 Abstract 45 This document describes usage directives for supporting COPS policy 46 services in RSVP environments. 48 Table of Contents 50 Abstract.............................................................1 51 Table of Contents....................................................2 52 1.Introduction.......................................................3 53 2.RSVP values for COPS objects.......................................3 54 2.1.Context Object (Context).........................................3 55 2.2.Client Specific Information (ClientSI)...........................4 56 2.3.Decision Object (Decision).......................................4 57 3.Operation of COPS for Policy Control Over RSVP.....................5 58 3.1.RSVP flows.......................................................5 59 3.2.Expected Associations for RSVP Requests..........................5 60 3.3.RSVP's Capacity Admission Control: Commit and Delete.............6 61 3.4.Policy Control Over PathTear and ResvTear........................6 62 3.5.PEP Caching COPS Decisions.......................................6 63 3.6.Using Multiple Context Flags in a single query...................7 64 3.7.Trusted zones and secure policy tunneling........................7 65 4.Illustrative Examples, Using COPS for RSVP.........................8 66 4.1.Unicast Flow Example.............................................8 67 4.2.Shared Multicast Flows...........................................9 68 5.References........................................................13 69 6.Author Information and Acknowledgments............................13 70 1. Introduction 72 The Common Open Policy Service (COPS) protocol is a query response 73 protocol used to exchange policy information between a network 74 policy server and a set of clients [COPS]. COPS is being developed 75 within the RSVP Admission Policy Working Group (RAP WG) of the IETF, 76 primarily for use as a mechanism for providing policy-based 77 admission control over requests for network resources [RAP]. 79 This document is based on and assumes prior knowledge of RAP 80 framework [RAP] and the basic COPS [COPS] protocol. It provides 81 specific usage directives for using COPS in outsourcing policy 82 control decisions by RSVP clients (PEPs) to policy servers (PDPs). 84 Given the COPS protocol design, client specific functionality is 85 mainly limited to interoperability usage guidelines as well as 86 client specific examples. 88 2. RSVP values for COPS objects 90 The format and usage of several COPS objects is affected when used 91 for client type RSVP. This section describes these objects and the 92 usage. 94 2.1. Context Object (Context) 96 The semantics of the Context object for RSVP is as follows: 98 R-Type (Request Type Flag) 100 0x01 = Incoming-Message request 101 The arrival of an incoming RSVP message 103 Allows processing of incoming policy information as well as 104 the decision whether to accept an incoming message. If It is 105 rejected, the message is treated as if it never Arrived. 107 0x02 = Resource-Allocation request 108 Applies only for Resv messages. 110 The decision whether to admit a reservation and commit local 111 resources to it is performed for the merge of all 112 reservations that arrived on a particular interface 113 (potentially from several RSVP Next-Hops). 115 0x04 = Outgoing-Message request 116 The forwarding of an outgoing RSVP message. 118 The Decision whether to allow the forwarding of an outgoing 119 RSVP message as well as providing the relevant outgoing 120 policy information. 122 M-Type (Message Type) 124 The M-Type field in the Context Object may have one of the 125 Following values that correspond to supported RSVP messages 126 In COPS: 128 1 = Path 129 2 = Resv 130 3 = PathErr 131 4 = ResvErr 133 Note: The PathTear, ResvTear, and the Resv Confirm message types are 134 not supported. 136 2.2. Client Specific Information (ClientSI) 138 All objects that were received within an RSVP message that are 139 associated with the RSVP flow are encapsulated inside the Client 140 Specific Information Object without alteration. (See Section 3.1. on 141 multiple flows packed in a single RSVP message). These RSVP objects 142 are simply contained within a single Signaled Client Specific 143 Information Object (RSVP ClientSI) exchanged between the PEP and 144 remote PDP. 146 2.3. Decision Object (Decision) 148 COPS allows PDP to control RSVP�s response to messages. Beyond 149 traditional accept/deny, PDPs may use the Trigger Error flag to 150 allow a request yet trigger a warning at the same time. To allow 151 resource allocation yet deny forwarding of a message, etc. 153 Decision Flags 155 The following decision flags apply to RSVP: 157 0x01 = Signaled (RSVP) accept (deny if set) 159 This flag should be interpreted with the decision context 160 flag to figure out what it applies to. 162 0x08 = Trigger Error (PathErr for Path query, or ResvErr for Resv) 164 Client Specific Policy Information 166 This object may include one or more policy elements (as specified 167 for the RSVP Policy Data object [RSVP-EXT] which are assumed to be 168 well understood by the client�s LDP. The PEP should consider these 169 as if they arrived in the message Policy Data object. 171 For example: Given Policy Elements that specify a flow�s preemption 172 priority, these elements may be included in an incoming Resv message 173 or may be also be provided by the PDP responding to a query. 175 Replacement Data 177 The Replacement object may contain multiple RSVP objects to be 178 replaced (from the original RSVP request). Typical replacement is 179 performed on the �Forward Outgoing� request (for instance, replacing 180 outgoing Policy Data), but is not limited, and can also be performed 181 on other contexts (such as �Allocate Resources�). Other examples, 182 may require replacement of the RSVP FlowSpec object for controlling 183 resources across a trusted zone (with PIN nodes). 184 Currently, RSVP clients are only required to allow replacement of 185 two objects: Policy Data and FlowSpec. 187 Replacement is performed in the following manner: 188 If Replacement Data decision doesn't appear in a decision message, 189 all signaled objects are passed as if the PDP was not there. When an 190 object of a certain C-Num appears it replaces ALL the instances of 191 C-Num objects in the RSVP message. If it appears empty (with a 192 length of 4) it simply removes all instances of C-Num objects 193 without adding a thing. 195 3. Operation of COPS for Policy Control Over RSVP 197 3.1. RSVP flows 199 Policy Control is performed per RSVP flow. An RSVP flow corresponds 200 to an atomic unit of reservation as identified by RSVP (TC 201 reservation). It should be noted that RSVP allows multiple flows to 202 be packed (which is different from merged) into a single FF Resv 203 message. To support such messages a separate COPS request must be 204 issued for each of the packed flows as if they were individual RSVP 205 messages. 207 3.2. Expected Associations for RSVP Requests 209 RSVP signaling requires the participation of both senders and 210 receivers. RSVP processing rules define what is the subset of the 211 Path state that matches each Resv state. In the common unicast case, 212 the RSVP session includes one Path state and one Resv state. In 213 multicast cases the correspondence might be many to many. Since the 214 decision to admit a reservation for a session may depend on 215 information carried both in Path and Resv messages, we term the Path 216 States that match with a single Resv state as its associated states. 217 It is assumed that the PDP is capable of determining these 218 associations based on the RSVP message processing rules given the 219 RSVP objects expressed in the COPS Client Specific Information 220 Object. 222 For example, the PDP should be able to recognize activation and 223 deactivation of RSVP blockade state following discrete events like 224 the arrival of a ResvErr message (activate the blockade state) as 225 well as the change in the outgoing Resv message. 227 3.3. RSVP's Capacity Admission Control: Commit and Delete 229 In RSVP, the admission of a new reservation requires both an 230 administrative approval (policy control) and capacity admission 231 control. Once local admission control accepts the reservation, the 232 PEP notifies the remote PDP by sending a report message specifying 233 the Commit type. The Commit type report message is to be used to 234 signify when billing should effectively begin, and performing 235 heavier operations (e.g., debiting a credit card) is permissible. 237 If instead a reservation approved by the PDP fails admission due to 238 lack of resources, the PEP must issue a no-commit report and fold 239 back and send an updated request to its previous state (previously 240 installed reservation). If no state was previously installed, the 241 PEP should issue a delete. 243 3.4. Policy Control Over PathTear and ResvTear 245 PathTear and ResvTear messages are not controlled by this policy 246 architecture. This relies on two assumptions: First, that MD-5 247 authentication verifies that the Tear is received from the same node 248 that sent the initial reservation, and second, that it is 249 functionally equivalent to that node holding-off refreshes for this 250 reservation. When a ResvTear or PathTear is received at the PEP, all 251 affected states installed on the PDP should either be deleted or 252 updated by the PEP. 254 3.5. PEP Caching COPS Decisions 256 Because COPS is a stateful protocol, refreshes for RSVP Path and 257 Resv messages need not be constantly sent to the remote PDP. Once a 258 decision has been returned for a request, the PEP can cache that 259 decision and apply it to future refreshes. The PEP is only 260 responsible for updating a request state if there is a change 261 detected in the corresponding Resv or Path message. 263 If the connection is lost between the PEP and the PDP, the cached 264 RSVP state may be retained for the RSVP timeout period. If no 265 connection can be reestablished with the PDP or a backup PDP after 266 the timeout period, the RSVP PEP is expected to default back to 267 using its LDP results. Additionally, the LDP is to be used for the 268 admission control of any new RSVP messages that may have arrived 269 while connectivity was lost. 271 Once a connection is reestablished to a new (or the original) PDP 272 the PDP may issue a SSQ request. In this case, the PEP must reissue 273 requests that correspond to the current RSVP state (as if all the 274 state has been updated recently). It should also include as LDP the 275 current (cached) decision regarding each such state. 277 3.6. Using Multiple Context Flags in a single query 279 RSVP is a store-and-forward control protocol where messages are 280 processed in three distinctive steps (input, resource allocation, 281 and output). Each step requires a separate policy decision as 282 indicated by context flags (see Section 2.1). In many cases, setting 283 multiple context flags for bundling two or three operations together 284 in one request may significantly optimize protocol operations. 286 The following rules apply for setting multiple Context flags: 288 a. Multiple context flags can be set only in two generic cases which 289 are guaranteed not to cause ambiguity and represent substantial 290 portion of expected COPS transactions. 292 Unicast FF: 294 [Incoming + Allocation + Outgoing] 296 Multicast with only one Resv message received on the interface 298 [Incoming + Allocation] 300 b. Context events are ordered by time since every message processing 301 must first be processed as Incoming, then as Resource allocation 302 and only then as Outgoing. When multiple context flags are set, 303 all ClientSI objects included in the request are assumed to be 304 processed to the latest flag. This rule applies both to request 305 (REQ) context as well as to decision (DEC) context. 307 For example: when combining Incoming + Allocation for an incoming 308 Resv message, the Flowspec included in the ClientSI would be the 309 one corresponding to the Resource-Allocation context (TC). 311 c. Each decision is bound to a context object, which determines 312 which portion of the request context it applies to. When 313 different decisions apply to different sub-groups of context the 314 PDP should send each group of decision objects encapsulated or 315 separated by the context flags object with the context flags 316 applicable to these objects set. (See the examples in Section 4). 318 3.7. Trusted zones and secure policy tunneling 319 Security for RSVP messages is provided by inter-router MD5 320 authentication [MD5], assuming a chain-of-trust model. 321 A possible deployment scenario calls for PEPs to be deployed at the 322 network edge (boundary nodes) while PINs are deployed in the core of 323 the network (backbone). In this case, MD5 trust (authentication) must 324 be established between boundary (non-neighboring) PEPs, which is 325 achieved through internal signing of the Policy Data object. [RSVP- 326 EXT]. 328 4. Illustrative Examples, Using COPS for RSVP 330 This section details both typical unicast and multicast scenarios. 332 4.1. Unicast Flow Example 334 This section details the steps in using COPS for controlling a 335 Unicast RSVP flow. It details the contents of the COPS messages 336 with respect to the following figure. 338 PEP (router) 339 +-----------------+ 340 | | 341 R1 ------------+if1 if2+------------ S1 342 | | 343 +-----------------+ 345 Figure 1: Unicast Example: a single PEP view 347 The PEP router has two interfaces (if1, if2). Sender S1 sends to 348 receiver R1. 350 A Path message arrives from S1: 352 PEP --> PDP REQ := 353 354 356 PDP --> PEP DEC := 357 359 A Resv message arrives from R1: 361 PEP --> PDP REQ := 362 363 364 366 PDP --> PEP DEC := 367 368 369 370 371 372 373 374 376 PEP --> PDP RPT := 377 379 Notice that the Decision was split because of the need to specify 380 different decision objects for different context flags. 382 Time Passes, the PDP changes its decision: 384 PDP --> PEP DEC := 385 386 387 389 Because the priority is too low, the PEP preempts the flow: 391 PEP --> PDP DRQ := 392 394 Time Passes, the sender S1 ceases to send Path messages: 396 PEP --> PDP DRQ := 397 399 4.2. Shared Multicast Flows 401 This section details the steps in using COPS for controlling a 402 multicast RSVP flow. It details the contents of the COPS messages 403 with respect to the following figure. 405 PEP (router) 406 +-----------------+ 407 | | 408 R1-------------+ if1 if3 +--------- S1 409 | | 410 R2----+ | | 411 | | | 412 +--------+ if2 if4 +--------- S2 413 | | | 414 R3----+ +-----------------+ 415 Figure 2: Multicast example: a single PEP view 417 Figure 2 shows an RSVP PEP (router) which has two senders (S1, S2) 418 and three receivers (R1, R2, R3) for the same multicast session. 419 Interface if2 is connected to a shared media. 420 In this example, we assume that the multicast membership is already 421 in place, no previous RSVP messages were received, and the first to 422 arrive is a Path message on interface if3 from sender S1: 424 PEP --> PDP REQ := 425 426 428 PDP --> PEP DEC := 429 431 The PEP consults its forwarding table, and finds two outgoing 432 interface for the path (if1, if2). The exchange below is for 433 interface if1, another exchange would likewise be completed for if2 434 using the new handle B2. 436 PEP --> PDP REQ := 437 438 440 PDP --> PEP DEC := 441 442 443 445 Here, the PDP decided to allow the forwarding of the Path message 446 and provided the appropriate policy-data object for interface if1. 448 Next, a WF Resv message from receiver R2 arrives on interface if2. 450 PEP --> PDP REQ := 451 452 455 PDP --> PEP DEC := 456 457 458 459 460 462 PEP --> PDP RPT := 464 Here, the PDP approves the reservation and assigned it preemption 465 priority of 5. The PEP responded with a commit report. 467 The PEP needs to forward the Resv message upstream toward S1: 469 PEP --> PDP REQ := 470 471 473 PDP --> PEP DEC := 474 475 476 478 Note: The Context object is part of this DEC message even though it 479 may look redundant since the REQ specified only one context flag. 481 Next, a new WF Resv message from receiver R3 arrives on interface 482 if2 with a higher RSpec (Rspec2). Given two reservations arrived on 483 if2, it cannot perform a request with multiple context flags, and 484 must issue them separately. 486 The PEP re-issues an updated handle C REQ with a new context object 487 , and receives a DEC for handle C. 489 PEP --> PDP REQ := 490 491 494 PDP --> PEP DEC := 495 497 PEP --> PDP REQ := 498 499 502 PDP --> PEP DEC := 503 504 505 507 PEP --> PDP RPT := 509 Given the change in incoming reservations, the PEP needs to forward 510 a new outgoing Resv message upstream toward S1. This repeats exactly 511 the previous interaction of Handle E, except that the ClientSI 512 objects now reflect the merging of two reservations. 514 If an ResvErr arrives from S1, the PEP maps it to R3 only (because 515 it has a higher flowspec: Rspec2) the following takes place: 517 PEP --> PDP REQ := 518 519 521 PDP --> PEP DEC := 522 524 PEP --> PDP REQ := 525 526 528 PDP --> PEP DEC := 529 530 531 533 When S2 joins the session by sending a Path message, incoming and 534 outgoing Path requests are issued for the new Path. A new outgoing 535 Resv request would be sent to S2. 537 5. References 539 [RSVP-EXT] Herzog, S. "RSVP Extensions for Policy Control", 540 Internet-Draft, draft-ietf-rap-rsvp-ext-00.txt, Apr. 1998. 542 [RAP] Yavatkar, R., et al., "A Framework for Policy Based Admission 543 Control",IETF , November, 544 1997. 546 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 547 Sastry, A., "The COPS (Common Open Policy Service) Protocol", 548 IETF , Aug. 1998. 550 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, S., 551 "Resource Reservation Protocol (RSVP) Version 1 Functional 552 Specification", IETF RFC 2205, Proposed Standard, September 553 1997. 555 6. Author Information and Acknowledgments 557 Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar, 558 Russell Fenger, Fred Baker, Laura Cunningham, Roch Guerin, Ping Pan, 559 and Dimitrios Pendarakis for their valuable contributions. 561 Jim Boyle Ron Cohen 562 Level 3 Communications CISCO Systems 563 1450 Infinite Drive13 Hasadna St. 564 Louisville, CO 80027 Ra'anana 43650 Israel 565 303.926.3100 972.9.7462020 566 email: jboyle@l3.net ronc@cisco.com 568 David Durham Raju Rajan 569 Intel IBM T.J. Watson Research Cntr 570 2111 NE 25th Avenue P.O. Box 704 571 Hillsboro, OR 97124 Yorktown Heights, NY 10598 572 503.264.6232 914.784.7260 573 David_Durham@mail.intel.com raju@watson.ibm.com 575 Shai Herzog Arun Sastry 576 IPHighway Cisco Systems 577 400 Kelby St., Suite 1500 506210 W Tasman Drive 578 Fort-Lee, NJ 07024 San Jose, CA 95134 579 201.585.0800 408.526.7685 580 herzog@iphighway.com asastry@cisco.com