idnits 2.17.1 draft-ietf-rap-cops-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-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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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 1224 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 (January 20, 1998) is 9593 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: 'SRVLOC' is mentioned on line 135, but not defined == Unused Reference: 'INSCH' is defined on line 857, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-rap-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. 'WRK') ** Obsolete normative reference: RFC 1825 (ref. 'IPSEC') (Obsoleted by RFC 2401) == Outdated reference: A later version (-08) exists of draft-ietf-rsvp-md5-05 Summary: 12 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jim Boyle 2 Expiration: July 1998 MCI 3 File: draft-ietf-rap-cops-00.txt Ron Cohen 4 Class Data Systems 5 David Durham 6 Intel 7 Shai Herzog 8 IPHighway 9 Raju Rajan 10 IBM 11 Arun Sastry 12 Cisco 14 The COPS (Common Open Policy Service) Protocol 16 Last Updated: January 20, 1998 18 Status of this Memo 20 This document is an Internet Draft. Internet Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its Areas, 22 and its Working Groups. Note that other groups may also distribute 23 working documents as Internet Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet 28 Drafts as reference material or to cite them other than as a 29 "working draft" or "work in progress". 31 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 33 Directories on ds.internic.net, nic.nordu.net, ftp.isi.edu, or 34 munnari.oz.au. 36 A revised version of this draft document will be submitted to the 37 RFC editor as a Proposed Standard for the Internet Community. 38 Discussion and suggestions for improvement are requested. This 39 document will expire before June 1998. Distribution of this draft is 40 unlimited. 42 Abstract 44 This document describes a simple client/server model for supporting 45 policy control over QoS Signaling Protocols with similar properties 46 as ReSerVation Protocol (RSVP). It is designed to be extensible so 47 that other kinds of policy clients may be supported in the future. 48 The model does not make any assumptions about the decision methods 49 of the policy server, but is based on the server returning responses 50 to policy requests. 52 1. Introduction 54 This document describes a simple query and response protocol that 55 can be used to exchange policy information between a policy server 56 (Policy Decision Point or PDP) and its clients (Policy Enforcement 57 Points or PEPs). One policy client is expected to be RSVP routers 58 that must exercise policy-based admission control over RSVP usage 59 [RSVP]. We assume that at least one policy server exists in each 60 controlled administrative domain. The basic model of interaction 61 between a policy server and its clients is compatible with 62 the framework document for policy based admission control [WRK]. 64 A chief objective of our proposal is to begin with a simple but 65 extensible design. The main characteristics of the proposed protocol 66 include: 68 1. The protocol employs a client/server model where the PEP 69 sends requests, updates, and retractions to the remote PDP and 70 the PDP returns decisions back to the PEP. 72 2. The protocol uses TCP as its transport protocol for reliable 73 exchange of messages between policy clients and a server. 74 Therefore, no additional mechanisms are necessary for reliable 75 communication between a server and its clients. 77 3. The protocol is extensible in that it is designed to leverage 78 off self-identifying objects and can support diverse client 79 specific information. Thus, even though the protocol was created 80 for the administration and enforcement of policies in 81 conjunction with RSVP, the protocol may be extended for 82 administration of other (signaling) protocols such as multicast 83 access and network security. 85 4. The protocol relies on existing protocols for security. 86 Namely IPSEC [IPSEC] can be used to authenticate and secure the 87 channel between the PEP and the server. 89 5. The protocol is stateful in two main aspects: 90 (1) Request/Response state is shared between client and server 91 and (2) State from various events (Request/Response pairs) may 92 be inter-associated. By (1) we mean that requests from the 93 client PEP are installed or remembered by the remote PDP until 94 they are explicitly deleted by the PEP. At the same time, 95 Responses from the remote PDP can be generated asynchronously at 96 any time for a currently installed request state. By (2) we mean 97 that the server may respond to new queries differently because 98 of previously installed, related Request/Response state (e.g., 99 for RSVP, the server may associate state from incoming Path and 100 Resv requests). 102 1.1. Basic Model 104 +----------------+ 105 | | 106 | Network Node | Policy Server 107 | | 108 | +-----+ | COPS +-----+ 109 | | PEP |<-----|-------------->| PDP | 110 | |+----+ | +-----+ 111 | ^ | 112 | | | 113 | \-->+-----+ | 114 | | LDP | | 115 | +-----+ | 116 | | 117 +----------------+ 119 Figure 1: A COPS illustration. 121 Figure 1 Illustrates the layout of various policy components in a 122 typical COPS example (taken from [WRK]). Here, COPS is used to 123 communicate policy information between a Policy Enforcement Point 124 (PEP) and a remote Policy Decision Point (PDP). 126 It is assumed that each participating policy client is functionally 127 consistent with a PEP [WRK]. The PEP may communicate with a policy 128 server (herein referred to as a remote PDP [WRK]) to obtain policy 129 decisions or directives. 131 The COPS protocol uses a single persistent TCP connection between 132 the PEP and a remote PDP. The remote PDP listens on a well-known 133 port number (COPS=3288), and the PEP is responsible for initiating 134 the connection. The location of the remote PDP can either be 135 configured, or obtained via a service location mechanism [SRVLOC]. 136 Service discovery is outside the scope of this protocol, however. 138 The PEP uses the TCP connection to send requests to and receive 139 responses from the remote PDP. Communication between the PEP and 140 remote PDP is mainly in the form of a stateful request/response 141 exchange, though the remote PDP may occasionally send an unsolicited 142 response to the PEP to force a change in a previously approved 143 request state. The PEP also has the capacity to report to the remote 144 PDP that it has committed to an accepted request state for purposes 145 of accounting and monitoring. Finally, the PEP is responsible for 146 the deletion (retraction) of a request state that is no longer 147 applicable. 149 The policy protocol is designed to communicate self-identifying 150 objects which contain the data necessary for identifying request 151 states, establishing the context for a request, identifying the type 152 of request, referencing previously installed requests, relaying 153 policy decisions, reporting errors, and transferring client specific 154 information. 156 To distinguish between different kinds of clients, the type of 157 client is identified in each message. Different types of clients may 158 have different client specific data and may require different kinds 159 of policy decisions. It is expected that each new client type will 160 have a corresponding extensions draft specifying the specifics of 161 its interaction with this policy protocol. 163 The context of each request corresponds to the policy event that 164 triggered it. COPS identifies three types of controlled events: (1) 165 the arrival of an incoming message (2) allocation of local 166 resources, and (3) the forwarding of an outgoing message. 167 Each of these events may require different decisions to be made. 168 Context sub types are also defined according to the type of message 169 that triggered the policy event. In RSVP, this subtype is used to 170 define the RSVP signaling message type (e.g., Path, Resv, etc.). The 171 content of a COPS request/response message depends on the context. 173 The PEP may also have the capability to make a local policy decision 174 via its Local Decision Point (LDP) [WRK], however, the PDP remains 175 the authoritative decision point at all times. This means that 176 any local decision information must always be relayed to the PDP. 177 That is, the PDP must be granted access to all relevant information 178 to make a final policy decision. To facilitate this functionality, 179 the PEP must send its local decision information to the remote PDP 180 via a LDP decision object. The PEP must then abide by the PDP's 181 decision as it is absolute. 183 Finally, fault tolerance is a required capability for this protocol, 184 particularly due to the fact it is associated with the security and 185 service management of distributed network devices. Fault tolerance 186 is achieved by having both the PEP and remote PDP constantly verify 187 their connection to each other via keep-alive messages. When a 188 failure is detected, the PEP must try to reconnect to the remote PDP 189 or attempt to connect to an new/alternative PDP. Once a connection 190 is reestablished, the remote PDP may request that all the PEP's 191 internal state be resynchronized (all previously installed requests 192 are to be reissued). After failure and before the new connection is 193 fully functional, disruption of service can be minimized if the PEP 194 caches previously communicated decisions and continues to use them 195 for some limited amount of time. (Discussions of specific provisions 196 for such a mechanism are outside of the scope of this draft, and are 197 left to client specific implementations). 199 2. The Protocol 201 This section describes the message formats and objects exchanged 202 between the PEP and remote PDP. 204 2.1 Common Header 206 Each COPS message consists of the COPS header followed by a number 207 of typed objects. 209 0 1 2 3 210 +--------------+--------------+--------------+--------------+ 211 |Version|XXXXXX| Op Code | Client Type | 212 +--------------+--------------+--------------+--------------+ 213 | Message Length | 214 +--------------+--------------+--------------+--------------+ 216 The fields in the header are: 217 Version: 4 bits 218 COPS version number. Current version is 1. 220 Op Code: 8 bits 221 The COPS operations: 222 1 = Request (REQ) 223 2 = Response (RES) 224 3 = Unsolicited Response (USR) 225 4 = Report State (RPT) 226 5 = Delete Request State (DRQ) 227 6 = Synchronize State Req (SSQ) 228 7 = Client-Open (OPN) 229 8 = Client-Accept (CAT) 230 9 = Keep Alive (KA) 232 Client Type: 16 bits 234 The Client Type identifies the policy client. Interpretation of 235 all encapsulated objects is relative to the client type. 236 (See Appendix A for the RSVPv1 client type ID). 238 Message Length: 32 bits 239 Size of message in octets, which includes the standard COPS 240 header and all encapsulated objects. Messages must be aligned on 241 4 octet intervals. 243 2.2 COPS Specific Object Formats 245 All the objects follow the same object format; each object consists 246 of one or more 32-bit words with a four octet header, using the 247 following format: 249 0 1 2 3 250 +-------------+-------------+-------------+-------------+ 251 | Length (octets) | C-Num | C-Type | 252 +-------------+-------------+-------------+-------------+ 253 | | 254 // (Object contents) // 255 | | 256 +-------------+-------------+-------------+-------------+ 258 Typically, C-Num identifies the class of information contained in 259 the object, and the C-Type identifies the subtype or version of the 260 information contained in the object. 262 C-num: 8 bits 264 1 = Handle 265 2 = Handle Reference. 266 3 = Context 267 4 = In Interface 268 5 = Out Interface 269 6 = Reason code 270 7 = Decision 271 8 = LDP Decision 272 9 = Protocol Error 273 10 = Client Specific Info 274 11 = Timer 275 12 = PEP Identification 276 13 = Report Type 278 C-type: 8 bits 279 Values defined per C-num. 281 2.2.1 Handle Object (Handle) 283 Unique value that identifies an installed request state. This 284 identification is used by most COPS operations. The request state 285 corresponding to this handle must be explicitly deleted by the 286 client when no longer applicable. 288 The handle value is set by the PEP and is opaque to the PDP. The PDP 289 performs a byte-wise comparison on the value in this object with 290 respect to the handle object values for other currently installed 291 requests. 293 C-Num = 1, C-Type = 1 295 Variable-length field, no implied format. 297 2.2.2 Handle Reference Object (HandleRef) 299 Same C-Type formats as the handle object. This object may appear in 300 requests and is used to associate the current request to previously 301 installed request states. The presence of a reference handle in a 302 request message tells the PDP that it should also consider 303 information in the referenced installed state when making a policy 304 decision for the current request. Handle References are only used 305 for the specific client types that mandate them. 307 C-num = 2, C-Type = (same as handle object) 309 2.2.3 Context Object (Context) 311 Specifies the type of event(s) that triggered the query. Required 312 for request messages. 314 C-num = 3, C-Type = 1 315 0 1 2 3 316 +--------------+--------------+--------------+--------------+ 317 | R-Type | M-Type | 318 +--------------+--------------+--------------+--------------+ 320 R-Type (Request Type Flag) 322 0x01 = Incoming-Message/Admission Control request 323 0x02 = Resource-Allocation request 324 0x04 = Outgoing-Message request 325 0x08 = Configuration request 327 M-Type (Message Type) 329 Client Specific 16 bit values of protocol message types 331 2.2.4 In-Interface Object (IN-Int) 333 The In-Interface Object is used to identify the incoming interface 334 on which a particular request/response applies. For flows or 335 messages generated from the PEP's local host, the loop back address 336 is used. 338 Note: In-Interface is typically relative to the flow of the 339 underlying protocol messages. That is, the In-Interface is the 340 interface on which the protocol message was received. 342 C-Num = 4 343 C-Type = 1, IPv4 Address 344 0 1 2 3 345 +--------------+--------------+--------------+--------------+ 346 | IPv4 Address format | 347 +--------------+--------------+--------------+--------------+ 349 C-Type = 2, IPv6 Address 350 0 1 2 3 351 +--------------+--------------+--------------+--------------+ 352 | | 353 + + 354 | | 355 + IPv6 Address format + 356 | | 357 + + 358 | | 359 +--------------+--------------+--------------+--------------+ 361 C-Type = 3, Ifindex value 362 0 1 2 3 363 +--------------+--------------+--------------+--------------+ 364 | ifindex | 365 +--------------+--------------+--------------+--------------+ 367 Ifindex may be used to differ between sub-interfaces and unnumbered 368 interfaces (see RSVP's LIH for an example). When appropriate, this 369 ifindex integer should correspond to the same integer value for the 370 interface in the SNMP MIB-II interface index table. 372 2.2.5 Out-Interface Object (OUT-Int) 374 The Out-Interface is used to identify the outgoing interface to 375 which a specific request/response applies. It has the same format as 376 the In-Interface Object. 378 C-Num = 5, C-Type = (same C-Type as for In-Interface) 380 Note: In-Interface is typically relative to the flow of the 381 underlying protocol messages. That is, the Out-Interface is the one 382 on which a protocol message is about to be forwarded. 384 2.2.6 Reason Object (Reason) 386 This object specifies the reason why the request state was deleted. 387 It should appear in the delete request (DRQ) message. 389 C-Num = 6, C-Type = 1 390 0 1 2 3 391 +--------------+--------------+--------------+--------------+ 392 | Reason-Code | Reason Sub-code | 393 +--------------+--------------+--------------+--------------+ 395 Reason Code: 396 1 = Unknown 397 2 = Management 398 3 = Preempted 399 4 = Tear 400 5 = Timeout 401 6 = Route Change 402 7 = Insufficient Resources 403 8 = PDP's Directive 404 9 = Client Specific (details in sub-code) 406 2.2.7 Decision Object (Decision) 408 Decision made by the PDP. Must appear in replies. The specific 409 decision objects required in a response to a particular request 410 depend on the type of client. 412 C-Num = 7 414 CType = 1, Decision Flags (mandatory!) 416 0 1 2 3 417 +--------------+--------------+--------------+--------------+ 418 | Flags | 419 +--------------+--------------+--------------+--------------+ 421 Flags: 422 0x01 = Reject Incoming (Reject if set) 423 0x02 = Do Not Allocate Resources (Reject if set) 424 0x04 = Drop Outgoing (do not forward message if set) 425 0x08 = Trigger Error (Trigger error message if set) 427 Ctype = 2, Resource Allocation Data (optional) 429 It is expected that PEPs would be able to configure simple 430 stateless policy information to be processed locally in their 431 LDP. As this set is well known and implemented ubiquitously, 432 PDPs are aware of it as well (either universally, through 433 configuration, or using the Client-Open message). The PDP may 434 also include this information in its response, and the PEP 435 should apply it to the resource allocation event that generated 436 the request. 438 Examples of resource allocation information that can be found in 439 other documents are: 441 Preemption Priority 443 Priority is used by PEP to decide which of the flows should be 444 preempted, when not enough resources are available on the 445 interface. For RSVP, when preemption is supported, a higher 446 priority reservation can preempt an installed reservation with 447 lower priority. 449 CType = 3, Replacement Data (Optional) 451 Format includes a list of client specific data that is to be 452 used in place of information specified in the request. Use of 453 this decision type is optional. For RSVP, this decision is used 454 to change objects carried in RSVP messages. For example, 455 replacing the policy data objects when forwarding a Resv message 456 upstream is possible due to this decision type. If this decision 457 doesn't appear in a response, all objects are passed as if the 458 PDP was not there. To remove an object the decision should carry 459 an empty object of length 4 (header only). Appendix A specifies 460 the list of RSVP objects that can be replaced. 462 CType = 4, Client Specific Decision Data (Optional) 464 Proprietary decision types can be introduced using the Client 465 Data Decision Object. Like the Replacement Data object, client 466 specific information is encapsulated within the Client Data 467 Object. 469 2.2.8 LDP Decision Object (LDPDecision) 471 Decision made by the PEP's local decision point (LDP). May appear in 472 requests. These objects correspond to and are formatted the same as 473 the client specific decision objects defined above. 475 C-Num = 8 477 CType = (same C-Type as for Decision object) 479 2.2.9 Error Object (Error) 481 This object is used to identify a particular COPS protocol error. 483 C-Num 9, C-Type = 1 485 0 1 2 3 486 +--------------+--------------+--------------+--------------+ 487 | Error-Code | Error Sub-code | 488 +--------------+--------------+--------------+--------------+ 490 Error-Code: 492 1 = Bad handle 493 2 = Invalid handle reference 494 3 = Bad message format 495 4 = Unable to process (server gives up on query) 496 5 = Mandatory client-specific info missing 497 6 = Unsupported client type 498 7 = Mandatory COPS object missing 500 2.2.10 Client Specific Information Object (ClientSI) 502 All objects specific to a client's signaling protocol must be 503 encapsulated within one or more Client Information Objects. 505 Class-Num = 10, C-Type = 1 507 Variable-length field. The format of the data encapsulated in the 508 ClientSI object is determined by the client type. 510 2.2.11 Timer Object (Timer) 512 Times are encoded as 32-bit integer values and are in units of 513 seconds. The time value is treated as a delta. 515 Class-Num = 11, C-Type = 1 (keep-alive timer value) 517 0 1 2 3 518 +--------------+--------------+--------------+--------------+ 519 | Timer Value | 520 +--------------+--------------+--------------+--------------+ 522 2.2.12 PEP Identification Object (PEPID) 524 The PEP Identification Object is used to identify the PEP client to 525 the remote PDP. It is required for Client-Open messages. 527 C-Num = 12, C-Type = 1 529 Variable-length field (zero padded ASCII symbolic name) configured 530 by local administrators for the PEP. For example, it can be the 531 PEP's main IP address (not to be confused with the actual IP address 532 used in the persistent TCP connection). It may also be the PEP's DNS 533 name, or any other symbol that uniquely identifies each PEP within 534 the policy domain. The choice of configuration bears no significance 535 to the COPS protocol. By default, at least the primary IP address of 536 the PEP represented as a string is expected in the PEPID. 538 2.2.13 Report-Type Object (Report-Type) 540 The Type of Report on the request state associated with a handle: 542 C-Num = 13, C-Type = 1 544 0 1 2 3 545 +--------------+--------------+--------------+--------------+ 546 | Report-Type | XXXXXXXXXXXXX | 547 +--------------+--------------+--------------+--------------+ 549 Report-Type: 550 1 = Commit : State was installed on client (PEP) 551 2 = Accounting: Accounting update for an installed state 553 3. Message Content 555 This section describes the basic messages exchanged between a PEP 556 and a remote PDP as well as their contents. 558 3.1 Request (REQ) PEP -> PDP 560 The PEP establishes a request state handle for which the remote PDP 561 may maintain a state. The remote PDP then uses this handle to refer 562 to the exchanged information and decisions. 564 Once a stateful handle is established for a new request, any 565 subsequent modifications of the request can be made using the REQ 566 message specifying the previously installed handle. 568 The format of the Request message is as follows: 570 ::= 571 572 573 [] 574 [] 575 576 [] 577 [] 579 The context object is used to determine the context within which all 580 the other objects are to be interpreted. It also is used to 581 determine the kind of response to be returned from the policy 582 server. This response might be related to admission control, 583 resource allocation, or object forwarding and substitution. 585 The interface objects are used to determine the corresponding 586 interface on which a signaling protocol message was received or is 587 about to be sent. They are only used if the client is participating 588 along the path of a signaling protocol. 590 ClientSI, the client specific information object holds the client 591 type specific data for which a policy decision needs to be made. 593 The handle reference objects are used to refer to state information 594 currently installed on the PDP that is associated with the current 595 request. 597 Finally, LDPDecision object holds information regarding the local 598 decision made by the LDP. 600 3.2 Response (RES) PDP -> PEP 602 The PDP responds to the REQ with a RES message that includes the 603 associated handle and the decision. If there was a protocol error an 604 error object is returned instead. 606 In order to avoid the issue of keeping track of which Request a 607 particular response belongs to, it is important that, for a given 608 handle, there be at most one outstanding response per query. This 609 essentially means that the PEP should not issue more than one 610 REQ(for a given handle) before it receives a corresponding RES. To 611 avoid deadlock, the client can always timeout after issuing a 612 request. It can then delete the timed-out handle, and try again 613 using a different (new) one. 615 The format of the Response message is as follows: 617 ::= 618 619 || 621 The response may include either an Error object or decision 622 object(s). COPS protocol problems are reported in the Error object 623 (e.g. an error with the format of the original request). Decision 624 object(s) depend on the context of the associated request and the 625 type of client. 627 3.3 Unsolicited Response (USR) PDP -> PEP 629 The remote PDP can also send an unsolicited response to a PEP to 630 report a different response than the one previously communicated. 631 For example, the PDP may admit a new flow and change its mind to 632 reject it sometime later. The change of mind is communicated using 633 the USR message. 635 The format for an USR is the same as that for a RES and similarly, 636 it dependents on the context of the original request. 638 3.4 Report State (RPT) PEP -> PDP 640 This message is used by the PEP to communicate the change in status 641 of a previously installed request state to the server. A commit 642 report indicates to the PDP that a particular policy directive has 643 been acted upon. (In RSVP this would mean that the reservation 644 successfully passed capacity admission control). 646 The Report State may also be used to provide periodic updates of 647 client specific information for accounting and state monitoring 648 purposes depending on the type of the client. In such cases the 649 accounting report type should be specified utilizing the client 650 specific information object. 652 ::== 653 654 655 [ ] 657 3.5 Delete Request State (DRQ) PEP -> PDP 659 This message indicates to the remote PDP that the request state must 660 be deleted. This will be used by the remote PDP to initiate the 661 appropriate housekeeping actions. The reason code object is 662 interpreted with respect to the client type. 664 The format of the Delete Request State message is as follows: 666 ::= 667 668 670 3.6 Synchronize State Request (SSQ) PDP -> PEP 672 The format of the Synchronize State Query message is as follows: 674 ::= 675 [] 677 This message indicates that the remote PDP wishes the client (which 678 appears in the common header) to re-send its state. If the optional 679 Handle is present, only the state associated with this handle is 680 synchronized. Otherwise, all the client state should be synchronized 681 with the PDP. 683 The client performs state synchronization by re-issuing request 684 queries of the specified client type for the existing state in the 685 PEP. 687 3.7 Client-Open (OPN) PEP -> PDP 689 The Client-Open message can be used to provide the characteristics 690 of the connection, suggested time intervals for the keep-alive 691 messages, and information on the locally known policy elements. 693 ::= 694 695 [] 697 The PEPID is a symbolic, variable length name that identifies the 698 specific client to the PDP. Values for the PEPID are configurable by 699 administrators of administrative domains and are of direct 700 significance to the COPS protocol. By default, the PEPID specifies 701 the primary IP address in the form of a string for the PEP in 702 question. 704 If included, the timer corresponds to PEP's preference for the 705 maximum intermediate time between the generation of messages for 706 connection verification. 708 3.8 Client-Accept (CAT) PDP -> PEP 710 The Client-Accept message is used to respond to the Client-Open 711 message. This message will return to the PEP either a timer object 712 indicating the expected time interval between keep-alive messages, 713 or an error object indicating that an error occurred (e.g. requested 714 client type is not supported by the remote PDP). 716 ::= 717 || 719 If the PDP refuses the client, it will return an Error object to 720 describe the reason. 722 The timer corresponds to maximum acceptable intermediate time 723 between the generation of messages by the PDP and PEP. The timer 724 value is determined by the PDP taking into account the client's 725 preference established with the OPN message. A timer value of 726 0xFFFFFFFF implies no secondary connection verification is 727 necessary. 729 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 731 The keep-alive message only needs to be transmitted when there has 732 been no activity between the client and server for a period 733 approaching half that of the minimum timer value negotiated with the 734 OPN & CAT messages. It is a validation for each side that the other 735 is still functioning. 737 ::= 739 Both client and server may assume the connection is insufficient for 740 the client type with the minimum time value (specified in the CAT 741 message) if no communication activity is detected for a period 742 exceeding the timer period. For the PEP, such detection implies the 743 remote PDP or connection is down and the PEP should now attempt to 744 use an alternative/backup PDP. 746 4. Common Operation 748 This section describes the typical exchanges between remote PDP 749 servers and PEP clients. 751 After a connection is established between the PEP and a remote PDP, 752 the PEP will send one or more Client-Open messages to the remote 753 PDP, one for each client type supported by the PEP. The open message 754 should contain the common header noting one client type supported by 755 the PEP. The remote PDP will then respond with a Client-Accept 756 message echoing back each of the client types the PEP supports that 757 it can support as well. If a specific client type is not supported 758 by the PDP, the corresponding Client-Accept message sent back to the 759 PEP will include an error object specifying the client type is not 760 supported. The PDP will include the timer interval between keep- 761 alive messages in its Client-Accept. 763 When the PEP receives an event that requires a new policy decision 764 it sends a request message to the remote PDP. The remote PDP then 765 makes a decision and sends a response back to the PEP. Since the 766 request is stateful, the request will be remembered, or installed, 767 on the remote PDP. The unique handle, specified in both the request 768 and its corresponding response identifies this request state. The 769 PEP is responsible for deleting this request state once the request 770 is no longer applicable. 772 The PEP may update a previously installed request state by reissuing 773 a request for the previously installed handle. The remote PDP is 774 then expected to make new decisions and send a response back to the 775 PEP. Likewise, the server may change a previously issued decision on 776 any currently installed request state at any time by issuing an 777 asynchronous response. At all times the PEP module is expected to 778 abide by the PDP's decisions. 780 The PEP may also notify the remote PDP of the local status of an 781 installed request using the report message where appropriate. The 782 report message is to be used to signify when billing should 783 effectively begin, or to produce periodic updates for monitoring and 784 accounting purposes depending on the client. This message can carry 785 client specific information when needed. 787 Finally, to validate the connection between the client and server is 788 still functioning, the keep-alive message is used. If no COPS 789 message is generated within one half the minimum timer value 790 interval, a keep-alive message needs to be generated. Both the PEP 791 and remote PDP are expected to follow this procedure. 793 5. Security 795 The security of RSVP messages is provided by inter-router MD5 796 authentication [MD5]. This assumes a chain-of-trust model for inter 797 PEP authentication. Security between the client (PEP) and server 798 (PDP) is provided by IPSEC [IPSEC]. 800 To ensure the client (PEP) is communicating with the correct policy 801 server (PDP) involves two issues: authentication of the policy 802 client and server using a shared secret, and consistent proof that 803 the connection remains valid. The shared secret requires manual 804 configuration of keys, which is a maintenance issue. IPSEC AH may be 805 used for the validation of the connection; IPSEC ESP may be used to 806 provide both validation and secrecy. 808 6. Open issues 810 6.1 Bi-directional Connection Establishment: 812 Currently, only the PEP is supposed to connect with the PDP. It 813 might be useful to have the PDP proactive in establishing 814 connections with its PEPs. Such would potentially simplify PEP 815 configuration and allow a primary PDP that has failed to notify its 816 clients that it is functional again. 818 6.2 Client Type Close/Redirect: 820 Is there a need for a Close message per client type so the PEP and 821 PDP can notify each other in case of a capability change? If there 822 is a close, should the PDP be able to tell the PEP which PDP server 823 it should now use (redirect)? 825 6.3 Division of Labor Negotiation: 827 How can (and is there a need for) the PEP to notify the remote PDP 828 of its LDP's capabilities (e.g. the LDP can directly authenticate 829 user information)? 831 6.4 Group ID: 833 Is there a need for a Group ID for identifying the group a client 834 belongs akin to how the PEPID identifies an individual client? 836 6.5 RSVP Object Replacement: 838 Should the PDP be capable of directing the RSVP PEP to replace other 839 objects than the Policy Data object (e.g. FlowSpec)? If so, for 840 which request types? 842 6.6 RSVP Priority Element Definition (other work). 844 7. References 846 [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) 847 Version 1 - Functional Specification", RFC 2205, September 848 1997. 850 [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission 851 Control", Internet-Draft, draft-ietf-rap-framework-00.txt, 852 November 1997. 854 [SRVLOC]Guttman, E. et al., "Service Location Protocol", Internet- 855 Draft, draft-ietf-svrloc-protocol-v2-01.txt, October 1997. 857 [INSCH] Shenker, S., Wroclawski, J., "General Characterization 858 Parameters for Integrated Service Network Elements", RFC 859 2215, September 1997. 861 [IPSEC] Atkinson, R., "Security Architecture for the Internet 862 Protocol", RFC1825, August 1995. 864 [MD5] Baker, F., "RSVP Cryptographic Authentication", Internet- 865 Draft, draft-ietf-rsvp-md5-05.txt, August 1997. 867 [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) 868 - Version 1 Message Processing Rules", RFC 2209, September 869 1997. 871 8. Author Information and Acknowledgments 873 Special thanks to Timothy O'Malley our WG Chair, Raj Yavatkar, 874 Russell Fenger, Laura Cunningham, Roch Guerin, Ping Pan, and 875 Dimitrios Pendarakis for their valuable contributions. 877 Jim Boyle Ron Cohen 878 MCI Class Data Systems 879 2100 Reston Parkway 13 Hasadna St. 880 Reston, VA 20191 Ra'anana 43650 Israel 881 703.715.7006 972.9.7462020 882 jboyle@mci.net ronc@classdata.com 884 David Durham Raju Rajan 885 Intel IBM T.J. Watson Research Cntr 886 2111 NE 25th Avenue P.O. Box 704 887 Hillsboro, OR 97124 Yorktown Heights, NY 10598 888 503.264.6232 914.784.7260 889 David_Durham@mail.intel.com raju@watson.ibm.com 891 Shai Herzog Arun Sastry 892 IPHighway Cisco Systems 893 2055 Gateway Pl., Suite 400 506210 W Tasman Drive 894 San Jose, CA 95110 San Jose, CA 95134 895 408.390.3045 408.526.7685 896 herzog@iphighway.com asastry@cisco.com 897 Appendix A. COPS Extensions for Use with RSVP 899 A.1 Overview of COPS extensions for RSVP 901 Building on the foundations described in the previous sections this 902 section describes the specific functionality required for this 903 protocol to support policy control over RSVP. 905 Setting the client type in the COPS common header to 1 indicates an 906 RSVP client capable of performing admission control and policy data 907 substitution using RSVP V1 objects. 909 A.2 COPS objects for use with RSVP 911 The COPS objects defined in section 2.2 are applicable to RSVP 912 policy control, and their use is described in the text that follows. 914 The message type information found in the RSVP message header is 915 represented by the M-Type in the COPS Context Object. 917 All objects contained within RSVP messaging are expected to be 918 encapsulated in the Client Specific Information Object without 919 alteration. Multiple RSVP objects may be contained within a single 920 Client Specific Information Object exchanged between the PEP and 921 remote PDP. 923 Finally, for the COPS outgoing message responses, RSVP objects may 924 be returned to the PEP from the remote PDP via the Replacement Data 925 Decision Object. This object may contain multiple RSVP objects, but 926 is primarily concerned with returning the Policy Data object. 927 Objects included in the Replace Data Decision Object are to replace 928 their corresponding object in the RSVP message (typically for 929 outgoing RSVP messages). 931 A.3. Operation of COPS for Policy Control Over RSVP 933 A.3.1 RSVP values for the Context Object (Context) 935 The semantics of the Context object for RSVP is as follows: 937 R-Type (Request Type Flag) 939 0x01 = Incoming-Message request 940 The arrival of an incoming RSVP message 942 Allows processing of incoming policy information as well as 943 the decision whether to accept an incoming message. If It is 944 rejected, the message is treated as if it never Arrived. 946 0x02 = Resource-Allocation request 947 Applies only for Resv messages. 949 The decision whether to admit a reservation and commit local 950 resources to it is performed for the merge of all 951 reservations that arrived on a particular interface 952 (potentially from several Previous Hops). 954 0x04 = Outgoing-Message request 955 The forwarding of an outgoing RSVP message. 957 The Decision whether to allow the forwarding of an outgoing 958 RSVP message as well as providing the relevant outgoing 959 policy information. 961 M-Type (Message Type) 963 The M-Type field in the Context Object may have one of the 964 Following values that correspond to supported RSVP messages 965 In COPS: 967 1 = Path 968 2 = Resv 969 3 = PathErr 970 4 = PathErr 972 Note: At this point, PathTear, ResvTear, and the Resv Confirm 973 message types are not supported. 975 A.3.2 RSVP flows 977 Policy Control is performed per RSVP flow. An RSVP flow corresponds 978 to an atomic unit of reservation as identified by RSVP (TC 979 reservation). It should be noted that RSVP allows multiple flows to 980 be packed (which is different from merged) into a single FF Resv 981 message. To support such messages a separate COPS request must be 982 issued for each of the packed flows as if they were individual RSVP 983 messages. 985 A.3.4 Expected Associations for RSVP Requests 987 RSVP signaling requires the participation of both senders and 988 receivers. RSVP processing rules define what is the subset of the 989 Path state that matches each Resv state. In the common unicast case, 990 the RSVP session includes one Path state and one Resv state. In 991 multicast cases the correspondence might be many to many. Since the 992 decision to admit a reservation for a session may depend on 993 information carried both in Path and Resv messages, we term the Path 994 States that match with a single Resv state as its associated states. 995 It is assumed that the PDP is capable of determining these 996 associations based on the RSVP message processing rules given the 997 RSVP objects expressed in the COPS Client Specific Information 998 Object. 1000 A.3.5 RSVP's Capacity Admission Control: Commit and Delete 1002 In RSVP, the admission of a new reservation requires both an 1003 administrative approval (policy control) and capacity admission 1004 control. Once local admission control accepts the reservation, the 1005 PEP notifies the remote PDP by sending a report message specifying 1006 the Commit type. The Commit type report message is to be used to 1007 signify when billing should effectively begin, and performing 1008 heavier operations (e.g., debiting a credit card) is permissible. 1010 If instead a reservation approved by the PDP fails admission due to 1011 lack of resources, the PEP must notify the PDP by issuing a delete 1012 message. 1014 A.3.6 Policy Control Over Path and Resv Tear 1016 Path and Resv Tear messages are not controlled by this policy 1017 architecture. This relies on two assumptions: First, that MD-5 1018 authentication verifies that the Tear is received from the same node 1019 that sent the initial reservation, and second, that it is 1020 functionally equivalent to that node holding-off refreshes for this 1021 reservation. When a Resv or Path Tear is received at the PEP, all 1022 affected states installed on the PDP should either be deleted or 1023 updated by the PEP. 1025 A.3.7 PEP Caching COPS Decisions 1027 Because COPS is a stateful protocol, refreshes for RSVP Path and 1028 Resv messages need not be constantly sent to the remote PDP. Once a 1029 decision has been returned for a request, the PEP can cache that 1030 decision and apply it to future refreshes. The PEP is only 1031 responsible for updating a request state if there is a change 1032 detected in the corresponding Resv or Path message. 1034 A.3.8 Data Expected in Request Messages for RSVP Support 1036 The information required in a RSVP request for each applicable 1037 message type and request type combination is outlined below: 1039 In, Path - 1040 1041 1042 Out, Path - 1043 1044 1045 In & Out (unicast combined request), Path - 1046 1047 1048 1050 In, Resv - 1051 1052 1053 Merge, Resv - 1054 1055 1057 Out, Resv - 1058 1059 1060 In & Merge (combined request, PEP can merge), Resv - 1061 1062 1063 In & Merge & Out (unicast combined request), Resv - 1064 1065 1066 1068 In, PathErr - 1069 1070 1071 Out, PathErr - 1072 1073 1074 In & Out (unicast combined request), PathErr - 1075 1076 1077 1079 In, ResvErr - 1080 1081 1082 Out, ResvErr - 1083 1084 1085 In & Out (unicast combined request), ResvErr 1086 1087 1088 1090 A.3.9 Expected Decisions for RSVP Requests 1092 The expected decision information relative to a request for each 1093 applicable message type and request type combination is outlined 1094 below: 1096 In, Path - 1097 1098 Out, Path - 1099 1100 In & Out (combined request), Path - 1101 1103 In, Resv - 1104 1105 Merge, Resv - 1106 1107 Out, Resv - 1108 1109 In & Merge (combined request, PEP can merge), Resv - 1110 1111 In & Merge & Out (unicast combined request), Resv - 1112 1113 1115 In, PathErr - 1116 1117 Out, PathErr - 1118 1119 In & Out (combined request), PathErr - 1120 1122 In, ResvErr - 1123 1124 Out, ResvErr - 1125 1126 In & Out (combined request), ResvErr - 1127 1129 A.4 Illustrative Examples, Using COPS for RSVP 1131 A.4.1 Unicast Flow Example 1133 This section details the steps in using COPS for controlling a 1134 Unicast RSVP flow. It details the contents of the COPS messages 1135 with respect to the following figure. 1137 PEP (router) 1138 +-----------------+ 1139 | | 1140 R1 ------------+if1 if3+------------ S1 1141 | if2 | 1142 +--------+--------+ 1143 | 1144 | 1145 PDP (server) 1147 figure 1: Unicast Example: a single router view 1149 The PEP router has three interfaces (1,2,3). Sender S1 sends to 1150 receiver R1. 1152 A Path message arrives from S1: 1154 PEP --> PDP REQ := 1155 1156 1158 PDP --> PEP RES := 1160 A Resv message arrives from R1: 1162 PEP --> PDP REQ := 1163 1164 1166 PDP --> PEP RES := 1167 1170 PEP --> PDP RPT := 1171 1173 Time Passes, the PDP changes its decision: 1175 PDP --> PEP USR := 1176 1179 Because the priority is too low, the PEP preempts the flow: 1181 PEP --> PDP DRQ := 1182 1184 Time Passes, the sender S1 ceases to send Path messages: 1186 PEP --> PDP DRQ := 1187 1189 A.4.2 Shared Multicast Flows 1191 This section details the steps in using COPS for controlling a 1192 multicast RSVP flow. It details the contents of the COPS messages 1193 with respect to the following figure. 1195 ----------------- 1196 r1 | | 1197 H1-------------|i1 | r4 1198 | o1 |---------------- S1 1199 r2 | Router | 1200 H2 ------------|i2 | 1201 | | o2 |---------------- S2 1202 | r3 | | 1203 | ----------------- 1204 H3 1206 figure 1: 2 senders and 3 receivers 1208 Figure 1 shows an RSVP router which has two senders and three 1209 receivers for the same multicast session. Interface i2 is connected 1210 to a shared media. 1212 First detailed is the request message content for a Path sent by 1213 sender S1, assuming that both receivers have already joined the 1214 multicast session, but haven't sent a Resv message as yet. Assume 1215 sender S2 has not yet sent a path message. The Path message arrives 1216 on interface o1: 1218 PEP -----> PDP REQ := 1219 1221 PDP -----> PEP RES := 1223 Here the PDP decides to allow the Path message. Next, the Router 1224 consults its forwarding table, and finds two outgoing interfaces, 1225 i1 and i2, for the path. The exchange below is for interface i1, 1226 another exchange would likewise be completed for i2 using the new 1227 handle B2. 1229 PEP -----> PDP REQ := 1230 1233 PDP -----> PEP RES := 1234 1237 Here, the PDP decided to allow the forwarding of the Path message 1238 via interface i1, and determined the appropriate policy objects for 1239 the message going out on this interface. 1241 Next, the receiver r2 sends a Resv message of WF style. The Resv 1242 arrives on interface i2. Here the PEP queries the PDP which decides 1243 to accept this reservation with priority 5 as shown below. 1245 PEP -----> PDP REQ := 1246 1248 PDP -----> PEP RES := 1250 This assumes the PEP is not itself capable of merging priority 1251 information, and, thus, must make another query for the incoming 1252 interface merge. 1254 PEP -----> PDP REQ := 1255 1257 PDP -----> PEP RES := 1259 After PEP successfully admitted the reservation it sends a report 1260 message that signals to the PDP that it can start an accounting log 1261 for this reservation. 1263 PEP -----> PDP RPT := 1264 1266 The reservation r2 needs to be sent upstream towards sender S1 out 1267 interface o1. An outgoing Resv request is made which carries the 1268 associated handle of the Path message for which this Resv is being 1269 forwarded. 1271 PEP -----> PDP REQ := 1272 1274 PDP -----> PEP RES := 1277 Next, receiver H3 sends the Resv message r3. The PEP sends an 1278 incoming request for handle F and the PDP decides to accept the Resv 1279 (as before). The new reservation also requires the PEP to update the 1280 merged request (handle D) due to the modified flowspec. The PDP now 1281 gives this request priority 7. If accepted by local admission 1282 control, a report is again sent. 1284 PEP -----> PDP REQ := 1285 1288 PDP -----> PEP RES := 1289 PEP -----> PDP RPT := 1290 1292 Now the outgoing request for handle E is reissued for the merged (R2 1293 & R3) outgoing Resv to be sent towards sender S1 due to a modified 1294 flowspec. 1296 PEP -----> PDP REQ := 1297 1300 PDP -----> PEP RES := 1303 When S2 joins the session by sending a Path message, incoming and 1304 outgoing Path requests are issued for the new Path. The two incoming 1305 Resv requests may then be reissued for handle C and handle E if 1306 there is a change in their shared sender filter list (for SE 1307 filters) specifying the new sender. A new outgoing Resv request 1308 would then be issued for the Resv to be sent to s2 out interface o2.