idnits 2.17.1 draft-ietf-rap-cops-ds-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) 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 the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. ** Expected the document's filename to be given on the first page, but didn't find any == 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 a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 8. Security' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There are 311 instances of too long lines in the document, the longest one being 6 characters in excess of 72. ** The abstract seems to contain references ([COPS]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 152 has weird spacing: '...ons and reque...' == Line 317 has weird spacing: '...es) and s...' == Line 627 has weird spacing: '... client in...' == Couldn't figure out when the document was first submitted -- there may comments or warnings related to the use of a disclaimer for pre-RFC5378 work that could not be issued because of this. Please check the Legal Provisions document at https://trustee.ietf.org/license-info to determine if you need the pre-RFC5378 disclaimer. -- The document date (August 1998) is 9385 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 section? 'COPS' on line 800 looks like a reference -- Missing reference section? 'ASN1' on line 823 looks like a reference -- Missing reference section? 'RAP' on line 804 looks like a reference -- Missing reference section? 'RSVP' on line 818 looks like a reference -- Missing reference section? 'E2E' on line 808 looks like a reference -- Missing reference section? 'RFC1832' on line 829 looks like a reference Summary: 11 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COPS Usage for Differentiated Services August 1998 4 Network Working Group Francis Reichmeyer 5 Internet Draft Kwok Chan 6 Draft-ietf-RAP-COPS-DS-00.txt Bay Networks, Inc. 7 Expiration Date: January 1999 David Durham 8 Raj Yavatkar 9 Intel 10 Silvano Gai 11 Keith McCloghrie 12 Cisco Systems, Inc. 13 Shai Herzog 14 IPHighway 15 August 1998 17 COPS Usage for Differentiated Services 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "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.is.co.za (Africa), nic.nordu.net (Europe), 34 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 35 ftp.isi.edu (US West Coast). 37 Abstract 39 There is a clear need for relatively simple and coarse methods of 40 providing differentiated classes of service for Internet traffic, to 41 support various types of services, and specific business 42 requirements. The IETF has chartered the Differentiated Service WG to 43 define the differentiated services architecture and a common language 44 for differentiated services. 46 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 47 1] 48 COPS Usage for Differentiated Services August 1998 50 In parallel, the IETF RSVP Admission Policy (RAP) WG has defined the 51 COPS (Common Open Policy Service) protocol [COPS]. 53 This document describes enhancements to the Common Open Policy 54 Service (COPS) protocol to support policy services in a 55 Differentiated Services (diff serv) environment. Further 56 modifications to COPS for diff serv may be proposed in the future, 57 but what is presented here is thought to be the minimum necessary 58 additions. 60 Table of contents 62 1. Terminology ......................................................3 63 2. Introduction ..........................Error! Bookmark not defined. 64 2.1 Basic Model...................................................6 65 3. The definition of the Policy Tree ................................7 66 3.1 Description of the Policy Tree................................8 67 3.2 Operations Supported On a PI..................................8 68 3.3 An example of a PIB...........................................8 69 4. COPS Diff Serv Client Data ......................................10 70 4.1 Policy Identifier (PID)......................................11 71 4.2 XDR Encoded Policy Instance Data (XPD).......................11 72 4.3 Diff Serv Decision Data......................................12 73 4.4 Diff Serv Request Data.......................................12 74 4.5 Diff Serv Report Data........................................12 75 4.5.1 Commit Data .............................................13 76 4.5.2 No Commit Data ..........................................13 77 4.5.3 Accounting Data .........................................13 78 5. Message Content .................................................13 79 5.1 Request (REQ) PEP -> PDP...................................13 80 5.2 Decision (DEC) PDP -> PEP..................................14 81 5.3 Report State (RPT) PEP -> PDP..............................15 82 6. Common Operation ................................................15 83 7. Fault Tolerance .................................................17 84 8. Security ........................................................17 85 9. References ......................................................17 86 10. Author Information .............................................18 88 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 89 2] 90 COPS Usage for Differentiated Services August 1998 92 1. Terminology 94 o ACL: Access Control List. 96 o COPS (Common Open Policy Service): client/server model for 97 supporting policy control [COPS]; 99 o Instance Identifier: one or more of the PC attributes the values of 100 which are used as part of the identification of a PI. 102 o Object: this term is used in the same sense as in COPS 103 specification. An object is identified by its C-num and C-type. 105 o PC (Policy Class): a type of policy data item. In object oriented 106 terminology this is equivalent to a class. It inherits from PC. A 107 PC defines a vector of attributes. Each attribute has a syntax type 108 that is either primitive or refined. It also overrides the READ and 109 WRITE methods and defines new error sub-codes. 111 o PI (Policy Instance): an instance of a PC. Potentially there are 112 multiple instances of the same PC. The value of a PI consist of a 113 vector of values, one value for each attribute in the PC's vector 114 of attributes. 116 o PDP (Policy Decision Point): a network entity where policy 117 decisions are made 119 o PEP (Policy Enforcement Point): network device where policy 120 decisions are enforced. 122 o PIB (Policy Information Base): policy objects are accessed via a 123 virtual information store, termed the Policy Information Base or 124 PIB. Objects in the PIB are defined using Abstract Syntax Notation 125 One (ASN.1) [ASN1]. 127 o PID (Policy IDentifier): the name which identifies a particular PI 128 or PC. It has a hierarchical structure of the form 1.3.4.2.7, where 129 the first part identifies the PC (i.e., 1.3.4) and the last part is 130 the value of the PII (Policy Instance Identifier), which identifies 131 the instance (i.e. 2.7). The PII is null in the case of a PC. 133 o XPD: XDR Encoded Policy Instance Data. 135 2. Introduction 136 The Common Open Policy Service (COPS) protocol is a query response 137 protocol used to exchange policy information between a network policy 139 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 140 3] 141 COPS Usage for Differentiated Services August 1998 143 server and a set of clients [COPS]. COPS is being developed within 144 the RSVP Admission Policy Working Group (RAP WG) of the IETF, 145 primarily for use as a mechanism for providing policy-based admission 146 control over requests for network resources [RAP]. 148 The underlying assumption in the RAP framework is that applications 149 or endsystems use the RSVP [RSVP] signaling protocol to communicate 150 Integrated Services (int serv) reservation requests to the network 151 nodes along the path of a flow. These reservation requests carry 152 necessary flow specifications and requests for a flow to receive one 153 of the defined Integrated Services, Controlled Load or Guaranteed. In 154 the int serv model, the RSVP messages themselves contain all the 155 necessary information needed at the networking device to classify and 156 service the flow [RSVP]. This information includes the session 157 identifier (source and destination addresses, port numbers, and 158 transmission protocol), flowspec token bucket parameters, and 159 requested service. 160 As shown I Figure 1, the network device contacts a policy decision 161 point (PDP) to make the policy-based admission control decision. 162 Then, the policy server (PDP) is simply required to return a 163 Decision, such as "accept" and the network device acts as a policy 164 enforcement point (PEP) and uses the session information and intserv 165 srvice parameters to classify and service the packets belonging to 166 the flow. 168 (router, switch) policy server 170 . 171 _ ---------------- ________ --------______ 172 | | | | ______ 173 . 174 | Network Node | | | 175 . 176 | ----- ___ | | | 177 | | | | | | 178 . 179 | | PEP |<-----|------->| PDP | 180 . 181 | |_____| | |_____ | 182 . 183 | ----- | | | 184 . 185 |________________| | | 186 ---------------- -------- 188 Figure 1: Under the RAP framework, network elements such as a 189 router or a switch contact the PDP for policy-based admission control 191 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 192 4] 193 COPS Usage for Differentiated Services August 1998 195 when a resource reservation request is received. 197 Providing policy services in a diff serv environment requires some 198 different assumptions about the admission control mechanisms used in 199 the network. First, there may be no explicit signaling from sources 200 of traffic requesting a particular service as in the case of an 201 intserv network. Second, requests for allocation of resources to 202 differentiated services may arrive at the policy server from entities 203 other than a PEP. Examples of such sources include attached users 204 requesting network services via a web interface into a central 205 management application, or H.323 servers requesting resources on 206 behalf of a user for a video conferencing application. Requests of 207 this sort require some policy decision to be made to ensure the 208 requesting user/application has permission to use the requested 209 services and that the resources are available. Once the decision is 210 made, the PDP must configure one or more PEPs to provision necessary 211 resources for services requested. In addition, the PDP may also pass 212 to the PEP provisioning decisions about resources related to flows of 213 a more static nature, such as long-term SLAs established across 214 boundaries of adjacent ISP networks. 216 In summary, the interaction between the PDP and PEP is different in 217 at least two respects from that in the case of the intserv 218 environment. First, the resource provisioning requests may originate 219 at places other than a PEP. Second, once the PDP makes a policy 220 decision to allocate resources for a service class or a flow 221 aggregate, it must pass on the sufficient information (such as packet 222 classification filters, traffic shaper parameters) to the PEPs so 223 that PEPs can implement policy decisions. This draft describes the 224 usage of the COPS protocol for communicating this information between 225 diff serv clients (PEPs) and the policy servers. 227 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 228 5] 229 COPS Usage for Differentiated Services August 1998 231 2.1 Basic Model 233 Figure 2 shows a sample network configuration for a diffserv 234 environment. Edge routers and boundary routers are located at the 235 boundary of diffserv domains as described in [draft-nichols-diff- 236 serv-arch-00.txt]. The BB is responsible for admission control 237 functions and resource provisioning. In the COPS model, the PDP is 238 part of the bandwidth broker that manages resources within a diffserv 239 domain. Both edge routers and boundary routers act as PEPs and 240 communicate with BBs using COPS for exchange of policy information. 241 The internal organization of the BB and policy functionality may 242 vary: the policy server and BB may be separate entities in which case 243 the BB, upon receiving COPS messages from the PEP, consults the 244 policy server to make its decision. 246 ---- ---- 247 | BB | | BB | 248 | | | | 249 _---- ---- 250 ^ ^ 251 | / 252 | / 253 | | 255 . 256 / Stub \ / Transit \ / Stub \ 257 . 258 / Network \ / Network \ / Network \ 259 |---| | |---| |---| |---| |---| | |---| 260 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 261 |---| | |-- | |---| |---| |---| | |---| 262 \ / \ / \ / 263 \ / \ / \ / 265 Figure 2: A sample Network Configuration in which 266 Edge Routers (ER) and Boundary routers (BR) in the stub and transit 267 networks communicate with the corresponding bandwidth brokers in 268 their domain. 270 To allow for use of COPS for diff-serv specific communication and to 271 distinuish diff-serv specific communication from other uses of COPS, 272 we have added a new client type to COPS (client type = DiffServ 273 client). In an environment where a stub network uses intserv/RSVP 274 signaling for admission control and uses diffserv-based policy server 275 for managing resources to a transit network, use of two different 277 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 278 6] 279 COPS Usage for Differentiated Services August 1998 281 client types (RSVP vs diffserv) may require a method that correlates 282 the two admission control decision. The issue of combining int serv 283 and diff serv to provide an end-to-end QoS solution is currently 284 being studied [E2E]. Also, the RSVP WG is currently planning on 285 addressing the use of RSVP within the differentiated services QoS 286 model. 288 3. The definition of the Policy Tree 290 This section defines data format for the diff serv client specific 291 information carried in the Decision, Request ClientSI, and Report 292 ClientSI objects. Diff serv client specific data may be defined for 293 the other objects in the future. 295 The policy tree is based on SMI and MIBs. COPS for RSVP does not need 296 a policy tree, since the information exchanged has a simple format. 297 However, the COPS protocol does not preclude the use of data, 298 represented in such a way, with RSVP. COPS for DiffServ needs much 299 more structure, since it needs to represent policies, mappings, ACLs, 300 interfaces etc. 302 The policy tree is structured in the following way: 304 -------+-------+----------+---PC--+--PI 305 | | | +--PI 306 | | +---PC-----PI 307 | +---PC--+--PI 308 | | +--PI 309 | | +--PI 310 | | +--PI 311 | | +--PI 312 | +---PC-----PI 313 +---PC---PI 315 Figure 1: Example of a Policy Tree 317 PIs (Policy Instances) and s 318 PC (Policy Classes) have names (PIDs: 319 Policy Identifiers). Names have a hierarchical structure of the form 320 1.3.4.2.7, where the first part identifies the PC (e.g., 1.3.4) and 321 the last part identifies the instance (e.g. 2.7). 323 The policy tree names all the policy data classes and instances and 324 this creates a common view of the policy organization between the 326 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 327 7] 328 COPS Usage for Differentiated Services August 1998 330 client (PEP) and the server (PDP). Therefore, when the PEP receives 331 data from the PDP, the data itself specifies what a PEP is supposed 332 to do with the data. The current granularity of access, i.e., the 333 atomicity of replacement, is proposed as a vector of values. 335 Note that the PCs/PIs in the above diagram are each a vector of 336 values. This proposal is that the hierarchy of PCs/PIs is for benefit 337 of human understanding, not for programmatic understanding, or 338 inheritance. 340 3.1 Description of the Policy Tree 342 The Policy Tree is described using SMI and PIBs. SMI and PIBs are 343 defined based on the ASN.1 data definition language [ASN1]. This does 344 not imply that the representation of the policy information on the 345 wire must follow ASN.1: on the contrary, the proposal it to follow 346 COPS conventions and to define a new objects (XDR Encoded Policy 347 Instance Data, see Section 4.2) which contains an XDR encoding. XDR 348 is a standard [RFC1832] for the description and encoding of data. 350 3.2 Operations Supported On a PI 352 The following operations are supported on a PI: 354 o Install - creates a new instance of a PC, i.e. a new PI, or 355 modifies an existing instance. The instance is automatically 356 enabled. Parameters to this operation are a PID (see Section 4.1) 357 and an "XPD (XDR encoded policy instance Data)" containing the 358 value to assign to the new PI see (Section 4.2). The XPD specifies 359 all the attributes of the new PI. 361 o Delete - This operation is used to delete an instance of a PC. The 362 parameter is a PID (see Section 4.1). 364 o Enable. This operation is used to enable a PI. 366 o Disable. This operation is used to disable a PI. 368 3.3 An example of a PIB 370 This section contains a simple example of a PIB describing a simple 371 set of filters for IP packets. Each filter is able to match either 372 the source IP address, the destination IP address or both. This 374 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 375 8] 376 COPS Usage for Differentiated Services August 1998 378 example is provided only for the benefit of understanding how a PIB 379 is structured. It is not supposed to describe any actual policy data. 381 policyFilterPIB OBJECT IDENTIFIER ::= { policyPIB 1 } 383 ipHeaderFilterTable OBJECT-TYPE 384 SYNTAX SEQUENCE OF IpHeaderFilterEntry 385 MAX-ACCESS not-accessible 386 STATUS current 387 DESCRIPTION "This table contains a simple ACL, i.e. one or 388 more IP filters." 390 ::= {policyFilterPIB 1} 392 ipHeaderFilterEntry OBJECT-TYPE 393 SYNTAX IpHeaderFilterEntry 394 MAX-ACCESS write-only 395 STATUS current 396 DESCRIPTION "Each row of the table has four columns. The 397 ipHeaderFilterIndex uniquely identifies a particular IP 398 filter. The ipHeaderFilterMatchType specifies the type of 399 match (source only, destination only, source and destination). 400 The ipHeaderFilterSourceAddress and 401 ipHeaderFilterDestinationAddress contain the source and 402 destination IP addresses." 404 INDEX {ipHeaderFilterIndex} 406 ::= {ipHeaderFilterTable 1} 408 IpHeaderFilterEntry ::= SEQUENCE { 409 ipHeaderFilterIndex INTEGER, 410 ipHeaderFilterMatchType BITS, 411 ipHeaderFilterSourceAddress IpAddress, 412 ipHeaderFilterDestinationAddress IpAddress 413 } 415 ipHeaderFilterIndex OBJECT-TYPE 416 SYNTAX INTEGER 417 MAX-ACCESS not-accessible 418 STATUS current 419 DESCRIPTION "The index of the table, used to identify each 420 individual IP filter" 422 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 423 9] 424 COPS Usage for Differentiated Services August 1998 426 ::= {ipHeaderFilterEntry 1} 428 ipHeaderFilterMatchType OBJECT-TYPE 429 SYNTAX BITS { 430 matchSource (0), 431 matchDestination (1) 432 } 433 MAX-ACCESS not-accessible 434 STATUS current 435 DESCRIPTION "This field indicates which one or more of the 436 addresses are required to match the corresponding addresses 437 of the IP packet." 439 ::= {ipHeaderFilterEntry 2} 441 ipHeaderFilterSourceAddress OBJECT-TYPE 442 SYNTAX IpAddress 443 MAX-ACCESS not-accessible 444 STATUS current 445 DESCRIPTION "IP source address to be matched against the 446 packet in the event the ipHeaderFilterMatchType has the 447 corresponding bit set. 449 ::= {ipHeaderFilterEntry 3} 451 ipHeaderFilterDestinationAddress OBJECT-TYPE 452 SYNTAX IpAddress 453 MAX-ACCESS not-accessible 454 STATUS current 455 DESCRIPTION "IP destination address to be matched against the 456 packet in the event the ipHeaderFilterMatchType has the 457 corresponding bit set. 459 ::= {ipHeaderFilterEntry 4} 461 4. COPS Diff Serv Client Data 463 The COPS-DS extensions define a new client type: 465 Client Type = 2; Diff Serv Client 467 Diff serv specific information is sent in a COPS message containing a 468 Common Header with the Diff Serv Client type specified: 470 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 471 10] 472 COPS Usage for Differentiated Services August 1998 474 0 1 2 475 3 476 +----------------+----------------+----------------+----------------+ 477 | Version| //// | Op Code | Client Type = 0x02 | 478 +----------------+----------------+----------------+----------------+ 479 | Message Length | 480 +----------------+----------------+----------------+----------------+ 482 The COPS protocol specification defines several objects which may 483 carry client specific information between PDP and PEP: 484 Context Object (Context) 485 Reason Object (Reason) 486 Decision Object (Decision) 487 Error Object (Error) 488 Client Specific Information Object (ClientSI) which includes: 489 Request ClientSI 490 Report ClientSI 491 Client-Open ClientSI 493 4.1 Policy Identifier (PID) 495 This object is used to carry the PID of the Policy Data Instance to 496 be installed or deleted. 498 0 1 2 3 499 +----------------+----------------+----------------+----------------+ 500 | Length | Type = PID | 501 +----------------+----------------+----------------+----------------+ 502 | Policy Identifier | 503 +----------------+----------------+----------------+----------------+ 505 4.2 XDR Encoded Policy Instance Data (XPD) 507 This object is used to carry the value of a Policy Data Instance to 508 be installed, It contains an XDR coding of the Policy Data Instance 509 [RFC1832]. 511 0 1 2 3 512 +----------------+----------------+----------------+----------------+ 513 | Length | Type = "XDR type" | 514 +----------------+----------------+----------------+----------------+ 515 | XDR Encoded PI Value | 516 +----------------+----------------+----------------+----------------+ 518 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 519 11] 520 COPS Usage for Differentiated Services August 1998 522 4.3 Diff Serv Decision Data 524 The diff serv Client Specific Decision Data is composed of one or 525 more bindings. Each binding associates a PID object and an XPD 526 object. The XPD object contains the value to be assigned to the PI 527 that is created or updated. 529 The diff serv specific decision data has the following format: 531 C-Num = 7 532 C-Type = 4 534 ::= | 535 | 536 | 537 539 :: = 541 ::= | 542 544 ::= 546 ::= 547 ::= 548 ::= 550 ::= | 551 553 4.4 Diff Serv Request Data 555 The diff serv request ClientSI data has the following format: 557 ::= 559 4.5 Diff Serv Report Data 561 Diff serv specific report data is used in the RPT message. The format 562 of the report data is dependant on the value of the accompanying COPS 563 Report Type object. 565 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 566 12] 567 COPS Usage for Differentiated Services August 1998 569 4.5.1 Commit Data 570 When used with the "commit" report type, the diff serv specific 571 report data has the following format: 573 ::= [] 575 4.5.2 No Commit Data 576 When used with the "no commit" report type, the diff serv specific 577 report data has the following format: 579 ::= 581 4.5.3 Accounting Data 582 TBD 584 5. Message Content 586 This section describes the COPS messages exchanged between a PEP and 587 PDP for use with diff serv policy services. 589 5.1 Request (REQ) PEP -> PDP 591 The REQ message is used by COPS diff serv clients for issuing a 592 config request from the to the PDP, as described in the COPS 593 protocol. The Client Handle is associated with request state 594 originated by the PEP and the PEP is responsible for notifying the 595 PDP when the Handle is no longer in use and can be deleted. 597 The diff serv request data, defined above, may be included in the 598 config request form PEP to PDP. Currently, the request data is 599 defined for carrying configuration/feature negotiation information 600 from the PEP. This provides the server with information on the types 601 of policy that the interface can enforce and the types of policy data 602 the PEP can install. 604 The config request message serves as a request from the PEP to the 605 PDP for any diff serv configuration data which the PDP may have pre- 606 defined for the PEP device, such as access control lists, etc., and 607 any future access data or updates. The pre-configured and any 608 asynchronous diff serv configuration data can then be sent to the PEP 609 over time via responses, as decided by the PDP. The configuration 611 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 612 13] 613 COPS Usage for Differentiated Services August 1998 615 information supplied by the PDP is of the consistent client specific 616 format defined above. The PDP responds to the config request with a 617 DEC message containing any available configuration information. 619 ::= 620 621 622 623 625 5.2 Decision (DEC) PDP -> PEP 627 The DEC message is sent from the PDP to a diff serv client in 628 response to a config REQ received from the PEP. The Client Handle 629 must be the same Handle that was received in the REQ message. The 630 Client Specific Decision Data for diff serv clients, to be used in 631 the DEC message, is defined above. 633 The DEC message is sent as an immediate response to a config request, 634 used to carry pre-defined configuration information set in the PDP, 635 to the PEP. Subsequent DECs may also be sent at any time after the 636 original DEC message to continue supplying the PEP with 637 additional/updated policy information. The state carried in the DEC 638 message is referred to in the PDP and PEP by the Client Handle and 639 the PID information. 640 The PEP performs the operation specified in the Decision Flags object 641 on the decision data. If no configuration state is available when the 642 config REQ is processed by the PDP, a DEC is sent with the "No 643 Configuration Data" decision flag set. 645 The "Install", "Delete", "Enable", and "Disable" decision flags are 646 used by the PEP and PDP to manage the policy data transactions. In 647 response to a DEC message, the diff serv client sends a RPT back to 648 the PDP to inform the PDP of the actual action taken. For example, in 649 response to a DEC with the "Install" flag (only) set, the PEP informs 650 the PDP if the decision data can be installed, based on the other 651 policy data on the device (are there conflicts, etc.). Then when the 652 PDP determines the policy should be enabled, based on the transaction 653 associated with the policy data, a subsequent DEC message may be sent 654 with the "Enable" flag set. 656 ::= 657 658 659 [< diff serv Specific Decision Data>] 661 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 662 14] 663 COPS Usage for Differentiated Services August 1998 665 5.3 Report State (RPT) PEP -> PDP 667 The RPT message is sent from the diff serv client to the PDP to 668 report accounting information from PEP to PDP on request state 669 installed at the PEP. It is also used as a mechanism to inform the 670 PDP about the action taken at the PEP, in response to a DEC message. 671 The diff serv report data format, as defined above, depends on the 672 Report Type included in the RPT message. 674 ::= 675 676 677 [] 679 6. Common Operation 681 This section describes, in general, typical exchanges between a PDP 682 and diff serv COPS client. 684 First, a connection is established between the PEP and PDP and the 685 PEP sends a Client-Open message with the Client-Type = 2, Diff Serv 686 client. If the PDP supports the Diff Serv client, the PDP responds 687 with a Client-Accept (CAT) message. If the client type is not 688 supported, a Client-Close (CC) message is returned by the PDP to the 689 PEP, possibly identifying an alternate server that is known 690 (believed?) to support the policy for the diff serv client. 692 Once the CAT message is accepted, the client can send requests to the 693 server. The first request a COPS Diff Serv client sends to the server 694 is for configuration information, that is a REQ with "Configuration 695 Request" set in the context object that identifies a specific 696 interface/module and any relevant client specific information. The 697 config request message serves two purposes in COPS-DS. First, it is a 698 request from the PEP to the PDP for any diff serv configuration data 699 which the PDP may have pre-defined for the PEP device, such as acces 700 control lists, etc. Also, the config request is a request to the PDP 701 to send asynchronous diff serv configuration data to the PEP, as it 702 is received by the PDP. This asynchronous data may be new policy data 703 or an update to policy data sent previously. 705 If the PDP has diff serv QoS policy configuration information for the 706 client, that information is returned to the client in a DEC message 707 containing the Diff Serv client policy data within the COPS Decision 708 object. If no filters are defined, the DEC message will simply 709 specify that there are no filters using the "No Configuration" 711 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 712 15] 713 COPS Usage for Differentiated Services August 1998 715 Decision Flags object. The handle associated with the request state 716 is the Client Handle sent in the original configuration REQ from the 717 PEP. This is to prevent the PEP from timing out the REQ and deleting 718 the Client Handle. 720 The PDP can then add new policy data or update existing state by 721 sending subsequent DEC message(s) to the PEP, with the same Client 722 Handle. The PEP is responsible for removing the Client handle when it 723 is no longer needed, for example when the interface goes down, and 724 informing the PDP that the handle is to be deleted. 726 For diff serv purposes, access state, and access requests to the 727 policy server can be initiated by other sources besides the PEP. 728 Examples of other sources include attached users requesting network 729 services via a web interface into a central management application, 730 or H.323 servers requesting resources on behalf of a user for a video 731 conferencing application. When such a request is accepted, the edge 732 device affected by the decision (the point where the flow is to enter 733 the network) must be informed of the decision. Since the PEP in the 734 edge device did not initiate the request, the specifics of the 735 request, e.g. flowspec, packet filter, and PHB to apply, must be 736 communicated to the PEP by the PDP. This information is sent to the 737 PEP using the Decision message containing Diff Serv client specific 738 data objects in the COPS Decision object as specified. Any updates to 739 the state information, for example in the case of a policy change or 740 call tear down, is communicated to the PEP by subsequent DEC messages 741 containing the same Client Handle and the updated diff serv request 742 state. Updates can be specify to delete, install, enable or disable 743 existing policy data. 745 The PEP acknowledges the DEC message and action taken by sending a 746 RPT message with a "Commit" Report-Type object. This serves as an 747 indication to the PDP that the requestor (e.g. H.323 server) can be 748 notified that the request has been accepted by the network. If the 749 PEP needs to reject the DEC operation for any reason, a RPT message 750 is sent with a Report-Type of value "No Commit" and optionally a 751 Client Specific Information object specifying the policy data that 752 was rejected. The PDP can then respond to the requestor accordingly. 754 The PEP can report to the PDP the local status of any installed 755 request state when appropriate. This information is sent in a Report- 756 State (RPT) message with the "Accounting" flag set. The state being 757 reported on is referenced by the Client Handle associated with the 758 request state and the client specific data identifier. 759 Finally, Client-Close (CC) messages are used to cancel the 760 corresponding Client-Open message. The CC message informs the other 761 side that the client type specified is no longer supported. 763 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 764 16] 765 COPS Usage for Differentiated Services August 1998 767 7. Fault Tolerance 769 When communication is lost between PEP and PDP, the PEP attempts to 770 re-establish the TCP connection with the PDP it was last connected 771 to. If that server cannot be reached, then the PEP attempts to 772 connect to a secondary PDP, assumed at this time to be manually 773 configured at the PEP. 775 When a connection is finally re-established, either with the primary 776 PDP or a secondary PDP, the PDP may request the PEP to re-synch its 777 current state information (SSQ message). If after re-connecting, the 778 PDP does not request the synchronization, the client can assume the 779 server recognizes it and the current state at the PEP is correct. Any 780 changes state changes which occurred at the PEP while connection was 781 lost must be reported to the PDP in a RPT message. 783 While the PEP is disconnected from the PDP, the request state at the 784 PEP is to be used for policy decisions. If the PEP cannot re-connect 785 in some pre-specified period of time (some multiple of the keep-alive 786 time? - TBD), the request state is to be deleted and the associated 787 Handles removed. The same holds true for the PDP; upon detecting a 788 failed TCP connection, the time-out timer is started for the request 789 state associated with the PEP and the state is removed after the 790 specified period without a connection. 792 8. Security 794 The use of COPS for diff serv introduce no new security issues over 795 the base COPS protocol. The use of IPSEC between PDP and PEP, as 796 described in [COPS] is sufficient. 798 9. References 800 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja,n R., 801 Sastry, A., "The COPS (Common Open Policy Service) 802 Protocol", IETF , March 1998. 804 [RAP] Yavatkar, R., et al., "A Framework for Policy Based 805 Admission Control",IETF , 806 November, 1997. 808 [E2E] Bernet, Y., Yavatka,r R., Ford, P., Bake,r F., Nichols, K., 809 Speer, M., "A Framework for End-to-End QoS Combining 811 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 812 17] 813 COPS Usage for Differentiated Services August 1998 815 RSVP/Intserv and Differentiated Services", IETF , March 1998. 818 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, 819 S., "Resource Reservation Protocol (RSVP) Version 1 820 Functional Specification", IETF RFC 2205, Proposed 821 Standard, September 1997. 823 [ASN1] Information processing systems - Open Systems 824 Interconnection, "Specification of Abstract Syntax Notation 825 One (ASN.1)", International Organization for 826 Standardization, International Standard 8824, December 827 1987. 829 [RFC1832] R. Srinivasan, "XDR: External Data Representation 830 Standard.", RFC 1832, August 1995. 832 10. Author Information 834 Francis Reichmeyer 835 Bay Networks, Inc. 836 3 Federal Street 837 Billerica, MA 01821 838 Phone: (978) 916-3352 839 Email: freichmeyer@BayNetworks.COM 841 Kwok Ho Chan 842 Bay Networks, Inc. 843 600 Technology Park 844 Billerica, MA 01821 845 Phone: (978) 916-8175 846 Email: khchan@BayNetworks.COM 848 David Durham 849 Intel 850 2111 NE 25th Avenue 851 Hillsboro, OR 97124 852 Phone: (503) 264-6232 853 Email: david.durham@intel.com 855 Raj Yavatkar 856 Intel 857 2111 NE 25th Avenue 858 Hillsboro OR 97124 859 Phone: (503) 264-9077 860 Email: yavatkar@ibeam.intel.com 862 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 863 18] 864 COPS Usage for Differentiated Services August 1998 866 Silvano Gai 867 Cisco Systems, Inc. 868 170 Tasman Dr. 869 San Jose, CA 95134-1706 870 Phone: (408) 527-2690 871 email: sgai@cisco.com 873 Keith McCloghrie 874 Cisco Systems, Inc. 875 170 Tasman Dr. 876 San Jose, CA 95134-1706 877 Phone: (408) 526-5260 878 email: kzm@cisco.com 880 Shai Herzog 881 IPHighway 882 2055 Gateway Place, Suite 400 883 San Jose, CA 95110 884 Phone: (408) 451-3923 885 Email: herzog@iphighway.com 887 ........... 889 Reichmeyer, Ho Chan, Durham, Gai, McCloghrie [Page 890 19]