idnits 2.17.1 draft-ietf-rap-cops-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-26) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 568: '...le to a given context's R-Type MUST be...' RFC 2119 keyword, line 883: '...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 (December 18, 1998) is 9261 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 817, but not defined == Unused Reference: 'INSCH' is defined on line 1351, 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: May 1999 Level 3 3 File: draft-ietf-rap-cops-04.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: December 18, 1998 18 Status of this Memo 20 This document is an Internet Draft. Internet Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its Areas, 22 and its Working Groups. Note that other groups may also distribute 23 working documents as Internet Drafts. 25 Internet Drafts are draft documents valid for a maximum of six 26 months. Internet Drafts may be updated, replaced, or obsoleted by 27 other documents at any time. It is not appropriate to use Internet 28 Drafts as reference material or to cite them other than as a 29 "working draft" or "work in progress". 31 To learn the current status of any Internet-Draft, please check the 32 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 33 Directories on 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 May 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)......................................11 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)...............15 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)...........................16 61 2.2.13 PDP Redirect Address (PDPRedirAddr)........................16 62 2.2.14 Last PDP Address (LastPDPAddr).............................17 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 Keep-Alive (KA) PEP -> PDP, PDP -> PEP.......................24 76 3.9 Client-Close (CC) 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| //// | 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 Op Code: 8 bits 287 The COPS operations: 288 1 = Request (REQ) 289 2 = Decision (DEC) 290 4 = Report State (RPT) 291 5 = Delete Request State (DRQ) 292 6 = Synchronize State Req (SSQ) 293 7 = Client-Open (OPN) 294 8 = Client-Accept (CAT) 295 9 = Keep-Alive (KA) 296 10= Client-Close (CC) 297 11= Synchronize Complete (SSC) 299 Client-type: 16 bits 301 The Client-type identifies the policy client. Interpretation of 302 all encapsulated objects is relative to the client-type. Client- 303 types that set the most significant bit in the client-type field 304 are enterprise specific (these are client-types 0x8000 - 305 0xFFFF). (See the specific client usage documents for particular 306 client-type IDs). For KA Messages, the client-type in the header 307 should always be set to 0 as the KA is used for connection 308 verification (not per client session verification). 310 Message Length: 32 bits 311 Size of message in octets, which includes the standard COPS 312 header and all encapsulated objects. Messages must be aligned on 313 4 octet intervals. 315 2.2 COPS Specific Object Formats 317 All the objects follow the same object format; each object consists 318 of one or more 32-bit words with a four-octet header, using the 319 following format: 321 0 1 2 3 322 +-------------+-------------+-------------+-------------+ 323 | Length (octets) | C-Num | C-Type | 324 +-------------+-------------+-------------+-------------+ 325 | | 326 // (Object contents) // 327 | | 328 +-------------+-------------+-------------+-------------+ 330 The length is a two-octet value that describes the number of octets 331 (including the header) that compose the object. If the length in 332 octets does not fall on a 32-bit word boundary, padding must be 333 added to the end of the object so that it is aligned to the next 32- 334 bit boundary before the object can be sent on the wire. On the 335 receiving side, a subsequent object boundary can be found by simply 336 rounding up the previous stated object length to the next 32-bit 337 boundary. 339 Typically, C-Num identifies the class of information contained in 340 the object, and the C-Type identifies the subtype or version of the 341 information contained in the object. 343 C-num: 8 bits 345 1 = Handle 346 3 = Context 347 4 = In Interface 348 5 = Out Interface 349 6 = Reason code 350 7 = Decision 351 8 = LDP Decision 352 9 = Error 353 10 = Client Specific Info 354 11 = Keep-Alive Timer 355 12 = PEP Identification 356 13 = Report Type 357 14 = PDP Redirect Address 358 15 = Last PDP Address 359 16 = Accounting Timer 361 C-type: 8 bits 362 Values defined per C-num. 364 2.2.1 Handle Object (Handle) 366 The Handle Object encapsulates a unique value that identifies an 367 installed state. This identification is used by most COPS 368 operations. A state corresponding to a handle must be explicitly 369 deleted when it is no longer applicable. 371 C-Num = 1 373 C-Type = 1, Client Handle. 375 Variable-length field, no implied format other than it is unique 376 from other client handles. It is always initially chosen by the PEP 377 and then deleted by the PEP when no longer applicable. The client 378 handle is used to refer to a request state initiated by the PEP and 379 installed at the PDP. A PEP will specify a client handle in its 380 Request messages, Report messages and Delete messages sent to the 381 PDP. In all cases, the client handle is used to uniquely identify 382 the PEP request. 384 The client handle value is set by the PEP and is opaque to the PDP. 385 The PDP simply performs a byte-wise comparison on the value in this 386 object with respect to the handle object values of other currently 387 installed requests. 389 2.2.2 Context Object (Context) 391 Specifies the type of event(s) that triggered the query. Required 392 for request messages. Admission control, resource allocation, and 393 forwarding requests are all amenable to client-types that outsource 394 their decision making facility to the PDP. For applicable client- 395 types a PEP can also make a request to receive named configuration 396 information from the PDP. This named configuration data may be in a 397 form useful for setting system attributes on a PEP, or it may be in 398 the form of policy rules that are to be directly verified by the 399 PEP. 401 Multiple flags can be set for the same request. This is only 402 allowed, however, if the set of client specific information in the 403 combined request is identical to the client specific information 404 that would be specified if individual requests were made for each 405 specified flag. 407 C-num = 3, C-Type = 1 409 0 1 2 3 410 +--------------+--------------+--------------+--------------+ 411 | R-Type | M-Type | 412 +--------------+--------------+--------------+--------------+ 414 R-Type (Request Type Flag) 416 0x01 = Incoming-Message/Admission Control request 417 0x02 = Resource-Allocation request 418 0x04 = Outgoing-Message request 419 0x08 = Configuration request 421 M-Type (Message Type) 423 Client Specific 16 bit values of protocol message types 425 2.2.3 In-Interface Object (IN-Int) 427 The In-Interface Object is used to identify the incoming interface 428 on which a particular request applies and the address where the 429 received message originated. For flows or messages generated from 430 the PEP's local host, the loop back address and ifindex are used. 432 This Interface object is also used to identify the incoming 433 (receiving) interface via its ifindex. The ifindex may be used to 434 differentiate between sub-interfaces and unnumbered interfaces (see 435 RSVP's LIH for an example). When SNMP is supported by the PEP, this 436 ifindex integer must correspond to the same integer value for the 437 interface in the SNMP MIB-II interface index table. 439 Note: The ifindex specified in the In-Interface is typically 440 relative to the flow of the underlying protocol messages. The 441 ifindex is the interface on which the protocol message was received. 443 C-Num = 4 445 C-Type = 1, IPv4 Address + Interface 446 0 1 2 3 447 +--------------+--------------+--------------+--------------+ 448 | IPv4 Address format | 449 +--------------+--------------+--------------+--------------+ 450 | ifindex | 451 +--------------+--------------+--------------+--------------+ 453 For this type of the interface object, the IPv4 address should 454 specify the IP address that the incoming message came from. 456 C-Type = 2, IPv6 Address + Interface 457 0 1 2 3 458 +--------------+--------------+--------------+--------------+ 459 | | 460 + + 461 | | 462 + IPv6 Address format + 463 | | 464 + + 465 | | 466 +--------------+--------------+--------------+--------------+ 467 | ifindex | 468 +--------------+--------------+--------------+--------------+ 470 For this type of the interface object, the IPv6 address should 471 specify the IP address that the incoming message came from. The 472 ifindex is used to refer to the MIB-II defined local incoming 473 interface on the PEP as described above. 475 2.2.4 Out-Interface Object (OUT-Int) 477 The Out-Interface is used to identify the outgoing interface to 478 which a specific request applies and the address for where the 479 forwarded message is to be sent. For flows or messages destined to 480 the PEP's local host, the loop back address and ifindex are used. 481 The Out-Interface has the same formats as the In-Interface Object. 483 This Interface object is also used to identify the outgoing 484 (forwarding) interface via its ifindex. The ifindex may be used to 485 differentiate between sub-interfaces and unnumbered interfaces (see 486 RSVP's LIH for an example). When SNMP is supported by the PEP, this 487 ifindex integer must correspond to the same integer value for the 488 interface in the SNMP MIB-II interface index table. 490 Note: The ifindex specified in the Out-Interface is typically 491 relative to the flow of the underlying protocol messages. The 492 ifindex is the one on which a protocol message is about to be 493 forwarded. 495 C-Num = 5 497 C-Type = 1, IPv4 Address + Interface 499 Same C-Type format as the In-Interface object. The IPv4 address 500 should specify the IP address to which the outgoing message is 501 going. The ifindex is used to refer to the MIB-II defined local 502 outgoing interface on the PEP. 504 C-Type = 2, IPv6 Address + Interface 506 Same C-Type format as the In-Interface object. For this type of the 507 interface object, the IPv6 address should specify the IP address to 508 which the outgoing message is going. The ifindex is used to refer to 509 the MIB-II defined local outgoing interface on the PEP. 511 2.2.5 Reason Object (Reason) 513 This object specifies the reason why the request state was deleted. 514 It should appear in the delete request (DRQ) message. The Reason 515 Sub-code field is reserved for more detailed client-specific reason 516 codes defined in the corresponding documents. 518 C-Num = 6, C-Type = 1 519 0 1 2 3 520 +--------------+--------------+--------------+--------------+ 521 | Reason-Code | Reason Sub-code | 522 +--------------+--------------+--------------+--------------+ 524 Reason Code: 525 1 = Unspecified 526 2 = Management 527 3 = Preempted (Another request state takes precedence) 528 4 = Tear (Used to communicate a signaled state removal) 529 5 = Timeout (Local state has timed-out) 530 6 = Route Change (Change invalidates request state) 531 7 = Insufficient Resources (No local resource available) 532 8 = PDP's Directive (PDP decision caused the delete) 533 9 = Unsupported decision (PDP decision not supported) 534 10= Synchronize Handle Unknown 535 11= Transient Handle (stateless event) 536 12= Malformed Decision (could not recover) 538 2.2.6 Decision Object (Decision) 540 Decision made by the PDP. Must appear in replies. The specific non- 541 mandatory decision objects required in a decision to a particular 542 request depend on the type of client. 544 C-Num = 7 546 C-Type = 1, Decision Flags (Mandatory) 548 0 1 2 3 549 +--------------+--------------+--------------+--------------+ 550 | Flags | 551 +--------------+--------------+--------------+--------------+ 553 Flags: 554 0x01 = Admit Signaled (Reject if set) 555 0x08 = Trigger Error (Trigger error message if set) 556 Note: For the above flags, a flag bit set to 1 557 implies a negative decision for that flag. Not 558 setting a flag implies a positive decision. 559 0x10 = NULL Configuration (No configuration data if set) 560 0x20 = Install Configuration (Install named data if set) 561 0x40 = Remove Configuration (Remove named data if set) 562 Note: If NULL Configuration ignore Install/Remove. 563 Note: Only one of Install OR Remove may be set in 564 one decision flags object. 565 0x200= Solicited Decision 566 (Initial decision after a new/updated request if set) 568 Flag values not applicable to a given context's R-Type MUST be 569 ignored by the PEP. See table below: 571 Decision Flag : Valid Context R-Type 572 ------------------------------------------------------- 573 Admit Signaled : Incoming-Message/Admission Control 574 Admit Signaled : Resource-Allocation 575 Admit Signaled : Outgoing-Message 576 Trigger Error : Any of the above R-Types 577 NULL Configuration : Configuration 578 Install Config. : Configuration 579 Remove Config. : Configuration 580 Solicited Decision : Any R-Type 582 C-Type = 2, Resource Allocation Data 584 This type of decision object carries additional stateless 585 information that can be applied by the PEP locally. It is a 586 variable length object and its internal format should be 587 specified in the relevant COPS extension document for the given 588 client-type. This object is optional in Decision messages and is 589 interpreted relative to a given context. 591 It is expected that even outsourcing PEPs will be able to make 592 some simple stateless policy decisions locally in their LDP. As 593 this set is well known and implemented ubiquitously, PDPs are 594 aware of it as well (either universally, through configuration, 595 or using the Client-Open message). The PDP may also include this 596 information in its decision, and the PEP should apply it to the 597 resource allocation event that generated the request. 599 As an example, reservations may be admitted by a PDP contingent 600 on some type of per-session preemption priority. A RSVP PEP 601 could have a set of stateless policy rules for when to preempt 602 other reservations in favor of a new one (e.g. higher-priority 603 pre-empts any of lower priority). The PDP would need to include 604 appropriate priority information for each reservation in its 605 decisions that the PEP can use to apply its rules. 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 = 8 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 9, 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 674 2.2.9 Client Specific Information Object (ClientSI) 676 The various types of this object are required for requests, and used 677 in reports and opens when required. It contains client-type specific 678 information. 680 C-Num = 10, 682 C-Type = 1, Signaled ClientSI. 684 Variable-length field. All objects/attributes specific to a client's 685 signaling protocol or internal state must be encapsulated within one 686 or more signaled Client Specific Information Objects. The format of 687 the data encapsulated in the ClientSI object is determined by the 688 client-type. 690 C-Type = 2, Named ClientSI. 692 Variable-length field. Contains named configuration information 693 useful for relaying specific information about the PEP, a request, 694 or configured state to the PDP server. 696 2.2.10 Keep-Alive Timer Object (KATimer) 698 Times are encoded as 2 octet integer values and are in units of 699 seconds. The timer value is treated as a delta. 701 C-Num = 11, 703 C-Type = 1, Keep-alive timer value 705 Timer object used to specify the maximum time interval over which a 706 COPS message must be sent or received. The value of zero implies 707 infinity. 709 0 1 2 3 710 +--------------+--------------+--------------+--------------+ 711 | ////////////// | KA Timer Value | 712 +--------------+--------------+--------------+--------------+ 714 2.2.11 PEP Identification Object (PEPID) 716 The PEP Identification Object is used to identify the PEP client to 717 the remote PDP. It is required for Client-Open messages. 719 C-Num = 12, C-Type = 1 721 Variable-length field. It is a NULL terminated ASCII string that is 722 also zero padded to a 32-bit word boundary (so the object length is 723 a multiple of 4 octets). The PEPID must contain an ASCII string that 724 uniquely identifies the PEP within the policy domain in a manner 725 that is persistent across PEP reboots. For example, it may be the 726 PEP's statically assigned IP address or DNS name. This identifier 727 may safely be used by a PDP as a handle for identifying the PEP in 728 its policy rules. 730 2.2.12 Report-Type Object (Report-Type) 732 The Type of Report on the request state associated with a handle: 734 C-Num = 13, C-Type = 1 736 0 1 2 3 737 +--------------+--------------+--------------+--------------+ 738 | Report-Type | ///////////// | 739 +--------------+--------------+--------------+--------------+ 741 Report-Type: 742 1 = Commit : PEP's local resources now allocated 743 2 = Accounting: Accounting update for an installed state 744 3 = No Commit : PEP's resource allocation failure 745 4 = Installed : Named configuration installed 746 5 = Removed : Named configuration removed 747 6 = NotInstall: Named configuration was not installed 748 7 = NotRemoved: Named configuration was not removed 750 2.2.13 PDP Redirect Address (PDPRedirAddr) 752 A PDP when closing a PEP session for a particular client-type may 753 optionally use this object to redirect the PEP to another PDP 754 server: 756 C-Num = 14, 758 C-Type = 1, IPv4 Address (4 octets) 759 0 1 2 3 760 +--------------+--------------+--------------+--------------+ 761 | IPv4 Address format | 762 +--------------+--------------+--------------+--------------+ 764 C-Type = 2, IPv6 Address (16 octets) 765 0 1 2 3 766 +--------------+--------------+--------------+--------------+ 767 | | 768 + + 769 | | 770 + IPv6 Address format + 771 | | 772 + + 773 | | 774 +--------------+--------------+--------------+--------------+ 776 2.2.14 Last PDP Address (LastPDPAddr) 778 When a PEP sends a Client-Open message for a particular client-type 779 the PEP should specify the last PDP it has successfully opened 780 (meaning it received a Client-Accept) since the PEP last rebooted. 781 If no PDP was used since the last reboot, the PEP will simply not 782 include this object in the Client-Open message. 784 C-Num = 15, 786 C-Type = 1, IPv4 Address (Same format as PDPRedirAddr) 788 C-Type = 2, IPv6 Address (Same format as PDPRedirAddr) 790 2.2.15 Accounting Timer Object (AcctTimer) 792 Times are encoded as 2 octet integer values and are in units of 793 seconds. The timer value is treated as a delta. 795 C-Num = 16, 797 C-Type = 1, Accounting timer value 799 Optional timer value used to determine the minimum interval between 800 periodic accounting type reports. It is used by the PDP to describe 801 to the PEP an acceptable interval between accounting updates via 802 Report messages where applicable. The value of zero implies there 803 are no timing constraints on accounting updates. 805 0 1 2 3 806 +--------------+--------------+--------------+--------------+ 807 | ////////////// | ACCT Timer Value | 808 +--------------+--------------+--------------+--------------+ 810 2.3 Communication 812 The COPS protocol uses a single persistent TCP connection between 813 the PEP and a remote PDP. The remote PDP listens on a well-known 814 port number (COPS=3288 [IANA]), and the PEP is responsible for 815 initiating the connection. The location of the remote PDP can either 816 be configured, or obtained via a service location mechanism 817 [SRVLOC]. Service discovery is outside the scope of this protocol, 818 however. 820 If a single PEP can support multiple client-types, it may send 821 multiple Client-Open messages, each specifying a particular client- 822 type to a PDP over one or more TCP connections. Likewise, a PDP 823 residing at a given address may support one or more client-types. 824 Given the client-types it supports, a PDP has the ability to either 825 accept or reject each client-type independently. If a client-type is 826 rejected, the PDP can redirect the PEP to an alternative PDP for a 827 given client-type via COPS. Additional provisions for supporting 828 multiple client-types (perhaps from independent PDP vendors) on a 829 single remote PDP server are not provided by the COPS protocol, but, 830 rather, are left to the software architecture of the given server 831 platform. 833 It is possible a single PEP may have open connections to multiple 834 PDPs. This is the case when there are physically different PDPs 835 supporting different client-types as shown in figure 2. 837 +----------------+ 838 | | 839 | Network Node | Policy Servers 840 | | 841 | +-----+ | COPS Client Type 1 +-----+ 842 | | |<-----|-------------------->| PDP1| 843 | + PEP + | COPS Client Type 2 +-----+ 844 | | |<-----|---------\ +-----+ 845 | +-----+ | \----------| PDP2| 846 | ^ | +-----+ 847 | | | 848 | \-->+-----+ | 849 | | LDP | | 850 | +-----+ | 851 | | 852 +----------------+ 854 Figure 2: Multiple PDPs illustration. 856 When a TCP connection is torn down or is lost, the PDP is expected 857 to eventually clean up any outstanding request state related to 858 request/decision exchanges with the PEP. When the PEP detects a lost 859 connection due to a timeout condition it should explicitly send a 860 Client-Close message for each opened client-type containing an 861 object indicating the "Communication Failure" Error-Code. 862 Additionally, the PEP should continuously attempt to contact the 863 primary PDP or, if unsuccessful, any known backup PDPs. Specifically 864 the PEP should keep trying all relevant PDPs with which it has been 865 configured until it can establish a connection. If a PEP is in 866 communication with a backup PDP and the primary PDP becomes 867 available, the backup PDP is responsible for redirecting the PEP 868 back to the primary PDP (via a message containing a 869 object indicating the primary PDP to use for each 870 affected client-type). 872 2.4 Client Handle Usage 874 The client handle is used to identify a unique request state. Client 875 handles are chosen by the PEP and are opaque to the PDP. The PDP 876 simply uses the request handle to uniquely identify the request 877 state and generically tie its decisions to a corresponding request. 879 Client handles are initiated in request messages and are then used 880 by subsequent request, decision, and report messages to reference 881 the same request state. When the PEP is ready to remove a local 882 request state, it will issue a delete message to the PDP for the 883 corresponding client handle. A handle MUST be explicitly deleted by 884 the PEP before it can be used to identify a new request state. 885 Handles referring to different request states must be unique. 887 2.5 Synchronization Behavior 889 When disconnected from a PDP, the PEP should revert to making local 890 decisions. Once a connection is reestablished, the PEP is expected 891 to notify the PDP of any events that have passed local admission 892 control. Additionally, the remote PDP may request that all the PEP's 893 internal state be resynchronized (all previously installed requests 894 are to be reissued) by sending a Synchronize State message. 896 After a failure and before a new connection is fully functional, 897 disruption of service can be minimized if the PEP caches previously 898 communicated decisions and continues to use them for some 899 appropriate length of time. Specific rules for such behavior are to 900 be defined in the appropriate COPS client-type extension 901 specifications. 903 A PEP that caches state from a previous exchange with a disconnected 904 PDP must communicate this fact to any PDP with which it is able to 905 later reconnect. This is accomplished by including the address of 906 the last PDP for which the PEP is still caching state in the Client- 907 Open message. The object will only be included for the 908 last PDP with which the PEP was completely in sync. If the service 909 interruption was temporary and the PDP still contains the complete 910 state for the PEP, the PDP may choose not to synchronize all states. 911 It is still the responsibility of the PEP to update the PDP of all 912 state changes that occurred during the disruption of service 913 including any states communicated to the previous PDP that had been 914 deleted after the connection was lost. These must be explicitly 915 deleted after a connection is reestablished. If the PDP issues a 916 synchronize request the PEP must pass all current states to the PDP 917 followed by a Synchronize State Complete message (thus completing 918 the synchronization process). 920 3. Message Content 922 This section describes the basic messages exchanged between a PEP 923 and a remote PDP as well as their contents. As a convention, object 924 ordering is expected as shown in the BNF for each COPS message 925 unless otherwise noted. Malformed messages are to be silently 926 dropped unless otherwise specified. 928 3.1 Request (REQ) PEP -> PDP 930 The PEP establishes a request state client handle for which the 931 remote PDP may maintain a state. The remote PDP then uses this 932 handle to refer to the exchanged information and decisions. 934 Once a stateful handle is established for a new request, any 935 subsequent modifications of the request can be made using the REQ 936 message specifying the previously installed handle. The PEP is 937 responsible for notifying the PDP whenever its local state changes 938 so the PDP's state will be able to accurately mirror the PEP's 939 state. 941 The format of the Request message is as follows: 943 ::= 944 945 946 [] 947 [] 948 [] 949 [] 951 ::= | 953 ::= | 954 956 The context object is used to determine the context within which all 957 the other objects are to be interpreted. It also is used to 958 determine the kind of decision to be returned from the policy 959 server. This decision might be related to admission control, 960 resource allocation, object forwarding and substitution, or 961 configuration. 963 The interface objects are used to determine the corresponding 964 interface on which a signaling protocol message was received or is 965 about to be sent. They are typically used if the client is 966 participating along the path of a signaling protocol or if the 967 client is requesting configuration data for a particular interface. 969 ClientSI, the client specific information object, holds the client- 970 type specific data for which a policy decision needs to be made. In 971 the case of configuration, the Named ClientSI may include named 972 information about the module, interface, or functionality to be 973 configured. The ordering of multiple ClientSIs is not important. 975 Finally, LDPDecision object holds information regarding the local 976 decision made by the LDP. 978 3.2 Decision (DEC) PDP -> PEP 980 The PDP responds to the REQ with a DEC message that includes the 981 associated client handle and one or more decision objects grouped 982 relative to a Context object and Decision Flags object type pair. If 983 there was a protocol error an error object is returned instead. 985 It is assumed that the first decision for a new/updated request will 986 set the solicited decision flag in all included Decision Flag object 987 types. This avoids the issue of keeping track of which updated 988 request (that is, a request reissued for the same handle) a 989 particular decision corresponds. It is important that, for a given 990 handle, there be at most one outstanding solicited decision per 991 request. This essentially means that the PEP should not issue more 992 than one REQ (for a given handle) before it receives a corresponding 993 DEC with the solicited decision flag set. 995 To avoid deadlock, the client can always timeout after issuing a 996 request. It must then delete the timed-out handle, and possibly try 997 again using a different (new) handle. 999 The format of the Decision message is as follows: 1001 ::= 1002 1003 | 1005 ::= | 1007 ::= 1008 1009 [] 1010 [] 1011 [] 1012 [] 1014 The Decision message may include either an Error object or one or 1015 more context plus associated decision objects. COPS protocol 1016 problems are reported in the Error object (e.g. an error with the 1017 format of the original request, including malformed request 1018 messages). The applicable Decision object(s) depend on the context 1019 and the type of client. The only ordering requirement for decision 1020 objects is that the required Decision Flags object type must proceed 1021 the other Decision object types per context binding. 1023 3.3 Report State (RPT) PEP -> PDP 1025 This message is used by the PEP to communicate a change in the 1026 status of a previously installed state to the PDP. A commit or no- 1027 commit report-type indicates to the PDP that a particular policy 1028 directive has or has not been acted upon as is relevant for 1029 accounting purposes. (In RSVP this would mean that a reservation 1030 passed or failed local capacity admission control [RSVP]. For a 1031 configuration decision, it would mean the configuration identified 1032 in the ClientSI either could or could not be installed by the PEP). 1034 The Report State may also be used to provide periodic updates of 1035 client specific information for accounting and state monitoring 1036 purposes depending on the type of the client. In such cases the 1037 accounting report type should be specified utilizing the appropriate 1038 client specific information object. 1040 ::== 1041 1042 1043 [] 1045 3.4 Delete Request State (DRQ) PEP -> PDP 1047 When sent from the PEP this message indicates to the remote PDP that 1048 the state identified by the client handle is no longer 1049 available/relevant. This information will then be used by the remote 1050 PDP to initiate the appropriate housekeeping actions. The reason 1051 code object is interpreted with respect to the client-type and 1052 signifies the reason for the removal. 1054 The format of the Delete Request State message is as follows: 1056 ::= 1057 1058 1060 Given the stateful nature of COPS, it is important that when a 1061 request state is finally removed from the PEP, a DRQ message for 1062 this request state is sent to the PDP so the corresponding state may 1063 likewise be removed on the PDP. Request states not explicitly 1064 deleted by the PEP will be maintained by the PDP until either the 1065 client session is closed or the connection is terminated. 1067 Malformed Decision messages should trigger a DRQ specifying the 1068 appropriate erroneous reason code (Bad Message Format) and any 1069 associated state on the PEP should either be removed or re- 1070 requested. 1072 3.5 Synchronize State Request (SSQ) PDP -> PEP 1074 The format of the Synchronize State Query message is as follows: 1076 ::= 1077 [] 1079 This message indicates that the remote PDP wishes the client (which 1080 appears in the common header) to re-send its state. If the optional 1081 Client Handle is present, only the state associated with this handle 1082 is synchronized. If the PEP does not recognize the requested handle, 1083 it should immediately send a DRQ message to the PDP for the handle 1084 that was specified in the SSQ message. If no handle is specified in 1085 the SSQ message, all the active client state should be synchronized 1086 with the PDP. 1088 The client performs state synchronization by re-issuing request 1089 queries of the specified client-type for the existing state in the 1090 PEP. When synchronization is complete, the PEP must issue a 1091 synchronize state complete message to the PDP. 1093 3.6 Client-Open (OPN) PEP -> PDP 1095 The Client-Open message can be used by the PEP to specify to the PDP 1096 the client-types the PEP can support, the last PDP to which the PEP 1097 connected for the given client-type, and/or client specific feature 1098 negotiation. A Client-Open message can be sent to the PDP at any 1099 time and multiple Client-Open messages for the same client-type are 1100 allowed (in case of global state changes). 1102 ::= 1103 1104 [] 1105 [] 1107 The PEPID is a symbolic, variable length name that uniquely 1108 identifies the specific client to the PDP. 1110 A named ClientSI object can be included for relaying additional 1111 global information about the PEP to the PDP when required (as 1112 specified in the appropriate extensions document for the client- 1113 type). 1115 Finally, the PEP may provide a Last PDP Address object in its 1116 Client-Open message specifying the last PDP (for the given client- 1117 type) for which it is still caching decisions since its last reboot. 1118 A PDP can use this information to determine the appropriate 1119 synchronization behavior (See section 2.5). 1121 3.7 Client-Accept (CAT) PDP -> PEP 1123 The Client-Accept message is used to positively respond to the 1124 Client-Open message. This message will return to the PEP a timer 1125 object indicating the maximum time interval between keep-alive 1126 messages. Optionally, a timer specifying the minimum allowed 1127 interval between accounting report messages may be included when 1128 applicable. 1130 ::= 1131 1132 [] 1134 If the PDP refuses the client, it will instead issue a Client-Close 1135 message. 1137 The KA Timer corresponds to maximum acceptable intermediate time 1138 between the generation of messages by the PDP and PEP. The timer 1139 value is determined by the PDP and is specified in seconds. A timer 1140 value of 0 implies no secondary connection verification is 1141 necessary. 1143 The optional accounting timer allows the PDP to indicate to the PEP 1144 that periodic accounting reports should not exceed the specified 1145 timer interval. This allows the PDP to control the rate at which 1146 accounting reports are sent by the PEP (when applicable). In 1147 general, accounting type Report messages are sent to the PDP when 1148 determined appropriate by the PEP. The accounting timer merely is 1149 used by the PDP to keep the rate of such updates in check (i.e. 1150 Preventing the PEP from blasting the PDP with accounting reports). 1152 3.8 Keep-Alive (KA) PEP -> PDP, PDP -> PEP 1154 The keep-alive message must be transmitted by the PEP within the 1155 period defined by the minimum of all KA Timer values specified in 1156 all received CAT messages for the connection. A KA message must be 1157 generated randomly between 1/4 and 3/4 of this minimum TA timer 1158 interval. When the PDP receives a keep-alive message from a PEP, it 1159 must echo a keep-alive back to the PEP. This message provides 1160 validation for each side that the connection is still functioning 1161 even when there is no other messaging. 1163 Note: The client-type in the header should always be set to 0 as the 1164 KA is used for connection verification (not per client session 1165 verification). 1167 ::= 1169 Both client and server may assume the TCP connection is insufficient 1170 for the client-type with the minimum time value (specified in the 1171 CAT message) if no communication activity is detected for a period 1172 exceeding the timer period. For the PEP, such detection implies the 1173 remote PDP or connection is down and the PEP should now attempt to 1174 use an alternative/backup PDP. 1176 3.9 Client-Close (CC) PEP -> PDP, PDP -> PEP 1178 The Client-Close message can be issued by either the PDP or PEP to 1179 notify the other that a particular type of client is no longer being 1180 supported. 1182 ::= 1183 1184 [] 1186 The Error object is included to describe the reason for the close 1187 (e.g. the requested client-type is not supported by the remote PDP 1188 or client failure). 1190 A PDP may optionally include a PDP Redirect Address object in order 1191 to inform the PEP of the alternate PDP it should use for the client- 1192 type specified in the common header. 1194 3.10 Synchronize State Complete (SSC) PEP -> PDP 1196 The Synchronize State Complete is sent by the PEP to the PDP after 1197 the PDP sends a synchronize state request to the PEP and the PEP has 1198 finished synchronization. It is useful so that the PDP will know 1199 when all the old client state has been successfully re-requested 1200 and, thus, the PEP and PDP are completely synchronized. 1202 ::= 1204 4. Common Operation 1206 This section describes the typical exchanges between remote PDP 1207 servers and PEP clients. 1209 4.1 PEP Initialization 1211 Sometime after a connection is established between the PEP and a 1212 remote PDP, the PEP will send one or more Client-Open messages to 1213 the remote PDP, one for each client-type supported by the PEP. The 1214 Client-Open message must contain the address of the last PDP with 1215 which the PEP is still caching a complete set of decisions. If no 1216 decisions are being cached from the previous PDP the LastPDPAddr 1217 object must not be included in the Client-Open message (see Section 1218 2.5). Each Client-Open message should at least contain the common 1219 header noting one client-type supported by the PEP. The remote PDP 1220 will then respond with separate Client-Accept messages for each of 1221 the client-types requested by the PEP that the PDP can also support. 1223 If a specific client-type is not supported by the PDP, the PDP will 1224 instead respond with a Client-Close specifying the client-type is 1225 not supported and will possibly suggest an alternate PDP address. 1226 Otherwise, the PDP will send a Client-Accept specifying the timer 1227 interval between keep-alive messages and the PEP may begin issuing 1228 requests to the PDP. 1230 4.2 Outsourcing Operations 1232 In the outsourcing scenario, when the PEP receives an event that 1233 requires a new policy decision it sends a request message to the 1234 remote PDP. What specifically qualifies as an event for a particular 1235 client-type should be specified in the specific document for that 1236 client-type. The remote PDP then makes a decision and sends a 1237 decision message back to the PEP. Since the request is stateful, the 1238 request will be remembered, or installed, on the remote PDP. The 1239 unique handle, specified in both the request and its corresponding 1240 decision identifies this request state. The PEP is responsible for 1241 deleting this request state once the request is no longer 1242 applicable. 1244 The PEP can update a previously installed request state by reissuing 1245 a request for the previously installed handle. The remote PDP is 1246 then expected to make new decisions and send a decision message back 1247 to the PEP. Likewise, the server may change a previously issued 1248 decision on any currently installed request state at any time by 1249 issuing another decision message. At all times the PEP module is 1250 expected to abide by the PDP's decisions and notify the PDP of any 1251 state changes. 1253 4.3 Configuration Operations 1255 In the configuration scenario, as in the outsourcing scenario, the 1256 PEP will make a configuration request to the PDP for a particular 1257 interface, module, or functionality that may be specified in the 1258 named client specific information object. The PDP will then send 1259 potentially several decisions containing named units of 1260 configuration data to the PEP. The PEP is expected to install and 1261 use the configuration locally. A particular named configuration can 1262 be updated by simply sending additional decision messages for the 1263 same named configuration. When the PDP no longer wishes the PEP to 1264 use a piece of configuration information, it will send a decision 1265 message specifying the named configuration and a decision flags 1266 object with the remove configuration flag set. The PEP should then 1267 proceed to remove the corresponding configuration and send a report 1268 message to the PDP that specifies it has been deleted. 1270 In all cases, the PEP may notify the remote PDP of the local status 1271 of an installed state using the report message where appropriate. 1272 The report message is to be used to signify when billing should 1273 begin, what actions were taken, or to produce periodic updates for 1274 monitoring and accounting purposes depending on the client. This 1275 message can carry client specific information when needed. 1277 4.4 Keep-Alive Operations 1279 The Keep-Alive message is used to validate the connection between 1280 the client and server is still functioning even when there is no 1281 other messaging from the PEP to PDP. The PEP must generate a COPS KA 1282 message randomly within one-fourth to three-fourths the negotiated 1283 minimum KA Timer interval. On receiving a Keep-Alive message from 1284 the PEP, the PDP must then respond to this Keep-Alive message by 1285 echoing a Keep-Alive message back to the PEP. If either side does 1286 not receive a Keep-Alive or any other COPS message within the 1287 minimum KA Timer interval from the other, the connection should be 1288 considered lost. 1290 4.5 PEP/PDP Close 1292 Finally, Client-Close messages are used to negate the effects of the 1293 corresponding Client-Open messages, notifying the other side that 1294 the specified client-type is no longer supported/active. When the 1295 PEP detects a lost connection due to a keep-alive timeout condition 1296 it should explicitly send a Client-Close message for each opened 1297 client-type specifying a communications failure error code. Then the 1298 PEP may proceed to terminate the connection to the PDP and attempt 1299 to reconnect again or try a backup/alternative PDP. When the PDP is 1300 shutting down, it should also explicitly send a Client-Close to all 1301 connected PEPs for each client-type, perhaps specifying an 1302 alternative PDP to use instead. 1304 5. Security 1306 The security of RSVP messages is provided by inter-router MD5 1307 authentication [MD5]. This assumes a chain-of-trust model for inter 1308 PEP authentication. Security between the client (PEP) and server 1309 (PDP) is provided by IPSEC [IPSEC]. 1311 To ensure the client (PEP) is communicating with the correct policy 1312 server (PDP) involves two issues: authentication of the policy 1313 client and server using a shared secret, and consistent proof that 1314 the connection remains valid. The shared secret requires manual 1315 configuration of keys, which is a maintenance issue. IPSEC AH may be 1316 used for the validation of the connection; IPSEC ESP may be used to 1317 provide both validation and secrecy. 1319 6. IANA Considerations 1321 The Client-type identifies the policy client application to which a 1322 message refers. Client-type values within the range 0x0000-0x3FFF 1323 are reserved Specification Required status as defined in [IANA- 1324 CONSIDERATIONS]. These values must be registered with IANA and their 1325 behavior and applicability must be described in a COPS extension 1326 document. 1328 Client-type values in the range 0x4000 - 0x7FFF are reserved for 1329 Private Use as defined in [IANA-CONSIDERATIONS]. These Client-types 1330 are not tracked by IANA and are not to be used in standards or 1331 general-release products, as their uniqueness cannot be assured. 1333 Client-type values in the range 0x8000 - 0xFFFF are First Come First 1334 Served as defined in [IANA-CONSIDERATIONS]. These Client-types are 1335 tracked by IANA but do not require published documents describing 1336 their use. IANA merely assures their uniqueness. 1338 7. References 1340 [RSVP] Braden, R. ed. et al., "Resource ReSerVation Protocol (RSVP) 1341 Version 1 - Functional Specification", RFC 2205, September 1342 1997. 1344 [WRK] Yavatkar, R. et al., "A Framework for Policy-Based Admission 1345 Control", Internet-Draft, draft-ietf-rap-framework-01.txt, 1346 November 1998. 1348 [SRVLOC]Guttman, E. et al., "Service Location Protocol", Internet- 1349 Draft, draft-ietf-svrloc-protocol-v2-01.txt, October 1997. 1351 [INSCH] Shenker, S., Wroclawski, J., "General Characterization 1352 Parameters for Integrated Service Network Elements", RFC 1353 2215, September 1997. 1355 [IPSEC] Atkinson, R., "Security Architecture for the Internet 1356 Protocol", RFC1825, August 1995. 1358 [MD5] Baker, F., "RSVP Cryptographic Authentication", Internet- 1359 Draft, draft-ietf-rsvp-md5-05.txt, August 1997. 1361 [RSVPPR]Braden, R., Zhang, L., "Resource ReSerVation Protocol (RSVP) 1362 - Version 1 Message Processing Rules", RFC 2209, September 1363 1997. 1365 [IANA] http://www.isi.edu/in-notes/iana/assignments/port-numbers 1367 [IANA-CONSIDERATIONS] Alvestrand, H. and T. Narten, "Guidelines for 1368 Writing an IANA Considerations Section in RFCs", BCP 26, RFC 1369 2434, October 1998. 1371 8. Author Information and Acknowledgments 1373 Special thanks to Andrew Smith and Timothy O'Malley our WG Chairs, 1374 Raj Yavatkar, Russell Fenger, Fred Baker, Laura Cunningham, Roch 1375 Guerin, Ping Pan, and Dimitrios Pendarakis for their valuable 1376 contributions. 1378 Jim Boyle Ron Cohen 1379 Level 3 Communications Cisco Systems 1380 1450 Infinite Drive13 Hasadna St. 1381 Louisville, CO 80027 Ra'anana 43650 Israel 1382 303.926.3100 972.9.7462020 1383 email: jboyle@l3.net ronc@classdata.com 1385 David Durham Raju Rajan 1386 Intel IBM T.J. Watson Research Cntr 1387 2111 NE 25th Avenue P.O. Box 704 1388 Hillsboro, OR 97124 Yorktown Heights, NY 10598 1389 503.264.6232 914.784.7260 1390 David_Durham@mail.intel.com raju@watson.ibm.com 1392 Shai Herzog Arun Sastry 1393 IPHighway Cisco Systems 1394 2055 Gateway Pl., Suite 400 506210 W Tasman Drive 1395 San Jose, CA 95110 San Jose, CA 95134 1396 408.390.3045 408.526.7685 1397 herzog@iphighway.com asastry@cisco.com