idnits 2.17.1 draft-ietf-rap-pr-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 26 longer pages, the longest (page 2) being 65 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 28 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 7.1. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([COPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. ** 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 194: '... instances MUST NOT be shared....' RFC 2119 keyword, line 342: '... new PRC. The PEP SHOULD ignore these...' RFC 2119 keyword, line 343: '...RI. However, it MAY return and error ...' RFC 2119 keyword, line 362: '... Consequently, an ASN.1 value MUST be...' RFC 2119 keyword, line 367: '... the PDP MUST send either an ASN.1 v...' (22 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 594 has weird spacing: '...clients encap...' == Line 862 has weird spacing: '...efer to the '...' == Line 871 has weird spacing: '...mat for this ...' -- 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 (March 10, 2000) is 8812 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: 'RAP-FRAMEWORK' is mentioned on line 114, but not defined == Missing Reference: 'COPS-RSVP' is mentioned on line 133, but not defined == Missing Reference: 'V2SMI' is mentioned on line 232, but not defined == Unused Reference: 'RSVP' is defined on line 1141, but no explicit reference was found in the text == Unused Reference: 'ASN1' is defined on line 1146, but no explicit reference was found in the text == Unused Reference: 'RFC2475' is defined on line 1158, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 2753 (ref. 'RAP') -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' ** Downref: Normative reference to an Informational RFC: RFC 2475 -- Possible downref: Normative reference to a draft: ref. 'PIB' ** Obsolete normative reference: RFC 2234 (Obsoleted by RFC 4234) Summary: 9 errors (**), 0 flaws (~~), 14 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Internet Draft Kwok Ho Chan 2 Expiration: September 2000 Nortel Networks 3 File: draft-ietf-rap-pr-02.txt David Durham 4 Intel 5 Silvano Gai 6 Cisco 7 Shai Herzog 8 IPHighway 9 Keith McCloghrie 10 Cisco 11 Francis Reichmeyer 12 IPHighway 13 John Seligson 14 Nortel Networks 15 Andrew Smith 16 Extreme Networks 17 Raj Yavatkar 18 Intel 20 COPS Usage for Policy Provisioning 22 March 10, 2000 24 Status of this Memo 26 This document is an Internet-Draft and is in full conformance with 27 all provisions of Section 10 of RFC2026. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other 36 documents at any time. It is inappropriate to use Internet-Drafts 37 as reference material or to cite them other than as "work in 38 progress." 40 The list of current Internet-Drafts can be accessed at 41 http://www.ietf.org/ietf/1id-abstracts.txt 43 The list of Internet-Draft Shadow Directories can be accessed at 44 http://www.ietf.org/shadow.html. 46 Distribution of this memo is unlimited. 48 Copyright Notice 50 Copyright (C) The Internet Society (1998). All Rights Reserved. 52 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 54 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 55 Abstract 57 This draft describes the use of the COPS protocol [COPS] for 58 support of policy provisioning. This specification is independent 59 of type of policy being provisioned (QoS, Security, etc.) but 60 focuses on the mechanisms and conventions used to communicate 61 provisioned information between PDPs and PEPs. The protocol 62 extensions described in this document do not make any assumptions 63 about the policy data being communicated, but describe the message 64 formats and objects that carry policy data. 66 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 67 Table of Contents 69 Abstract..............................................................3 70 Table of Contents.....................................................4 71 Glossary..............................................................5 72 1. Introduction.....................................................5 73 1.1. Why not SNMP?..................................................6 74 1.2. Interaction between the PEP and PDP............................7 75 2. Policy Information Base (PIB)....................................8 76 2.1. Rules for Modifying and Extending PIBs.........................9 77 2.2. Adding PRCs to, or deprecating from, a PIB.....................9 78 2.2.1. Adding or Deprecating Attributes of a PRC......................9 79 2.2.2. Augmenting a PRC with another PRC.............................10 80 2.3. COPS Operations Supported for a Policy Rule Instance..........10 81 3. Message Content.................................................11 82 3.1. Request (REQ) PEP -> PDP.....................................11 83 3.2. Decision (DEC) PDP -> PEP....................................12 84 3.3. Report State (RPT) PEP -> PDP................................14 85 4. COPS-PR Protocol Objects........................................14 86 4.1. Complete Policy Rule Identifier (PRID)........................15 87 4.2. Prefix PRID (PPRID)...........................................16 88 4.3. Encoded Policy Instance Data (EPD)............................16 89 4.4. Provisioning Error Object (PERR)..............................18 90 4.5. Error PRID Object (ErrorPRID).................................19 91 5. COPS-PR Client-Specific Data Formats............................19 92 5.1. Named Decision Data...........................................20 93 5.2. ClientSI Request Data.........................................20 94 5.3. Policy Provisioning Report Data...............................20 95 5.3.1. Success and Failure Report-Type Data Format...................21 96 5.3.2. Accounting Report-Type Data Format............................21 97 6. Common Operations...............................................22 98 7. Fault Tolerance.................................................24 99 7.1. Security Considerations.......................................25 100 8. Acknowledgements................................................25 101 9. References......................................................26 102 10. Author Information..............................................27 103 11. Full Copyright Notice...........................................28 105 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 107 Glossary 109 PRC Policy Rule Class. A type of policy data. 110 PRI Policy Rule Instance. An instance of a PRC. 111 PIB Policy Information Base. The database of policy 112 information. 113 PDP Policy Decision Point. See [RAP-FRAMEWORK]. 114 PEP Policy Enforcement Point. See [RAP-FRAMEWORK]. 115 PRID Policy Rule Instance Identifier. Uniquely identifies an 116 instance of a PRC. 118 1. Introduction 120 The IETF Resource Allocation Protocol (RAP) WG has defined the 121 COPS (Common Open Policy Service) protocol [COPS] as a scalable 122 protocol that allows policy servers (PDPs) to communicate policy 123 decisions to network devices (PEP). COPS was designed to support 124 multiple types of policy clients. 126 COPS is a query/response protocol that supports two common models 127 for policy control: Outsourcing and Configuration. 129 The Outsourcing model addresses the kind of events at the PEP that 130 require instantaneous policy decision (authorization). The PEP, 131 being aware that it must perform a policy decision. However, being 132 unable to carry the task itself, the PEP delegates responsibility 133 to an external policy server (PDP). For example, in [COPS-RSVP] 134 when a reservation message arrives, the PEP is aware that it must 135 decide whether to admit or reject the request. It sends a specific 136 query to the PDP, and in most case, waits for a decision before 137 admitting the outstanding reservation. 139 The COPS Configuration model (herein described as the Provisioning 140 model), on the other hand, makes no assumptions of such direct 1:1 141 correlation between PEP events and PDP decisions. The PDP may 142 proactively provision the PEP reacting to external events (such as 143 user input), PEP events, and any combination thereof (N:M 144 correlation). Provisioning may be performed in bulk (e.g., entire 145 router QoS configuration) or in portions (e.g., updating a 146 DiffServ marking filter). 148 Network resources are often provisioned based on relatively static 149 SLAs (Service Level Agreements) at network boundaries. While the 150 Outsourcing model is dynamically paced by the PEP in real-time, 151 the Provisioning model is paced by the PDP in somewhat flexible 152 timing over a wide range of configurable aspects of the PEP. 154 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 155 Edge Device Policy Server 156 +--------------+ +-----------+ +-----------+ 157 | | | | | External | 158 | | COPS | | | Events | 159 | +-----+ | REQ() | +-----+ | +---+-------+ 160 | | |----|----------|->| | | | 161 | | PEP | | | | PDP |<-|---------+ 162 | | |<---|----------|--| | | 163 | +-----+ | COPS | +-----+ | 164 | | DEC() | | 165 +--------------+ +-----------+ 167 Figure 1: COPS Provisioning Model 169 In COPS-PR, policy requests describe the PEP and its configurable 170 parameters (rather than an operational event). If a change occurs 171 in these basic parameters, an updated request is sent. Hence, 172 requests are issued quite infrequently. Decisions are not 173 necessarily mapped directly to requests, and are issued mostly 174 when the PDP responds to external events or PDP events (policy/SLA 175 updates). 177 This draft describes the use of the COPS protocol [COPS] for 178 support of policy provisioning. This specification is independent 179 of the type of policy being provisioned (QoS, Security, etc.) but, 180 rather, focuses on the mechanisms and conventions used to 181 communicate provisioned information between PDPs and PEPs. The 182 model described in this document is based on the concept of Policy 183 Information Bases (PIBs) that define the policy data. There may be 184 one or more PIBs for given area of policy and different areas of 185 policy will have different sets of PIBs. 187 In order to support a model that includes multiple PDPs 188 controlling non-overlapping areas of policy on a single PEP, the 189 client type specified by the PEP to the PDP is unique for the area 190 of policy being managed. A single client type for a given area of 191 policy (eg. QoS) will be used for all PIBs that exist in that 192 area. The client should treat all the COPS-PR client-types it 193 supports as non-overlapping and independent namespaces where 194 instances MUST NOT be shared. 196 The Examples used in this document are biased toward QoS Policy 197 Provisioning in a Differentiated Services (DiffServ) environment. 198 However, COPS-PR can be used for other types of provisioning 199 policies under the same framework. 201 1.1. Why not SNMP? 203 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 204 SNMP is a very popular network management protocol. One may 205 question using COPS-PR, rather than extending SNMP for policy 206 provisioning. 208 SNMP is designed for low-level access at very fine levels of 209 granularity. When configuring large amounts of policy 210 information, the low-level, granular access makes it inefficient 211 and cumbersome. 213 COPS-PR has been designed within a framework which is less 214 general-purpose and more optimized for configuration to overcome 215 these shortcomings, based on the requirements defined in [RAP]. It 216 has a single connection between client and server, it guarantees 217 only one server updates the policy configuration at any given time 218 (and these are locked, even from console configuration, while COPS 219 is connected to a server). COPS uses reliable TCP transport and 220 thus uses a state sharing/synchronization mechanism and exchanges 221 differential updates only. If either the server or client are 222 rebooted (or restarted) the other would know about it quickly. 223 Last, it is defined as a real-time mechanism for the PEP device. 225 The COPS protocol is already used for policy control over RSVP. It 226 is highly desirable to use a single policy control protocol for 227 Quality of Service (QoS) mechanisms (if possible), rather than 228 invent a new one for each type of policy problem. 230 At the same time, useful mechanisms from SNMP were adopted. COPS- 231 PR uses a named Policy Information Base (PIB), which can be 232 described using the SMI [V2SMI] and encoded using BER [BER] data 233 encoding. This allows reuse of experience, knowledge, tools and 234 some code from the SNMP world. 236 1.2. Interaction between the PEP and PDP 238 When a device boots, it opens a COPS connection to its Primary 239 PDP. When the connection is established, the PEP sends information 240 about itself to the PDP in the form of a configuration request. 241 This information includes client specific information (e.g., 242 hardware type, software release, configuration information). 243 During this phase the client may also specify the maximum COPS-PR 244 message size supported. 246 In response, the PDP downloads all provisioned policies that are 247 currently relevant to that device. On receiving the provisioned 248 policies, the device maps them into its local QoS mechanisms, and 249 installs them. If conditions change at the PDP such that the PDP 250 detects that changes are required in the provisioned policies 251 currently in effect, then the PDP sends the changes (installs 252 and/or deletes) in policy to the PEP, and the PEP updates its 253 local QoS mechanisms appropriately. 255 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 257 If, subsequently, the configuration of the device changes (board 258 removed, board added, new software installed, etc.) in ways not 259 covered by policies already known to the PEP, then the PEP sends 260 this unsolicited new information to the PDP. On receiving this new 261 information, the PDP sends to the PEP any additional provisioned 262 policies now needed by the PEP. 264 2. Policy Information Base (PIB) 266 The data carried by COPS-PR is a set of policy rules. The protocol 267 uses a named data structure, known as a Policy Information Base 268 (PIB), to identify the type and purpose of unsolicited policy 269 information that is "pushed" from the PDP to the PEP for 270 provisioning policy. The PIB name space is common to both the PEP 271 and the PDP and data instances within this space are unique within 272 the scope of a given PDP/PEP/Client-Type communication channel. 273 Note that a given device might implement multiple PEPs or multiple 274 Client-Types and the name space is then only relevant within each 275 separate channel (there is no sharing of instance data across the 276 PDP/PEP/Client-Types). 278 The PIB can be described as a conceptual tree data structure where 279 the branches of the tree represent types of rules or Policy Rule 280 Classes (PRCs), while the leaves represent the contents of Policy 281 Rule Instances (PRIs). There may be multiple instances of rules 282 (PRIs) for any given rule type (PRC). For example, if one wanted 283 to install multiple access control filters, the PRC might 284 represent a generic access control filter type and each PRI might 285 represent an individual access control filter to be applied. The 286 tree might be represented as follows: 288 -------+-------+----------+---PRC--+--PRI 289 | | | +--PRI 290 | | | 291 | | +---PRC-----PRI 292 | | 293 | +---PRC--+--PRI 294 | +--PRI 295 | +--PRI 296 | +--PRI 297 | +--PRI 298 | 299 +---PRC---PRI 301 Figure 2: The PIB Tree 303 Instances of the policy rules (PRIs) are each identified by a 304 Policy Rule Identifier (PRID). A PRID is a name, carried in a COPS 306 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 307 or object, which identifies 308 a particular instance of a rule. 310 2.1. Rules for Modifying and Extending PIBs 312 As experience is gained with policy management, and as new 313 requirements arise, it will be necessary to make changes to PIBs. 314 Changes to an existing PIB can be made in several ways. 316 (1) Additional PRCs can be added to a PIB or an existing one 317 deprecated. 319 (2) Attributes can be added to, or deprecated from an existing 320 PRC. 322 (3) An existing PRC can be extended by "augmenting" it with a new 323 PRC defined in another (perhaps enterprise specific) PIB. 325 The rules for each of these extension mechanisms is described in 326 this sub-section. All of these mechanisms for modifying a PIB 327 allow for interoperability between PDPs and PEPs even when one 328 party is using a new version of the PIB while the other is using 329 an old version. 331 2.2. Adding PRCs to, or deprecating from, a PIB 333 A published PIB can be extended with new PRCs by simply revising 334 the document and adding additional PRCs. These additional PRCs 335 are easily identified with new PRIDs under the module's PRID 336 Prefix. 338 In the event that a PEP implementing the new PIB is being 339 configured by a PDP implementing the old PIB, the PEP will simply 340 not receive any instances of the new PRC. In the event that the 341 PEP is implementing the old PIB and the PDP the new one, the PEP 342 may receive PRIs for the new PRC. The PEP SHOULD ignore these 343 unsupported PRI. However, it MAY return and error to the PDP. In 344 the latter case, the PDP must restructure its policy decisions to 345 exclude the unsupported PRCs. 347 Similarly, existing PRCs can be deprecated from a PIB. In this 348 case, the PEP ignores any PRIs sent it by a PDP implementing the 349 old (non- deprecated) version of the PIB. A PDP implementing the 350 new version of the PIB simply does not send any instances of the 351 deprecated class. 353 2.2.1. Adding or Deprecating Attributes of a BER Encoded PRC 355 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 356 A PIB can be modified to deprecate existing attributes of a PRC or 357 add new ones. 359 When deprecating the attributes of a PRC, it must be remembered 360 that, with the COPS-PR protocol, the attributes of the PRC are 361 identified by their order in the sequence rather than an explicit 362 label (or attribute OID). Consequently, an ASN.1 value MUST be 363 sent even for deprecated attributes so that a PDP and PEP 364 implementing different versions of the PIB are inter-operable. 366 For a deprecated attribute, if the PDP is using a BER encoded PIB, 367 the PDP MUST send either an ASN.1 value of the correct type, or it 368 may send an ASN.1 NULL value. A PEP that receives an ASN.1 NULL 369 for an attribute that is not deprecated SHOULD substitute a 370 default value. If it has no default value to substitute it MUST 371 return an error to the PDP. 373 When adding new attributes to a PIB, these new attributes must be 374 added in sequence after the existing ones. A PEP that receives a 375 PRI with more attributes than it is expecting MUST ignore the 376 additional attributes. It MAY send a warning back to the PDP. 378 A PEP that receives a PRI with fewer attributes than it is 379 expecting SHOULD assume default values for the missing attributes. 380 It MAY send a warning back to the PDP. If the missing attributes 381 are required and there is no suitable default, the PEP MUST send 382 and error back to the PDP. In all cases the missing attributes 383 are assumed to correspond to the last attributes of the PRC. 385 2.3. COPS Operations Supported for a Policy Rule Instance 387 A Policy Rule Instance (PRI) typically contains a value for each 388 attribute defined for the PRC of which it an instance and is 389 identified uniquely, within the scope of a given COPS Client-Type on 390 a PEP, by a Policy Rule Identifier (PRID). The following COPS 391 operations are supported on a PRI: 393 o Install - This operation creates or updates a named instance of 394 a PRC. It includes two parameters: a PRID object to name the PRI 395 and an Encoded Policy Instance Data (EPD) object with the 396 new/updated values. The PRID value MUST uniquely identify a 397 single PRI (i.e. PRID/PRC prefix values are illegal). 399 o Remove - This operation is used to delete an instance of a PRC. 400 It includes one parameter, a PRID object, which names either the 401 individual PRI to be deleted or a PRID prefix naming one or more 402 complete classes of PRIs. Prefix-based deletion supports 403 efficient bulk policy removal. 405 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 407 3. Message Content 409 The COPS protocol provides for different COPS clients to define 410 their own "named", i.e. client-specific, information for various 411 messages. This section describes the messages exchanged between a 412 COPS server (PDP) and COPS Policy Provisioning clients (PEP) that 413 carry client-specific data objects. All the COPS messages used by 414 COPS-PR conform to the message specifications defined in the COPS 415 base protocol [COPS]. 417 Note: The use of the '*' character represented throughout this 418 document is consistent with the ABNF [RFC2234] and means 0 or more 419 of the following entities. 421 3.1. Request (REQ) PEP -> PDP 423 The REQ message is sent by policy provisioning clients to issue a 424 'configuration request' to the PDP as specified in the COPS 425 Context Object. The Client Handle associated with the REQ message 426 originated by a provisioning client must be unique for that 427 client. The Client Handle is used to identify a specific request 428 state. Thus, one client can potentially open several configuration 429 request states, each uniquely identified by its handle. Different 430 request states are used to isolate similarly named configuration 431 information into non-overlapping contexts (or logically isolated 432 namespaces). Thus, a piece of named information is unique relative 433 to a particular client-type and is unique relative to a particular 434 request state for that client-type, even if the information was 435 similarly identified in other request states. Thus, the Client 436 Handle is part of the instance identification of the communicated 437 configuration information. 439 The config request message serves as a request from the PEP to the 440 PDP for provisioning policy data which the PDP may have for the 441 PEP, such as access control lists, etc. This includes policy the 442 PDP may have at the time the REQ is received as well as any future 443 policy data or updates to this data. 445 The config request message should include provisioning client 446 information to provide the PDP with client-specific configuration 447 or capability information about the PEP. The information provided 448 by the PEP should include client resource (e.g. queuing 449 capabilities) and default policy configuration (e.g. default role 450 combinations) information as well as references to existing policy 451 (i.e. PIB) incarnation data. This information typically does not 452 include all the information previously installed by a PDP but 453 rather should include checksums or shortened references to 454 previously installed information for synchronization purposes. 456 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 457 This information from the client assists the server in deciding 458 what types of policy the PEP can install and enforce. The format 459 of the information encapsulated in the provisioning Named ClientSI 460 data is described in section 5. Note that the config request 461 message is regenerated and sent to the PDP in response to the 462 receipt of a Synchronize State Request (SSQ) message. 464 The policy information supplied by the PDP must be consistent with 465 the named decision data defined for the policy provisioning 466 client. The PDP responds to the config request with a DEC message 467 containing any available provisioning policy data. 469 The REQ message has the following format: 471 ::= 472 473 474 [] 475 [] 477 Note that the COPS objects IN-Int, OUT-Int and LDPDecisions are 478 not included in a COPS-PR Request. 480 3.2. Decision (DEC) PDP -> PEP 482 The DEC message is sent from the PDP to a policy provisioning 483 client in response to the REQ message received from the PEP. The 484 Client Handle must be the same Handle that was received in the 485 corresponding REQ message. 487 The DEC message is sent as an immediate response to a 488 configuration request with the solicited message flag set in the 489 COPS message header. Subsequent DEC messages may also be sent at 490 any time after the original DEC message to supply the PEP with 491 additional/updated policy information without the solicited 492 message flag set in the COPS message header (as they are 493 unsolicited decisions). 495 Each DEC message may contain multiple decisions. This means a 496 single message can install some policies and delete others. In 497 general a COPS-PR decision message should contain at most one or 498 more deletes followed by one or more install decisions. This is 499 used to solve a precedence issue, not a timing issue: the delete 500 decision deletes what it specifies, except those items that are 501 installed in the same message. 503 The DEC message can also be used by the PDP to command the PEP to 504 open a new Request State or Delete an existing Request State as 505 identified by the Client-Handle. To accomplish this, COPS-PR 507 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 508 defines a new flag for the COPS Decision Flags object. The flag 509 0x02 is to be used by COPS-PR client-types and is hereafter 510 referred to as the "Request-State" flag. An Install decision 511 (Decision Flags: Command-Code=Install) with the Request-State flag 512 set in the COPS Decision Flags object will cause the PEP to issue 513 a new Request with a new Client Handle or else specify the 514 appropriate error in a COPS Report message. A Remove decision 515 (Decision Flags: Command-Code=Remove) with the Request-State flag 516 set in the COPS Decision Flags object will cause the PEP to send a 517 COPS Delete Request State (DRQ) message for the request state 518 identified by the Client Handle in the DEC message. Whenever the 519 Request-State flag is set in the COPS Decision Flags object in the 520 DEC message, no COPS Named Decision Data object can be included in 521 the corresponding decision (as it serves no purpose for this 522 decision flag). 524 A COPS-PR DEC message must be treated as a single "transaction", 525 i.e. either all the decisions in a DEC message succeed or they all 526 fail. This allows the PDP to delete some policies only if other 527 policies can be installed in their place. The DEC message has the 528 following format: 530 ::= 531 532 *() | 533 [] 535 ::= 536 537 [] 539 Note that the Named Decision Data (Provisioning) object is 540 included in a COPS-PR Decision when it is an Install or Remove 541 decision with no Decision Flags set. Other types of COPS decision 542 data objects (e.g. Stateless, Replacement) are not supported by 543 COPS-PR client-types. The Named Decision Data object MUST NOT be 544 included in the decision if the Decision Flags object Command-Code 545 is NULL (meaning there is no configuration information to install 546 at this time) or if the Request-State flag is set in the Decision 547 Flags object. 549 For each decision on the DEC message, the PEP performs the 550 operation specified in the Command-Code and Flags field in the 551 Decision Flags object on the Named Decision Data. For the policy 552 provisioning clients, the format for this data is defined in the 553 context of the Policy Information Base (see section 5). In 554 response to a DEC message, the policy provisioning client sends a 555 RPT message with the solicited message flag set back to the PDP to 556 inform the PDP of the action taken. 558 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 560 3.3. Report State (RPT) PEP -> PDP 562 The RPT message is sent from the policy provisioning clients to 563 the PDP to report accounting information associated with the 564 provisioned policy, or to notify the PDP of changes in the PEP 565 (Report-Type = 'Accounting') related to the provisioning client. 567 RPT is also used as a mechanism to inform the PDP about the action 568 taken at the PEP, in response to a DEC message. For example, in 569 response to an 'Install' decision, the PEP informs the PDP if the 570 policy data is installed (Report-Type = 'Success') or not (Report- 571 Type = 'Failure'). Reports that are in response to a DEC message 572 MUST set the solicited message flag in their COPS message header. 573 Reports can also be unsolicited and all unsolicited Reports MUST 574 NOT set the solicited message flag in their COPS message header. 575 Examples of unsolicited reports include 'Accounting' Report-Types, 576 that were not triggered by a specific DEC messages, or 'Failure' 577 Report-Types that indicate a change of state in a previously 578 successfully installed configuration. 580 The RPT message may contain provisioning client information such 581 as accounting parameters or errors/warnings related to a decision. 582 The data format for this information is defined in the context of 583 the policy information base (see section 5). The RPT message has 584 the following format: 586 ::= 587 588 589 [] 590 [] 592 4. COPS-PR Protocol Objects 594 The COPS Policy Provisioning clients encapsulate several new 595 objects within the existing COPS Named Client-specific information 596 object and Named Decision Data object. This section defines the 597 format of these new objects. 599 COPS-PR classifies policy data according to "bindings", where a 600 binding consists of a Policy Rule Identifier and the Policy Rule 601 Instance data, encoded within the context of the provisioning 602 policy information base (see section 5). 604 The format for these new objects is as follows: 606 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 607 0 1 2 3 608 +---------------+---------------+---------------+---------------+ 609 | Length | S-Num | S-Type | 610 +---------------+---------------+---------------+---------------+ 611 | 32 bit unsigned integer | 612 +---------------+---------------+---------------+---------------+ 614 S-Num and S-Type are similar to the C-Num and C-Type used in the 615 base COPS objects. The difference is that S-Num and S-Type are 616 used only for COPS-PR clients and are encapsulated within the 617 existing COPS Named ClientSI or Named Decision Data objects. The 618 S-Num identifies the general purpose of the object, and the S-Type 619 describes the specific encoding used for the object. All the 620 object descriptions and examples in this document use the Basic 621 Encoding Rules as the encoding type (S-Type = 1). Additional 622 encodings can be defined for the remaining S-Types in the future 623 (for example, XML string based encodings). 625 Length is a two-octet value that describes the number of octets 626 (including the header) that compose the object. If the length in 627 octets does not fall on a 32-bit word boundary, padding must be 628 added to the end of the object so that it is aligned to the next 629 32-bit boundary before the object can be sent on the wire. On the 630 receiving side, a subsequent object boundary can be found by 631 simply rounding up the stated object length of the current object 632 to the next 32-bit boundary. 634 4.1. Complete Policy Rule Identifier (PRID) 636 S-Num = 1, S-Type = 1 (Complete BER PRID), Length = variable. 638 This object is used to carry the identifier, or PRID, of a Policy 639 Rule Instance. The identifier is encoded following the rules that 640 have been defined for encoding SNMP Object Identifier (OID) 641 values. Specifically, PRID values are encoded using the 642 Type/Length/Value (TLV) format and initial sub-identifier packing 643 that is specified by the binary encoding rules [BER] used for 644 Object Identifiers in an SNMP PDU. 646 0 1 2 3 647 +---------------+---------------+---------------+---------------+ 648 | Length | S-Num = PRID | S-Type = BER | 649 +---------------+---------------+---------------+---------------+ 650 ... ... 651 | Policy Rule Identifier | 652 ... ... 653 +---------------+---------------+---------------+---------------+ 655 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 656 For example, a (fictitious) PRID equal to 1.3.6.1.2.2.8.1 would be 657 encoded as follows (values in hex): 659 06 07 2B 06 01 02 02 08 01 661 The entire PRID object would be encoded as follows: 663 00 0D - Length 664 01 - S-Num 665 01 - S-Type (Complete PRID) 666 06 07 2B 06 01 02 02 08 01 - Encoded PRID 667 00 00 00 - Padding 669 4.2. PRID Prefix(PPRID) 671 Certain operations, such as decision removal, can be optimized by 672 specifying a PRID prefix with the intent that the requested 673 operation be applied to all PRIs matching the prefix. PRID prefix 674 objects MUST only be used in the COPS protocol 675 operation where it may be more optimal to perform bulk decision 676 removal using class prefixes instead of a sequence of individual 677 operations. Other COPS operations, e.g. operations always require individual PRID specification. 680 S-Num = 2, S-Type = 1 (BER PRID Prefix), Length = variable. 682 0 1 2 3 683 +---------------+---------------+---------------+---------------+ 684 | Length | S-Num = PPRID | S-Type = BER | 685 +---------------+---------------+---------------+---------------+ 686 ... ... 687 | PRID Prefix | 688 ... ... 689 +---------------+---------------+---------------+---------------+ 691 Continuing with the previous example, a PRID prefix that is 692 equal to 1.3.6.1.2.2 would be encoded as follows (values in hex): 694 06 05 2B 06 01 02 02 696 The entire PRID object would be encoded as follows: 698 00 0B - Length 699 02 - S-Num = PRID Prefix 700 01 - S-Type = BER 701 06 05 2B 06 01 02 02 - Encoded PRID Prefix 702 00 - Padding 704 4.3. Encoded Policy Instance Data (EPD) 706 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 708 S-Num = 3, S-Type = 1, Length = variable. 710 This object is used to carry the encoded value of a Policy Rule 711 Instance. The PRI value, which contains all of the individual 712 values of the attributes that comprise the class, is encoded as a 713 series of TLV sub-components. Each sub-component represents the 714 value of a single attribute and is encoded following the BER. 715 0 1 2 3 716 +---------------+---------------+---------------+---------------+ 717 | Length | S-Num = EPD | S-Type = BER | 718 +---------------+---------------+---------------+---------------+ 719 ... ... 720 | BER Encoded PRI Value | 721 ... ... 722 +---------------+---------------+---------------+---------------+ 724 As an example, an instance of the filter class, defined in the QoS 725 Policy IP PIB [PIB], would be encoded as follows: 727 02 01 08 :filterIndex/INTEGER/Value = 8 728 40 04 C0 39 01 05 :filterDstAddr/IpAddress/Value = 192.57.1.5 729 40 04 FF FF FF FF :filterDstMask/IpAddress/Value = 255.255.255.255 730 40 04 00 00 00 00 :filterSrcAddr/IpAddress/Value = 0.0.0.0 731 40 04 00 00 00 00 :filterSrcMask/IpAddress/Value = 0.0.0.0 732 02 01 FF :filterDscp/Integer32/Value = -1 (not used) 733 02 01 06 :filterProtocol/INTEGER/Value = 6 (TCP) 734 05 00 :filterDstL4PortMin/NULL/not supported 735 05 00 :filterDstL4PortMax/NULL/not supported 736 05 00 :filterSrcL4PortMin/NULL/not supported 737 05 00 :filterSrcL4PortMax/NULL/not supported 738 02 01 01 :filterPermit/TruthValue/Value = 1 (true) 740 The entire EPD object would be encoded as follows: 742 00 30 - Length 743 03 - S-Num = EPD 744 01 - S-Type = BER 745 02 01 08 - filterIndex 746 40 04 C0 39 01 05 - filterDstAddr 747 40 04 FF FF FF FF - filterDstMask 748 40 04 00 00 00 00 - filterSrcAddr 749 40 04 00 00 00 00 - filterSrcMask 750 02 01 FF - filterDscp 751 02 01 06 - filterProtocol 752 05 00 - filterDstL4PortMin 753 05 00 - filterDstL4PortMax 755 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 756 05 00 - filterSrcL4PortMin 757 05 00 - filterSrcL4PortMax 758 02 01 01 - filterPermit 760 Note that attributes not supported within a class are still 761 returned in the EPD for a PRI. By convention, a NULL value is 762 returned for attributes that are not supported. In the previous 763 example, source and destination port number attributes are not 764 supported. 766 4.4. Global Provisioning Error Object (GPERR) 768 S-Num = 4, S-Type = 1, Length = 8. 770 0 1 2 3 771 +---------------+---------------+---------------+---------------+ 772 | Length | S-Num = GPERR | S-Type = BER | 773 +---------------+---------------+---------------+---------------+ 774 | Error-Code | Error Sub-code | 775 +---------------+---------------+---------------+---------------+ 777 The global provisioning error object has the same format as the 778 Error object in COPS [COPS], except with C-Num and C-Type replaced 779 by the S-Num and S-Type values shown. The global provision error 780 object is used to communicate general errors that do not map to a 781 specific PRC. 783 The following global error codes are defined: 785 availMemLow(1), 786 availMemExhausted(2), 787 unknownASN.1Tag(3), 788 maxMsgSizeExceeded(4), 789 unknownError(5) 791 Note: For the unknownASN.1Tag, the erroneous tag type 792 MUST be specified in the Error Sub-Code field 794 4.5. PRC Class Provisioning Error Object (CPERR) 796 S-Num = 5, S-Type = 1, Length = 8. 798 0 1 2 3 799 +---------------+---------------+---------------+---------------+ 800 | Length | S-Num = CPERR | S-Type = BER | 801 +---------------+---------------+---------------+---------------+ 802 | Error-Code | Error Sub-code | 803 +---------------+---------------+---------------+---------------+ 805 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 807 The class-specific provisioning error object has the same format 808 as the Error object in COPS [COPS], except with C-Num and C-Type 809 replaced by the S-Num and S-Type values shown. The class-specific 810 error object is used to communicate errors relating to specific 811 PRCs and MUST have an associated Error PRID Object. 813 The following Generic Class-Specific errors are defined: 815 priSpaceExhausted(1), 816 priInstanceInvalid(2), 817 attrValueInvalid(3), 818 attrValueSupLimited(4), 819 attrEnumSupLimited(5), 820 attrMaxLengthExceeded(6), 821 attrReferenceUnknown(7), 822 priNotifyOnly(8), 823 unknownPrc(9), -- install a PRI of a class not supported by PEP 824 noAccess(10), -- install a PRI of a class whose access is notify 825 tooFewAttrs(11), -- recvd PRI has fewer attributes than required. 826 invalidAttrType(12), -- recvd PRI has an attribute of the wrong 827 type. 828 deletedInRef(13), -- deleted PRI is still referenced by other 829 (non) deleted PRIs 830 priSpecificError(14) 832 Note: For the priSpecificError code the Error Sub-code field 833 contains the PRC specific error code 835 4.6. Error PRID Object (ErrorPRID) 837 S-Num = 6, S-Type = 1 (BER ErrorPRID), Length = variable. 839 This object is used to carry the identifier, or PRID, of a Policy 840 Rule Instance that caused an installation error or could not be 841 installed or removed. The identifier is encoded and formatted 842 exactly as in the PRID object as described in section 4.1. 844 5. COPS-PR Client-Specific Data Formats 846 This section describes the format of the named client specific 847 information for the COPS policy provisioning client. ClientSI 848 formats are defined for Decision message's Named Decision Data 849 object, the Request message's Named ClientSI object and Report 850 message's Named ClientSI object. The actual content of the data is 851 defined by the policy information base for a specific provisioning 852 client type (see below). 854 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 856 5.1. Named Decision Data 858 The formats encapsulated by the Named Decision Data object for the 859 policy provisioning client-types depends on the type of decision. 860 Install and Remove are the two types of decisions that dictate the 861 internal format of the COPS Named Decision Data object and require 862 its presence. Install and Remove refer to the 'Install' and 863 'Remove' Command-Code, respectively, specified in the COPS 864 Decision Flags Object when no Decision Flags are set. The data, 865 in general, is composed of one or more bindings. Each binding 866 associates a PRID object and a EPD object. The PRID object is 867 always present in both install and remove decisions, the EPD 868 object MUST be present in the case of an install decision and MUST 869 NOT be present in the case of a remove decision. 871 The format for this data is encapsulated within the COPS Named 872 Decision Data object as follows: 874 < Decision: Named Data> ::= < | 875 > 877 ::= *( ) 879 ::= *(|) 881 Note that PRID objects in a Remove Decision may specify PRID 882 prefix values. Explicit and implicit deletion of installed 883 policies is supported by a client. Install Decision data MUST be 884 explicit (i.e., PRID prefix values are illegal and MUST be 885 rejected by a client). 887 5.2. ClientSI Request Data 889 The provisioning client request data will use same bindings as 890 described above. The format for this data is encapsulated in the 891 COPS Named ClientSI object as follows: 893 ::= <*( )> 895 5.3. Policy Provisioning Report Data 897 The COPS Named ClientSI object is used in the RPT message in 898 conjunction with the accompanying COPS Report Type object to 899 encapsulate COPS-PR report information from the PEP to the PDP. 900 Report types can be 'Success' or 'Failure', indicating to the PDP 901 that a particular set of provisioning policies has been either 902 successfully or unsuccessfully installed/removed on the PEP, or 903 'Accounting'. 905 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 906 5.3.1. Success and Failure Report-Type Data Format 908 Report-types can be 'Success' or 'Failure' indicating to the PDP 909 that a particular set of provisioning policies has been either 910 successfully or unsuccessfully installed/removed on the PEP. The 911 provisioning report data consists of the bindings described above 912 and global and specific error/warning information. 914 Specific errors are associated with a particular policy rule. For 915 a 'Success' Report-Type, a specific error is an indication of a 916 warning related to a specific policy that has been installed, but 917 that is not fully implemented (e.g., its parameters have been 918 approximated) as identified by the ErrorPRID object. For a 919 'Failure' Report-Type, this is an error code specific to a 920 binding, again, identified by the ErrorPRID object. Specific 921 errors may also include regular bindings to carry 922 additional information in a generic manner so that the specific 923 errors/warnings may be more verbosely described and associated 924 with the erroneous ErrorPRID object. 926 Global errors are not tied to a specific ErrorPRID. In a 'Success' 927 RPT message, a global error is an indication of a general warning 928 at the PEP level (e.g., memory low). In a 'Failure' RPT message, 929 this is an indication of a general error at the PEP level (e.g., 930 memory exhausted). 932 In the case of a 'Failure' Report-Type the PEP MUST report at 933 least the first error and should report as many errors as 934 possible. In this case the PEP MUST roll-back its configuration to 935 the last good transaction before the erroneous Decision message 936 was received. 938 The format for this data is encapsulated in the COPS Named 939 ClientSI object as follows: 941 ::= <[] *()> 943 ::= *() 945 5.3.2. Accounting Report-Type Data Format 947 Additionally, reports can be used to carry accounting information 948 when specifying the 'Accounting' Report-Type. This accounting report 949 message will typically carry statistical or event information 950 related to the installed configuration for use at the PDP. This 951 information is encoded as one or more bindings that 952 generally describe the accounting information being reported from 953 the PEP to the PDP. 955 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 956 The format for this data is encapsulated in the COPS Named ClientSI 957 object as follows: 959 ::= <*()> 961 6. Common Operations 963 This section describes, in general, typical exchanges between a 964 PDP and Policy Provisioning COPS client. 966 First, a TCP connection is established between the client and 967 server and the PEP sends a Client-Open message specifying a COPS- 968 PR client-type, Policy Provisioning client. If the PDP supports 969 the specified provisioning client type, the PDP responds with a 970 Client-Accept (CAT) message. If the client-type is not supported, 971 a Client-Close (CC) message is returned by the PDP to the PEP, 972 possibly identifying an alternate server that is known to support 973 the policy for the provisioning client-type specified. 975 After receiving the CAT message, the PEP can send requests to the 976 server. The REQ from a policy provisioning client contains a COPS 977 'Configuration Request' context object and, optionally, any 978 relevant named client specific information from the PEP. The 979 information provided by the PEP should include available client 980 resources (e.g., supported classes/attributes) and default policy 981 configuration information as well as references to existing policy 982 (i.e., PIB) incarnation data. The configuration request message 983 from a provisioning client serves two purposes. First, it is a 984 request to the PDP for any provisioning configuration data which 985 the PDP may currently have that is suitable for the PEP, such as 986 access control filters, etc., given the information the PEP 987 specified in its REQ. Also, the configuration request effectively 988 opens a channel that will allow the PDP to asynchronously send 989 policy data to the PEP, as the PDP decides is necessary, as long 990 as the PEP keeps its request state open (ie. As long as the PEP 991 does not send a DRQ with the request state's Client Handle). This 992 asynchronous data may be new policy data or an update to policy 993 data sent previously. 995 After the PEP sends a REQ, if the PDP has Policy Provisioning 996 policy configuration information for the client, that information 997 is returned to the client in a DEC message containing the Policy 998 Provisioning client policy data within the COPS Named Decision 999 Data object and specifying an "Install" Command-Code in the 1000 Decision Flags object. If no filters are defined, the DEC message 1001 will simply specify that there are no filters using the "NULL 1002 Decision" Command-Code in the Decision Flags object. As the PEP 1003 MUST specify a Client Handle in the request message, the PDP MUST 1004 process the Client Handle and copy it in the corresponding 1006 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 1007 decision message. A DEC message must be issued by the PDP with the 1008 Solicited Message Flag set in the COPS message header, regardless 1009 of whether or not the PDP has any configuration information for 1010 the PEP at the time of the request. This is to prevent the PEP 1011 from timing out the REQ and deleting the Client Handle. 1013 The PDP can then add new policy data or update/delete existing 1014 state by sending subsequent unsolicited DEC message(s) to the PEP, 1015 with the same Client Handle. The PEP is responsible for removing 1016 the Client handle when it is no longer needed, for example when 1017 the interface goes down, and informing the PDP that the Client 1018 Handle is to be deleted via the COPS DRQ message. 1020 For Policy Provisioning purposes, access state, and access 1021 requests to the policy server can be initiated by other sources 1022 besides the PEP. Examples of other sources include attached users 1023 requesting network services via a web interface into a central 1024 management application, or H.323 servers requesting resources on 1025 behalf of a user for a video conferencing application. When such a 1026 request is accepted, the edge device affected by the decision (the 1027 point where the flow is to enter the network) must be informed of 1028 the decision. Since the PEP in the edge device did not initiate 1029 the request, the specifics of the request, e.g. flowspec, packet 1030 filter, and PHB to apply, must be communicated to the PEP by the 1031 PDP. This information is sent to the PEP using the Decision 1032 message containing Policy Provisioning Named Decision Data objects 1033 in the COPS Decision object as specified. Any updates to the state 1034 information, for example in the case of a policy change or call 1035 tear down, is communicated to the PEP by subsequent DEC messages 1036 containing the same Client Handle and the updated Policy 1037 Provisioning request state. Updates can specify that policy data 1038 is to be deleted or installed. 1040 PDPs may also command the PEP to open a new Request State or 1041 delete an exiting one by issuing a decision with the Decision 1042 Flags object's Request-State flag set. If the command-code is 1043 "install", then the PDP is commanding the PEP to create a new 1044 Request State, and therefore issue a new REQ message specifying a 1045 new Client Handle or otherwise issue a "Failure" RPT specifying an 1046 error condition. Each request state represents an independent and 1047 logically non-overlapping namespace, identified by the Client 1048 Handle, on which transactions may be performed. Other existing 1049 Request States will be unaffected by the new request state as they 1050 are independent (thus, no instances of configuration data within 1051 one Request State can be affected by DECs for another Request 1052 State as identified by the Client Handle). If the command-code is 1053 "Remove", then the PDP is commanding the PEP to delete the 1054 existing Request-State specified by the DEC message's Client 1055 Handle, thereby causing the PEP to issue a DRQ message for this 1056 Handle. 1058 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 1060 The PEP acknowledges the DEC message and action taken by sending a 1061 RPT message with a "Success" or "Failure" Report-Type object with 1062 the Solicited Message Flag set in the COPS message header. This 1063 serves as an indication to the PDP that the requestor (e.g. H.323 1064 server) can be notified that the request has been accepted by the 1065 network. If the PEP needs to reject the DEC operation for any 1066 reason, a RPT message is sent with a Report-Type of value 1067 "Failure" and optionally a Client Specific Information object 1068 specifying the policy data that was rejected. The PDP can then 1069 respond to the requestor accordingly. 1071 The PEP can report to the PDP the local status of any installed 1072 request state when appropriate. This information is sent in a 1073 Report-State (RPT) message with the "Accounting" flag set. The 1074 request state being reported is referenced by the Client Handle 1075 associated with the request state and the client specific data 1076 identifier. 1078 Finally, Client-Close (CC) messages are used to cancel the 1079 corresponding Client-Open message. The CC message informs the 1080 other side that the client type specified is no longer supported. 1082 7. Fault Tolerance 1084 When communication is lost between PEP and PDP, the PEP attempts 1085 to re-establish the TCP connection with the PDP it was last 1086 connected to. If that server cannot be reached, then the PEP 1087 attempts to connect to a secondary PDP, assumed at this time to be 1088 manually configured at the PEP. 1090 When a connection is finally re-established with a PDP, the PEP 1091 sends a OPN message with a object providing the 1092 address of the most recent PDP for which it is still caching 1093 decisions. If no decisions are being cached on the PEP (due to 1094 reboot or TTL timeout of state) the PEP must not include the last 1095 PDP address information. Based on this information, the PDP may 1096 request the PEP to re-synch its current state information (by 1097 issuing a COPS SSQ message). If, after re-connecting, the PDP does 1098 not request the synchronization, the client can assume the server 1099 recognizes it and the current state at the PEP is correct. Any 1100 state changes which occurred at the PEP while the connection was 1101 lost must be reported to the PDP via the PEP sending an updated 1102 REQ message. On the other hand, if re-synchronization is 1103 requested, the PEP MUST reissue any REQ messages it generated 1104 during initial connection establishment and the PDP MUST issue DEC 1105 messages to delete either individual PRIDs or prefixes as 1106 appropriate to ensure a consistent known state at the PEP. 1108 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 1109 While the PEP is disconnected from the PDP, the request state at 1110 the PEP is to be used for policy decisions. If the PEP cannot re- 1111 connect in some pre-specified period of time, the request state is 1112 to be deleted and the associated Handles removed. The same holds 1113 true for the PDP; upon detecting a failed TCP connection, the 1114 time-out timer is started for the request state associated with 1115 the PEP and the state is removed after the specified period 1116 without a connection. 1118 7.1. Security Considerations 1120 The use of COPS for Policy Provisioning introduces no new security 1121 issues over the base COPS protocol [COPS]. The security mechanism 1122 described in that document should be deployed in a COPS-PR 1123 environment. 1125 8. Acknowledgements 1127 This document has been developed with active involvement 1128 from a number of sources. The authors would specifically like to 1129 acknowledge the valuable input given by Michael Fine and Scott Hahn. 1131 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 1132 9. References 1134 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., 1135 Sastry, A., "The COPS (Common Open Policy Service) 1136 Protocol", IETF RFC 2748, Proposed Standard, January 2000. 1138 [RAP] Yavatkar, R., et al., "A Framework for Policy Based 1139 Admission Control",IETF RFC 2753, January 2000. 1141 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, 1142 S., "Resource Reservation Protocol (RSVP) Version 1 1143 Functional Specification", IETF RFC 2205, Proposed 1144 Standard, September 1997. 1146 [ASN1] Information processing systems - Open Systems 1147 Interconnection, "Specification of Abstract Syntax Notation 1148 One (ASN.1)", International Organization for 1149 Standardization, International Standard 8824, December 1150 1987. 1152 [BER] Information processing systems - Open Systems 1153 Interconnection - Specification of Basic Encoding Rules for 1154 Abstract Syntax Notation One (ASN.1), International 1155 Organization for Standardization. International Standard 1156 8825, (December, 1987). 1158 [RFC2475] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, W. 1159 Weiss, "An Architecture for Differentiated Service," RFC 1160 2475, December 1998. 1162 [PIB] M. Fine, K. McCloghrie, S. Hahn, K. Chan, A. Smith, "An 1163 Initial Quality of Service Policy Information Base for 1164 COPS-PR Clients and Servers", draft-mfine-cops-pib-02.txt, 1165 October 1999. 1167 V2SMI] McCloghrie, K., Perkins, D., Schoenwaelder, J., Case, J., 1168 Rose, M. and S. Waldbusser, "Structure of Management 1169 Information Version 2(SMIv2)", STD 58, RFC 2578, April 1170 1999. 1172 [RFC2234] D. Crocker, P. Overell, " Augmented BNF for Syntax 1173 Specifications: ABNF", RFC 2234, November 1997. 1175 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 1177 10. Author Information 1179 Francis Reichmeyer IPHighway Inc. 1180 Phone: (201) 585-0800 Parker Plaza, 16th Floor 1181 Email: FranR@iphighway.com 400 Kelby St. 1182 Fort-Lee, NJ 07024 1183 Shai Herzog 1184 Phone: (201) 585-0800 1185 Email: Herzog@iphighway.com 1187 Kwok Ho Chan Nortel Networks, Inc. 1188 Phone: (978) 916-8175 600 Technology Park Drive 1189 Email: kchan@nortelnetworks.com Billerica, MA 01821 1191 David Durham Intel 1192 Phone: (503) 264-6232 2111 NE 25th Avenue 1193 Email: david.durham@intel.com Hillsboro, OR 97124 1195 Raj Yavatkar 1196 Phone: (503) 264-9077 1197 Email: raj.yavatkar@intel.com 1199 Silvano Gai Cisco Systems, Inc. 1200 Phone: (408) 527-2690 170 Tasman Dr. 1201 Email: sgai@cisco.com San Jose, CA 95134-1706 1203 Keith McCloghrie 1204 Phone: (408) 526-5260 1205 Email: kzm@cisco.com 1207 Andrew Smith Extreme Networks 1208 Phone: +1 408 579 2821 3585 Monroe St. 1209 Email: andrew@extremenetworks.com Santa Clara CA 95051 1210 USA 1212 John Seligson Nortel Networks, Inc. 1213 Phone: (408) 495-2992 4401 Great America Parkway 1214 Email:jseligso@nortelnetworks.com Santa Clara, CA 95054 1216 Internet Draft COPS Usage for Policy Provisioning 10-Mar-00 1217 11. Full Copyright Notice 1219 Copyright (C) The Internet Society (1997). All Rights Reserved. 1221 This document and translations of it may be copied and furnished to 1222 others, and derivative works that comment on or otherwise explain it 1223 or assist in its implementation may be prepared, copied, published 1224 and distributed, in whole or in part, without restriction of any 1225 kind, provided that the above copyright notice and this paragraph are 1226 included on all such copies and derivative works. However, this 1227 document itself may not be modified in any way, such as by removing 1228 the copyright notice or references to the Internet Society or other 1229 Internet organizations, except as needed for the purpose of 1230 developing Internet standards in which case the procedures for 1231 copyrights defined in the Internet Standards process must be 1232 followed, or as required to translate it into languages other than 1233 English. 1235 The limited permissions granted above are perpetual and will not be 1236 revoked by the Internet Society or its successors or assigns. 1238 This document and the information contained herein is provided on an 1239 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 1240 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 1241 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 1242 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 1243 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.