idnits 2.17.1 draft-ietf-rap-cops-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. 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. == 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 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 (February 24, 1999) is 9193 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: 'RFC-2119' is mentioned on line 45, but not defined == Missing Reference: 'SRVLOC' is mentioned on line 830, but not defined == Unused Reference: 'INSCH' is defined on line 1403, but no explicit reference was found in the text == Outdated reference: A later version (-03) exists of draft-ietf-rap-framework-01 ** 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 -- Possible downref: Non-RFC (?) normative reference: ref. 'IANA' ** Obsolete normative reference: RFC 2434 (ref. 'IANA-CONSIDERATIONS') (Obsoleted by RFC 5226) Summary: 7 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Draft Jim Boyle 3 Expiration: August 1999 Level 3 4 File: draft-ietf-rap-cops-06.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 The COPS (Common Open Policy Service) Protocol 17 Last Updated: February 24, 1999 19 Status of this Memo 21 This document is an Internet-Draft and is in full conformance with 22 all provisions of Section 10 of RFC2026. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six 30 months and may be updated, replaced, or obsoleted by other documents 31 at any time. It is inappropriate to use Internet-Drafts as 32 reference material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 Conventions used in this document 42 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 43 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 44 this document are to be interpreted as described in [RFC-2119]. 46 Status of this Memo................................................1 47 Conventions used in this document..................................1 48 Abstract...........................................................3 49 1. Introduction....................................................3 50 1.1 Basic Model....................................................4 51 2. The Protocol....................................................7 52 2.1 Common Header..................................................7 53 2.2 COPS Specific Object Formats...................................8 54 2.2.1 Handle Object (Handle).......................................9 55 2.2.2 Context Object (Context).....................................9 56 2.2.3 In-Interface Object (IN-Int)................................10 57 2.2.4 Out-Interface Object (OUT-Int)..............................11 58 2.2.5 Reason Object (Reason)......................................12 59 2.2.6 Decision Object (Decision)..................................12 60 2.2.7 LDP Decision Object (LDPDecision)...........................14 61 2.2.8 Error Object (Error)........................................14 62 2.2.9 Client Specific Information Object (ClientSI)...............14 63 2.2.10 Keep-Alive Timer Object (KATimer)..........................15 64 2.2.11 PEP Identification Object (PEPID)..........................15 65 2.2.12 Report-Type Object (Report-Type)...........................16 66 2.2.13 PDP Redirect Address (PDPRedirAddr)........................16 67 2.2.14 Last PDP Address (LastPDPAddr).............................17 68 2.2.15 Accounting Timer Object (AcctTimer)........................17 69 2.3 Communication.................................................17 70 2.4 Client Handle Usage...........................................19 71 2.5 Synchronization Behavior......................................19 72 3. Message Content................................................20 73 3.1 Request (REQ) PEP -> PDP.....................................20 74 3.2 Decision (DEC) PDP -> PEP....................................21 75 3.3 Report State (RPT) PEP -> PDP................................22 76 3.4 Delete Request State (DRQ) PEP -> PDP........................22 77 3.5 Synchronize State Request (SSQ) PDP -> PEP...................23 78 3.6 Client-Open (OPN) PEP -> PDP.................................23 79 3.7 Client-Accept (CAT) PDP -> PEP...............................24 80 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................24 81 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................25 82 3.10 Synchronize State Complete (SSC) PEP -> PDP..................25 83 4. Common Operation...............................................26 84 4.1 PEP Initialization............................................26 85 4.2 Outsourcing Operations........................................26 86 4.3 Configuration Operations......................................27 87 4.4 Keep-Alive Operations.........................................27 88 4.5 PEP/PDP Close.................................................27 89 5. Security Considerations........................................28 90 6. IANA Considerations............................................29 91 7. References.....................................................30 92 8. Author Information and Acknowledgments.........................31 94 Abstract 96 This document describes a simple client/server model for supporting 97 policy control over QoS Signaling Protocols and provisioned QoS 98 resource management. It is designed to be extensible so that other 99 kinds of policy clients may be supported in the future. The model 100 does not make any assumptions about the methods of the policy 101 server, but is based on the server returning decisions to policy 102 requests. 104 1. Introduction 106 This document describes a simple query and response protocol that 107 can be used to exchange policy information between a policy server 108 (Policy Decision Point or PDP) and its clients (Policy Enforcement 109 Points or PEPs). One example of a policy client is RSVP routers 110 that must exercise policy-based admission control over RSVP usage 111 [RSVP]. We assume that at least one policy server exists in each 112 controlled administrative domain. The basic model of interaction 113 between a policy server and its clients is compatible with 114 the framework document for policy based admission control [WRK]. 116 A chief objective of policy control protocol is to begin with a 117 simple but extensible design. The main characteristics of the COPS 118 protocol include: 120 1. The protocol employs a client/server model where the PEP 121 sends requests, updates, and deletes to the remote PDP and the 122 PDP returns decisions back to the PEP. 124 2. The protocol uses TCP as its transport protocol for reliable 125 exchange of messages between policy clients and a server. 126 Therefore, no additional mechanisms are necessary for reliable 127 communication between a server and its clients. 129 3. The protocol is extensible in that it is designed to leverage 130 off self-identifying objects and can support diverse client 131 specific information without requiring modifications to the COPS 132 protocol itself. The protocol was created for the general 133 administration, configuration, and enforcement of policies 134 whether signaled or provisioned. The protocol may be extended 135 for the administration of a variety of signaling protocols as 136 well as policy configuration on a device. 138 4. The protocol relies on existing protocols for security. 139 Namely IPSEC [IPSEC] can be used to authenticate and secure the 140 channel between the PEP and the server. 142 5. The protocol is stateful in two main aspects: 143 (1) Request/Decision state is shared between client and server 144 and (2) State from various events (Request/Decision pairs) may 145 be inter-associated. By (1) we mean that requests from the 146 client PEP are installed or remembered by the remote PDP until 147 they are explicitly deleted by the PEP. At the same time, 148 Decisions from the remote PDP can be generated asynchronously at 149 any time for a currently installed request state. By (2) we mean 150 that the server may respond to new queries differently because 151 of previously installed Request/Decision state(s) that are 152 related. 154 6. Additionally, the protocol is stateful in that it allows the 155 server to push configuration information to the client, and then 156 allows the server to remove such state from the client when it 157 is no longer applicable. 159 1.1 Basic Model 161 +----------------+ 162 | | 163 | Network Node | Policy Server 164 | | 165 | +-----+ | COPS +-----+ 166 | | PEP |<-----|-------------->| PDP | 167 | +-----+ | +-----+ 168 | ^ | 169 | | | 170 | \-->+-----+ | 171 | | LDP | | 172 | +-----+ | 173 | | 174 +----------------+ 176 Figure 1: A COPS illustration. 178 Figure 1 Illustrates the layout of various policy components in a 179 typical COPS example (taken from [WRK]). Here, COPS is used to 180 communicate policy information between a Policy Enforcement Point 181 (PEP) and a remote Policy Decision Point (PDP) within the context of 182 a particular type of client. The optional Local Decision Point (LDP) 183 can be used by the device to make local policy decisions in the 184 absence of a PDP. 186 It is assumed that each participating policy client is functionally 187 consistent with a PEP [WRK]. The PEP may communicate with a policy 188 server (herein referred to as a remote PDP [WRK]) to obtain policy 189 decisions or directives. 191 The PEP is responsible for initiating a persistent TCP connection to 192 a PDP. The PEP uses this TCP connection to send requests to and 193 receive decisions from the remote PDP. Communication between the PEP 194 and remote PDP is mainly in the form of a stateful request/decision 195 exchange, though the remote PDP may occasionally send unsolicited 196 decisions to the PEP to force changes in previously approved request 197 states. The PEP also has the capacity to report to the remote PDP 198 that it has committed to an accepted request state for purposes of 199 accounting and monitoring. The PEP is responsible for notifying the 200 PDP when a request state has changed on the PEP. Finally, the PEP is 201 responsible for the deletion of any state that is no longer 202 applicable due to events at the client or decisions issued by the 203 server. 205 When the PEP sends a configuration request, it expects the PDP to 206 continuously send named units of configuration data to the PEP via 207 decision messages as applicable for the configuration request. When 208 a unit of named configuration data is successfully installed on the 209 PEP, the PEP should send a report message to the PDP confirming the 210 installation. The server may then update or remove the named 211 configuration information via a new decision message. When the PDP 212 sends a decision to remove named configuration data from the PEP, 213 the PEP will delete the specified configuration and send a report 214 message to the PDP as confirmation. 216 The policy protocol is designed to communicate self-identifying 217 objects which contain the data necessary for identifying request 218 states, establishing the context for a request, identifying the type 219 of request, referencing previously installed requests, relaying 220 policy decisions, reporting errors, and transferring client 221 specific/name space information. 223 To distinguish between different kinds of clients, the type of 224 client is identified in each message. Different types of clients may 225 have different client specific data and may require different kinds 226 of policy decisions. It is expected that each new client-type will 227 have a corresponding usage draft specifying the specifics of its 228 interaction with this policy protocol. 230 The context of each request corresponds to the type of event that 231 triggered it. COPS identifies three types of outsourcing events: (1) 232 the arrival of an incoming message (2) allocation of local 233 resources, and (3) the forwarding of an outgoing message. Each of 234 these events may require different decisions to be made. Context sub 235 types are also available to describe the type of message that 236 triggered the policy event. The content of a COPS request/decision 237 message depends on the context. A fourth type of request is useful 238 for types of clients that wish to receive configuration information 239 from the PDP. This allows a PEP to issue a configuration request for 240 a specific named device or module that requires configuration 241 information to be installed. 243 The PEP may also have the capability to make a local policy decision 244 via its Local Decision Point (LDP) [WRK], however, the PDP remains 245 the authoritative decision point at all times. This means that the 246 relevant local decision information must be relayed to the PDP. That 247 is, the PDP must be granted access to all relevant information to 248 make a final policy decision. To facilitate this functionality, the 249 PEP must send its local decision information to the remote PDP via a 250 LDP decision object. The PEP must then abide by the PDP's decision 251 as it is absolute. 253 Finally, fault tolerance is a required capability for this protocol, 254 particularly due to the fact it is associated with the security and 255 service management of distributed network devices. Fault tolerance 256 can be achieved by having both the PEP and remote PDP constantly 257 verify their connection to each other via keep-alive messages. When 258 a failure is detected, the PEP must try to reconnect to the remote 259 PDP or attempt to connect to a backup/alternative PDP. While 260 disconnected, the PEP should revert to making local decisions. Once 261 a connection is reestablished, the PEP is expected to notify the PDP 262 of any deleted state or new events that passed local admission 263 control after the connection was lost. Additionally, the remote PDP 264 may request that all the PEP's internal state be resynchronized (all 265 previously installed requests are to be reissued). After failure and 266 before the new connection is fully functional, disruption of service 267 can be minimized if the PEP caches previously communicated decisions 268 and continues to use them for some limited amount of time. Sections 269 2.3 and 2.5 detail COPS mechanisms for achieving reliability. 271 2. The Protocol 273 This section describes the message formats and objects exchanged 274 between the PEP and remote PDP. 276 2.1 Common Header 278 Each COPS message consists of the COPS header followed by a number 279 of typed objects. 281 0 1 2 3 282 +--------------+--------------+--------------+--------------+ 283 |Version| Flags| Op Code | Client-type | 284 +--------------+--------------+--------------+--------------+ 285 | Message Length | 286 +--------------+--------------+--------------+--------------+ 288 Global note: //// implies field is reserved, set to 0. 290 The fields in the header are: 291 Version: 4 bits 292 COPS version number. Current version is 1. 294 Flags: 4 bits 295 Defined flag values (all other flags must be set to 0): 296 0x1 Solicited Message Flag Bit 297 This flag is set when the message is solicited by 298 another COPS message. This flag is NOT to be set 299 (value=0) unless otherwise specified in section 3. 301 Op Code: 8 bits 302 The COPS operations: 303 1 = Request (REQ) 304 2 = Decision (DEC) 305 3 = Report State (RPT) 306 4 = Delete Request State (DRQ) 307 5 = Synchronize State Req (SSQ) 308 6 = Client-Open (OPN) 309 7 = Client-Accept (CAT) 310 8 = Client-Close (CC) 311 9 = Keep-Alive (KA) 312 10= Synchronize Complete (SSC) 314 Client-type: 16 bits 316 The Client-type identifies the policy client. Interpretation of 317 all encapsulated objects is relative to the client-type. Client- 318 types that set the most significant bit in the client-type field 319 are enterprise specific (these are client-types 0x8000 - 320 0xFFFF). (See the specific client usage documents for particular 321 client-type IDs). For KA Messages, the client-type in the header 322 should always be set to 0 as the KA is used for connection 323 verification (not per client session verification). 325 Message Length: 32 bits 326 Size of message in octets, which includes the standard COPS 327 header and all encapsulated objects. Messages must be aligned on 328 4 octet intervals. 330 2.2 COPS Specific Object Formats 332 All the objects follow the same object format; each object consists 333 of one or more 32-bit words with a four-octet header, using the 334 following format: 336 0 1 2 3 337 +-------------+-------------+-------------+-------------+ 338 | Length (octets) | C-Num | C-Type | 339 +-------------+-------------+-------------+-------------+ 340 | | 341 // (Object contents) // 342 | | 343 +-------------+-------------+-------------+-------------+ 345 The length is a two-octet value that describes the number of octets 346 (including the header) that compose the object. If the length in 347 octets does not fall on a 32-bit word boundary, padding must be 348 added to the end of the object so that it is aligned to the next 32- 349 bit boundary before the object can be sent on the wire. On the 350 receiving side, a subsequent object boundary can be found by simply 351 rounding up the previous stated object length to the next 32-bit 352 boundary. 354 Typically, C-Num identifies the class of information contained in 355 the object, and the C-Type identifies the subtype or version of the 356 information contained in the object. 358 C-num: 8 bits 360 1 = Handle 361 2 = Context 362 3 = In Interface 363 4 = Out Interface 364 5 = Reason code 365 6 = Decision 366 7 = LDP Decision 367 8 = Error 368 9 = Client Specific Info 369 10 = Keep-Alive Timer 370 11 = PEP Identification 371 12 = Report Type 372 13 = PDP Redirect Address 373 14 = Last PDP Address 374 15 = Accounting Timer 376 C-type: 8 bits 377 Values defined per C-num. 379 2.2.1 Handle Object (Handle) 381 The Handle Object encapsulates a unique value that identifies an 382 installed state. This identification is used by most COPS 383 operations. A state corresponding to a handle must be explicitly 384 deleted when it is no longer applicable. See Section 2.4 for 385 details. 387 C-Num = 1 389 C-Type = 1, Client Handle. 391 Variable-length field, no implied format other than it is unique 392 from other client handles from the same PEP (a.k.a. COPS TCP 393 connection) for a particular client-type. It is always initially 394 chosen by the PEP and then deleted by the PEP when no longer 395 applicable. The client handle is used to refer to a request state 396 initiated by a particular PEP and installed at the PDP for a client- 397 type. A PEP will specify a client handle in its Request messages, 398 Report messages and Delete messages sent to the PDP. In all cases, 399 the client handle is used to uniquely identify a particular PEP's 400 request for a client-type. 402 The client handle value is set by the PEP and is opaque to the PDP. 403 The PDP simply performs a byte-wise comparison on the value in this 404 object with respect to the handle object values of other currently 405 installed requests. 407 2.2.2 Context Object (Context) 409 Specifies the type of event(s) that triggered the query. Required 410 for request messages. Admission control, resource allocation, and 411 forwarding requests are all amenable to client-types that outsource 412 their decision making facility to the PDP. For applicable client- 413 types a PEP can also make a request to receive named configuration 414 information from the PDP. This named configuration data may be in a 415 form useful for setting system attributes on a PEP, or it may be in 416 the form of policy rules that are to be directly verified by the 417 PEP. 419 Multiple flags can be set for the same request. This is only 420 allowed, however, if the set of client specific information in the 421 combined request is identical to the client specific information 422 that would be specified if individual requests were made for each 423 specified flag. 425 C-num = 2, C-Type = 1 427 0 1 2 3 428 +--------------+--------------+--------------+--------------+ 429 | R-Type | M-Type | 430 +--------------+--------------+--------------+--------------+ 432 R-Type (Request Type Flag) 434 0x01 = Incoming-Message/Admission Control request 435 0x02 = Resource-Allocation request 436 0x04 = Outgoing-Message request 437 0x08 = Configuration request 439 M-Type (Message Type) 441 Client Specific 16 bit values of protocol message types 443 2.2.3 In-Interface Object (IN-Int) 445 The In-Interface Object is used to identify the incoming interface 446 on which a particular request applies and the address where the 447 received message originated. For flows or messages generated from 448 the PEP's local host, the loop back address and ifindex are used. 450 This Interface object is also used to identify the incoming 451 (receiving) interface via its ifindex. The ifindex may be used to 452 differentiate between sub-interfaces and unnumbered interfaces (see 453 RSVP's LIH for an example). When SNMP is supported by the PEP, this 454 ifindex integer must correspond to the same integer value for the 455 interface in the SNMP MIB-II interface index table. 457 Note: The ifindex specified in the In-Interface is typically 458 relative to the flow of the underlying protocol messages. The 459 ifindex is the interface on which the protocol message was received. 461 C-Num = 3 463 C-Type = 1, IPv4 Address + Interface 464 0 1 2 3 465 +--------------+--------------+--------------+--------------+ 466 | IPv4 Address format | 467 +--------------+--------------+--------------+--------------+ 468 | ifindex | 469 +--------------+--------------+--------------+--------------+ 471 For this type of the interface object, the IPv4 address should 472 specify the IP address that the incoming message came from. 474 C-Type = 2, IPv6 Address + Interface 476 0 1 2 3 477 +--------------+--------------+--------------+--------------+ 478 | | 479 + + 480 | | 481 + IPv6 Address format + 482 | | 483 + + 484 | | 485 +--------------+--------------+--------------+--------------+ 486 | ifindex | 487 +--------------+--------------+--------------+--------------+ 489 For this type of the interface object, the IPv6 address should 490 specify the IP address that the incoming message came from. The 491 ifindex is used to refer to the MIB-II defined local incoming 492 interface on the PEP as described above. 494 2.2.4 Out-Interface Object (OUT-Int) 496 The Out-Interface is used to identify the outgoing interface to 497 which a specific request applies and the address for where the 498 forwarded message is to be sent. For flows or messages destined to 499 the PEP's local host, the loop back address and ifindex are used. 500 The Out-Interface has the same formats as the In-Interface Object. 502 This Interface object is also used to identify the outgoing 503 (forwarding) interface via its ifindex. The ifindex may be used to 504 differentiate between sub-interfaces and unnumbered interfaces (see 505 RSVP's LIH for an example). When SNMP is supported by the PEP, this 506 ifindex integer must correspond to the same integer value for the 507 interface in the SNMP MIB-II interface index table. 509 Note: The ifindex specified in the Out-Interface is typically 510 relative to the flow of the underlying protocol messages. The 511 ifindex is the one on which a protocol message is about to be 512 forwarded. 514 C-Num = 4 516 C-Type = 1, IPv4 Address + Interface 518 Same C-Type format as the In-Interface object. The IPv4 address 519 should specify the IP address to which the outgoing message is 520 going. The ifindex is used to refer to the MIB-II defined local 521 outgoing interface on the PEP. 523 C-Type = 2, IPv6 Address + Interface 525 Same C-Type format as the In-Interface object. For this type of the 526 interface object, the IPv6 address should specify the IP address to 527 which the outgoing message is going. The ifindex is used to refer to 528 the MIB-II defined local outgoing interface on the PEP. 530 2.2.5 Reason Object (Reason) 532 This object specifies the reason why the request state was deleted. 533 It should appear in the delete request (DRQ) message. The Reason 534 Sub-code field is reserved for more detailed client-specific reason 535 codes defined in the corresponding documents. 537 C-Num = 5, C-Type = 1 539 0 1 2 3 540 +--------------+--------------+--------------+--------------+ 541 | Reason-Code | Reason Sub-code | 542 +--------------+--------------+--------------+--------------+ 544 Reason Code: 545 1 = Unspecified 546 2 = Management 547 3 = Preempted (Another request state takes precedence) 548 4 = Tear (Used to communicate a signaled state removal) 549 5 = Timeout (Local state has timed-out) 550 6 = Route Change (Change invalidates request state) 551 7 = Insufficient Resources (No local resource available) 552 8 = PDP's Directive (PDP decision caused the delete) 553 9 = Unsupported decision (PDP decision not supported) 554 10= Synchronize Handle Unknown 555 11= Transient Handle (stateless event) 556 12= Malformed Decision (could not recover) 557 13= Unknown COPS Object from PDP: 558 Sub-code (octet 2) should contain unknown object's 559 C-Num and (octet 3) should contain unknown object's 560 C-Type. 562 2.2.6 Decision Object (Decision) 564 Decision made by the PDP. Must appear in replies. The specific non- 565 mandatory decision objects required in a decision to a particular 566 request depend on the type of client. 568 C-Num = 6 569 C-Type = 1, Decision Flags (Mandatory) 571 0 1 2 3 572 +--------------+--------------+--------------+--------------+ 573 | Command-Code | Flags | 574 +--------------+--------------+--------------+--------------+ 576 Commands: 577 0 = NULL Decision (No configuration data available) 578 1 = Install (Admit request/Install configuration) 579 2 = Remove (Remove request/Remove configuration) 581 Flags: 582 0x01 = Trigger Error (Trigger error message if set) 583 Note: Trigger Error is applicable to client-types that 584 are capable of sending error notifications for signaled 585 messages. 587 Flag values not applicable to a given context's R-Type or 588 client-type MUST be ignored by the PEP. 590 C-Type = 2, Stateless Data 592 This type of decision object carries additional stateless 593 information that can be applied by the PEP locally. It is a 594 variable length object and its internal format should be 595 specified in the relevant COPS extension document for the given 596 client-type. This object is optional in Decision messages and is 597 interpreted relative to a given context. 599 It is expected that even outsourcing PEPs will be able to make 600 some simple stateless policy decisions locally in their LDP. As 601 this set is well known and implemented ubiquitously, PDPs are 602 aware of it as well (either universally, through configuration, 603 or using the Client-Open message). The PDP may also include this 604 information in its decision, and the PEP should apply it to the 605 resource allocation event that generated the request. 607 C-Type = 3, Replacement Data 609 This type of decision object carries replacement data that is to 610 replace existing data in a signaled message. It is a variable 611 length object and its internal format should be specified in the 612 relevant COPS extension document for the given client-type. It 613 is optional in Decision messages and is interpreted relative to 614 a given context. 616 C-Type = 4, Client Specific Decision Data 618 Additional decision types can be introduced using the Client 619 Specific Decision Data Object. It is a variable length object 620 and its internal format should be specified in the relevant COPS 621 extension document for the given client-type. It is optional in 622 Decision messages and is interpreted relative to a given 623 context. 625 C-Type = 5, Named Decision Data 627 Named configuration information should be encapsulated in this 628 version of the decision object in response to configuration 629 requests. It is a variable length object and its internal format 630 should be specified in the relevant COPS extension document for 631 the given client-type. It is optional in Decision messages and 632 is interpreted relative to both a given context and decision 633 flags. 635 2.2.7 LDP Decision Object (LDPDecision) 637 Decision made by the PEP's local decision point (LDP). May appear in 638 requests. These objects correspond to and are formatted the same as 639 the client specific decision objects defined above. 641 C-Num = 7 643 C-Type = (same C-Type as for Decision objects) 645 2.2.8 Error Object (Error) 647 This object is used to identify a particular COPS protocol error. 648 The error sub-code field contains additional detailed client 649 specific error codes. The appropriate Error Sub-codes for a 650 particular client-type should be specified in the relevant COPS 651 extensions document. 653 C-Num = 8, C-Type = 1 655 0 1 2 3 656 +--------------+--------------+--------------+--------------+ 657 | Error-Code | Error Sub-code | 658 +--------------+--------------+--------------+--------------+ 660 Error-Code: 662 1 = Bad handle 663 2 = Invalid handle reference 664 3 = Bad message format (Malformed Message) 665 4 = Unable to process (server gives up on query) 666 5 = Mandatory client-specific info missing 667 6 = Unsupported client-type 668 7 = Mandatory COPS object missing 669 8 = Client Failure 670 9 = Communication Failure 671 10= Unspecified 672 11= Shutting down 673 12= Redirect to Preferred Server 674 13= Unknown COPS Object: 675 Sub-code (octet 2) should contain unknown object's 676 C-Num and (octet 3) should contain unknown object's 677 C-Type. 679 2.2.9 Client Specific Information Object (ClientSI) 681 The various types of this object are required for requests, and used 682 in reports and opens when required. It contains client-type specific 683 information. 685 C-Num = 9, 687 C-Type = 1, Signaled ClientSI. 689 Variable-length field. All objects/attributes specific to a client's 690 signaling protocol or internal state must be encapsulated within one 691 or more signaled Client Specific Information Objects. The format of 692 the data encapsulated in the ClientSI object is determined by the 693 client-type. 695 C-Type = 2, Named ClientSI. 697 Variable-length field. Contains named configuration information 698 useful for relaying specific information about the PEP, a request, 699 or configured state to the PDP server. 701 2.2.10 Keep-Alive Timer Object (KATimer) 703 Times are encoded as 2 octet integer values and are in units of 704 seconds. The timer value is treated as a delta. 706 C-Num = 10, 708 C-Type = 1, Keep-alive timer value 710 Timer object used to specify the maximum time interval over which a 711 COPS message must be sent or received. The range of finite timeouts 712 is 1 to 65535 seconds represented as an unsigned two-octet integer. 713 The value of zero implies infinity. 715 0 1 2 3 716 +--------------+--------------+--------------+--------------+ 717 | ////////////// | KA Timer Value | 718 +--------------+--------------+--------------+--------------+ 720 2.2.11 PEP Identification Object (PEPID) 722 The PEP Identification Object is used to identify the PEP client to 723 the remote PDP. It is required for Client-Open messages. 725 C-Num = 11, C-Type = 1 727 Variable-length field. It is a NULL terminated ASCII string that is 728 also zero padded to a 32-bit word boundary (so the object length is 729 a multiple of 4 octets). The PEPID must contain an ASCII string that 730 uniquely identifies the PEP within the policy domain in a manner 731 that is persistent across PEP reboots. For example, it may be the 732 PEP's statically assigned IP address or DNS name. This identifier 733 may safely be used by a PDP as a handle for identifying the PEP in 734 its policy rules. 736 2.2.12 Report-Type Object (Report-Type) 738 The Type of Report on the request state associated with a handle: 740 C-Num = 12, C-Type = 1 742 0 1 2 3 743 +--------------+--------------+--------------+--------------+ 744 | Report-Type | ///////////// | 745 +--------------+--------------+--------------+--------------+ 747 Report-Type: 748 1 = Commit : PEP's local resources now allocated 749 2 = No Commit : PEP's resource allocation failure 750 3 = Accounting: Accounting update for an installed state 751 4 = Installed : Admitted request/Installed configuration 752 5 = Removed : Removed request/Removed configuration 753 6 = NotInstall: Request/Configuration was not installed 754 7 = NotRemoved: Request/Configuration was not removed 756 2.2.13 PDP Redirect Address (PDPRedirAddr) 758 A PDP when closing a PEP session for a particular client-type may 759 optionally use this object to redirect the PEP to the specified PDP 760 server address and TCP port number: 762 C-Num = 13, 764 C-Type = 1, IPv4 Address + TCP Port 765 0 1 2 3 766 +--------------+--------------+--------------+--------------+ 767 | IPv4 Address format | 768 +--------------+--------------+--------------+--------------+ 769 | ///////////////////////// | TCP Port Number | 770 +-----------------------------+-----------------------------+ 772 C-Type = 2, IPv6 Address + TCP Port 773 0 1 2 3 774 +--------------+--------------+--------------+--------------+ 775 | | 776 + + 777 | | 778 + IPv6 Address format + 779 | | 780 + + 781 | | 782 +--------------+--------------+--------------+--------------+ 783 | ///////////////////////// | TCP Port Number | 784 +-----------------------------+-----------------------------+ 786 2.2.14 Last PDP Address (LastPDPAddr) 788 When a PEP sends a Client-Open message for a particular client-type 789 the PEP should specify the last PDP it has successfully opened 790 (meaning it received a Client-Accept) since the PEP last rebooted. 791 If no PDP was used since the last reboot, the PEP will simply not 792 include this object in the Client-Open message. 794 C-Num = 14, 796 C-Type = 1, IPv4 Address (Same format as PDPRedirAddr) 798 C-Type = 2, IPv6 Address (Same format as PDPRedirAddr) 800 2.2.15 Accounting Timer Object (AcctTimer) 802 Times are encoded as 2 octet integer values and are in units of 803 seconds. The timer value is treated as a delta. 805 C-Num = 15, 807 C-Type = 1, Accounting timer value 809 Optional timer value used to determine the minimum interval between 810 periodic accounting type reports. It is used by the PDP to describe 811 to the PEP an acceptable interval between unsolicited accounting 812 updates via Report messages where applicable. It provides a method 813 for the PDP to control the amount of accounting traffic seen by the 814 network. The range of finite time values is 1 to 65535 seconds 815 represented as an unsigned two-octet integer. A value of zero means 816 there should be no unsolicited accounting updates. 818 0 1 2 3 819 +--------------+--------------+--------------+--------------+ 820 | ////////////// | ACCT Timer Value | 821 +--------------+--------------+--------------+--------------+ 823 2.3 Communication 825 The COPS protocol uses a single persistent TCP connection between 826 the PEP and a remote PDP. One PDP implementation per server must 827 listen on a well-known TCP port number (COPS=3288 [IANA]). The PEP 828 is responsible for initiating the TCP connection to a PDP. The 829 location of the remote PDP can either be configured, or obtained via 830 a service location mechanism [SRVLOC]. Service discovery is outside 831 the scope of this protocol, however. 833 If a single PEP can support multiple client-types, it may send 834 multiple Client-Open messages, each specifying a particular client- 835 type to a PDP over one or more TCP connections. Likewise, a PDP 836 residing at a given address and port number may support one or more 837 client-types. Given the client-types it supports, a PDP has the 838 ability to either accept or reject each client-type independently. 839 If a client-type is rejected, the PDP can redirect the PEP to an 840 alternative PDP address and TCP port for a given client-type via 841 COPS. Different TCP port numbers can be used to redirect the PEP to 842 another PDP implementation running on the same server. Additional 843 provisions for supporting multiple client-types (perhaps from 844 independent PDP vendors) on a single remote PDP server are not 845 provided by the COPS protocol, but, rather, are left to the software 846 architecture of the given server platform. 848 It is possible a single PEP may have open connections to multiple 849 PDPs. This is the case when there are physically different PDPs 850 supporting different client-types as shown in figure 2. 852 +----------------+ 853 | | 854 | Network Node | Policy Servers 855 | | 856 | +-----+ | COPS Client Type 1 +-----+ 857 | | |<-----|-------------------->| PDP1| 858 | + PEP + | COPS Client Type 2 +-----+ 859 | | |<-----|---------\ +-----+ 860 | +-----+ | \----------| PDP2| 861 | ^ | +-----+ 862 | | | 863 | \-->+-----+ | 864 | | LDP | | 865 | +-----+ | 866 | | 867 +----------------+ 869 Figure 2: Multiple PDPs illustration. 871 When a TCP connection is torn down or is lost, the PDP is expected 872 to eventually clean up any outstanding request state related to 873 request/decision exchanges with the PEP. When the PEP detects a lost 874 connection due to a timeout condition it should explicitly send a 875 Client-Close message for each opened client-type containing an 876 object indicating the "Communication Failure" Error-Code. 877 Additionally, the PEP should continuously attempt to contact the 878 primary PDP or, if unsuccessful, any known backup PDPs. Specifically 879 the PEP should keep trying all relevant PDPs with which it has been 880 configured until it can establish a connection. If a PEP is in 881 communication with a backup PDP and the primary PDP becomes 882 available, the backup PDP is responsible for redirecting the PEP 883 back to the primary PDP (via a message containing a 884 object identifying the primary PDP to use for each 885 affected client-type). Section 2.5 details synchronization behavior 886 between PEPs and PDPs. 888 2.4 Client Handle Usage 890 The client handle is used to identify a unique request state for a 891 single PEP per client-type. Client handles are chosen by the PEP and 892 are opaque to the PDP. The PDP simply uses the request handle to 893 uniquely identify the request state for a particular Client-Type 894 over a particular TCP connection and generically tie its decisions 895 to a corresponding request. Client handles are initiated in request 896 messages and are then used by subsequent request, decision, and 897 report messages to reference the same request state. When the PEP is 898 ready to remove a local request state, it will issue a delete 899 message to the PDP for the corresponding client handle. A handle 900 MUST be explicitly deleted by the PEP before it can be used by the 901 PEP to identify a new request state. Handles referring to different 902 request states must be unique within the context of a particular TCP 903 connection and client-type. 905 2.5 Synchronization Behavior 907 When disconnected from a PDP, the PEP should revert to making local 908 decisions. Once a connection is reestablished, the PEP is expected 909 to notify the PDP of any events that have passed local admission 910 control. Additionally, the remote PDP may request that all the PEP's 911 internal state be resynchronized (all previously installed requests 912 are to be reissued) by sending a Synchronize State message. 914 After a failure and before a new connection is fully functional, 915 disruption of service can be minimized if the PEP caches previously 916 communicated decisions and continues to use them for some 917 appropriate length of time. Specific rules for such behavior are to 918 be defined in the appropriate COPS client-type extension 919 specifications. 921 A PEP that caches state from a previous exchange with a disconnected 922 PDP must communicate this fact to any PDP with which it is able to 923 later reconnect. This is accomplished by including the address and 924 TCP port of the last PDP for which the PEP is still caching state in 925 the Client-Open message. The object will only be 926 included for the last PDP with which the PEP was completely in sync. 927 If the service interruption was temporary and the PDP still contains 928 the complete state for the PEP, the PDP may choose not to 929 synchronize all states. It is still the responsibility of the PEP to 930 update the PDP of all state changes that occurred during the 931 disruption of service including any states communicated to the 932 previous PDP that had been deleted after the connection was lost. 933 These must be explicitly deleted after a connection is 934 reestablished. If the PDP issues a synchronize request the PEP must 935 pass all current states to the PDP followed by a Synchronize State 936 Complete message (thus completing the synchronization process). If 937 the PEP crashes and loses all cached state for a client-type, it 938 will simply not include a in its Client-Open message. 940 3. Message Content 942 This section describes the basic messages exchanged between a PEP 943 and a remote PDP as well as their contents. As a convention, object 944 ordering is expected as shown in the BNF for each COPS message 945 unless otherwise noted. Malformed messages are to be silently 946 dropped unless otherwise specified. 948 3.1 Request (REQ) PEP -> PDP 950 The PEP establishes a request state client handle for which the 951 remote PDP may maintain state. The remote PDP then uses this handle 952 to refer to the exchanged information and decisions communicated 953 over the TCP connection to a particular PEP for a given client-type. 955 Once a stateful handle is established for a new request, any 956 subsequent modifications of the request can be made using the REQ 957 message specifying the previously installed handle. The PEP is 958 responsible for notifying the PDP whenever its local state changes 959 so the PDP's state will be able to accurately mirror the PEP's 960 state. 962 The format of the Request message is as follows: 964 ::= 965 966 967 [] 968 [] 969 [] 970 [] 972 ::= | 974 ::= | 975 977 The context object is used to determine the context within which all 978 the other objects are to be interpreted. It also is used to 979 determine the kind of decision to be returned from the policy 980 server. This decision might be related to admission control, 981 resource allocation, object forwarding and substitution, or 982 configuration. 984 The interface objects are used to determine the corresponding 985 interface on which a signaling protocol message was received or is 986 about to be sent. They are typically used if the client is 987 participating along the path of a signaling protocol or if the 988 client is requesting configuration data for a particular interface. 990 ClientSI, the client specific information object, holds the client- 991 type specific data for which a policy decision needs to be made. In 992 the case of configuration, the Named ClientSI may include named 993 information about the module, interface, or functionality to be 994 configured. The ordering of multiple ClientSIs is not important. 996 Finally, LDPDecision object holds information regarding the local 997 decision made by the LDP. 999 3.2 Decision (DEC) PDP -> PEP 1001 The PDP responds to the REQ with a DEC message that includes the 1002 associated client handle and one or more decision objects grouped 1003 relative to a Context object and Decision Flags object type pair. If 1004 there was a protocol error an error object is returned instead. 1006 It is required that the first decision message for a new/updated 1007 request will have the solicited message flag set (value = 1) in the 1008 COPS header. This avoids the issue of keeping track of which updated 1009 request (that is, a request reissued for the same handle) a 1010 particular decision corresponds. It is important that, for a given 1011 handle, there be at most one outstanding solicited decision per 1012 request. This essentially means that the PEP should not issue more 1013 than one REQ (for a given handle) before it receives a corresponding 1014 DEC with the solicited message flag set. The PDP must always issue 1015 decisions for requests on a particular handle in the order they 1016 arrive and all requests must have a corresponding decision. 1018 To avoid deadlock, the PEP can always timeout after issuing a 1019 request that does not receive a decision. It must then delete the 1020 timed-out handle, and may try again using a new handle. 1022 The format of the Decision message is as follows: 1024 ::= 1025 1026 | 1028 ::= | 1030 ::= 1031 1032 [] 1033 [] 1034 [] 1035 [] 1037 The Decision message may include either an Error object or one or 1038 more context plus associated decision objects. COPS protocol 1039 problems are reported in the Error object (e.g. an error with the 1040 format of the original request including malformed request messages, 1041 unknown COPS objects in the Request, etc.). The applicable Decision 1042 object(s) depend on the context and the type of client. The only 1043 ordering requirement for decision objects is that the required 1044 Decision Flags object type must precede the other Decision object 1045 types per context binding. 1047 3.3 Report State (RPT) PEP -> PDP 1049 The RPT message is used by the PEP to communicate to the PDP its 1050 success or failure in carrying out the PDP's decision, or to report 1051 a change in state. The Report-Type specifies the kind of report and 1052 the optional ClientSI can carry additional information per Client- 1053 Type. 1055 The Report State may also be used to provide periodic updates of 1056 client specific information for accounting and state monitoring 1057 purposes depending on the type of the client. In such cases the 1058 accounting report type should be specified utilizing the appropriate 1059 client specific information object. 1061 ::== 1062 1063 1064 [] 1066 3.4 Delete Request State (DRQ) PEP -> PDP 1068 When sent from the PEP this message indicates to the remote PDP that 1069 the state identified by the client handle is no longer 1070 available/relevant. This information will then be used by the remote 1071 PDP to initiate the appropriate housekeeping actions. The reason 1072 code object is interpreted with respect to the client-type and 1073 signifies the reason for the removal. 1075 The format of the Delete Request State message is as follows: 1077 ::= 1078 1079 1081 Given the stateful nature of COPS, it is important that when a 1082 request state is finally removed from the PEP, a DRQ message for 1083 this request state is sent to the PDP so the corresponding state may 1084 likewise be removed on the PDP. Request states not explicitly 1085 deleted by the PEP will be maintained by the PDP until either the 1086 client session is closed or the connection is terminated. 1088 Malformed Decision messages should trigger a DRQ specifying the 1089 appropriate erroneous reason code (Bad Message Format) and any 1090 associated state on the PEP should either be removed or re- 1091 requested. If a Decision contained an unknown COPS Decision Object, 1092 the PEP must delete its request specifying the Unknown COPS Object 1093 reason code because the PEP will be unable to comply with the 1094 information contained in the unknown object. In any case, after 1095 issuing a DRQ, the PEP may retry the corresponding Request again. 1097 3.5 Synchronize State Request (SSQ) PDP -> PEP 1099 The format of the Synchronize State Query message is as follows: 1101 ::= 1102 [] 1104 This message indicates that the remote PDP wishes the client (which 1105 appears in the common header) to re-send its state. If the optional 1106 Client Handle is present, only the state associated with this handle 1107 is synchronized. If the PEP does not recognize the requested handle, 1108 it should immediately send a DRQ message to the PDP for the handle 1109 that was specified in the SSQ message. If no handle is specified in 1110 the SSQ message, all the active client state should be synchronized 1111 with the PDP. 1113 The client performs state synchronization by re-issuing request 1114 queries of the specified client-type for the existing state in the 1115 PEP. When synchronization is complete, the PEP must issue a 1116 synchronize state complete message to the PDP. 1118 3.6 Client-Open (OPN) PEP -> PDP 1120 The Client-Open message can be used by the PEP to specify to the PDP 1121 the client-types the PEP can support, the last PDP to which the PEP 1122 connected for the given client-type, and/or client specific feature 1123 negotiation. A Client-Open message can be sent to the PDP at any 1124 time and multiple Client-Open messages for the same client-type are 1125 allowed (in case of global state changes). 1127 ::= 1128 1129 [] 1130 [] 1132 The PEPID is a symbolic, variable length name that uniquely 1133 identifies the specific client to the PDP (see Section 2.2.11). 1135 A named ClientSI object can be included for relaying additional 1136 global information about the PEP to the PDP when required (as 1137 specified in the appropriate extensions document for the client- 1138 type). 1140 Finally, the PEP may provide a Last PDP Address object in its 1141 Client-Open message specifying the last PDP (for the given client- 1142 type) for which it is still caching decisions since its last reboot. 1144 A PDP can use this information to determine the appropriate 1145 synchronization behavior (See section 2.5). 1147 If the PEP specifies an unknown COPS object to the PDP via the 1148 Client-Open, the PDP must send back a Client-Close message 1149 specifying the Unknown COPS Object error code. 1151 3.7 Client-Accept (CAT) PDP -> PEP 1153 The Client-Accept message is used to positively respond to the 1154 Client-Open message. This message will return to the PEP a timer 1155 object indicating the maximum time interval between keep-alive 1156 messages. Optionally, a timer specifying the minimum allowed 1157 interval between accounting report messages may be included when 1158 applicable. 1160 ::= 1161 1162 [] 1164 If the PDP refuses the client, it will instead issue a Client-Close 1165 message. 1167 The KA Timer corresponds to maximum acceptable intermediate time 1168 between the generation of messages by the PDP and PEP. The timer 1169 value is determined by the PDP and is specified in seconds. A timer 1170 value of 0 implies no secondary connection verification is 1171 necessary. 1173 The optional ACCT Timer allows the PDP to indicate to the PEP that 1174 periodic accounting reports should not exceed the specified timer 1175 interval per client handle. This allows the PDP to control the rate 1176 at which accounting reports are sent by the PEP (when applicable). 1177 In general, accounting type Report messages are sent to the PDP when 1178 determined appropriate by the PEP. The accounting timer merely is 1179 used by the PDP to keep the rate of such updates in check (i.e. 1180 Preventing the PEP from blasting the PDP with accounting reports). 1181 Not including this object implies there are no PDP restrictions on 1182 the rate at which accounting updates are generated. 1184 If the PDP specifies an unknown COPS object to the PEP via the 1185 Client-Accept, the PEP must send back a Client-Close message 1186 specifying the Unknown COPS Object error code. The PEP should then 1187 retry its Client-Open for the client-type again. 1189 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP 1191 The Client-Close message can be issued by either the PDP or PEP to 1192 notify the other that a particular type of client is no longer being 1193 supported. 1195 ::= 1196 1197 [] 1199 The Error object is included to describe the reason for the close 1200 (e.g. the requested client-type is not supported by the remote PDP 1201 or client failure). 1203 A PDP may optionally include a PDP Redirect Address object in order 1204 to inform the PEP of the alternate PDP it should use for the client- 1205 type specified in the common header. 1207 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 1209 The keep-alive message must be transmitted by the PEP within the 1210 period defined by the minimum of all KA Timer values specified in 1211 all received CAT messages for the connection. A KA message must be 1212 generated randomly between 1/4 and 3/4 of this minimum KA timer 1213 interval. When the PDP receives a keep-alive message from a PEP, it 1214 must echo a keep-alive back to the PEP. This message provides 1215 validation for each side that the connection is still functioning 1216 even when there is no other messaging. 1218 Note: The client-type in the header should always be set to 0 as the 1219 KA is used for connection verification (not per client session 1220 verification). 1222 ::= 1224 Both client and server may assume the TCP connection is insufficient 1225 for the client-type with the minimum time value (specified in the 1226 CAT message) if no communication activity is detected for a period 1227 exceeding the timer period. For the PEP, such detection implies the 1228 remote PDP or connection is down and the PEP should now attempt to 1229 use an alternative/backup PDP. 1231 3.10 Synchronize State Complete (SSC) PEP -> PDP 1233 The Synchronize State Complete is sent by the PEP to the PDP after 1234 the PDP sends a synchronize state request to the PEP and the PEP has 1235 finished synchronization. It is useful so that the PDP will know 1236 when all the old client state has been successfully re-requested 1237 and, thus, the PEP and PDP are completely synchronized. 1239 ::= 1241 4. Common Operation 1243 This section describes the typical exchanges between remote PDP 1244 servers and PEP clients. 1246 4.1 PEP Initialization 1248 Sometime after a connection is established between the PEP and a 1249 remote PDP, the PEP will send one or more Client-Open messages to 1250 the remote PDP, one for each client-type supported by the PEP. The 1251 Client-Open message must contain the address of the last PDP with 1252 which the PEP is still caching a complete set of decisions. If no 1253 decisions are being cached from the previous PDP the LastPDPAddr 1254 object must not be included in the Client-Open message (see Section 1255 2.5). Each Client-Open message should at least contain the common 1256 header noting one client-type supported by the PEP. The remote PDP 1257 will then respond with separate Client-Accept messages for each of 1258 the client-types requested by the PEP that the PDP can also support. 1260 If a specific client-type is not supported by the PDP, the PDP will 1261 instead respond with a Client-Close specifying the client-type is 1262 not supported and will possibly suggest an alternate PDP address and 1263 port. Otherwise, the PDP will send a Client-Accept specifying the 1264 timer interval between keep-alive messages and the PEP may begin 1265 issuing requests to the PDP. 1267 4.2 Outsourcing Operations 1269 In the outsourcing scenario, when the PEP receives an event that 1270 requires a new policy decision it sends a request message to the 1271 remote PDP. What specifically qualifies as an event for a particular 1272 client-type should be specified in the specific document for that 1273 client-type. The remote PDP then makes a decision and sends a 1274 decision message back to the PEP. Since the request is stateful, the 1275 request will be remembered, or installed, on the remote PDP. The 1276 unique handle (unique per TCP connection and client-type), specified 1277 in both the request and its corresponding decision identifies this 1278 request state. The PEP is responsible for deleting this request 1279 state once the request is no longer applicable. 1281 The PEP can update a previously installed request state by reissuing 1282 a request for the previously installed handle. The remote PDP is 1283 then expected to make new decisions and send a decision message back 1284 to the PEP. Likewise, the server may change a previously issued 1285 decision on any currently installed request state at any time by 1286 issuing an unsolicited decision message. At all times the PEP module 1287 is expected to abide by the PDP's decisions and notify the PDP of 1288 any state changes. 1290 4.3 Configuration Operations 1292 In the configuration scenario, as in the outsourcing scenario, the 1293 PEP will make a configuration request to the PDP for a particular 1294 interface, module, or functionality that may be specified in the 1295 named client specific information object. The PDP will then send 1296 potentially several decisions containing named units of 1297 configuration data to the PEP. The PEP is expected to install and 1298 use the configuration locally. A particular named configuration can 1299 be updated by simply sending additional decision messages for the 1300 same named configuration. When the PDP no longer wishes the PEP to 1301 use a piece of configuration information, it will send a decision 1302 message specifying the named configuration and a decision flags 1303 object with the remove configuration command. The PEP should then 1304 proceed to remove the corresponding configuration and send a report 1305 message to the PDP that specifies it has been deleted. 1307 In all cases, the PEP may notify the remote PDP of the local status 1308 of an installed state using the report message where appropriate. 1309 The report message is to be used to signify when billing should 1310 begin, what actions were taken, or to produce periodic updates for 1311 monitoring and accounting purposes depending on the client. This 1312 message can carry client specific information when needed. 1314 4.4 Keep-Alive Operations 1316 The Keep-Alive message is used to validate the connection between 1317 the client and server is still functioning even when there is no 1318 other messaging from the PEP to PDP. The PEP must generate a COPS KA 1319 message randomly within one-fourth to three-fourths the minimum KA 1320 Timer interval specified by the PDP in the Client-Accept message. On 1321 receiving a Keep-Alive message from the PEP, the PDP must then 1322 respond to this Keep-Alive message by echoing a Keep-Alive message 1323 back to the PEP. If either side does not receive a Keep-Alive or any 1324 other COPS message within the minimum KA Timer interval from the 1325 other, the connection should be considered lost. 1327 4.5 PEP/PDP Close 1329 Finally, Client-Close messages are used to negate the effects of the 1330 corresponding Client-Open messages, notifying the other side that 1331 the specified client-type is no longer supported/active. When the 1332 PEP detects a lost connection due to a keep-alive timeout condition 1333 it should explicitly send a Client-Close message for each opened 1334 client-type specifying a communications failure error code. Then the 1335 PEP may proceed to terminate the connection to the PDP and attempt 1336 to reconnect again or try a backup/alternative PDP. When the PDP is 1337 shutting down, it should also explicitly send a Client-Close to all 1338 connected PEPs for each client-type, perhaps specifying an 1339 alternative PDP to use instead. 1341 5. Security Considerations 1343 The security of RSVP messages is provided by inter-router MD5 1344 authentication [MD5]. This assumes a chain-of-trust model for inter 1345 PEP authentication. Security between the client (PEP) and server 1346 (PDP) is provided by IPSEC [IPSEC]. 1348 To ensure the client (PEP) is communicating with the correct policy 1349 server (PDP) involves two issues: authentication of the policy 1350 client and server using a shared secret, and consistent proof that 1351 the connection remains valid. The shared secret requires manual 1352 configuration of keys, which is a maintenance issue. IPSEC AH may be 1353 used for the validation of the connection; IPSEC ESP may be used to 1354 provide both validation and secrecy. 1356 6. IANA Considerations 1358 The Client-type identifies the policy client application to which a 1359 message refers. Client-type values within the range 0x0000-0x3FFF 1360 are reserved Specification Required status as defined in [IANA- 1361 CONSIDERATIONS]. These values must be registered with IANA and their 1362 behavior and applicability must be described in a COPS extension 1363 document. 1365 Client-type values in the range 0x4000 - 0x7FFF are reserved for 1366 Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types 1367 are not tracked by IANA and are not to be used in standards or 1368 general-release products, as their uniqueness cannot be assured. 1370 Client-type values in the range 0x8000 - 0xFFFF are First Come First 1371 Served as defined in [IANA-CONSIDERATIONS]. These Client-types are 1372 tracked by IANA but do not require published documents describing 1373 their use. IANA merely assures their uniqueness. 1375 Objects in the COPS Protocol are identified by their C-Num and C- 1376 Type values. IETF Consensus as identified in [IANA-CONSIDERATIONS] 1377 is required to introduce new values for these numbers and, 1378 therefore, new objects into the base COPS protocol. 1380 Additional Context Object R-Types, Reason-Codes, Report-Types, 1381 Decision Object Command-Codes/Flags, and Error-Codes may be defined 1382 for use with future Client-types, but such additions require IETF 1383 Consensus as defined in [IANA-CONSIDERATIONS]. 1385 Context Object M-Types, Reason Sub-Codes, and Error Sub-codes may be 1386 defined relative to a particular Client-type following the same IANA 1387 considerations as their respective Client-type. 1389 7. References 1391 [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) 1392 Version 1 - Functional Specification", RFC 2205, September 1393 1997. 1395 [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission 1396 Control", Internet-Draft, draft-ietf-rap-framework-01.txt, 1397 November 1998. 1399 [SRVLOC]Guttman, E. et al., "Service Location Protocol , Version 2", 1400 Internet-Draft, draft-ietf-svrloc-protocol-v2-12.txt, 1401 February 1999. 1403 [INSCH] Shenker, S., Wroclawski, J., "General Characterization 1404 Parameters for Integrated Service Network Elements", RFC 1405 2215, September 1997. 1407 [IPSEC] Atkinson, R., "Security Architecture for the Internet 1408 Protocol", RFC1825, August 1995. 1410 [MD5] Baker, F., "RSVP Cryptographic Authentication", Internet- 1411 Draft, draft-ietf-rsvp-md5-05.txt, August 1997. 1413 [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) 1414 - Version 1 Message Processing Rules", RFC 2209, September 1415 1997. 1417 [IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers 1419 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 1420 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 1421 2434, October 1998. 1423 8. Author Information and Acknowledgments 1425 Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, 1426 Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch 1427 Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable 1428 contributions. 1430 Jim Boyle Ron Cohen 1431 Level 3 Communications Cisco Systems 1432 1450 Infinite Drive13 Hasadna St. 1433 Louisville, CO 80027 Ra'anana 43650 Israel 1434 303.926.3100 972.9.7462020 1435 email: jboyle@l3.net ronc@classdata.com 1437 David Durham Raju Rajan 1438 Intel IBM T.J. Watson Research Cntr 1439 2111 NE 25th Avenue P.O. Box 704 1440 Hillsboro, OR 97124 Yorktown Heights, NY 10598 1441 503.264.6232 914.784.7260 1442 David_Durham@mail.intel.com raju@watson.ibm.com 1444 Shai Herzog Arun Sastry 1445 IPHighway Cisco Systems 1446 2055 Gateway Pl., Suite 400 506210 W Tasman Drive 1447 San Jose, CA 95110 San Jose, CA 95134 1448 408.390.3045 408.526.7685 1449 herzog@iphighway.com asastry@cisco.com