idnits 2.17.1 draft-ietf-rap-cops-05.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-23) 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. == 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. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 572: '... client-type MUST be ignored by th...' RFC 2119 keyword, line 866: '...handle. A handle MUST be explicitly de...' 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 (January 18, 1999) is 9227 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 801, but not defined == Unused Reference: 'INSCH' is defined on line 1334, 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: 12 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Jim Boyle 2 Expiration: June 1999 Level 3 3 File: draft-ietf-rap-cops-05.txt Ron Cohen 4 Cisco 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 18, 1999 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 ftp.ietf.org, 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 1999. Distribution of this draft is 40 unlimited. 42 Status of this Memo................................................1 43 Abstract...........................................................3 44 1. Introduction....................................................3 45 1.1 Basic Model....................................................4 46 2. The Protocol....................................................7 47 2.1 Common Header..................................................7 48 2.2 COPS Specific Object Formats...................................8 49 2.2.1 Handle Object (Handle).......................................9 50 2.2.2 Context Object (Context).....................................9 51 2.2.3 In-Interface Object (IN-Int)................................10 52 2.2.4 Out-Interface Object (OUT-Int)..............................11 53 2.2.5 Reason Object (Reason)......................................12 54 2.2.6 Decision Object (Decision)..................................12 55 2.2.7 LDP Decision Object (LDPDecision)...........................14 56 2.2.8 Error Object (Error)........................................14 57 2.2.9 Client Specific Information Object (ClientSI)...............14 58 2.2.10 Keep-Alive Timer Object (KATimer)..........................15 59 2.2.11 PEP Identification Object (PEPID)..........................15 60 2.2.12 Report-Type Object (Report-Type)...........................15 61 2.2.13 PDP Redirect Address (PDPRedirAddr)........................16 62 2.2.14 Last PDP Address (LastPDPAddr).............................16 63 2.2.15 Accounting Timer Object (AcctTimer)........................17 64 2.3 Communication.................................................17 65 2.4 Client Handle Usage...........................................18 66 2.5 Synchronization Behavior......................................19 67 3. Message Content................................................20 68 3.1 Request (REQ) PEP -> PDP.....................................20 69 3.2 Decision (DEC) PDP -> PEP....................................21 70 3.3 Report State (RPT) PEP -> PDP................................22 71 3.4 Delete Request State (DRQ) PEP -> PDP........................22 72 3.5 Synchronize State Request (SSQ) PDP -> PEP...................23 73 3.6 Client-Open (OPN) PEP -> PDP.................................23 74 3.7 Client-Accept (CAT) PDP -> PEP...............................24 75 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP.....................24 76 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................25 77 3.10 Synchronize State Complete (SSC) PEP -> PDP..................25 78 4. Common Operation...............................................26 79 4.1 PEP Initialization............................................26 80 4.2 Outsourcing Operations........................................26 81 4.3 Configuration Operations......................................27 82 4.4 Keep-Alive Operations.........................................27 83 4.5 PEP/PDP Close.................................................27 84 5. Security.......................................................28 85 6. IANA Considerations............................................29 86 7. References.....................................................30 87 8. Author Information and Acknowledgments.........................31 89 Abstract 91 This document describes a simple client/server model for supporting 92 policy control over QoS Signaling Protocols and provisioned QoS 93 resource management. It is designed to be extensible so that other 94 kinds of policy clients may be supported in the future. The model 95 does not make any assumptions about the methods of the policy 96 server, but is based on the server returning decisions to policy 97 requests. 99 1. Introduction 101 This document describes a simple query and response protocol that 102 can be used to exchange policy information between a policy server 103 (Policy Decision Point or PDP) and its clients (Policy Enforcement 104 Points or PEPs). One example of a policy client is RSVP routers 105 that must exercise policy-based admission control over RSVP usage 106 [RSVP]. We assume that at least one policy server exists in each 107 controlled administrative domain. The basic model of interaction 108 between a policy server and its clients is compatible with 109 the framework document for policy based admission control [WRK]. 111 A chief objective of policy control protocol is to begin with a 112 simple but extensible design. The main characteristics of the COPS 113 protocol include: 115 1. The protocol employs a client/server model where the PEP 116 sends requests, updates, and deletes to the remote PDP and the 117 PDP returns decisions back to the PEP. 119 2. The protocol uses TCP as its transport protocol for reliable 120 exchange of messages between policy clients and a server. 121 Therefore, no additional mechanisms are necessary for reliable 122 communication between a server and its clients. 124 3. The protocol is extensible in that it is designed to leverage 125 off self-identifying objects and can support diverse client 126 specific information without requiring modifications to the COPS 127 protocol itself. The protocol was created for the general 128 administration, configuration, and enforcement of policies 129 whether signaled or provisioned. The protocol may be extended 130 for the administration of a variety of signaling protocols as 131 well as policy configuration on a device. 133 4. The protocol relies on existing protocols for security. 134 Namely IPSEC [IPSEC] can be used to authenticate and secure the 135 channel between the PEP and the server. 137 5. The protocol is stateful in two main aspects: 138 (1) Request/Decision state is shared between client and server 139 and (2) State from various events (Request/Decision pairs) may 140 be inter-associated. By (1) we mean that requests from the 141 client PEP are installed or remembered by the remote PDP until 142 they are explicitly deleted by the PEP. At the same time, 143 Decisions from the remote PDP can be generated asynchronously at 144 any time for a currently installed request state. By (2) we mean 145 that the server may respond to new queries differently because 146 of previously installed Request/Decision state(s) that are 147 related. 149 6. Additionally, the protocol is stateful in that it allows the 150 server to push configuration information to the client, and then 151 allows the server to remove such state from the client when it 152 is no longer applicable. 154 1.1 Basic Model 156 +----------------+ 157 | | 158 | Network Node | Policy Server 159 | | 160 | +-----+ | COPS +-----+ 161 | | PEP |<-----|-------------->| PDP | 162 | +-----+ | +-----+ 163 | ^ | 164 | | | 165 | \-->+-----+ | 166 | | LDP | | 167 | +-----+ | 168 | | 169 +----------------+ 171 Figure 1: A COPS illustration. 173 Figure 1 Illustrates the layout of various policy components in a 174 typical COPS example (taken from [WRK]). Here, COPS is used to 175 communicate policy information between a Policy Enforcement Point 176 (PEP) and a remote Policy Decision Point (PDP) within the context of 177 a particular type of client. 179 It is assumed that each participating policy client is functionally 180 consistent with a PEP [WRK]. The PEP may communicate with a policy 181 server (herein referred to as a remote PDP [WRK]) to obtain policy 182 decisions or directives. 184 The PEP is responsible for initiating a persistent TCP connection to 185 a PDP. The PEP uses this TCP connection to send requests to and 186 receive decisions from the remote PDP. Communication between the PEP 187 and remote PDP is mainly in the form of a stateful request/decision 188 exchange, though the remote PDP may occasionally send unsolicited 189 decisions to the PEP to force changes in previously approved request 190 states. The PEP also has the capacity to report to the remote PDP 191 that it has committed to an accepted request state for purposes of 192 accounting and monitoring. The PEP is responsible for notifying the 193 PDP when a request state has changed on the PEP. Finally, the PEP is 194 responsible for the deletion of any state that is no longer 195 applicable due to events at the client or decisions issued by the 196 server. 198 When the PEP sends a configuration request, it expects the PDP to 199 continuously send named units of configuration data to the PEP via 200 decision messages as applicable for the configuration request. When 201 a unit of named configuration data is successfully installed on the 202 PEP, the PEP should send a report message to the PDP confirming the 203 installation. The server may then update or remove the named 204 configuration information via a new decision message. When the PDP 205 sends a decision to remove named configuration data from the PEP, 206 the PEP will delete the specified configuration and send a report 207 message to the PDP as confirmation. 209 The policy protocol is designed to communicate self-identifying 210 objects which contain the data necessary for identifying request 211 states, establishing the context for a request, identifying the type 212 of request, referencing previously installed requests, relaying 213 policy decisions, reporting errors, and transferring client 214 specific/name space information. 216 To distinguish between different kinds of clients, the type of 217 client is identified in each message. Different types of clients may 218 have different client specific data and may require different kinds 219 of policy decisions. It is expected that each new client-type will 220 have a corresponding usage draft specifying the specifics of its 221 interaction with this policy protocol. 223 The context of each request corresponds to the type of event that 224 triggered it. COPS identifies three types of outsourcing events: (1) 225 the arrival of an incoming message (2) allocation of local 226 resources, and (3) the forwarding of an outgoing message. Each of 227 these events may require different decisions to be made. Context sub 228 types are also available to describe the type of message that 229 triggered the policy event. The content of a COPS request/decision 230 message depends on the context. A fourth type of request is useful 231 for types of clients that wish to receive configuration information 232 from the PDP. This allows a PEP to issue a configuration request for 233 a specific named device or module that requires configuration 234 information to be installed. 236 The PEP may also have the capability to make a local policy decision 237 via its Local Decision Point (LDP) [WRK], however, the PDP remains 238 the authoritative decision point at all times. This means that the 239 relevant local decision information must be relayed to the PDP. That 240 is, the PDP must be granted access to all relevant information to 241 make a final policy decision. To facilitate this functionality, the 242 PEP must send its local decision information to the remote PDP via a 243 LDP decision object. The PEP must then abide by the PDP's decision 244 as it is absolute. 246 Finally, fault tolerance is a required capability for this protocol, 247 particularly due to the fact it is associated with the security and 248 service management of distributed network devices. Fault tolerance 249 can be achieved by having both the PEP and remote PDP constantly 250 verify their connection to each other via keep-alive messages. When 251 a failure is detected, the PEP must try to reconnect to the remote 252 PDP or attempt to connect to a new/alternative PDP. While 253 disconnected, the PEP should revert to making local decisions. Once 254 a connection is reestablished, the PEP is expected to notify the PDP 255 of any deleted state or new events that passed local admission 256 control after the connection was lost. Additionally, the remote PDP 257 may request that all the PEP's internal state be resynchronized (all 258 previously installed requests are to be reissued). After failure and 259 before the new connection is fully functional, disruption of service 260 can be minimized if the PEP caches previously communicated decisions 261 and continues to use them for some limited amount of time. 263 2. The Protocol 265 This section describes the message formats and objects exchanged 266 between the PEP and remote PDP. 268 2.1 Common Header 270 Each COPS message consists of the COPS header followed by a number 271 of typed objects. 273 0 1 2 3 274 +--------------+--------------+--------------+--------------+ 275 |Version| Flags| Op Code | Client-type | 276 +--------------+--------------+--------------+--------------+ 277 | Message Length | 278 +--------------+--------------+--------------+--------------+ 280 Global note: //// implies field is reserved, set to 0. 282 The fields in the header are: 283 Version: 4 bits 284 COPS version number. Current version is 1. 286 Flags: 4 bits 287 Defined flag values (all other flags must be set to 0): 288 0x1 Solicited Message Flag Bit 289 This flag is set when the message is solicited by 290 another COPS message. This flag is NOT to be set 291 (value=0) unless otherwise specified in section 3. 293 Op Code: 8 bits 294 The COPS operations: 295 1 = Request (REQ) 296 2 = Decision (DEC) 297 3 = Report State (RPT) 298 4 = Delete Request State (DRQ) 299 5 = Synchronize State Req (SSQ) 300 6 = Client-Open (OPN) 301 7 = Client-Accept (CAT) 302 8 = Client-Close (CC) 303 9 = Keep-Alive (KA) 304 10= Synchronize Complete (SSC) 306 Client-type: 16 bits 308 The Client-type identifies the policy client. Interpretation of 309 all encapsulated objects is relative to the client-type. Client- 310 types that set the most significant bit in the client-type field 311 are enterprise specific (these are client-types 0x8000 - 312 0xFFFF). (See the specific client usage documents for particular 313 client-type IDs). For KA Messages, the client-type in the header 314 should always be set to 0 as the KA is used for connection 315 verification (not per client session verification). 317 Message Length: 32 bits 318 Size of message in octets, which includes the standard COPS 319 header and all encapsulated objects. Messages must be aligned on 320 4 octet intervals. 322 2.2 COPS Specific Object Formats 324 All the objects follow the same object format; each object consists 325 of one or more 32-bit words with a four-octet header, using the 326 following format: 328 0 1 2 3 329 +-------------+-------------+-------------+-------------+ 330 | Length (octets) | C-Num | C-Type | 331 +-------------+-------------+-------------+-------------+ 332 | | 333 // (Object contents) // 334 | | 335 +-------------+-------------+-------------+-------------+ 337 The length is a two-octet value that describes the number of octets 338 (including the header) that compose the object. If the length in 339 octets does not fall on a 32-bit word boundary, padding must be 340 added to the end of the object so that it is aligned to the next 32- 341 bit boundary before the object can be sent on the wire. On the 342 receiving side, a subsequent object boundary can be found by simply 343 rounding up the previous stated object length to the next 32-bit 344 boundary. 346 Typically, C-Num identifies the class of information contained in 347 the object, and the C-Type identifies the subtype or version of the 348 information contained in the object. 350 C-num: 8 bits 352 1 = Handle 353 2 = Context 354 3 = In Interface 355 4 = Out Interface 356 5 = Reason code 357 6 = Decision 358 7 = LDP Decision 359 8 = Error 360 9 = Client Specific Info 361 10 = Keep-Alive Timer 362 11 = PEP Identification 363 12 = Report Type 364 13 = PDP Redirect Address 365 14 = Last PDP Address 366 15 = Accounting Timer 368 C-type: 8 bits 369 Values defined per C-num. 371 2.2.1 Handle Object (Handle) 373 The Handle Object encapsulates a unique value that identifies an 374 installed state. This identification is used by most COPS 375 operations. A state corresponding to a handle must be explicitly 376 deleted when it is no longer applicable. 378 C-Num = 1 380 C-Type = 1, Client Handle. 382 Variable-length field, no implied format other than it is unique 383 from other client handles. It is always initially chosen by the PEP 384 and then deleted by the PEP when no longer applicable. The client 385 handle is used to refer to a request state initiated by the PEP and 386 installed at the PDP. A PEP will specify a client handle in its 387 Request messages, Report messages and Delete messages sent to the 388 PDP. In all cases, the client handle is used to uniquely identify 389 the PEP request. 391 The client handle value is set by the PEP and is opaque to the PDP. 392 The PDP simply performs a byte-wise comparison on the value in this 393 object with respect to the handle object values of other currently 394 installed requests. 396 2.2.2 Context Object (Context) 398 Specifies the type of event(s) that triggered the query. Required 399 for request messages. Admission control, resource allocation, and 400 forwarding requests are all amenable to client-types that outsource 401 their decision making facility to the PDP. For applicable client- 402 types a PEP can also make a request to receive named configuration 403 information from the PDP. This named configuration data may be in a 404 form useful for setting system attributes on a PEP, or it may be in 405 the form of policy rules that are to be directly verified by the 406 PEP. 408 Multiple flags can be set for the same request. This is only 409 allowed, however, if the set of client specific information in the 410 combined request is identical to the client specific information 411 that would be specified if individual requests were made for each 412 specified flag. 414 C-num = 2, C-Type = 1 415 0 1 2 3 416 +--------------+--------------+--------------+--------------+ 417 | R-Type | M-Type | 418 +--------------+--------------+--------------+--------------+ 420 R-Type (Request Type Flag) 422 0x01 = Incoming-Message/Admission Control request 423 0x02 = Resource-Allocation request 424 0x04 = Outgoing-Message request 425 0x08 = Configuration request 427 M-Type (Message Type) 429 Client Specific 16 bit values of protocol message types 431 2.2.3 In-Interface Object (IN-Int) 433 The In-Interface Object is used to identify the incoming interface 434 on which a particular request applies and the address where the 435 received message originated. For flows or messages generated from 436 the PEP's local host, the loop back address and ifindex are used. 438 This Interface object is also used to identify the incoming 439 (receiving) interface via its ifindex. The ifindex may be used to 440 differentiate between sub-interfaces and unnumbered interfaces (see 441 RSVP's LIH for an example). When SNMP is supported by the PEP, this 442 ifindex integer must correspond to the same integer value for the 443 interface in the SNMP MIB-II interface index table. 445 Note: The ifindex specified in the In-Interface is typically 446 relative to the flow of the underlying protocol messages. The 447 ifindex is the interface on which the protocol message was received. 449 C-Num = 3 451 C-Type = 1, IPv4 Address + Interface 452 0 1 2 3 453 +--------------+--------------+--------------+--------------+ 454 | IPv4 Address format | 455 +--------------+--------------+--------------+--------------+ 456 | ifindex | 457 +--------------+--------------+--------------+--------------+ 459 For this type of the interface object, the IPv4 address should 460 specify the IP address that the incoming message came from. 462 C-Type = 2, IPv6 Address + Interface 463 0 1 2 3 464 +--------------+--------------+--------------+--------------+ 465 | | 466 + + 467 | | 468 + IPv6 Address format + 469 | | 470 + + 471 | | 472 +--------------+--------------+--------------+--------------+ 473 | ifindex | 474 +--------------+--------------+--------------+--------------+ 476 For this type of the interface object, the IPv6 address should 477 specify the IP address that the incoming message came from. The 478 ifindex is used to refer to the MIB-II defined local incoming 479 interface on the PEP as described above. 481 2.2.4 Out-Interface Object (OUT-Int) 483 The Out-Interface is used to identify the outgoing interface to 484 which a specific request applies and the address for where the 485 forwarded message is to be sent. For flows or messages destined to 486 the PEP's local host, the loop back address and ifindex are used. 487 The Out-Interface has the same formats as the In-Interface Object. 489 This Interface object is also used to identify the outgoing 490 (forwarding) interface via its ifindex. The ifindex may be used to 491 differentiate between sub-interfaces and unnumbered interfaces (see 492 RSVP's LIH for an example). When SNMP is supported by the PEP, this 493 ifindex integer must correspond to the same integer value for the 494 interface in the SNMP MIB-II interface index table. 496 Note: The ifindex specified in the Out-Interface is typically 497 relative to the flow of the underlying protocol messages. The 498 ifindex is the one on which a protocol message is about to be 499 forwarded. 501 C-Num = 4 503 C-Type = 1, IPv4 Address + Interface 505 Same C-Type format as the In-Interface object. The IPv4 address 506 should specify the IP address to which the outgoing message is 507 going. The ifindex is used to refer to the MIB-II defined local 508 outgoing interface on the PEP. 510 C-Type = 2, IPv6 Address + Interface 512 Same C-Type format as the In-Interface object. For this type of the 513 interface object, the IPv6 address should specify the IP address to 514 which the outgoing message is going. The ifindex is used to refer to 515 the MIB-II defined local outgoing interface on the PEP. 517 2.2.5 Reason Object (Reason) 519 This object specifies the reason why the request state was deleted. 520 It should appear in the delete request (DRQ) message. The Reason 521 Sub-code field is reserved for more detailed client-specific reason 522 codes defined in the corresponding documents. 524 C-Num = 5, C-Type = 1 526 0 1 2 3 527 +--------------+--------------+--------------+--------------+ 528 | Reason-Code | Reason Sub-code | 529 +--------------+--------------+--------------+--------------+ 531 Reason Code: 532 1 = Unspecified 533 2 = Management 534 3 = Preempted (Another request state takes precedence) 535 4 = Tear (Used to communicate a signaled state removal) 536 5 = Timeout (Local state has timed-out) 537 6 = Route Change (Change invalidates request state) 538 7 = Insufficient Resources (No local resource available) 539 8 = PDP's Directive (PDP decision caused the delete) 540 9 = Unsupported decision (PDP decision not supported) 541 10= Synchronize Handle Unknown 542 11= Transient Handle (stateless event) 543 12= Malformed Decision (could not recover) 545 2.2.6 Decision Object (Decision) 547 Decision made by the PDP. Must appear in replies. The specific non- 548 mandatory decision objects required in a decision to a particular 549 request depend on the type of client. 551 C-Num = 6 553 C-Type = 1, Decision Flags (Mandatory) 555 0 1 2 3 556 +--------------+--------------+--------------+--------------+ 557 | Command-Code | Flags | 558 +--------------+--------------+--------------+--------------+ 560 Commands: 561 0 = NULL Decision (No configuration data available) 562 1 = Install (Admit request/Install configuration) 563 2 = Remove (Remove request/Remove configuration) 565 Flags: 566 0x01 = Trigger Error (Trigger error message if set) 567 Note: Trigger Error is applicable to client-types that 568 are capable of sending error notifications for signaled 569 messages. 571 Flag values not applicable to a given context's R-Type or 572 client-type MUST be ignored by the PEP. 574 C-Type = 2, Stateless Data 576 This type of decision object carries additional stateless 577 information that can be applied by the PEP locally. It is a 578 variable length object and its internal format should be 579 specified in the relevant COPS extension document for the given 580 client-type. This object is optional in Decision messages and is 581 interpreted relative to a given context. 583 It is expected that even outsourcing PEPs will be able to make 584 some simple stateless policy decisions locally in their LDP. As 585 this set is well known and implemented ubiquitously, PDPs are 586 aware of it as well (either universally, through configuration, 587 or using the Client-Open message). The PDP may also include this 588 information in its decision, and the PEP should apply it to the 589 resource allocation event that generated the request. 591 C-Type = 3, Replacement Data 593 This type of decision object carries replacement data that is to 594 replace existing data in a signaled message. It is a variable 595 length object and its internal format should be specified in the 596 relevant COPS extension document for the given client-type. It 597 is optional in Decision messages and is interpreted relative to 598 a given context. 600 C-Type = 4, Client Specific Decision Data 602 Additional decision types can be introduced using the Client 603 Specific Decision Data Object. It is a variable length object 604 and its internal format should be specified in the relevant COPS 605 extension document for the given client-type. It is optional in 606 Decision messages and is interpreted relative to a given 607 context. 609 C-Type = 5, Named Decision Data 611 Named configuration information should be encapsulated in this 612 version of the decision object in response to configuration 613 requests. It is a variable length object and its internal format 614 should be specified in the relevant COPS extension document for 615 the given client-type. It is optional in Decision messages and 616 is interpreted relative to both a given context and decision 617 flags. 619 2.2.7 LDP Decision Object (LDPDecision) 621 Decision made by the PEP's local decision point (LDP). May appear in 622 requests. These objects correspond to and are formatted the same as 623 the client specific decision objects defined above. 625 C-Num = 7 627 C-Type = (same C-Type as for Decision objects) 629 2.2.8 Error Object (Error) 631 This object is used to identify a particular COPS protocol error. 632 The error sub-code field contains additional detailed client 633 specific error codes. The appropriate Error Sub-codes for a 634 particular client-type should be specified in the relevant COPS 635 extensions document. 637 C-Num = 8, C-Type = 1 639 0 1 2 3 640 +--------------+--------------+--------------+--------------+ 641 | Error-Code | Error Sub-code | 642 +--------------+--------------+--------------+--------------+ 644 Error-Code: 646 1 = Bad handle 647 2 = Invalid handle reference 648 3 = Bad message format (Malformed Message) 649 4 = Unable to process (server gives up on query) 650 5 = Mandatory client-specific info missing 651 6 = Unsupported client-type 652 7 = Mandatory COPS object missing 653 8 = Client Failure 654 9 = Communication Failure 655 10= Unspecified 656 11= Shutting down 658 2.2.9 Client Specific Information Object (ClientSI) 660 The various types of this object are required for requests, and used 661 in reports and opens when required. It contains client-type specific 662 information. 664 C-Num = 9, 666 C-Type = 1, Signaled ClientSI. 668 Variable-length field. All objects/attributes specific to a client's 669 signaling protocol or internal state must be encapsulated within one 670 or more signaled Client Specific Information Objects. The format of 671 the data encapsulated in the ClientSI object is determined by the 672 client-type. 674 C-Type = 2, Named ClientSI. 676 Variable-length field. Contains named configuration information 677 useful for relaying specific information about the PEP, a request, 678 or configured state to the PDP server. 680 2.2.10 Keep-Alive Timer Object (KATimer) 682 Times are encoded as 2 octet integer values and are in units of 683 seconds. The timer value is treated as a delta. 685 C-Num = 10, 687 C-Type = 1, Keep-alive timer value 689 Timer object used to specify the maximum time interval over which a 690 COPS message must be sent or received. The value of zero implies 691 infinity. 693 0 1 2 3 694 +--------------+--------------+--------------+--------------+ 695 | ////////////// | KA Timer Value | 696 +--------------+--------------+--------------+--------------+ 698 2.2.11 PEP Identification Object (PEPID) 700 The PEP Identification Object is used to identify the PEP client to 701 the remote PDP. It is required for Client-Open messages. 703 C-Num = 11, C-Type = 1 705 Variable-length field. It is a NULL terminated ASCII string that is 706 also zero padded to a 32-bit word boundary (so the object length is 707 a multiple of 4 octets). The PEPID must contain an ASCII string that 708 uniquely identifies the PEP within the policy domain in a manner 709 that is persistent across PEP reboots. For example, it may be the 710 PEP's statically assigned IP address or DNS name. This identifier 711 may safely be used by a PDP as a handle for identifying the PEP in 712 its policy rules. 714 2.2.12 Report-Type Object (Report-Type) 716 The Type of Report on the request state associated with a handle: 718 C-Num = 12, C-Type = 1 720 0 1 2 3 721 +--------------+--------------+--------------+--------------+ 722 | Report-Type | ///////////// | 723 +--------------+--------------+--------------+--------------+ 725 Report-Type: 726 1 = Commit : PEP's local resources now allocated 727 2 = No Commit : PEP's resource allocation failure 728 3 = Accounting: Accounting update for an installed state 729 4 = Installed : Admitted request/Installed configuration 730 5 = Removed : Removed request/Removed configuration 731 6 = NotInstall: Request/Configuration was not installed 732 7 = NotRemoved: Request/Configuration was not removed 734 2.2.13 PDP Redirect Address (PDPRedirAddr) 736 A PDP when closing a PEP session for a particular client-type may 737 optionally use this object to redirect the PEP to another PDP 738 server: 740 C-Num = 13, 742 C-Type = 1, IPv4 Address (4 octets) 743 0 1 2 3 744 +--------------+--------------+--------------+--------------+ 745 | IPv4 Address format | 746 +--------------+--------------+--------------+--------------+ 748 C-Type = 2, IPv6 Address (16 octets) 749 0 1 2 3 750 +--------------+--------------+--------------+--------------+ 751 | | 752 + + 753 | | 754 + IPv6 Address format + 755 | | 756 + + 757 | | 758 +--------------+--------------+--------------+--------------+ 760 2.2.14 Last PDP Address (LastPDPAddr) 762 When a PEP sends a Client-Open message for a particular client-type 763 the PEP should specify the last PDP it has successfully opened 764 (meaning it received a Client-Accept) since the PEP last rebooted. 765 If no PDP was used since the last reboot, the PEP will simply not 766 include this object in the Client-Open message. 768 C-Num = 14, 770 C-Type = 1, IPv4 Address (Same format as PDPRedirAddr) 772 C-Type = 2, IPv6 Address (Same format as PDPRedirAddr) 774 2.2.15 Accounting Timer Object (AcctTimer) 776 Times are encoded as 2 octet integer values and are in units of 777 seconds. The timer value is treated as a delta. 779 C-Num = 15, 781 C-Type = 1, Accounting timer value 783 Optional timer value used to determine the minimum interval between 784 periodic accounting type reports. It is used by the PDP to describe 785 to the PEP an acceptable interval between accounting updates via 786 Report messages where applicable. The value of zero implies there 787 are no timing constraints on accounting updates. 789 0 1 2 3 790 +--------------+--------------+--------------+--------------+ 791 | ////////////// | ACCT Timer Value | 792 +--------------+--------------+--------------+--------------+ 794 2.3 Communication 796 The COPS protocol uses a single persistent TCP connection between 797 the PEP and a remote PDP. The remote PDP listens on a well-known 798 port number (COPS=3288 [IANA]), and the PEP is responsible for 799 initiating the connection. The location of the remote PDP can either 800 be configured, or obtained via a service location mechanism 801 [SRVLOC]. Service discovery is outside the scope of this protocol, 802 however. 804 If a single PEP can support multiple client-types, it may send 805 multiple Client-Open messages, each specifying a particular client- 806 type to a PDP over one or more TCP connections. Likewise, a PDP 807 residing at a given address may support one or more client-types. 808 Given the client-types it supports, a PDP has the ability to either 809 accept or reject each client-type independently. If a client-type is 810 rejected, the PDP can redirect the PEP to an alternative PDP for a 811 given client-type via COPS. Additional provisions for supporting 812 multiple client-types (perhaps from independent PDP vendors) on a 813 single remote PDP server are not provided by the COPS protocol, but, 814 rather, are left to the software architecture of the given server 815 platform. 817 It is possible a single PEP may have open connections to multiple 818 PDPs. This is the case when there are physically different PDPs 819 supporting different client-types as shown in figure 2. 821 +----------------+ 822 | | 823 | Network Node | Policy Servers 824 | | 825 | +-----+ | COPS Client Type 1 +-----+ 826 | | |<-----|-------------------->| PDP1| 827 | + PEP + | COPS Client Type 2 +-----+ 828 | | |<-----|---------\ +-----+ 829 | +-----+ | \----------| PDP2| 830 | ^ | +-----+ 831 | | | 832 | \-->+-----+ | 833 | | LDP | | 834 | +-----+ | 835 | | 836 +----------------+ 838 Figure 2: Multiple PDPs illustration. 840 When a TCP connection is torn down or is lost, the PDP is expected 841 to eventually clean up any outstanding request state related to 842 request/decision exchanges with the PEP. When the PEP detects a lost 843 connection due to a timeout condition it should explicitly send a 844 Client-Close message for each opened client-type containing an 845 object indicating the "Communication Failure" Error-Code. 846 Additionally, the PEP should continuously attempt to contact the 847 primary PDP or, if unsuccessful, any known backup PDPs. Specifically 848 the PEP should keep trying all relevant PDPs with which it has been 849 configured until it can establish a connection. If a PEP is in 850 communication with a backup PDP and the primary PDP becomes 851 available, the backup PDP is responsible for redirecting the PEP 852 back to the primary PDP (via a message containing a 853 object indicating the primary PDP to use for each 854 affected client-type). 856 2.4 Client Handle Usage 858 The client handle is used to identify a unique request state. Client 859 handles are chosen by the PEP and are opaque to the PDP. The PDP 860 simply uses the request handle to uniquely identify the request 861 state and generically tie its decisions to a corresponding request. 862 Client handles are initiated in request messages and are then used 863 by subsequent request, decision, and report messages to reference 864 the same request state. When the PEP is ready to remove a local 865 request state, it will issue a delete message to the PDP for the 866 corresponding client handle. A handle MUST be explicitly deleted by 867 the PEP before it can be used to identify a new request state. 868 Handles referring to different request states must be unique. 870 2.5 Synchronization Behavior 872 When disconnected from a PDP, the PEP should revert to making local 873 decisions. Once a connection is reestablished, the PEP is expected 874 to notify the PDP of any events that have passed local admission 875 control. Additionally, the remote PDP may request that all the PEP's 876 internal state be resynchronized (all previously installed requests 877 are to be reissued) by sending a Synchronize State message. 879 After a failure and before a new connection is fully functional, 880 disruption of service can be minimized if the PEP caches previously 881 communicated decisions and continues to use them for some 882 appropriate length of time. Specific rules for such behavior are to 883 be defined in the appropriate COPS client-type extension 884 specifications. 886 A PEP that caches state from a previous exchange with a disconnected 887 PDP must communicate this fact to any PDP with which it is able to 888 later reconnect. This is accomplished by including the address of 889 the last PDP for which the PEP is still caching state in the Client- 890 Open message. The object will only be included for the 891 last PDP with which the PEP was completely in sync. If the service 892 interruption was temporary and the PDP still contains the complete 893 state for the PEP, the PDP may choose not to synchronize all states. 894 It is still the responsibility of the PEP to update the PDP of all 895 state changes that occurred during the disruption of service 896 including any states communicated to the previous PDP that had been 897 deleted after the connection was lost. These must be explicitly 898 deleted after a connection is reestablished. If the PDP issues a 899 synchronize request the PEP must pass all current states to the PDP 900 followed by a Synchronize State Complete message (thus completing 901 the synchronization process). 903 3. Message Content 905 This section describes the basic messages exchanged between a PEP 906 and a remote PDP as well as their contents. As a convention, object 907 ordering is expected as shown in the BNF for each COPS message 908 unless otherwise noted. Malformed messages are to be silently 909 dropped unless otherwise specified. 911 3.1 Request (REQ) PEP -> PDP 913 The PEP establishes a request state client handle for which the 914 remote PDP may maintain a state. The remote PDP then uses this 915 handle to refer to the exchanged information and decisions. 917 Once a stateful handle is established for a new request, any 918 subsequent modifications of the request can be made using the REQ 919 message specifying the previously installed handle. The PEP is 920 responsible for notifying the PDP whenever its local state changes 921 so the PDP's state will be able to accurately mirror the PEP's 922 state. 924 The format of the Request message is as follows: 926 ::= 927 928 929 [] 930 [] 931 [] 932 [] 934 ::= | 936 ::= | 937 939 The context object is used to determine the context within which all 940 the other objects are to be interpreted. It also is used to 941 determine the kind of decision to be returned from the policy 942 server. This decision might be related to admission control, 943 resource allocation, object forwarding and substitution, or 944 configuration. 946 The interface objects are used to determine the corresponding 947 interface on which a signaling protocol message was received or is 948 about to be sent. They are typically used if the client is 949 participating along the path of a signaling protocol or if the 950 client is requesting configuration data for a particular interface. 952 ClientSI, the client specific information object, holds the client- 953 type specific data for which a policy decision needs to be made. In 954 the case of configuration, the Named ClientSI may include named 955 information about the module, interface, or functionality to be 956 configured. The ordering of multiple ClientSIs is not important. 958 Finally, LDPDecision object holds information regarding the local 959 decision made by the LDP. 961 3.2 Decision (DEC) PDP -> PEP 963 The PDP responds to the REQ with a DEC message that includes the 964 associated client handle and one or more decision objects grouped 965 relative to a Context object and Decision Flags object type pair. If 966 there was a protocol error an error object is returned instead. 968 It is required that the first decision message for a new/updated 969 request will have the solicited message flag set (value = 1) in the 970 COPS header. This avoids the issue of keeping track of which updated 971 request (that is, a request reissued for the same handle) a 972 particular decision corresponds. It is important that, for a given 973 handle, there be at most one outstanding solicited decision per 974 request. This essentially means that the PEP should not issue more 975 than one REQ (for a given handle) before it receives a corresponding 976 DEC with the solicited message flag set. 978 To avoid deadlock, the client can always timeout after issuing a 979 request. It must then delete the timed-out handle, and possibly try 980 again using a different (new) handle. 982 The format of the Decision message is as follows: 984 ::= 985 986 | 988 ::= | 990 ::= 991 992 [] 993 [] 994 [] 995 [] 997 The Decision message may include either an Error object or one or 998 more context plus associated decision objects. COPS protocol 999 problems are reported in the Error object (e.g. an error with the 1000 format of the original request, including malformed request 1001 messages). The applicable Decision object(s) depend on the context 1002 and the type of client. The only ordering requirement for decision 1003 objects is that the required Decision Flags object type must proceed 1004 the other Decision object types per context binding. 1006 3.3 Report State (RPT) PEP -> PDP 1008 This message is used by the PEP to communicate a change in the 1009 status of a previously installed state to the PDP. A commit or no- 1010 commit report-type indicates to the PDP that a particular policy 1011 directive has or has not been acted upon as is relevant for 1012 accounting purposes. (In RSVP this would mean that a reservation 1013 passed or failed local capacity admission control [RSVP]. For a 1014 configuration decision, it would mean the configuration identified 1015 in the ClientSI either could or could not be installed by the PEP). 1017 The Report State may also be used to provide periodic updates of 1018 client specific information for accounting and state monitoring 1019 purposes depending on the type of the client. In such cases the 1020 accounting report type should be specified utilizing the appropriate 1021 client specific information object. 1023 ::== 1024 1025 1026 [] 1028 3.4 Delete Request State (DRQ) PEP -> PDP 1030 When sent from the PEP this message indicates to the remote PDP that 1031 the state identified by the client handle is no longer 1032 available/relevant. This information will then be used by the remote 1033 PDP to initiate the appropriate housekeeping actions. The reason 1034 code object is interpreted with respect to the client-type and 1035 signifies the reason for the removal. 1037 The format of the Delete Request State message is as follows: 1039 ::= 1040 1041 1043 Given the stateful nature of COPS, it is important that when a 1044 request state is finally removed from the PEP, a DRQ message for 1045 this request state is sent to the PDP so the corresponding state may 1046 likewise be removed on the PDP. Request states not explicitly 1047 deleted by the PEP will be maintained by the PDP until either the 1048 client session is closed or the connection is terminated. 1050 Malformed Decision messages should trigger a DRQ specifying the 1051 appropriate erroneous reason code (Bad Message Format) and any 1052 associated state on the PEP should either be removed or re- 1053 requested. 1055 3.5 Synchronize State Request (SSQ) PDP -> PEP 1057 The format of the Synchronize State Query message is as follows: 1059 ::= 1060 [] 1062 This message indicates that the remote PDP wishes the client (which 1063 appears in the common header) to re-send its state. If the optional 1064 Client Handle is present, only the state associated with this handle 1065 is synchronized. If the PEP does not recognize the requested handle, 1066 it should immediately send a DRQ message to the PDP for the handle 1067 that was specified in the SSQ message. If no handle is specified in 1068 the SSQ message, all the active client state should be synchronized 1069 with the PDP. 1071 The client performs state synchronization by re-issuing request 1072 queries of the specified client-type for the existing state in the 1073 PEP. When synchronization is complete, the PEP must issue a 1074 synchronize state complete message to the PDP. 1076 3.6 Client-Open (OPN) PEP -> PDP 1078 The Client-Open message can be used by the PEP to specify to the PDP 1079 the client-types the PEP can support, the last PDP to which the PEP 1080 connected for the given client-type, and/or client specific feature 1081 negotiation. A Client-Open message can be sent to the PDP at any 1082 time and multiple Client-Open messages for the same client-type are 1083 allowed (in case of global state changes). 1085 ::= 1086 1087 [] 1088 [] 1090 The PEPID is a symbolic, variable length name that uniquely 1091 identifies the specific client to the PDP. 1093 A named ClientSI object can be included for relaying additional 1094 global information about the PEP to the PDP when required (as 1095 specified in the appropriate extensions document for the client- 1096 type). 1098 Finally, the PEP may provide a Last PDP Address object in its 1099 Client-Open message specifying the last PDP (for the given client- 1100 type) for which it is still caching decisions since its last reboot. 1101 A PDP can use this information to determine the appropriate 1102 synchronization behavior (See section 2.5). 1104 3.7 Client-Accept (CAT) PDP -> PEP 1106 The Client-Accept message is used to positively respond to the 1107 Client-Open message. This message will return to the PEP a timer 1108 object indicating the maximum time interval between keep-alive 1109 messages. Optionally, a timer specifying the minimum allowed 1110 interval between accounting report messages may be included when 1111 applicable. 1113 ::= 1114 1115 [] 1117 If the PDP refuses the client, it will instead issue a Client-Close 1118 message. 1120 The KA Timer corresponds to maximum acceptable intermediate time 1121 between the generation of messages by the PDP and PEP. The timer 1122 value is determined by the PDP and is specified in seconds. A timer 1123 value of 0 implies no secondary connection verification is 1124 necessary. 1126 The optional accounting timer allows the PDP to indicate to the PEP 1127 that periodic accounting reports should not exceed the specified 1128 timer interval. This allows the PDP to control the rate at which 1129 accounting reports are sent by the PEP (when applicable). In 1130 general, accounting type Report messages are sent to the PDP when 1131 determined appropriate by the PEP. The accounting timer merely is 1132 used by the PDP to keep the rate of such updates in check (i.e. 1133 Preventing the PEP from blasting the PDP with accounting reports). 1135 3.8 Client-Close (CC) PEP -> PDP, PDP -> PEP 1137 The Client-Close message can be issued by either the PDP or PEP to 1138 notify the other that a particular type of client is no longer being 1139 supported. 1141 ::= 1142 1143 [] 1145 The Error object is included to describe the reason for the close 1146 (e.g. the requested client-type is not supported by the remote PDP 1147 or client failure). 1149 A PDP may optionally include a PDP Redirect Address object in order 1150 to inform the PEP of the alternate PDP it should use for the client- 1151 type specified in the common header. 1153 3.9 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 1155 The keep-alive message must be transmitted by the PEP within the 1156 period defined by the minimum of all KA Timer values specified in 1157 all received CAT messages for the connection. A KA message must be 1158 generated randomly between 1/4 and 3/4 of this minimum TA timer 1159 interval. When the PDP receives a keep-alive message from a PEP, it 1160 must echo a keep-alive back to the PEP. This message provides 1161 validation for each side that the connection is still functioning 1162 even when there is no other messaging. 1164 Note: The client-type in the header should always be set to 0 as the 1165 KA is used for connection verification (not per client session 1166 verification). 1168 ::= 1170 Both client and server may assume the TCP connection is insufficient 1171 for the client-type with the minimum time value (specified in the 1172 CAT message) if no communication activity is detected for a period 1173 exceeding the timer period. For the PEP, such detection implies the 1174 remote PDP or connection is down and the PEP should now attempt to 1175 use an alternative/backup PDP. 1177 3.10 Synchronize State Complete (SSC) PEP -> PDP 1179 The Synchronize State Complete is sent by the PEP to the PDP after 1180 the PDP sends a synchronize state request to the PEP and the PEP has 1181 finished synchronization. It is useful so that the PDP will know 1182 when all the old client state has been successfully re-requested 1183 and, thus, the PEP and PDP are completely synchronized. 1185 ::= 1187 4. Common Operation 1189 This section describes the typical exchanges between remote PDP 1190 servers and PEP clients. 1192 4.1 PEP Initialization 1194 Sometime after a connection is established between the PEP and a 1195 remote PDP, the PEP will send one or more Client-Open messages to 1196 the remote PDP, one for each client-type supported by the PEP. The 1197 Client-Open message must contain the address of the last PDP with 1198 which the PEP is still caching a complete set of decisions. If no 1199 decisions are being cached from the previous PDP the LastPDPAddr 1200 object must not be included in the Client-Open message (see Section 1201 2.5). Each Client-Open message should at least contain the common 1202 header noting one client-type supported by the PEP. The remote PDP 1203 will then respond with separate Client-Accept messages for each of 1204 the client-types requested by the PEP that the PDP can also support. 1206 If a specific client-type is not supported by the PDP, the PDP will 1207 instead respond with a Client-Close specifying the client-type is 1208 not supported and will possibly suggest an alternate PDP address. 1209 Otherwise, the PDP will send a Client-Accept specifying the timer 1210 interval between keep-alive messages and the PEP may begin issuing 1211 requests to the PDP. 1213 4.2 Outsourcing Operations 1215 In the outsourcing scenario, when the PEP receives an event that 1216 requires a new policy decision it sends a request message to the 1217 remote PDP. What specifically qualifies as an event for a particular 1218 client-type should be specified in the specific document for that 1219 client-type. The remote PDP then makes a decision and sends a 1220 decision message back to the PEP. Since the request is stateful, the 1221 request will be remembered, or installed, on the remote PDP. The 1222 unique handle, specified in both the request and its corresponding 1223 decision identifies this request state. The PEP is responsible for 1224 deleting this request state once the request is no longer 1225 applicable. 1227 The PEP can update a previously installed request state by reissuing 1228 a request for the previously installed handle. The remote PDP is 1229 then expected to make new decisions and send a decision message back 1230 to the PEP. Likewise, the server may change a previously issued 1231 decision on any currently installed request state at any time by 1232 issuing another decision message. At all times the PEP module is 1233 expected to abide by the PDP's decisions and notify the PDP of any 1234 state changes. 1236 4.3 Configuration Operations 1238 In the configuration scenario, as in the outsourcing scenario, the 1239 PEP will make a configuration request to the PDP for a particular 1240 interface, module, or functionality that may be specified in the 1241 named client specific information object. The PDP will then send 1242 potentially several decisions containing named units of 1243 configuration data to the PEP. The PEP is expected to install and 1244 use the configuration locally. A particular named configuration can 1245 be updated by simply sending additional decision messages for the 1246 same named configuration. When the PDP no longer wishes the PEP to 1247 use a piece of configuration information, it will send a decision 1248 message specifying the named configuration and a decision flags 1249 object with the remove configuration command. The PEP should then 1250 proceed to remove the corresponding configuration and send a report 1251 message to the PDP that specifies it has been deleted. 1253 In all cases, the PEP may notify the remote PDP of the local status 1254 of an installed state using the report message where appropriate. 1255 The report message is to be used to signify when billing should 1256 begin, what actions were taken, or to produce periodic updates for 1257 monitoring and accounting purposes depending on the client. This 1258 message can carry client specific information when needed. 1260 4.4 Keep-Alive Operations 1262 The Keep-Alive message is used to validate the connection between 1263 the client and server is still functioning even when there is no 1264 other messaging from the PEP to PDP. The PEP must generate a COPS KA 1265 message randomly within one-fourth to three-fourths the negotiated 1266 minimum KA Timer interval. On receiving a Keep-Alive message from 1267 the PEP, the PDP must then respond to this Keep-Alive message by 1268 echoing a Keep-Alive message back to the PEP. If either side does 1269 not receive a Keep-Alive or any other COPS message within the 1270 minimum KA Timer interval from the other, the connection should be 1271 considered lost. 1273 4.5 PEP/PDP Close 1275 Finally, Client-Close messages are used to negate the effects of the 1276 corresponding Client-Open messages, notifying the other side that 1277 the specified client-type is no longer supported/active. When the 1278 PEP detects a lost connection due to a keep-alive timeout condition 1279 it should explicitly send a Client-Close message for each opened 1280 client-type specifying a communications failure error code. Then the 1281 PEP may proceed to terminate the connection to the PDP and attempt 1282 to reconnect again or try a backup/alternative PDP. When the PDP is 1283 shutting down, it should also explicitly send a Client-Close to all 1284 connected PEPs for each client-type, perhaps specifying an 1285 alternative PDP to use instead. 1287 5. Security 1289 The security of RSVP messages is provided by inter-router MD5 1290 authentication [MD5]. This assumes a chain-of-trust model for inter 1291 PEP authentication. Security between the client (PEP) and server 1292 (PDP) is provided by IPSEC [IPSEC]. 1294 To ensure the client (PEP) is communicating with the correct policy 1295 server (PDP) involves two issues: authentication of the policy 1296 client and server using a shared secret, and consistent proof that 1297 the connection remains valid. The shared secret requires manual 1298 configuration of keys, which is a maintenance issue. IPSEC AH may be 1299 used for the validation of the connection; IPSEC ESP may be used to 1300 provide both validation and secrecy. 1302 6. IANA Considerations 1304 The Client-type identifies the policy client application to which a 1305 message refers. Client-type values within the range 0x0000-0x3FFF 1306 are reserved Specification Required status as defined in [IANA- 1307 CONSIDERATIONS]. These values must be registered with IANA and their 1308 behavior and applicability must be described in a COPS extension 1309 document. 1311 Client-type values in the range 0x4000 - 0x7FFF are reserved for 1312 Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types 1313 are not tracked by IANA and are not to be used in standards or 1314 general-release products, as their uniqueness cannot be assured. 1316 Client-type values in the range 0x8000 - 0xFFFF are First Come First 1317 Served as defined in [IANA-CONSIDERATIONS]. These Client-types are 1318 tracked by IANA but do not require published documents describing 1319 their use. IANA merely assures their uniqueness. 1321 7. References 1323 [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) 1324 Version 1 - Functional Specification", RFC 2205, September 1325 1997. 1327 [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission 1328 Control", Internet-Draft, draft-ietf-rap-framework-01.txt, 1329 November 1998. 1331 [SRVLOC]Guttman, E. et al., "Service Location Protocol", Internet- 1332 Draft, draft-ietf-svrloc-protocol-v2-01.txt, October 1997. 1334 [INSCH] Shenker, S., Wroclawski, J., "General Characterization 1335 Parameters for Integrated Service Network Elements", RFC 1336 2215, September 1997. 1338 [IPSEC] Atkinson, R., "Security Architecture for the Internet 1339 Protocol", RFC1825, August 1995. 1341 [MD5] Baker, F., "RSVP Cryptographic Authentication", Internet- 1342 Draft, draft-ietf-rsvp-md5-05.txt, August 1997. 1344 [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) 1345 - Version 1 Message Processing Rules", RFC 2209, September 1346 1997. 1348 [IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers 1350 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 1351 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 1352 2434, October 1998. 1354 8. Author Information and Acknowledgments 1356 Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, 1357 Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch 1358 Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable 1359 contributions. 1361 Jim Boyle Ron Cohen 1362 Level 3 Communications Cisco Systems 1363 1450 Infinite Drive13 Hasadna St. 1364 Louisville, CO 80027 Ra'anana 43650 Israel 1365 303.926.3100 972.9.7462020 1366 email: jboyle@l3.net ronc@classdata.com 1368 David Durham Raju Rajan 1369 Intel IBM T.J. Watson Research Cntr 1370 2111 NE 25th Avenue P.O. Box 704 1371 Hillsboro, OR 97124 Yorktown Heights, NY 10598 1372 503.264.6232 914.784.7260 1373 David_Durham@mail.intel.com raju@watson.ibm.com 1375 Shai Herzog Arun Sastry 1376 IPHighway Cisco Systems 1377 2055 Gateway Pl., Suite 400 506210 W Tasman Drive 1378 San Jose, CA 95110 San Jose, CA 95134 1379 408.390.3045 408.526.7685 1380 herzog@iphighway.com asastry@cisco.com