idnits 2.17.1 draft-ietf-rap-cops-ds-01.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-18) 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. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 23 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** 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. ** There are 351 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. ** 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 448: '...nt-Open ClientSI MUST specify the MCMS...' RFC 2119 keyword, line 610: '... BPD object MUST be present in th...' RFC 2119 keyword, line 611: '... MUST NOT be present in the cas...' RFC 2119 keyword, line 700: '... commit" the PEP MUST report at least ...' RFC 2119 keyword, line 848: '... object. The PEP MUST specify a client...' (1 more instance...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 747 has weird spacing: '... client in re...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 1998) is 9256 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'COPS' -- Possible downref: Non-RFC (?) normative reference: ref. 'RAP' -- Possible downref: Non-RFC (?) normative reference: ref. 'E2E' -- Possible downref: Non-RFC (?) normative reference: ref. 'ASN1' -- Possible downref: Non-RFC (?) normative reference: ref. 'BER' == Outdated reference: A later version (-02) exists of draft-nichols-diff-svc-arch-00 ** Downref: Normative reference to an Informational draft: draft-nichols-diff-svc-arch (ref. 'Nichols') Summary: 11 errors (**), 0 flaws (~~), 4 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 COPS Usage for Differentiated Services December 1998 4 Network Working Group Francis Reichmeyer 5 Internet Draft Kwok Chan 6 draft-ietf-rap-cops-ds-01.txt Bay Networks, Inc. 7 Expiration Date: May 1999 David Durham 8 Raj Yavatkar 9 Intel 10 Silvano Gai 11 Keith McCloghrie 12 Cisco Systems, Inc. 13 Shai Herzog 14 IPHighway 15 December 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 COPS Usage for Differentiated Services December 1998 48 In parallel, the IETF RSVP Admission Policy (RAP) WG has defined the 49 COPS (Common Open Policy Service) protocol [COPS]. 51 This document describes enhancements to the Common Open Policy 52 Service (COPS) protocol to support policy services in a 53 Differentiated Services (DiffServ) environment. Further modifications 54 to COPS for DiffServ may be proposed in the future, but what is 55 presented here is thought to be the minimum necessary additions. 57 Table of contents 59 1. Terminology ......................................................3 60 2. Introduction .....................................................4 61 2.1 Basic Model...................................................6 62 2.2 Interaction between the PDP and the PEP.......................8 63 3. The definition of the Policy Tree ................................8 64 3.1 Description of the Policy Tree................................9 65 3.2 Operations Supported On a PRI................................10 66 3.3 PIB general information......................................10 67 3.4 An example of a PIB..........................................10 68 4. COPS DiffServ Client Data .......................................13 69 4.1 Policy Identifier (PRID).....................................13 70 4.2 BER encoded Policy instance Data (BPD).......................14 71 4.3 DiffServ Decision Data.......................................14 72 4.4 DiffServ Request Data........................................15 73 4.5 DiffServ Report Data.........................................15 74 4.5.1 Successfully Installed/Removed Data .....................15 75 4.5.2 Unsuccessfully Installed/Removed Data ...................15 76 4.5.3 Accounting Data .........................................16 77 5. Message Content .................................................16 78 5.1 Request (REQ) PEP -> PDP...................................16 79 5.2 Decision (DEC) PDP -> PEP..................................17 80 5.3 Report State (RPT) PEP -> PDP..............................18 81 6. Common Operation ................................................18 82 7. Fault Tolerance .................................................20 83 8. Security ........................................................21 84 9. References ......................................................21 85 10. Author Information .............................................22 87 COPS Usage for Differentiated Services December 1998 89 1. Terminology 91 o ACL: Access Control List. 93 o ClientSI: Client Specific Information Object. 95 o COPS (Common Open Policy Service): client/server model for 96 supporting policy control [COPS]; 98 o Object: this term is used in the same sense as in COPS 99 specification. An object is identified by its C-num and C-type. 101 o PDP (Policy Decision Point): a network entity where policy 102 decisions are made. 104 o PEP (Policy Enforcement Point): network device where policy 105 decisions are enforced. 107 o Policy Rule: policy information specified by the PDP to be enforced 108 at the PEP. 110 o PRC (Policy Rule Class): a type of policy rule data item. In object 111 oriented terminology this is equivalent to a class. It inherits 112 from PRC. A PRC defines a vector of attributes. Each attribute has 113 a syntax type that is either primitive or refined. It also 114 overrides the READ and WRITE methods and defines new error sub- 115 codes. 117 o PRI (Policy Rule Instance): an instance of a PRC. Potentially there 118 are multiple instances of the same PRC. The value of a PRI consist 119 of a vector of values, one value for each attribute in the PRC's 120 vector of attributes. 122 o PII (Policy Instance Identifier): one or more of the PRC attributes 123 the values of which are used as part of the identification of a 124 PRI. 126 o PIB (Policy Information Base): policy objects are accessed via a 127 virtual information store, termed the Policy Information Base or 128 PIB. Objects in the PIB are defined using a subset of Abstract 129 Syntax Notation One (ASN.1) [ASN1]. 131 o PRID (Policy Rule IDentifier): the name which identifies a 132 particular PRI or PRC. It has a hierarchical structure of the form 133 1.3.4.2.7, where the first part identifies the PRC (i.e., 1.3.4) 134 and the last part is the value of the PII (Policy Instance 135 Identifier), which identifies the instance (i.e. 2.7). The PII is 137 COPS Usage for Differentiated Services December 1998 139 null in the case of a PRC. PRIDs are represented as a BER encoded 140 oids (Object Identifiers). 142 o BPD: BER (ASN.1 [ASN1] Basic Encoding Rule [BER]) encoded Policy 143 Instance Data. 145 2. Introduction 147 The Common Open Policy Service (COPS) protocol is a query response 148 protocol used to exchange policy information between a network policy 149 server and a set of clients [COPS]. COPS is being developed within 150 the RSVP Admission Policy Working Group (RAP WG) of the IETF, 151 primarily for use as a mechanism for providing policy-based admission 152 control over requests for network resources [RAP]. 154 The underlying assumption in the RAP framework is that applications 155 or end systems use the RSVP [RSVP] signaling protocol to communicate 156 Integrated Services (IntServ) reservation requests to the network 157 nodes along the path of a flow. These reservation requests carry 158 necessary flow specifications and requests for a flow to receive one 159 of the defined Integrated Services, Controlled Load or Guaranteed. In 160 the IntServ model, the RSVP messages themselves contain all the 161 necessary information needed at the networking device to classify and 162 service the flow [RSVP]. This information includes the session 163 identifier (source and destination addresses, port numbers, and 164 transmission protocol), flowspec token bucket parameters, and 165 requested service. 167 Edge Device Policy Server 168 +--------------+ +-----------+ 169 | | | | 170 | | COPS | | 171 | +-----+ | REQ() | +-----+ | 172 RSVP | | |----|----------|->| | | 173 --------|-->| PEP | | | | PDP | | 174 | | |<---|----------|--| | | 175 | +-----+ | COPS | +-----+ | 176 | | DEC() | | 177 +--------------+ +-----------+ 179 Figure 1: COPS with RSVP/IntServ 181 As shown in Figure 1, the network device contacts a Policy Decision 182 Point (PDP) to make the policy-based admission control decision. The 184 COPS Usage for Differentiated Services December 1998 186 PDP is simply required to return a Decision, such as "accept" and the 187 network device acts as a Policy Enforcement Point (PEP) and uses the 188 session information and IntServ service parameters to classify and 189 service the packets belonging to the flow. 191 Providing policy services in a DiffServ environment requires some 192 different assumptions about the admission control mechanisms used in 193 the network. First, there might be no explicit dynamic signaling from 194 sources of traffic requesting a particular service, as in the case of 195 an IntServ network. Network resources are provisioned based on static 196 SLAs (Service Level Agreements) at network boundaries. Second, where 197 requests for allocation of resources to differentiated services are 198 used, they may arrive at the PDP from network entities other than the 199 PEP. Examples of such sources include attached users requesting 200 network services via a web interface into a central management 201 application, or H.323 gatekeeper requesting resources on behalf of a 202 user for a video conferencing application, as shown in Figure 2. 204 +----------+ 205 Edge Device Policy Server | H.323 | 206 +--------------+ +-----------+ |Gatekeeper| 207 | | | | | | 208 | | | | +----------+ 209 | ----- | COPS | ----- | | 210 | | | | DECs() | | | | | 211 | | PEP |<---|----------|--| PDP |<----------+ 212 | | | | | | | | Service 213 | ----- | | ----- | Request 214 | | | | 215 +--------------+ +-----------+ 217 Figure 2: COPS Example with DiffServ 219 Requests of this sort still require some policy decision to be made 220 to ensure the requesting user/application has permission to use the 221 requested services and that the resources are available. Once the 222 decision is made, the PDP must configure one or more PEPs to allocate 223 necessary resources for services requested. In addition, the PDP may 224 also pass to the PEP provisioning decisions about resources related 225 to flows of a more static nature, such as long-term SLAs established 226 across boundaries of adjacent ISP networks. 228 In summary, the interaction between the PDP and PEP is different in 229 at least two respects from that in the case of the IntServ 230 environment. First, the resource provisioning requests may originate 232 COPS Usage for Differentiated Services December 1998 234 at places other than a PEP. Second, once the PDP makes a policy 235 decision to allocate resources for a service class or a flow 236 aggregate, it must pass sufficient information (such as packet 237 classification filters, traffic shaper parameters) in the decision 238 message to the PEPs so that PEPs can enforce policy decisions. This 239 draft describes the usage of the COPS protocol for communicating this 240 information between DiffServ clients (PEPs) and the policy servers 241 (PDPs). 243 2.1 Basic Model 245 Figure 2 shows a sample network configuration for a DiffServ 246 environment. Edge routers and boundary routers are located at the 247 boundary of DiffServ domains as described in [Nichols]. The BB/PS is 248 responsible for admission control functions and resource 249 provisioning. 251 +-----+ +-----+ 252 | BB/ | | BB/ | 253 | PS | | PS | 254 +-----+ +-----+ 255 \ | 256 | / 257 | / 258 / Stub \ / Transit \ / Stub \ 259 / Network \ / Network \ / Network \ 260 +---+ | +---\ /---+ +---\ /---+ | +---+ 261 |Tx |-| |ER1|---|BR1| |BR2|---|ER2| |-|Rx | 262 +---+ | +---/ \---+ ---/ \---+ | +---+ 263 \ / \ / \ / 264 \ / \ / \ / 266 Figure 3: Sample DiffServ Network Configuration 268 In the COPS model, the PDP is part of the bandwidth broker/policy 269 server that manages policy information and resources within a 270 DiffServ domain. Both edge routers and boundary routers act as PEPs 271 and communicate with BB/PS using COPS for exchange of policy 272 information. The internal organization of the bandwidth broker 273 functionality and policy functionality may vary and the policy server 274 and BB may be separate entities. In that case, either the BB or the 275 PS may communicate with the edge devices. The BB, upon receiving COPS 276 messages from the PEP, would consult the policy server to make its 277 final admission control decision. Similarly, if the PS receives COPS 279 COPS Usage for Differentiated Services December 1998 281 messages directly from PEP, the PS would consult the BB to verify 282 available resources before making a final admission control decision. 284 To allow for use of COPS for DiffServ specific communication and to 285 distinguish DiffServ usage from other uses of COPS, we have added a 286 new client type to COPS (client type = DiffServ client). It is 287 possible for an edge device to contain both a COPS-DS and a COPS-RSVP 288 client. Each COPS clients can communicate with different PDPs, or 289 they can connect to the same PDP which supports both client types, as 290 shown in Figure 4. 292 Edge Device 293 +-----------------+ 294 | | PS/BB 295 | +---------+ | +-------------+ 296 | | | | | | 297 RSVP | |COPS-RSVP| | COPS-RSVP | +-----+ | 298 <-------|-->| Client |<--|-----------|-->| | | 299 | | | | | | | | 300 | |---------| | | | PDP | | 301 | | | | | | | | 302 | |COPS-DS |<--|-----------|-->| | | 303 | | Client | | COPS-DS | +-----+ | 304 | | | | | | 305 | +---------+ | +-------------+ 306 | | 307 +-----------------+ 309 Figure 4: COPS DS and RSVP Clients in Same Edge Device 311 Allowing multiple COPS client types to co-exist in a single PEP means 312 that the same PDP can coordinate policy decisions in an environment 313 where, say, both RSVP/IntServ and DiffServ QoS mechanisms need to be 314 managed. For example, in a stub network that uses IntServ with RSVP 315 signaling internally and is connected to a DiffServ transit network 316 externally. In this case, the edge device that connects the stub 317 network to the transit network may require policy decisions from the 318 same PDP for both RSVP requests as well as for policy rules to 319 enforce on the egress (DiffServ is with respect to the ingress) 320 interface. 322 The two decisions may very well need to be coordinated to ensure 323 proper provisioning and allocation of network resources. For example, 324 the decision of whether to admit an RSVP flow, or not, would depend 325 on the provisioning policy in place at the egress interface where the 327 COPS Usage for Differentiated Services December 1998 329 flow is leaving the stub network, and vice versa. The issue of 330 combining IntServ and DiffServ to provide an end-to-end QoS solution 331 is discussed in the draft [E2E]. Also, the RSVP WG is currently 332 planning on addressing the use of RSVP within the differentiated 333 services QoS model. 335 2.2 Interaction between the PDP and the PEP 337 When a device boots, it opens a COPS connection to its Primary PDP. 338 When the connection is established, the PEP sends information about 339 itself to the PDP in the form of a configuration request. This 340 information includes client specific information (hardware type, 341 software release, configuration information). During this phase the 342 client also specifies the maximum COPS-DS message size supported (see 343 Section 3.3). 345 In response, the PDP downloads all provisioned policies which are 346 currently relevant to that device. On receiving the provisioned 347 policies, the device maps them into its local QoS mechanisms, and 348 installs them. If conditions change at the PDP such that the PDP 349 detects that changes are required in the provisioned policies 350 currently in effect at the PEP, then the PDP sends the changes 351 (installs/deletes) in policy to the PEP, and the PEP updates its 352 local QoS mechanisms appropriately. 354 If, subsequently, the configuration of the device changes (board 355 removed, board added, new software installed, etc.) in ways not 356 covered by policies already known to the PEP, then the PEP sends this 357 new information to the PDP. On receiving this new information, the 358 PDP sends to the PEP any additional provisioned policies now needed 359 by the PEP. 361 3. The definition of the Policy Tree 363 This section defines data format for the DiffServ client specific 364 information carried in the Decision, Request ClientSI, and Report 365 ClientSI objects. DiffServ client specific data may be defined for 366 the other objects in the future. COPS-DS data is represented by a 367 policy tree containing Policy Rule Classes (PRCs) and Instances of 368 those classes (PRIs), as shown in Figure 5. 370 COPS Usage for Differentiated Services December 1998 372 -------+-------+----------+---PRC--+--PRI 373 | | | +--PRI 374 | | +---PRC-----PRI 375 | +---PRC--+--PRI 376 | | +--PRI 377 | | +--PRI 378 | | +--PRI 379 | | +--PRI 380 | +---PRC-----PRI 381 +---PRC---PRI 383 Figure 5: Example of a Policy Tree 385 The policy tree is based on SMI and MIBs. COPS for RSVP does not need 386 a policy tree, since the information exchanged has a simple format 387 and is defined by existing RSVP objects. COPS for DiffServ needs much 388 more structure, since it needs to represent policies, mappings, ACLs, 389 interfaces etc. 391 PRIs (Policy Rule Instances) and PRCs (Policy Rule Classes) have 392 names called PRIDs (Policy Rule IDentifiers). PRIDs have a 393 hierarchical structure of the form 1.3.4.2.7, where the first part 394 identifies the PRC (e.g., 1.3.4) and the last part identifies the 395 instance (e.g. 2.7). 397 The policy tree names all the policy rule classes and instances and 398 this creates a common view of the policy organization between the 399 client (PEP) and the server (PDP). Therefore, when the PEP receives 400 data from the PDP, the data itself specifies what a PEP is supposed 401 to do with the data. The current granularity of access, i.e., the 402 atomicity of replacement, is proposed as a vector of values. 404 Note that the PRCs/PRIs in the above diagram are each a vector of 405 values. This proposal is that the hierarchy of PRCs/PRIs is for 406 benefit of human understanding, not for programmatic understanding, 407 or inheritance. 409 3.1 Description of the Policy Tree 411 The Policy Tree is described using SMI and PIBs. SMI and PIBs are 412 defined based on the ASN.1 data definition language [ASN1]. To 413 simplify the implementation and re-use the SNMP encoding/decoding 415 COPS Usage for Differentiated Services December 1998 417 code, the representation of the policy information on the wire must 418 follow BER both for the PRID and for the BPD [BER]. 420 3.2 Operations Supported On a PRI 422 The following operations are supported on a PRI: 424 o Install - creates a new instance of a PRC, i.e. a new PRI, or 425 modifies an existing instance. The instance is automatically 426 enabled. Parameters to this operation are a PRID (see Section 4.1) 427 and an "BPD (BER encoded Policy instance Data)" containing the 428 value to assign to the new PRI see (Section 4.2). The BPD specifies 429 all the attributes of the new PRI. 431 o Delete - This operation is used to delete an instance of a PRC. The 432 parameter is a PRID (see Section 4.1). 434 3.3 PIB general information 436 The PIB has a branch that contains general information. Examples of 437 information stored in this branch are: 439 o TTL (Time To Live): a period of time in seconds. In the event the 440 PEP looses the COPS-DS connection with the PDP, it tries to re- 441 establish the connection with the primary and secondary PDPs. If 442 this fails for a period of time greater than the TTL, the DS 443 policies are discarded. The TTL specified in this branch is the 444 default TTL and may be overridden by TTLs present in specific 445 branches. A TTL = 0 means infinite. 447 o MCMS (Maximum COPS-DS Message Size): a message size in bytes. The 448 COPS-DS Client-Open ClientSI MUST specify the MCMS supported by the 449 client. This value must be in the range 4KB - 64KB. 451 o Interface to be provisioned. 453 o Capability information: This may include what filters the PEP 454 supports, what kind of profiles or dispositions it can perform. 456 3.4 An example of a PIB 458 This section contains a simple example of a PIB describing a simple 459 set of filters for IP packets. Each filter is able to match either 460 the source IP address, the destination IP address or both. This 462 COPS Usage for Differentiated Services December 1998 464 example is provided only for the benefit of understanding how a PIB 465 is structured. It is not necessarily supposed to describe any actual 466 policy data. 468 policyFilterPIB OBJECT IDENTIFIER ::= { policyPIB 1 } 470 ipHeaderFilterTable OBJECT-TYPE 471 SYNTAX SEQUENCE OF IpHeaderFilterEntry 472 MAX-ACCESS not-accessible 473 STATUS current 474 DESCRIPTION "This table contains a simple ACL, i.e. one or 475 more IP filters." 477 ::= {policyFilterPIB 1} 479 ipHeaderFilterEntry OBJECT-TYPE 480 SYNTAX IpHeaderFilterEntry 481 MAX-ACCESS write-only 482 STATUS current 483 DESCRIPTION "Each row of the table has four columns. The 484 ipHeaderFilterIndex uniquely identifies a particular IP 485 filter. The ipHeaderFilterMatchType specifies the type of 486 match (source only, destination only, source and destination). 487 The ipHeaderFilterSourceAddress and 488 ipHeaderFilterDestinationAddress contain the source and 489 destination IP addresses." 491 INDEX {ipHeaderFilterIndex} 493 ::= {ipHeaderFilterTable 1} 495 IpHeaderFilterEntry ::= SEQUENCE { 496 ipHeaderFilterIndex INTEGER, 497 ipHeaderFilterMatchType BITS, 498 ipHeaderFilterSourceAddress IpAddress, 499 ipHeaderFilterDestinationAddress IpAddress 500 } 502 ipHeaderFilterIndex OBJECT-TYPE 503 SYNTAX INTEGER 504 MAX-ACCESS not-accessible 505 STATUS current 506 DESCRIPTION "The index of the table, used to identify each 508 COPS Usage for Differentiated Services December 1998 510 individual IP filter" 512 ::= {ipHeaderFilterEntry 1} 514 ipHeaderFilterMatchType OBJECT-TYPE 515 SYNTAX BITS { 516 matchSource (0), 517 matchDestination (1) 518 } 519 MAX-ACCESS not-accessible 520 STATUS current 521 DESCRIPTION "This field indicates which one or more of the 522 addresses are required to match the corresponding addresses 523 of the IP packet." 525 ::= {ipHeaderFilterEntry 2} 527 ipHeaderFilterSourceAddress OBJECT-TYPE 528 SYNTAX IpAddress 529 MAX-ACCESS not-accessible 530 STATUS current 531 DESCRIPTION "IP source address to be matched against the 532 packet in the event the ipHeaderFilterMatchType has the 533 corresponding bit set. 535 ::= {ipHeaderFilterEntry 3} 537 ipHeaderFilterDestinationAddress OBJECT-TYPE 538 SYNTAX IpAddress 539 MAX-ACCESS not-accessible 540 STATUS current 541 DESCRIPTION "IP destination address to be matched against the 542 packet in the event the ipHeaderFilterMatchType has the 543 corresponding bit set. 545 ::= {ipHeaderFilterEntry 4} 547 COPS Usage for Differentiated Services December 1998 549 4. COPS DiffServ Client Data 551 The COPS-DS extensions define a new client type: 553 Client Type = 2; DiffServ Client 555 DiffServ specific information is sent in a COPS message containing a 556 Common Header with the DiffServ Client type specified: 558 0 1 2 559 3 560 +----------------+----------------+----------------+----------------+ 561 | Version| //// | Op Code | Client Type = 0x02 | 562 +----------------+----------------+----------------+----------------+ 563 | Message Length | 564 +----------------+----------------+----------------+----------------+ 566 The COPS protocol specification defines several objects which may 567 carry client specific information between PDP and PEP: 569 o Context Object (Context) 570 o Reason code Object (Reason code) 571 o Decision Object (Decision) 572 o Error Object (Error) 573 o Client Specific Info Object (ClientSI) which includes: 574 o Request ClientSI 575 o Report ClientSI 576 o Client-Open ClientSI 578 4.1 Policy Identifier (PRID) 580 This object is used to carry the PRID of the Policy Rule Instance to 581 be installed or deleted. 583 0 1 2 3 584 +----------------+----------------+----------------+----------------+ 585 | Length | Type = PRID | 586 +----------------+----------------+----------------+----------------+ 587 | Policy Rule Identifier | 588 +----------------+----------------+----------------+----------------+ 590 COPS Usage for Differentiated Services December 1998 592 4.2 BER encoded Policy instance Data (BPD) 594 This object is used to carry the value of a Policy Data Instance to 595 be installed, It contains an BER coding of the Policy Data Instance 596 [BER]. 598 0 1 2 3 599 +----------------+----------------+----------------+----------------+ 600 | Length | Type = "BER type" | 601 +----------------+----------------+----------------+----------------+ 602 | BER Encoded PRI Value | 603 +----------------+----------------+----------------+----------------+ 605 4.3 DiffServ Decision Data 607 The DiffServ Named Decision Data (, see Section 608 5.2) is composed of one or more bindings. Each binding associates a 609 PRID object and an BPD object. The PRID object is always present, the 610 BPD object MUST be present in the case of an install decision and 611 MUST NOT be present in the case of a delete decision. 613 The BPD object contains the value to be assigned to the PRI that is 614 created or updated. 616 The DiffServ specific decision data uses the following format: 618 C-Num = 7 619 C-Type = 5 621 ::= | 622 624 This depends from the , see Section 5.2. 626 :: = 628 ::= | 629 631 ::= 633 ::= 635 ::= | 636 638 COPS Usage for Differentiated Services December 1998 640 Please note that the delete has the capability of deleting an entire 641 table with a single operation. 643 4.4 DiffServ Request Data 645 The diffServ Configuration request will utilize the COPS Named 646 ClientSI (C-Num=10 C-Type=2) object to carry the same bindings as 647 described above. The DiffServ request Named ClientSI data has the 648 following format: 650 ::= 652 ::= 654 4.5 DiffServ Report Data 656 DiffServ specific report data is used in the RPT message. The format 657 of the report data is dependant on the value of the accompanying COPS 658 Report Type object. Report types can be Installed/Removed or 659 NotInstalled/NotRemoved indicating to the PDP that a particular set 660 of policies has been either successfully or unsuccessfully 661 installed/deleted on the PEP. 663 4.5.1 Successfully Installed/Removed Data 665 When used with the "Installed" or "Removed" report type, the DiffServ 666 Named ClientSI object in the Report Message has the following 667 format: 669 ::= 671 ::= [] 673 where is the set of PRID successfully installed/deleted. 675 4.5.2 Unsuccessfully Installed/Removed Data 677 When used with the "Not Installed" or "Not Removed" report type, the 678 DiffServ specific report data has the following format: 680 ::= 682 COPS Usage for Differentiated Services December 1998 684 ::= 686 ::= | 688 ::= [] 690 where: 692 is the PRID of the unsuccessful install/delete, is the 693 error code and are conflicting bindings that caused the 694 error. 696 The COPS-DS adds also the following two error codes: 697 - 12 COPS Client Specific Error Code; 698 - 13 Vendor Specific Error Code. 700 In the case of "no commit" the PEP MUST report at least the first 701 error and should report as many errors as possible. 703 4.5.3 Accounting Data 704 TBD 706 5. Message Content 708 This section describes the COPS messages exchanged between a PEP and 709 PDP for use with DiffServ policy services. 711 5.1 Request (REQ) PEP -> PDP 713 The REQ message is used by COPS DiffServ clients for issuing a config 714 request to the PDP, as described in the COPS protocol. The Client 715 Handle is associated with request state originated by the PEP and the 716 PEP is responsible for notifying the PDP when the Handle is no longer 717 in use and can be deleted. 719 The DiffServ request data, defined above, may be included in the 720 config request form PEP to PDP. Currently, the request data is 721 defined for carrying configuration/feature negotiation information 722 from the PEP. This provides the server with information on the types 723 of policy that the interface can enforce and the types of policy data 724 the PEP can install. 726 COPS Usage for Differentiated Services December 1998 728 The config request message serves as a request from the PEP to the 729 PDP for any DiffServ configuration data which the PDP may have pre- 730 defined for the PEP device, such as access control lists, etc., and 731 any future access data or updates. The pre-configured and any 732 asynchronous DiffServ configuration data can then be sent to the PEP 733 over time via decisions, as decided by the PDP. The configuration 734 information supplied by the PDP is of the consistent client specific 735 format defined above. The PDP responds to the config request with a 736 DEC message containing any available configuration information. 738 ::= 739 740 741 [ ] 742 744 5.2 Decision (DEC) PDP -> PEP 746 The DEC message () is sent from the PDP to a 747 DiffServ client in response to a config REQ received from the PEP. 748 The Client Handle must be the same Handle that was received in the 749 REQ message. The Client Specific Decision Data for DiffServ clients 750 (), to be used in the DEC message, is 751 defined in Section 4.3. 753 The DEC message is sent as an immediate response to a config request 754 with the solicited decision flag set, used to carry pre-defined 755 configuration information set in the PDP, to the PEP. Subsequent DEC 756 messages may also be sent at any time after the original DEC message 757 to continue supplying the PEP with additional/updated policy 758 information. The state carried in the DEC message is correlated with 759 an initial request state by the Client Handle and provides the 760 appropriate PRID information. 762 Each DEC message may contain multiple decisions. This allows with a 763 single message to install some policies and delete some others. In 764 general a COPS-DS decision message should contain at most one delete 765 decision followed by at most one install decision. This is used to 766 solve a precedence issue, not a timing issue: the delete decision 767 deletes what it specifies, except those items that are installed in 768 the same message. 770 A COPS-DS decision message is also a "transaction", i.e. all the 771 bindings in a message either succeed or fail. This allow to delete 772 some policies only if other policies can be installed in their place. 774 COPS Usage for Differentiated Services December 1998 776 For each decision (), the PEP performs the operation 777 specified in the Decision Flags object () on the 778 decision data (]). 780 ::= 781 782 | 784 ::= | 786 ::= 787 788 [] 790 If no configuration state is available when the config REQ is 791 processed by the PDP, a DEC is sent with the "No Configuration Data" 792 decision flag set. 794 In response to a DEC message, the DiffServ client sends a RPT back to 795 the PDP to inform the PDP of the actual action taken. For example, in 796 response to a DEC with the "Install" flag (only) set, the PEP informs 797 the PDP if the decision data can be installed, based on the other 798 policy data on the device (are there conflicts, etc.). 800 5.3 Report State (RPT) PEP -> PDP 802 The RPT message is sent from the DiffServ client to the PDP to report 803 accounting information from PEP to PDP on request state installed at 804 the PEP. It is also used as a mechanism to inform the PDP about the 805 action taken at the PEP, in response to a DEC message. The DiffServ 806 report data format, as defined above, depends on the Report Type 807 included in the RPT message. 809 ::= 810 811 812 [] 814 6. Common Operation 816 This section describes, in general, typical exchanges between a PDP 817 and DiffServ COPS client. 819 First, a connection is established between the PEP and PDP and the 820 PEP sends a Client-Open message with the Client-Type = 2, DiffServ 822 COPS Usage for Differentiated Services December 1998 824 client. If the PDP supports the DiffServ client, the PDP responds 825 with a Client-Accept (CAT) message. If the client type is not 826 supported, a Client-Close (CC) message is returned by the PDP to the 827 PEP, possibly identifying an alternate server that is known 828 (believed?) to support the policy for the DiffServ client. 830 Once the CAT message is received, the client can send requests to the 831 server. The request a COPS DiffServ client sends to the server is for 832 configuration information, that is a REQ with "Configuration Request" 833 set in the context object that identifies a specific interface/module 834 and any relevant client specific information (see also Section 3.3). 835 The config request message serves two purposes in COPS-DS. First, it 836 is a request from the PEP to the PDP for any DiffServ configuration 837 data which the PDP may have pre-defined for the PEP device, such as 838 acces control lists, etc. Also, the config request is a request to 839 the PDP to send asynchronous DiffServ configuration data to the PEP, 840 as it is received by the PDP. This asynchronous data may be new 841 policy data or an update to policy data sent previously. 843 If the PDP has DiffServ QoS policy configuration information for the 844 client, that information is returned to the client in a DEC message 845 containing the DiffServ client policy data within the COPS Decision 846 object. If no filters are defined, the DEC message will simply 847 specify that there are no filters using the "No Configuration" 848 Decision Flags object. The PEP MUST specify a client handle (which 849 can be zero) in the request message. The PDP MUST process the client 850 handle and copy it in the decision message. This is to prevent the 851 PEP from timing out the REQ and deleting the Client Handle. 853 The PDP can then add new policy data or update existing state by 854 sending subsequent DEC message(s) to the PEP, with the same Client 855 Handle. The PEP is responsible for removing the Client handle when it 856 is no longer needed, for example when the interface goes down, and 857 informing the PDP that the handle is to be deleted. 859 For DiffServ purposes, access state, and access requests to the 860 policy server can be initiated by other sources besides the PEP. 861 Examples of other sources include attached users requesting network 862 services via a web interface into a central management application, 863 or H.323 servers requesting resources on behalf of a user for a video 864 conferencing application. When such a request is accepted, the edge 865 device affected by the decision (the point where the flow is to enter 866 the network) must be informed of the decision. Since the PEP in the 867 edge device did not initiate the request, the specifics of the 868 request, e.g. flowspec, packet filter, and PHB to apply, must be 869 communicated to the PEP by the PDP. This information is sent to the 871 COPS Usage for Differentiated Services December 1998 873 PEP using the Decision message containing DiffServ client specific 874 data objects in the COPS Decision object as specified. Any updates to 875 the state information, for example in the case of a policy change or 876 call tear down, is communicated to the PEP by subsequent DEC messages 877 containing the same Client Handle and the updated DiffServ request 878 state. Updates can specify that policy data is to be deleted or 879 installed. 881 The PEP acknowledges the DEC message and action taken by sending a 882 RPT message with a "Installed" or "Removed" Report-Type object. This 883 serves as an indication to the PDP that the requestor (e.g. H.323 884 server) can be notified that the request has been accepted by the 885 network. If the PEP needs to reject the DEC operation for any reason, 886 a RPT message is sent with a Report-Type of value "Not Installed" or 887 "Not Removed" and optionally a Client Specific Information object 888 specifying the policy data that was rejected. The PDP can then 889 respond to the requestor accordingly. 891 The PEP can report to the PDP the local status of any installed 892 request state when appropriate. This information is sent in a Report- 893 State (RPT) message with the "Accounting" flag set. The state being 894 reported on is referenced by the Client Handle associated with the 895 request state and the client specific data identifier. 896 Finally, Client-Close (CC) messages are used to cancel the 897 corresponding Client-Open message. The CC message informs the other 898 side that the client type specified is no longer supported. 900 7. Fault Tolerance 902 When communication is lost between PEP and PDP, the PEP attempts to 903 re-establish the TCP connection with the PDP it was last connected 904 to. If that server cannot be reached, then the PEP attempts to 905 connect to a secondary PDP, assumed at this time to be manually 906 configured at the PEP. 908 When a connection is finally re-established, either with the primary 909 PDP or a secondary PDP, the PEP should provide the last PDP address 910 of the PDP for which it is still caching decisions. Based on this 911 information, the PDP may request the PEP to re-synch its current 912 state information (SSQ message). If no decisions are being cached on 913 the PEP (due to reboot or TTL timeout of state) the PEP must not 914 included the last PDP address information. If after re-connecting, 915 the PDP does not request the synchronization, the client can assume 916 the server recognizes it and the current state at the PEP is correct. 917 Any changes state changes which occurred at the PEP while connection 918 was lost must be reported to the PDP in a RPT message. If re- 920 COPS Usage for Differentiated Services December 1998 922 synchronization is requested, the PEP should reissue its 923 configuration requests and the PDP should delete the appropriate PRCs 924 on the PEP (thus, removing all previous decisions below the PRC, 925 effectively resetting all state). 927 While the PEP is disconnected from the PDP, the request state at the 928 PEP is to be used for policy decisions. If the PEP cannot re-connect 929 in some pre-specified period of time (some multiple of the keep-alive 930 time? - TBD), the request state is to be deleted and the associated 931 Handles removed. The same holds true for the PDP; upon detecting a 932 failed TCP connection, the time-out timer is started for the request 933 state associated with the PEP and the state is removed after the 934 specified period without a connection. 936 8. Security 938 The use of COPS for DiffServ introduce no new security issues over 939 the base COPS protocol. The use of IPSEC between PDP and PEP, as 940 described in [COPS] is sufficient. 942 9. References 944 [COPS] Boyle, J., Cohen, R., Durham, D., Herzog, S., Raja, R., 945 Sastry, A., "The COPS (Common Open Policy Service) 946 Protocol", IETF , December 947 1998. 949 [RAP] Yavatkar, R., et al., "A Framework for Policy Based 950 Admission Control",IETF , 951 November, 1997. 953 [E2E] Bernet, Y., Yavatka,r R., Ford, P., Baker, F., Nichols, K., 954 Speer, M., "A Framework for End-to-End QoS Combining 955 RSVP/Intserv and Differentiated Services", IETF , March 1998. 958 [RSVP] Braden, R., Zhang, L., Berson, S., Herzog, S., and Jamin, 959 S., "Resource Reservation Protocol (RSVP) Version 1 960 Functional Specification", IETF RFC 2205, Proposed 961 Standard, September 1997. 963 [ASN1] Information processing systems - Open Systems 964 Interconnection, "Specification of Abstract Syntax Notation 965 One (ASN.1)", International Organization for 967 COPS Usage for Differentiated Services December 1998 969 Standardization, International Standard 8824, December 970 1987. 972 [BER] Information processing systems - Open Systems 973 Interconnection - Specification of Basic Encoding Rules for 974 Abstract Syntax Notation One (ASN.1), International 975 Organization for Standardization. International Standard 976 8825, (December, 1987). 978 [Nichols] K. Nichols, V. Jacobson, L. Zhang, " A Two-bit 979 Differentiated Services Architecture for the Internet," 980 draft-nichols-diff-svc-arch-00.txt 982 10. Author Information 984 Francis Reichmeyer 985 Bay Networks, Inc. 986 3 Federal Street 987 Billerica, MA 01821 988 Phone: (978) 916-3352 989 Email: freichmeyer@baynetworks.com 991 Kwok Ho Chan 992 Bay Networks, Inc. 993 600 Technology Park 994 Billerica, MA 01821 995 Phone: (978) 916-8175 996 Email: khchan@baynetworks.com 998 David Durham 999 Intel 1000 2111 NE 25th Avenue 1001 Hillsboro, OR 97124 1002 Phone: (503) 264-6232 1003 Email: david.durham@intel.com 1005 Raj Yavatkar 1006 Intel 1007 2111 NE 25th Avenue 1008 Hillsboro OR 97124 1009 Phone: (503) 264-9077 1010 Email: yavatkar@ibeam.intel.com 1012 Silvano Gai 1013 Cisco Systems, Inc. 1015 COPS Usage for Differentiated Services December 1998 1017 170 Tasman Dr. 1018 San Jose, CA 95134-1706 1019 Phone: (408) 527-2690 1020 email: sgai@cisco.com 1022 Keith McCloghrie 1023 Cisco Systems, Inc. 1024 170 Tasman Dr. 1025 San Jose, CA 95134-1706 1026 Phone: (408) 526-5260 1027 email: kzm@cisco.com 1029 Shai Herzog 1030 IPHighway 1031 400 Kelby St., Suite 1500 1032 Parker Plaza 1033 Fort Lee, NJ 07024 1034 Phone: (201) 585-0800 1035 Email: herzog@iphighway.com