idnits 2.17.1 draft-rajan-policy-qosschema-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-27) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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. ** The document is more than 15 pages and seems to lack a Table of Contents. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an 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. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 36 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 14 instances 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 969: '... The first three MAY attributes descri...' RFC 2119 keyword, line 1592: '... SHOULD be used in conjunction with ...' RFC 2119 keyword, line 1595: '...ch communication SHOULD be secured, wi...' Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 625 has weird spacing: '...ecified inter...' == Line 875 has weird spacing: '...he form hhmms...' == Line 1024 has weird spacing: '...th this token...' == Line 1103 has weird spacing: '...emeters for i...' == Line 1114 has weird spacing: '...emeters for o...' -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: 'Piper98' on line 790 == Unused Reference: '1' is defined on line 1608, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 1616, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 1623, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 1630, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1795 (ref. '1') == Outdated reference: A later version (-08) exists of draft-ietf-rap-cops-00 ** Obsolete normative reference: RFC 1777 (ref. '4') (Obsoleted by RFC 3494) ** Obsolete normative reference: RFC 1541 (ref. '5') (Obsoleted by RFC 2131) -- Possible downref: Normative reference to a draft: ref. '6' == Outdated reference: A later version (-03) exists of draft-ietf-rap-framework-00 ** Downref: Normative reference to an Informational draft: draft-ietf-rap-framework (ref. '8') -- Possible downref: Non-RFC (?) normative reference: ref. '9' -- No information found for draft-ietf-ipsec-policy-ldapschema - is the name correct? -- Possible downref: Normative reference to a draft: ref. '10' -- Possible downref: Non-RFC (?) normative reference: ref. '11' -- Possible downref: Non-RFC (?) normative reference: ref. '12' == Outdated reference: A later version (-01) exists of draft-strassner-policy-terms-00 -- Possible downref: Normative reference to a draft: ref. '13' Summary: 16 errors (**), 0 flaws (~~), 14 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force Authors 3 INTERNET DRAFT R. Rajan/J. C. Martin 4 IBM/Sun Microsystems 5 S. Kamat/M. See/ R. Chaudhury 6 IBM/Xylan/ Telstra 7 D. Verma/ G. Powers/ R. Yavatkar 8 IBM/ Packeteer/ Intel 9 23/ October/1998 11 Schema for Differentiated Services and Integrated Services in Networks 12 draft-rajan-policy-qosschema-00.txt 14 Status of Memo 16 This document is an Internet-Draft. Internet-Drafts are 17 working documents of the Internet Engineering Task Force 18 (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as 20 Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of 23 six months and may be updated, replaced, or obsoleted by 24 other documents at any time. It is inappropriate to use 25 Internet-Drafts as reference material or to cite them other 26 than as ``work in progress.'' 28 To learn the current status of any Internet-Draft, please 29 check the 30 ``1id-abstracts.txt'' listing contained in the 31 Internet-Drafts Shadow Directories on ftp.ietf.org (US 32 East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West 33 Coast), or munnari.oz.au (Pacific Rim). 35 Abstract 37 This document describes the structure of a directory schema 38 to enable and support administration of differentiated 39 services and/or integrated services within and among 40 Internet domains, intranets, and extranets. This draft 41 replaces draft-ellesson-sla-schema-00.txt. 43 1. Overview 45 Integrated services with RSVP [2] signaling approach seeks to 46 provide per-flow QoS assurances with dynamic resource reservation. 47 A flow is defined by the 5-tuple (source address, destination 48 address, protocol, source port, destination port). In this context, 49 there is a need to provide policy control of individual flows, and 50 regulate their ability to reserve network resources. (See [8] 51 for a discussion of policy based admission control framework and 52 sample policies). Differentiated services[6], on the other hand, 53 are aimed at traffic aggregates that may not correspond to fine 54 grained flows. This approach may rely more on administrative control 55 of bandwidth, delay or dropping preferences, rather than per-flow 56 signaling protocols to communicate the service level information 57 to network elements. For such services we wish to enable flexible 58 definition of class-based packet handling behaviors and class-based 59 policy control. (See [6] for a discussion of DiffServ framework and 60 sample behavior/service descriptions). 62 In either of these environments, network administrators need the 63 ability to define and administer different types of services for 64 customers. Administrative policies tend to change infrequently, and 65 can be conveniently stored in a directory based repository which may 66 be distributed across multiple physical servers, but is administered 67 as a single entity by the network administrator. Furthermore, 68 this information must be propagated to network elements such as 69 hosts, proxies and routers, that actually implement the policies and 70 preferences by classifying traffic to identify its level of service, 71 and apportioning resources according to defined resource regulation 72 policies. 74 This document describes a common language for describing 75 administrative policies for integrated services and differentiated 76 services in terms of an LDAP schema. Currently, LDAP [4] is a widely 77 deployed industry standard for accessing directory information, and 78 hence LDAP based administration of these customer service level 79 preferences and the associated resource regulation policies seems a 80 natural approach. We envision that policies embodied as LDAP schema 81 will be stored on directories and downloaded to devices such as 82 hosts, routers, policy servers, proxies, etc., that implement the 83 policies. The use of LDAP assures a standard, widely deployed and 84 simple protocol for directory access. 86 The details of the architecture within which this schema will be 87 deployed, is presented in a seperate draft (citation TBDs). This 88 architecture for network resource control involves a management tool, 89 a policy repository, a policy decision point and a policy enforcement 90 entity. The network administrator uses the management tool to 91 populate the policy repository with a number of policy rules that 92 regulate access/use of network resources. These rules could specify 93 for instance, the service category to be employed for a particular 94 application, how much bandwidth is allocated to a particular flow or 95 TOS category, the maximum number of flows to be supported between 96 two subnets, etc. In any case, the administrator-specified rules 97 are stored in the policy repository in a well understood format 98 or schema. The decision entity downloads the policy rules. The 99 enforcement entity is the host or router which encounters (data 100 or signaling) packet flowing across the network. It queries the 101 decision entity for specific actions that are to be applied in 102 conditioning the packet stream. The next section describes the scope 103 of the schema, following which we discuss policy rule matching and 104 present the detailed schema. The draft concludes with a section on 105 examples. For an explanation of terminology employed to describe 106 network policy and services in this document, please refer to [13]. 108 1.1. Objectives and Scope 110 This document aims to support QoS policies for differentiated and 111 integrated services networks that fall within the following three 112 scenarios: 114 - Integrated services secured through the use of RSVP signaling, 115 within or across domains. The use of policy in such an 116 environment allows enterprises to be able to police QoS requests 117 on a per-flow, per-user or per-application basis. Directory 118 schema are meant to be used in conjunction with the use of the 119 policy elements in RSVP signaling messages, to enable routers to 120 identify users and applications to which policy must be applied. 122 - Differentiated services secured through provisioning within a 123 domain, and, in an inter-domain scenario, bilateral agreements 124 across peer network boundaries. In such cases, policies are used 125 to map across the two domain specific semantics, and enforce 126 access control restrictions, such as ensuring that the amount of 127 in-profile traffic is within the specified contractual limits. 129 - Integrated services secured within a domain, being mapped onto 130 differentiated services across domains. In such cases, policies 131 are needed at the domain boundary to translate between Integrated 132 and Differentiated service semantics, to enforce traffic 133 monitoring and to provide access control to network resources. 135 Two important scenarios, not explicitly supported by the schema in 136 this draft, but which may be covered by extensions to it are: 138 - RSVP aggregation, i.e., the mapping of several RSVP flows into 139 pre-configured RSVP tunnels, 141 - Support of differentiated services using RSVP tunnels. 143 We have the following objectives in defining this schema. 145 1. The directory provides a convenient repository of the resource 146 regulation policies, which may be used by a wide variety 147 of clients that actually enforce the resource regulation 148 rules. As illustrated before, there are at least three such 149 potential clients for the near term: 1) an edge device that 150 marks/drops/buffers/schedules certain packets to enforce a 151 service differentiation policy, 2) an RSVP capable router that 152 accepts/denies resource reservation requests based on allowed 153 policies, and 3) hosts capable of packet marking and traffic 154 conditioning. We would like the schema definition to be generic 155 enough to support a wide range of resource control environments 156 including the clients mentioned above. 158 2. When viewed in the context of resource control policies, the 159 associated schema can be considered to provide a ``language'' 160 for defining these policies. From this perspective, we desire 161 that the schema should facilitate definition of a wide range 162 of policies varying in their complexity. Simple policies (the 163 common case) should be easy to specify, and there should be 164 sufficient hooks to define sophisticated policies within the 165 schema. Using the language analogy, an administrator's ability 166 to define sophisticated resource regulation policies should not 167 be limited by the structure of the schema, although it may be 168 limited by the available implementation of the policy enforcement 169 environment. 171 3. The schema should facilitate simple addition and deletion 172 of new rules, automated checks for rule ambiguities, and 173 allow for diverse methods (varying in efficiency and ease of 174 implementation) to be employed in the policy decision entity to 175 search through rules. 177 2. Class Hierarchy 179 In this section, we describe the inheritance hierarchy and the 180 relationship between various classes. We define a structural 181 LDAP object class called Policy as the container for policy 182 rules. An object of this class will ``piece together'' several 183 policy components relating to differentiated services, RSVP and 184 IPSec based VPNs [10]. In this section we largely focus on the 185 PolicyRules object class itself and not on where it is placed in the 186 organization's existing directory tree. However, the Policy class 187 described here is best understaod within the Common Information 188 Model [11] of the Directory Management Task Force or the directory 189 structure proposed by the Directory Enabled Networks specification 190 [9]. 192 The class hierarchy in the schema is given below. 194 Top 195 |----Policy 196 | 197 |----PolicyCondition 198 | | 199 | |--IPPolicyCondition 200 | 201 |-----UserIDCondition 202 | 203 |----PolicyValidityPeriod 204 | 205 |----PolicyAction 206 | |----RSVPAction 207 | |----DiffServAction 208 | |----TCPAction 209 | |----ISAKMPAction 210 | |----IPSecSecurityAction 211 | 212 |----DiffServResourceGroup 213 |----RSVPResourceGroup 214 |----IPSecProposal 215 |----ISAKMPProposal 216 |----IPSecTransform 217 |----IPSecPrivateDiffieHellmanGroup 218 | 219 |----PolicyContainmentAuxClass 221 The schema described above closely follows the policy class hierarchy 222 described in the document ``Information Model and Base Schema'' 223 version 3.0r5 released by the Directory Enabled Network AdHoc 224 Group. The schema described in this document expands on the DEN 225 specification but differs in a few significant details. 227 3. Policy Rules 229 The Policy object class is instantiated by LDAP entries, where each 230 entry encodes a policy rule that specifies the resources and services 231 that are allowed (or denied) to a stream of packets. An entry is 232 composed of several attributes. Each attribute is of a certain type, 233 and has one or more values. The two principal components of a policy 234 rule are objects of the type PolicyCondition and and PolicyAction. 235 These two objects describe a rule through the relation 237 if then . 239 A PolicyCondition object is defined by the values of a collection 240 of certain attributes that are typically used to determine when a 241 policy rule applies. A typical condition is, for instance, a range 242 of source addresses (or a source address and mask) to which the 243 policy applies. An action is defined by a collection of attributes 244 that detail permissions or additional behaviours that the policy 245 enforcement entity should perform for the given condition. For 246 instance, the value of attribute PolicyConditionRef could be the 247 distinguished name of an object that places restrictions on the 248 source address range of IP packets, while PolicyActionRef could 249 be the distinguished name of a DiffServAction object that fully 250 describes the treatment of a flow with respect to TOS marking and QoS 251 requirements. 253 Conditions and actions may each be of different types. For instance, 254 a PolicyCondition object may place restrictions on, or otherwise 255 refer to information contained in IP header fields such as source 256 addresses, or to information contained inside signalling packets 257 as with RSVP PATH or RESV messages, or may refer to information 258 regarding the layer 2 protocol such as restrictions on MAC addresses. 259 In this draft we take a simple, first cut approach to such issues, 260 covering the most common policy cases, but allowing for future 261 extensions to this draft or to policy standards. We allow the 262 class PolicyCondition to be expanded through an auxillary class 263 IPPolicyAuxCondition which allows for conditions based on IP 264 header fields, or through the class UserIDPolicyAuxCondition which 265 allows for conditions based on user IDs. Similarly, the class 266 PolicyAction is subclassed into a number of protocol or service 267 specific actions -- DiffServAction, RSVPAction, IPSecSecurityAction 268 and IPSecISAKMPAction. Both the PolicyCondition class and the 269 PolicyAction class may be easily extended in future. 271 4. Ascertaining Applicability of Policy Rules 273 Typically, the policy decision entity needs to ascertain which 274 actions to apply to a particular (data or signalling) packet based on 275 the rules that it has downloaded from the repository. In doing so, 276 it must combine logical information that has been organized through 277 the schema structure where policy rules are made up of condition 278 and action attributes, and these attributes may assume one or more 279 values. We now explain the process of ascertaining whether a packet 280 meets a condition. 282 Consider a PolicyCondition object composed of several attributes 283 attribute1, attribute2, ..., each potentially assuming one or 284 more values (value1-1, value1-2,...), (value2-1,value2-2,...),..., 285 respectively. The packet header has several fields (field1, 286 field2,...). We say that the packet meets the condition if field1 287 belongs to any of the sets value1-1, value1-2 AND if field2 belongs 288 to any of the sets value 2-1, value2-2, AND so on. Thus, the check 289 of if packet matches condition can be written as 291 if (((field1 belongs to value1-1) OR (field1 belongs to value1-2) OR ...) 292 AND 293 ((field2 belongs to value2-1) OR (field2 belongs to value2-2) OR ...) 294 AND 295 ... 296 ) 298 Most attributes are NOT multi-valued, and exceptions such as 299 Interface (denoting the incoming and outgoing interfaces on which the 300 rule is applicable) or TimeOfDay (denoting the time of day when the 301 rule is applicable) have been introduced only where unavoidable. As 302 an example, consider a packet with source address 8.2.3.1, source 303 port 50, destination address 7.2.3.1, destination port 51, protocol 304 22 arriving at a router on the interface 3, departing on interface 5 305 being matched against the following condition. 307 Attribute Values 309 SourceAddressRange 8.0.0.0 : 8.255.255.255 310 SourcePortRange 50 : 51 311 DestinationAddressRange 7.2.0.0 : 7.2.255.255 312 DestinationPortRange 50 : 51 313 Protocol 0 : 100000 (May be omitted) 314 Interface 1 : 5 (format - incoming:outgoing) 315 2 : 5 316 3 : 5 318 It is easy to check that the packet meets the condition, but another 319 packet destined to the address 9.2.19.250 would not. 321 Now, the policy decision point successively evaluates multiple rules 322 and in order to choose the one that matches. Thus, it checks 324 RULE 1: if (packet meets condition1) then perform (action1-1, action1-2, ...) 325 RULE 2: if (packet meets condition2) then perform (action2-1, action2-1, ...) 326 etc. 328 Here the logical operator that is used to combine the rules is an 329 AND, i.e., 331 RULE 1 AND RULE 2 333 If the rules are mutually exclusive, i.e., no packet can ever 334 meet both conditions, then the actions corresponding to the one 335 that applies are performed. What does the decision entity do if 336 both conditions are applicable? In some cases, action 1 could be 337 compatible with action 2, i.e., it may be possible to perform both 338 actions. As an example, if action1 is a directive to encapsulate the 339 packet, and action2 indicates the QoS stream the packet belongs to, 340 then the packet is encapsulated and then given the right QoS. On the 341 other hand, if the actions are incompatible, then the operation of 342 the decision entity could be undefined. 344 Rule consistency is desirable whenever possible. However, for 345 purposes of administrative convenience, it is often useful to 346 introduce temporary rules that override others, without having to 347 remove the overriden rule -- for example, special rules for New 348 Year's day. We allow for this by optionally attaching priorities 349 to rules. Potential ambiguities are thus resolved by assigning a 350 higher priority to the overriding rule. In the earlier example, for 351 instance, if rule 2 has higher priority, then the decision point 352 performs all the actions specified in rule 2, and all the compatible 353 actions specified in rule 1. Hence, the right interpretation of the 354 rule set is: 356 if (packet meets condition2) then perform (action2-1, ...) 357 AND 358 if (packet meets condition1) then 359 if (action1-1) is compatible then perform it 360 if (action1-2) is compatible then perform it 361 ... 363 It is very simple to check for compatibility. Actions correspond a 364 few basic scopes -- RSVP, DiffServ, IPSec, and so on. We need to 365 collect no more than one action of a particular scope. 367 5. The class Policy 369 The Policy object class is the container class for the policy rules. 370 It contains a number of entries, each entry encodes a policy rule 371 that specifies the resources and services that are allowed (or 372 denied) to a stream of packets. An overview of the class Policy is 373 presented below, followed by the detailed sytax and semantics of 374 various attributes. 376 NAME Policy 377 TYPE Structural 378 DERIVED FROM Top 379 MUST 380 CommonName, 381 PolicyScope, 382 PolicyConditionRef, 383 PolicyActionRef, 384 PolicyVersion 385 MAY 386 PolicyRulePriority, 387 PolicyKeyword, 388 PolicyType, 389 PolicyName, 390 PolicyEnabled 392 The syntax and semantics of the attributes of the class Policy are as 393 follows: 395 NAME CommonName 396 DESC The common name for objects of this class. Used as relative 397 distinguished name to identify object within a branch of 398 directory tree. 399 SYNTAX IA5String 400 EQUALITY caseExactIA5Match 401 SINGLE-VALUED 403 NAME PolicyScope 404 DESC Lists the services that are controlled through this policy 405 SYNTAX IA5String 406 EQUALITY caseExactIA5Match 407 MULTI-VALUED 408 FORMAT The currently defined values for this attribute are: 409 DiffServ 410 RSVP 411 IPSec 412 ISAKMP 413 SEMANTICS This attribute is used by the appropriate directory clients 414 to fetch only those policy rules that are relevant for their 415 functionality. The value DiffServ' means the policy rule 416 specifies DiffServ packet classification and traffic treatment. 417 The value `RSVP' means specifes an RSVP policy 418 decision point. The value `IPSec' means the policy refers 419 to an IPSec action rule. The value `ISAKMP' means the policy 420 refers to an ISAKMP action rule. Note that this is a multi- 421 valued attribute, and the same rule may regulate multiple 422 services for a packet stream. 424 NAME PolicyConditionRef 425 DESC Absolute Distinguished name of LDAP entry of the objectclass 426 PolicyCondition, that identify the packets that the policy rule 427 applies to. 428 SYNTAX DN 429 EQUALITY distinguishedNameMatch 430 SINGLE-VALUED 432 The following reference attributes specify the treatment of packets 433 that match the condition specified in the policy rule. The value 434 of a reference attribute is the distinguished name of an LDAP entry 435 which is an object corresponding to a prespecified class. For 436 instance, if the value of the attribute PolicyActionRef is the 437 distinguished name of an entry in the class RSVPAction, then the 438 policy rule specifies the policy relating to the handling of RSVP 439 signalling messages. 441 NAME PolicyActionRef 442 DESC Absolute Distinguished name(s) of LDAP entry, of the objectclass 443 PolicyAction, that specifies permissions and restrictions 444 that apply to the packets identified by the policy condition 445 SYNTAX DN 446 EQUALITY distinguishedNameMatch 447 MULTI-VALUED 448 SEMANTICS Multiple values are understood as logical AND; that is, all 449 the actions must be performed 451 NAME PolicyVersion 452 DESC The version of the policy schema embodied by this policy. 453 SYNTAX IA5String 454 EQUALITY caseExactIA5Match 455 FORMAT The current draft specifies version ``1.0'' 456 SINGLE-VALUED 458 NAME PolicyKeyword 459 DESC List of keywords that assist in locating this policy 460 SYNTAX IA5String 461 EQUALITY caseExactIA5Match 462 MULTI-VALUED 463 DEFAULT No Keywords 465 NAME PolicyType 466 DESC Describes the types of a policy 467 SYNTAX IA5String 468 EQUALITY caseExactIA5Match 469 MULTI-VALUED 470 FORMAT The following values are allowed: 471 ISAKMPPhase1 472 ISAKMPPhase2 473 IPSecDataLocal 474 IPSecDataRemote 475 RSVPSignalling 476 RSVP-DiffServ 477 DiffServ 478 SEMANTICS ISAKMPPhase1 denotes an ISAKMP Phase 1 policy 479 ISAKMPPhase2 denotes an ISAKMP Phase 2 or Quick Mode policy 480 IPSecDataLocal denotes a policy for securing locally 481 originating data by IPSec. Local means either originating 482 from the same host or from an host for which this host 483 acts as a proxy 484 IPSecDataRemote denotes a policy for securing remotely 485 originating data by IPSec. Remote is the opposite of Local 486 as defined before. 487 RSVPSignalling denotes an RSVP signalling policy 488 RSVP-DiffServ denotes a policy for mapping an RSVP traffic 489 into a DiffServ pipe 490 DiffServ denotes a DiffServ policy 491 DEFAULT Unnamed Type 493 NAME PolicyName 494 DESC A user friendly name of this policy class 495 SYNTAX IA5String 496 EQUALITY caseExactIA5Match 497 SINGLE-VALUED 498 DEFAULT No Name 500 The following attribute defines relationships among multiple related 501 rules within the policy repository. 503 NAME PolicyRulePriority 504 DESC Priority level for this rule. Used to resolve ambiguity in 505 condition matching when the ranges specified in the Policy 506 conditions overlap. Higher values of this attribute imply 507 higher priority of the rule. 508 SYNTAX INTEGER 509 EQUALITY integerMatch 510 SINGLE-VALUED 511 DEFAULT The default value is 0 (lowest priority) 512 SEMANTICS Whenever a packet matches two rules of different priority, 513 the rule with the higher value of PolicyRulePriority is 514 applied. 516 NAME PolicyEnabled 517 DESC A flag describing whether the policy is currently enabled or 518 disabled 519 SYNTAX IA5String 520 EQUALITY caseExactIA5Match 521 SINGLE-VALUED 522 FORMAT The currently defined values for this attribute are: 523 Enabled 524 Disabled 525 DEFAULT Enabled 527 5.1. PolicyContainmentAuxClass 529 Policy rules may need to be grouped together for a number 530 of different purposes -- organizational, security, ease of 531 administration, or ease of retrieval by a policy decision point. We 532 reproduce the PolicyContainmentAuxClass from the DEN specification 533 [9] that serves the useful purpose of grouping policies together. 534 This auxillary class definition is as follows: 536 NAME PolicyContainmentAuxClass 537 TYPE Auxillary 538 DERIVED FROM Top 539 AUXILIARY CLASS None 540 POSSIBLE SUPERIORS Organization, OrganizationalUnit, Group, 541 GroupOfDevices 542 MUST PoliciesContainedRef 543 MAY 545 The syntax and semantics of its sole attribute are as follows: 547 NAME PoliciesContainedRef 548 DESC Absolute distinguished names of policies grouped together 549 for some (context-dependent) purpose. 550 SYNTAX DN 551 EQUALITY distinguishedNameMatch 552 MULTI-VALUED 553 6. Policy Conditions 555 In this section we define the abstract class PolicyCondition, its 556 subclass IPPolicyCondition, and the class UserIDCondition. These 557 classes list the conditions that must be statisfied by a stream of 558 packets in order for the referring rule to apply to that packet 559 stream. 561 The reason for subclassing PolicyCondition is to allow extensibility 562 to other networking protocols through sub-classes such as 563 ATMPolicyCondition (for instance). 565 NAME PolicyCondition 566 TYPE Abstract 567 DERIVED FROM Top 568 AUXILIARY CLASS None 569 MUST CommonName 570 MAY PolicyConditionName 571 PolicyValidityPeriodRef 573 The detailed syntax and semantics of the attributes is as below: 575 NAME CommonName 576 DESC The common name of the policy condition object. Unique within a 577 limited scope and used to identify the object within the 578 directory tree. 579 SYNTAX IA5String 580 EQUALITY caseExactIA5Match 581 SINGLE-VALUED 583 NAME PolicyConditionName 584 DESC The user friendly name of this entry.The Name related attributes 585 are only for ease of user administration. 586 EQUALITY caseExactIA5Match 587 SYNTAX IA5String 588 SINGLE-VALUED 590 The next attribute is a reference to PolicyValdityPeriod object that 591 identifies the entry that limits the temporal scope of the policy to 592 specified periods of time. 594 NAME PolicyValidityPeriodRef 595 DESC Absolute distinguished name(s) of an PolicyValidityPeriod 596 object that specifies the times that the policy is active. 597 SYNTAX DN 598 EQUALITY distinguishedNameMatch 599 MULTI-VALUED 600 DEFAULT Policy applies at all times 601 6.1. The class IPPolicyCondition 603 The class PolicyCondition is now specialized to deal with IPv4 packet 604 headers in the class IPPolicyCondition. 606 NAME IPPolicyCondition 607 TYPE Structural 608 DERIVED FROM PolicyCondition 609 AUXILIARY CLASSES none 610 MAY Interface, 611 SourceIPAddressRange, 612 DestinationIPAddressRange, 613 SourcePortRange, 614 DestinationPortRange, 615 IPProtocolNumberRange, 616 ReceivedTOSByteCheck 617 HostUserIDRef 619 The first attribute limits the spatial scope of the policy rule by 620 identifying specific router interfaces where the policy is to be 621 applied. 623 NAME Interface 624 DESC An attribute that limits the scope of the policy to packets on 625 specified interface(s) and the direction(s) of traffic on these. 626 SYNTAX IA5String 627 EQUALITY caseExactIA5Match 628 MULTI-VALUED 629 FORMAT Three colon seperated strings. The left-most string is a numeral 630 denoting the type of the specification, followed by the incoming 631 and outgoing interface identifiers. Currently defined type/value 632 formats are 633 1:: 634 2:: 635 The IP addresses are in dotted decimal notation. The interface 636 IDs are integers unique to the host device. 637 The first address string specifies a restriction of the rule 638 to traffic inbound on the interface, and the rightmost string 639 specifies a corresponding restriction of the rule to traffic 640 outbound from that interface. An unspecified interface(s) 641 defaults to all interfaces on the device that this rule 642 applies to. 643 DEFAULTS Defaults to traffic inbound on all interfaces, outbound on 644 all interfaces. 646 EXAMPLE 1:9.3.1.52:9.2.1.54 (Applies to traffic inbound on 9.3.1.52 647 and outbound on 9.3.1.54) 649 1:9.3.1.32: (Applies to traffic inbound on 9.3.1.52 650 outgoing from any interface) 651 2::3 (Applies to traffic outbound on interface 3 652 arriving on any interface) 654 NAME SourceIPAddressRange 655 DESC Source IP addresses to which the policy applies 656 SYNTAX IA5String 657 EQUALITY caseExactIA5Match 658 SINGLE-VALUED 659 FORMAT SourceIPAddressRange is of the following form: three colon (':') 660 separated strings denoting a range of IP addresses. The formats 661 currently defined are: 663 1:: 664 The IP v4 address is in dotted decimal format. The 665 CIDRPrefixLength is the number of unmasked leading bits. 666 A packet matches the condition if the unmasked 667 bits on the packet are identical to the unmasked bits on the 668 condition. 670 2:: 671 IP addresses in dotted decimal format. The second 672 address must be no smaller than the first. The first 673 denotes the start of the range, and the second denotes 674 the end of the range. A packet matches the condition 675 if its source address is no smaller than the first 676 IP address in the condition, and no larger than the 677 second. 679 3 680 Indicates policy applies to locally generated packets. 681 DEFAULT Defaults to the entire address range, i.e., every packet 682 matches the source address range condition. 684 EXAMPLE 1:83.23.23.1:24 685 A packet with source address 83.23.23.5 matches. 686 A packet with source address 83.23.24.1 does not. 687 2:83.23.23.0:83.28.28.0 688 A packet with source address 83.23.23.5 matches. 689 A packet with source address 83.29.24.1 does not. 691 NAME DestinationIPAddressRange 692 DESC Destination IP addresses to which policy applies 693 SYNTAX IA5String 694 EQUALITY caseExactIA5Match 695 SINGLE-VALUED 696 FORMAT Identical to that of SourceIPAddressRange above. 698 The value of ``3''indicates a locally destined packet. 699 DEFAULT Defaults to the entire address range, i.e., every packet 700 matches the destination address range condition. 702 NAME SourcePortRange 703 DESC Source Ports to which policy applies 704 SYNTAX IA5String 705 EQUALITY caseExactIA5Match 706 SINGLE-VALUED 707 FORMAT String consisting of two colon separated positive 708 integers, the second no smaller than the first, or one 709 positive integer. 710 DEFAULT Defaults to the entire port range 0 to 65535, i.e., every 711 packet matches the destination address range condition. 712 EXAMPLE 8000:8080 (ports 8000 to 8080), 713 8000 (only port 8000) 715 NAME DestinationPortRange 716 DESC Destination Ports to which policy applies 717 SYNTAX IA5String 718 EQUALITY caseExactIA5Match 719 SINGLE-VALUED 720 FORMAT String consisting of two colon separated positive 721 integers, the second no smaller than the first, or one 722 positive integer. 723 DEFAULT Defaults to the entire port range 0 to 65535, i.e., every 724 packet matches the source address range condition. 726 NAME IPProtocolNumberRange 727 DESC Protocol numbers to which policy applies 728 SYNTAX INTEGER 729 EQUALITY integerMatch 730 SINGLE-VALUED 731 FORMAT String consisting of two colon separated positive 732 integers, the second no smaller than the first, or one 733 positive integer. 734 DEFAULT Defaults to the entire protocol range 0 to 255, i.e., every 735 packet matches the ip protocol range condition. 736 EXAMPLE 50:51 (protocol 50 to 51), 737 50 (only protocol 50) 739 NAME ReceivedTOSByteCheck 740 DESC A condition attribute used to select traffic based on the 741 contents of the TOS byte of the received packet's IP header 742 SYNTAX IA5String 743 EQUALITY caseExactIA5Match 744 SINGLE-VALUED 745 FORMAT String of the form xxxxxxxx:xxxxxxxx, where each of the 746 x's is either 0 or 1. 747 SEMANTICS Each of the substrings is treated as specifying an 8-bit 748 field. The left substring is termed Mask and the right 749 substring Match. The TOS byte of the received packet's IP 750 header is ANDed with Mask and the result is compared against 751 Match. The combination of Mask and Match allows definition of 752 TOS byte based conditions where certain bits in the TOS byte 753 may be ignored for the purpose of comparison. 755 EXAMPLE An incoming packet with TOS byte 11001010 matches the 756 condition specified by a value of 00111100:00001000 for 757 ReceivedTOSByte. 759 NAME UserIDConditionRef 760 DESC Absolute Distinguished name(s) of LDAP entry or entries, of 761 an UserIDCondition object that identify the user or 762 host whose packets that the policy rule applies to. 763 SYNTAX DN 764 EQUALITY distinguishedNameMatch 765 MULTI-VALUED 767 6.2. The Class UserIDCondition 769 In many scenarios, for instance an end host IPSec, policy needs to 770 be specified for a user or a host ID instead of an IP address. A 771 standard example is a corporate worker connecting from home via an 772 ISP. The policy would be specified by Host FQDN, UserFQDN, X500 DN 773 etc. To accomodate this source and destination ids are required. 775 NAME HostUserID 776 TYPE Structural 777 DERIVED FROM Top 778 AUXILIARY CLASS None 779 MUST CommonName 780 MAY SourceID, 781 DestinationID, 783 NAME SourceID 784 DESC Source Host Identifier 785 SYNTAX IA5String 786 EQUALITY caseExact1A5Match 787 MULTI-VALUED 788 FORMAT Two strings , colon (`:') seperated, the first describing the 789 ID type and the second the ID value. The valid IdTypes and 790 their corresponding values are defined in [Piper98]. These 791 include: 792 Host-FQDN: 793 User-FQDN: 794 X500-DN: 795 X500-GN: 796 Key-Id: 797 DEFAULT Any ID is considered valid. 799 NAME DestinationID 800 DESC Destination Host Identifier 801 SYNTAX IA5String 802 EQUALITY caseExact1A5Match 803 MULTI-VALUED 804 DEFAULT Any ID is considered valid. 805 FORMAT Same as Source ID. 807 7. The class PolicyValidityPeriod 809 Objects of this class describe conditions that restrict the validity 810 period of the policy rule. The class definition is as follows: 812 NAME PolicyValidityPeriod 813 TYPE Structural 814 DERIVED FROM Top 815 AUXILIARY CLASSES NONE 816 MUST CommonName 817 MAY PolicyValidityPeriodName, 818 PolicyValidityTime, 819 PolicyValidityMonthMask, 820 PolicyValidityDayOfWeekMask, 821 PolicyValidityTimeOfDayRange 823 The syntax and semantics of various attributes are as given below 825 NAME PolicyValidityPeriodName 826 DESC The user friendly name of this entry. 827 SYNTAX IA5String 828 EQUALITY caseExactIA5Match 829 SINGLE-VALUED 831 NAME PolicyValidityTime 832 DESC When this policy is valid 833 SYNTAX IA5String 834 EQUALITY caseExactIA5Match 835 MULTI-VALUED 836 FORMAT String(s) of the form yyyymmddhhmmss:yyyymmddhhmmss: 837 SEMANTICS The first two substrings must be valid times, 838 (year-month-date-hour-minute- second) the second larger 839 than the first. The last substring is optional and 840 describes the time zone. 841 DEFAULT If the time zone is omitted then the time is local time at 842 the policy decision point. If the attribute itself is absent 843 then the policy is always valid. 844 EXAMPLE 19980121060000:19991231133000:GMT 845 (meaning Policy in effect from 6:00 AM on January 21, 1998 846 to 1:30 PM on December 31, 1999, Greenwich Mean Time). 848 NAME PolicyValidityMonthMask 849 DESC Months during which policy is valid 850 SYNTAX IA5String 851 EQUALITY caseExactIA5Match 852 SINGLE-VALUED 853 FORMAT String denoting a mask of 12 0s and 1s. 854 SEMANTICS 1's corresponding to months in the January to December 855 range when the policy is valid. 856 EXAMPLE 000111111100 (Valid from April until October) 857 DEFAULT 111111111111, i.e., valid always 859 NAME PolicyValidityDayOfWeekMask 860 DESC days during which policy is valid 861 SYNTAX IA5String 862 EQUALITY caseExactIA5Match 863 SINGLE-VALUED 864 FORMAT String representing a mask of 7 0s and 1s. 865 SEMANTICS 1's correspond to days in the Monday to Sunday range 866 when the policy is valid. 867 EXAMPLE 1111100 (Valid weekdays) 868 DEFAULT 1111111, i.e., valid always 870 NAME PolicyValidityTimeOfDayRange 871 DESC Time(s) of day during which policy is valid 872 SYNTAX IA5String 873 EQUALITY caseExactIA5Match 874 MULTI-VALUED 875 FORMAT String(s) of the form hhmmss:hhmmss 876 SEMANTICS Substrings on either side of the colon must be be valid 877 time of day values. If the second string is not larger 878 than the first, then a wrap around midnight is assumed. 879 DEFAULT 000000:235959 881 EXAMPLE 090000:170000 (Policy valid from 9 AM to 5 PM) 882 7.1. The class DiffServAction 884 Each object of type DiffServAction describes a component per-hop 885 behaviour (PHB) in force at a network device. The DiffServAction 886 class does not seek to describe in detail resource reservations, 887 packet treatment and configuration of every possible network device. 888 Instead, it provides a high-level description of QoS services 889 through a simple model that uses the following three descriptors -- 890 traffic descriptors, packet marking descriptors and resource group 891 descriptors. 893 The traffic descriptor assumes a leaky bucket model with three 894 attributes -- a mean rate, a peak rate and a bucket size -- to 895 specify the characteristics of what is to be considered in-profile 896 traffic, with the understanding that the rest is out-of-profile 897 or excess traffic. The traffic descriptor makes sense only with 898 the assumption that a policing device is present at the policy 899 enforcement point; if not the attributes may be omitted or will be 900 ignored. 902 The packet marking descriptor provides an edge device with the 903 ability to mark the DS byte for simple QoS classification at 904 downstream network devices. We allow for differential marking of 905 in and out of profile traffic (which makes sense if policing is 906 present); as well as for the enforcement point to mask certain bits 907 while modifying others. 909 The resource group descriptor describes the treatment expected by 910 packets within a common service group. It is not a description of 911 how the service is to be provided, but simply a high-level view of 912 the service to be accorded to the in-profile traffic, its delay and 913 loss requirements, for instance, as well as the treatment of excess 914 traffic, whether this is to be tolerated, reshaped or dropped. 916 It is important to note that TrafficDescriptor and ResourceGroupDescriptor 917 objects refer to states created in the network device. To understand 918 this better, consider two policy rules, as follows. 920 Rule1: If PolicyCondition1 then PolicyDSAction1 922 Rule2: If PolicyCondition2 then PolicyDSAction1 924 PolicyDSAction1: TrafficDescriptor1 925 PacketMarkingDescriptor1 926 ResourceGroupDescriptor1 928 Now, all packets described either by PolicyCondition1 or by 929 PolicyCondition2 will be policed together, and share the same rate 930 resource reservations. This is different from the case where we have 932 Rule1: If PolicyCondition1 then PolicyDSAction1 934 Rule2: If PolicyCondition2 then PolicyDSAction2 936 PolicyDSAction1: TrafficDescriptor1 937 PacketMarkingDescriptor1 938 ResourceGroupDescriptor1 940 PolicyDSAction2: TrafficDescriptor2 941 PacketMarkingDescriptor2 942 ResourceGroupDescriptor2 944 Even if the two traffic descriptors are identical, the two streams 945 will not be policed together by the same policer -- they will be 946 policed by identical policers. Similarly, they will not share 947 the same buffer or bandwidth resources. In fact, the resource 948 requirements for the second example will be twice those of the first 949 (ignoring multiplexing gains). 951 The class description of DiffServAction is as follows: 953 NAME DiffServAction 954 TYPE Structural 955 DERIVED FROM PolicyAction 956 AUXILIARY CLASSES NONE 957 MUST 958 CommonName 959 DiffServPermission 960 MAY 961 DiffServInProfileRate, 962 DiffServInProfilePeakRate, 963 DiffServInProfileTokenBucket, 964 DiffServInProfileTransmittedTOSByte 965 DiffServOutProfileTransmittedTOSByte 966 DiffServResourceGroupRef 967 DiffServActionName 969 The first three MAY attributes describe the traffic, the next two 970 specify the marking, and next is a reference to the resource group. 972 The following set of attributes are currently defined for the 973 DiffServ Policy Directory Clients, namely hosts, edge devices, and 974 routers that do traffic conditioning (packet marking, dropping, 975 shaping, etc). 977 NAME DiffServPermission 978 DESC Allow/drop data packets matching the profile 979 EQUALITY caseExactIA5Match 980 SYNTAX IA5String 981 SINGLE-VALUED 982 FORMAT The currently defined values for this attribute are: 983 Accept 984 Deny 986 With the permission attribute set to ``Accept'', and no other 987 attribute present, the packets matching the PolicyCondition are given 988 the ``Best Effort'' service. 990 NAME DiffServActionName 991 DESC The user friendly name of this entry. 992 EQUALITY caseExactIA5Match 993 SYNTAX IA5String 994 SINGLE-VALUED 995 DEFAULT No name 997 NAME DiffServInProfileRate 998 DESC Specifies the token rate for the in-profile traffic descriptor 999 in kbps 1000 EQUALITY integerMatch 1001 SYNTAX INTEGER 1002 SINGLE-VALUED 1003 SEMANTICS All packets in the behavior aggregate are measured against 1004 a leaky bucket with this token rate. Traffic that passes the leaky 1005 bucket check is considered in-profile. 1006 DEFAULT All packets considered in-profile, i.e., infinity 1008 NAME DiffServInProfilePeakRate 1009 DESC Specifies the peak rate for the in-profile traffic descriptor in kbps 1010 EQUALITY integerMatch 1011 SYNTAX INTEGER 1012 SINGLE-VALUED 1013 SEMANTICS All packets in the behaviour aggregate are measured 1014 against a leaky bucket with this peak rate. 1015 DEFAULT Same value as DiffServInProfileRate 1017 NAME DiffServInProfileTokenBucket 1018 DESC Specifies the token bucket size for in-profile traffic 1019 descriptor kilobits 1020 EQUALITY integerMatch 1021 SYNTAX INTEGER 1022 SINGLE-VALUED 1023 SEMANTICS All packets in the behaviour aggregate are measured 1024 against a leaky bucket with this token bucket size. 1025 DEFAULT Defaults to the maximum IP packet size. 1027 NAME DiffServInProfileTransmittedTOSByte 1028 DESC Specifies the outgoing TOS byte for in profile packet 1029 marking descriptor 1030 EQUALITY caseExactIA5Match 1031 SYNTAX IA5String 1032 FORMAT String(s) of the form xxxxxxxx:xxxxxxxx, where each of the `x's 1033 is either 0 or 1. 1034 SINGLE-VALUED 1035 SEMANTICS Each of the two substrings is treated as specifying an 8-bit 1036 field. The left substring is termed Mask and the right 1037 substring Modify. 0's in the Mask specify the bit locations 1038 in the TOS byte that must not be changed and 1's specify 1039 those that must be changed to match the corresponding ones 1040 in the Modify field. The operation involved is: newTOSByte 1041 = (Mask' & oldTOSbyte) | (Mask & Modify), where Mask' is the 1042 bitwise complement of Mask and '&' and '|' denote the 1043 bit-wise AND and OR operations respectively. 1044 EXAMPLE Consider a policy rule that specifies 11100000:11001010 as 1045 the value for this attribute. The Mask of 11100000 means 1046 that when this rule is applied, the 5 least significant bits 1047 in the TOS byte must be left unchanged but the 3 most 1048 significant bits must be changed to make them identical to 1049 the corresponding ones in the Modify field. Thus, if this 1050 rule were to be applicable to a packet whose TOS byte is 1051 10101010, then the TOS byte will be changed to 11001010 1052 before transmission. 1053 DEFAULT Dont modify any bit, i.e., 1054 Mask 00000000 1055 Modify 00000000 1057 NAME DiffServOutProfileTransmittedTOSByte 1058 DESC Specifies the outgoing TOS byte for out-of-profile packet 1059 marking descriptor 1060 EQUALITY caseExactIA5Match 1061 SYNTAX IA5String 1062 FORMAT same as `DiffServInProfileTransmittedTOSByte' attribute 1063 SINGLE-VALUED 1064 SEMANTICS same as `DiffServInProfileTransmittedTOSByte' attribute 1065 DEFAULT same as `DiffServInProfileTransmittedTOSByte' attribute 1067 NAME DiffServResourceGroupRef 1068 DESC Absolute distinguished name of LDAP entry, from the objectclass 1069 DiffServResourceGroup, that identifies the service category and 1070 resource group descriptors that apply to the traffic. 1071 EQUALITY distinguishedNameMatch 1072 SINGLE-VALUED 1073 SYNTAX DN 1074 DEFAULT Best Effort Service 1076 7.1.1. The class DiffServResourceGroup 1078 Objects of this class fully specify the treatment accorded to 1079 in-profile and out-of-profile traffic, in terms of their access to 1080 QoS resources. 1082 NAME DiffServResourceGroup 1083 TYPE Structural 1084 DERIVED FROM Top 1085 AUXILIARY CLASSES NONE 1086 MUST CommonName 1087 MAY 1088 DiffServLossParameter, 1089 DiffServDelayParameter, 1090 DiffServBandwidthShare, 1091 DiffServExcessTrafficTreatment 1092 DiffServAutoStart 1093 DiffServResourceGroupName 1095 NAME DiffServResourceGroupName 1096 DESC The user friendly name of this entry. 1097 EQUALITY caseExactIA5Match 1098 SYNTAX IA5String 1099 SINGLE-VALUED 1100 DEFAULT No name 1102 NAME DiffServLossParameter 1103 DESC Packet loss paremeters for in-profile traffic for this 1104 class of service 1105 EQUALITY caseExactIA5Match 1106 SYNTAX IA5String 1107 FORMAT Colon seperate numeric strings, A:B, where at most A packets 1108 may be dropped for every B packets received. 1109 SINGLE-VALUED 1110 EXAMPLE 2:1000 implies a maximum loss rate of .002. 1111 DEFAULT Best Effort 1113 NAME DiffServDelayParameters 1114 DESC Packet delay paremeters for out-of-profile traffic for this 1115 class of service 1117 EQUALITY caseExactIA5Match 1118 SYNTAX IA5String 1119 FORMAT Colon seperated integer:string pair. Currently defined 1120 1: where the absolute delay is expressed in msec 1121 2: where the relative delay is expressed as 1122 a priority (1 means best effort) 1123 SINGLE-VALUED 1124 DEFAULT Best Effort 1126 NAME DiffServBandwidthShare 1127 DESC Bandwidth share for this class of service 1128 EQUALITY caseExactIA5Match 1129 SYNTAX IA5String 1130 FORMAT Colon seperated integer:string pair. Currently defined 1131 1: where the absolute bw is expressed 1132 in kilobits/sec 1133 2: where the bandwidth percent is a number 1134 between 0 and 100 expressing the share of the bandwidth 1135 allowed to this class 1136 SINGLE-VALUED 1137 SEMANTICS The bandwidth weight is converted into a bandwidth share at 1138 the enforcement entity by adding the weights of all 1139 DiffServ classes and then taking the appropriate 1140 ratios. The second case is provided for instances where 1141 the policy rule is unaware of the link capacity at the 1142 enforcement entity. 1143 EXAMPLES 1:200 -- This class is allocated a 200kbps 1144 2:40 -- This class is allocated 40% of the link bandwidth 1145 DEFAULT 0, i.e., No reserved share 1147 NAME DiffServExcessTrafficTreatment 1148 DESC Describes how excess traffic is to be treated. 1149 EQUALITY caseExactIA5Match 1150 SYNTAX IA5String 1151 FORMAT The following values are defined 1152 `Drop' -- Allow no excess traffic 1153 `Best Effort' -- Treat excess traffic as best effort 1154 `Reshape'--Reshape excess traffic 1155 SINGLE-VALUED 1156 SEMANTICS: This field specifes the actions that must be taken if an 1157 incoming packet cannot be placed within the reserved buffer 1158 allocation of the stream. 1159 DEFAULT Best Effort 1161 NAME DiffServAutoStart 1162 DESC Indicates if the resource allocation for this service should be 1163 done at time of enforcement entity startup, or should be packet 1164 driven. This attribute is for guidance only, and its 1165 interpretation is implementation specific. 1166 EQUALITY caseExactIA5Match 1167 SYNTAX IA5String 1168 FORMAT The following strings are defined 1169 `AutoStart' --- Allocate resources at device startup 1170 `NoAutoStart' --- Allocate resources when packets for 1171 flow are seen. 1172 SINGLE-VALUED 1173 DEFAULT Autostart 1175 7.2. The Class RSVPAction 1177 The class RSVPAction contains policies to be applied to RSVP 1178 signalling packets, i.e., PATH messages and RESV messages, satisfying 1179 the conditions specified in the policy conditions. In this draft of 1180 the schema we allow for simple forms of policy based control, where 1181 administrative restrictions may be placed on the amount of resources 1182 that a single RSVP flow, or group of flows, may consume. We also 1183 allow for an RSVP reservation to be supported through a mapping into 1184 a DiffServ service category. As RSVP policy evolves to support the 1185 signalling of richer classes of policy information such as user 1186 ids, we may extend schema to provide for restrictions based on this 1187 information as well. 1189 Currently, there are two kinds of restrictions that we may place on 1190 resource usage by RSVP flows -- individual restrictions and group 1191 restrictions. 1193 NAME RSVPAction 1194 TYPE Structural 1195 DERIVED FROM PolicyAction 1196 AUXILIARY CLASSES NONE 1197 MUST CommonName 1198 RSVPFlowServiceType, 1199 RSVPPermission 1200 MAY RSVPActionName 1201 RSVPMaxRatePerFlow, 1202 RSVPMaxTokenBucketPerFlow, 1203 RSVPMinDelay, 1204 RSVPMaxFlowDuration, 1205 RSVPResourceGroupRef, 1206 DiffServActionRef 1208 The syntax and semantics of the attributes of an `RSVPAction' entry 1209 are described below. 1211 NAME RSVPFlowServiceType 1212 DESC IntServ service type that a flow can request 1213 EQUALITY caseExactIA5Match 1214 SYNTAX IA5String 1215 FORMAT: String with allowed values 1216 ControlledLoad 1217 GuaranteedService 1218 MULTI-VALUED 1220 Name RSVPPermission 1221 DESC Allow/Dissallow RSVP flows 1222 EQUALITY caseExactIA5Match 1223 SYNTAX IA5String 1224 FORMAT: String with allowed values 1225 Accept 1226 Deny 1227 SEMANTICS Accept or deny RSVP sessions of the specified Service Type(s). 1228 The remaining attributes make sense only in the case of `Accept' 1229 SINGLE-VALUED 1231 NAME RSVPActionName 1232 DESC The user friendly name of this entry. 1233 EQUALITY caseExactIA5Match 1234 SYNTAX IA5String 1235 SINGLE-VALUED 1236 DEFAULT No Name 1238 NAME RSVPMaxRatePerFlow 1239 DESC The maximum token rate for any individual flow in kilobits per second 1240 EQUALITY integerMatch 1241 SYNTAX INTEGER 1242 SINGLE-VALUED 1243 SEMANTICS Reservation requests for higher per-flow bandwidth are denied. 1244 DEFAULT No limit 1246 NAME RSVPMaxPeakRatePerFlow 1247 DESC The maximum peak rate for any individual flow in kilobits per second 1248 EQUALITY integerMatch 1249 SYNTAX INTEGER 1250 SINGLE-VALUED 1251 SEMANTICS Reservation requests for higher per-flow peak rate are denied. 1252 DEFAULT Assigned the same value as RSVPMaxRatePerFlow. 1254 NAME RSVPMaxTokenBucketPerFlow 1255 DESC The maximum token bucket size for any individual flow in kilobits 1256 EQUALITY integerMatch 1257 SYNTAX INTEGER 1258 SINGLE-VALUED 1259 SEMANTICS: Reservation requests for higher per-flow token bucket size 1260 are denied. 1261 DEFAULT Implementation Specific. 1263 NAME RSVPMinDelay 1264 DESC The minimum delay value an individual flow may request in millisec 1265 EQUALITY integerMatch 1266 SYNTAX INTEGER 1267 SINGLE-VALUED 1268 DEFAULT No limit 1270 NAME RSVPMaxFlowDuration 1271 DESC Maximum time (in seconds) an RSVP flow matching the profile may last 1272 SYNTAX INTEGER 1273 EQUALITY integerMatch 1274 SINGLE-VALUED 1275 DEFAULT No limit 1277 NAME RSVPUserAuthPolicy 1278 DESC Manner of authentication to be performed to authenticate user 1279 EQUALITY caseExactIA5Match 1280 SYNTAX IA5String 1281 SINGLE-VALUED 1282 FORMAT: String, currently defined values are 1283 Plain (Plain text password) 1284 Kerberos (Kerberos ticket authentication) 1285 Public-Key (Public Key authentication) 1286 None (for no authentication) 1287 Default None 1289 All the policy attributes hitherto described for RSVPAction refer 1290 to an individual flow for which a reservation is sought to be made. 1291 Often an adminstrator might wish to place group restrictions on 1292 flows described as an aggregation of multiple policy condition 1293 objects. For instance, the administrator might wish to restrict the 1294 total number of active RSVP reservations. To facilitate such group 1295 restrictions, we allow the reference attribute RSVPResourceGroupRef. 1296 The reason for making this a reference is not difficult to see. 1297 The group that the adminstrator wishes to control may not be 1298 describable through a single profile, or a single profile might 1299 belong to different groups in terms of resource control. In such 1300 cases, multiple policy rules ``point'' to the same group. Note that 1301 policies described through group rules require that the enforcement 1302 entity maintain some state; in the example suggested above, the 1303 enforcement entity would have to track the number of active flows in 1304 order to enforce the policy. 1306 NAME RSVPResourceGroupRef 1307 DESC Absolute distinguished name(s) of LDAP entry, from the objectclass 1308 RSVPResourceGroup, which specifies constraints on a group of 1309 RSVP flows. 1310 EQUALITY distinguishedNameMatch 1311 MULTI-VALUED 1312 SYNTAX DN 1313 DEFAULT No Resource Group 1315 The next attribute allows the enforcement entity to map RSVP flows 1316 onto DiffServ resource groups. 1318 NAME DiffServActionRef 1319 DESC Absolute distinguished name of an LDAP entry, from the objectclass 1320 DiffServAction, which specifies the class of service that the 1321 RSVP flow must be mapped into. 1322 EQUALITY distinguishedNameMatch 1323 SINGLE-VALUED 1324 SYNTAX DN 1325 DEFAULT No RSVP to DiffServ Translation 1327 7.2.1. The Class RSVPResourceGroup 1329 NAME RSVPResourceGroup 1330 TYPE Structural 1331 DERIVED FROM Top 1332 AUXILIARY CLASSES NONE 1333 MUST CommonName 1334 MAY RSVPMaxFlows 1335 RSVPMaxAggregateRate 1336 RSVPMaxAggregateTokenBucket 1337 RSVPResourceGroupName 1339 NAME RSVPResourceGroupName 1340 DESC The user friendly name of this entry. 1341 EQUALITY caseExactIA5Match 1342 SYNTAX IA5String 1343 SINGLE-VALUED 1344 DEFAULT No Name 1346 NAME RSVPMaxFlows 1347 DESC The maximum allowed number of reserved flows belonging to the 1348 group 1349 EQUALITY integerMatch 1350 SYNTAX INTEGER 1351 SINGLE-VALUED 1352 DEFAULT No limit 1354 NAME RSVPMaxAggregateRate 1355 DESC The aggregate maximum token rate for all flows in the group 1356 EQUALITY integerMatch 1357 SYNTAX INTEGER 1358 SINGLE-VALUED 1359 SEMANTICS: Reservation requests that result in a higher aggregate 1360 bandwidth reservation are denied. 1361 Default No limit 1363 NAME RSVPMaxAggregateTokenBucket 1364 DESC The maximum token bucket size for the aggregate traffic matching 1365 the profile in kilobits 1366 EQUALITY integerMatch 1367 SYNTAX INTEGER 1368 SINGLE-VALUED 1369 DEFAULT No limit 1371 7.3. The class TCPAction 1373 End hosts and firewalls often control the number and nature of active 1374 TCP connections. Each object of type TCPaction describes policies 1375 used to control TCP behaviour. 1377 The class description of TCPAction is as follows: 1379 NAME TCPAction 1380 TYPE Structural 1381 DERIVED FROM PolicyAction 1382 AUXILIARY CLASSES NONE 1383 MUST 1384 CommonName, 1385 TCPPermission 1386 MAY 1387 TCPFlag, 1388 MaxTCPSessions, 1389 MaxRatePerTCPSession 1391 NAME TCPPermission 1392 DESC Allow/drop data packets matching the profile 1393 EQUALITY caseExactIA5Match 1394 SYNTAX IA5String 1395 SINGLE-VALUED 1396 FORMAT The currently defined values for this attribute are: 1397 Accept 1398 Deny 1400 NAME TCPFlag 1401 DESC The types of TCP packets to which the policy action applies. 1402 EQUALITY caseExactIA5Match 1403 SYNTAX IA5String 1404 MULTI-VALUED 1405 FORMAT The following strings are recognized: 1406 ``SYN'' 1407 ``ACK'' 1408 ``FIN'' 1409 ``All'' 1410 DEFAULT ``All'' 1412 NAME TCPActionName 1413 DESC The user friendly name of this entry. 1414 EQUALITY caseExactIA5Match 1415 SYNTAX IA5String 1416 SINGLE-VALUED 1417 DEFAULT No name 1419 NAME MaxTCPSessions 1420 DESC The maximum number of simultaneously open TCP sessions. 1421 EQUALITY integerMatch 1422 SYNTAX integer 1423 SINGLE-VALUED 1424 DEFAULT No limit 1426 NAME MaxRatePerTCPSession 1427 DESC The maximum rate in kilobits/sec that is allowed. 1428 EQUALITY integerMatch 1429 SYNTAX integer 1430 SINGLE-VALUED 1431 DEFAULT No limit 1433 8. QoS Schema Usage Examples 1435 In this section we describe some usage scenarios for QoS using LDIF 1436 notation. 1438 8.1. DiffServ PHB 1440 The requirements are: 1442 - All web traffic originating from two server clusters S1 1443 (1.1.1.0 mask 255.255.255.0) and S2 (2.2.2.0 mask 255.255.255.0) 1444 traversing a router must be assigned a low delay, low loss 1445 service with a shared reservation of 40Mbps. 1447 - This traffic must be marked with the TOS bits set to 10100000. 1449 The following rules achieves the above objective 1451 dn: cn=S1-Web-Rule, o=XYZ, c=US 1452 Objectclass: Policy 1453 PolicyScope: DiffServ 1454 PolicyType: DiffServ 1455 PolicyConditionRef: cn=S1-Web-Condition,o=XYZ, c=US, 1456 PolicyActionRef: cn=DSGoldService, o=XYZ, c=US 1458 dn: cn=S2-Web-Rule, o=XYZ, c=US 1459 Objectclass: Policy 1460 PolicyScope: DiffServ 1461 PolicyType: DiffServ 1462 PolicyConditionRef: cn=S2-Web-Condition,o=XYZ, c=US, 1463 PolicyActionRef: cn=DSGoldService, o=XYZ, c=US 1465 The conditions and actions referred to in the above rules are: 1467 dn: cn=S1-Web-Condition, o=XYZ, c=US 1468 Objectclass: IPPolicyCondition 1469 SourceAddressRange: 1:1.1.0:24 1470 SourcePortRange: 8000:8080 1471 IPProtocolRange: 4 (TCP) 1473 dn: cn=S2-Web-Condition, o=XYZ, c=US 1474 Objectclass: IPPolicyCondition 1475 SourceAddressRange: 1:2.2.2.0:24 1476 SourcePortRange: 8000:8080 1477 IPProtocolRange: 4 (TCP) 1479 dn: cn=DSGoldService, o=XYZ, c=US 1480 Objectclass: DiffServAction 1481 DiffServPermission: Permit 1482 DiffServInProfileTransmittedTOSByte: 11111111:1010000 1483 DiffServResourceGroupRef: cn=S1-S2-WebDSResourceGroup, o=XYZ, c=US 1484 dn: cn=S1-S2-WebDSResourceGroup, o=XYZ, c=US 1485 ObjectClass: DiffServResourceGroup 1486 DiffServQueuePriority: 1 (implementation specific) 1487 DiffServLossParameter: 1:1000000 1488 DiffServDelayParameter: 1:1 1489 DiffServBandwidthShare: 40000 (kbps) 1490 DiffServAutoStart: AutoStart 1492 8.2. DiffServ Policing 1494 Now, consider a policy rule that allows for no more than an aggregate 1495 of 5000 kilobits/second of best effort traffic from sources in subnet 1496 S3 (range 139.24.2.12 to 139.24.2.255.) 1498 dn: cn=S3-Policing-Rule, o=XYZ, c=US 1499 Objectclass: Policy 1500 PolicyScope: DiffServ 1501 PolicyType: DiffServ 1502 PolicyConditionRef: cn=S3-Condition,o=XYZ, c=US, 1503 PolicyActionRef: cn=S3-DS-Action, o=XYZ, c=US 1505 dn: cn=S3-Condition,o=XYZ, c=US, 1506 Objectclass: PolicyCondition 1507 SourceAddressRange: 2:139.24.2.12:139.24.2.255 1509 dn: cn=S3-DS-Action, o=XYZ, c=US 1510 Objectclass: PolicyAction 1511 DiffServInProfileRate: 5000 1512 DiffServInProfileTokenBucket: 1024 1513 DiffServResourceGroupRef: cn=BestEffortPolicing, o=XYZ, c=US 1515 dn: cn=BestEffortPolicing, o=XYZ, c=US 1516 DiffServQueuePriority: 1 1517 DiffServExcessTrafficTreatment: drop 1518 DiffServAutoStart: NoAutoStart 1520 Here, we have allocated a nominal token bucket to take care of the 1521 maximum packet size. 1523 8.3. Forbidding RSVP Sessions 1525 Suppose that non-RSVP datatraffic from a subnet S1 is to be denied 1526 access to the network during the working day (9 am to 5 pm). We have 1527 the following entry to express this policy. 1529 dn: cn=S1-RSVP-Rule, o=XYZ, c=US 1530 Objectclass: Policy 1531 PolicyScope: RSVP 1532 PolicyType: RSVP 1533 PolicyConditionRef: cn=S1-RSVP-Condition,o=XYZ, c=US, 1534 PolicyActionRef: cn=S1-RSVP-Action, o=XYZ, c=US 1536 dn: cn=S1-RSVP-Condition,o=XYZ, c=US 1537 Objectclass: IPPolicyCondition 1538 SourceAddressRange: 1:1.1.0:4 1539 PolicyValidityPeriodRef: cn=workinghrs, o=XYZ, c=US 1541 dn: cn=workinghrs, o=XYZ, c=US 1542 Objectclass: PolicyValidityPeriod 1543 PolicyValidityTimeOfDayRange: 090000:170000 1545 dn: cn=S1-RSVP-Action, o=XYZ, c=US 1546 Objectclass: RSVPAction 1547 RSVPFlowServiceType: ControlledLoad 1548 RSVPFlowServiceType: GuaranteedService (multi-valued) 1549 RSVPPermission: Deny 1551 8.4. Controlling RSVP Reservations 1553 Consider a policy that specifies that during after hours (5 pm to 1554 9am) each RSVP controlled load reservation for outgoing traffic from 1555 subnet S1 have a token rate of no more than 1 Mbps, that there be 1556 no more than 100 such reservations active at any time, and that the 1557 aggregate reservable amount from that subnet total to no more than 10 1558 Mbps. 1560 dn: cn=S1-CL-nw-Rule, o=XYZ, c=US 1561 Objectclass: Policy 1562 PolicyScope: RSVP 1563 PolicyType: RSVP 1564 PolicyConditionRef: cn=S1-CL-nw-Condition,o=XYZ, c=US, 1565 PolicyActionRef: cn=S1-CL-nw-Action, o=XYZ, c=US 1567 dn: cn=S1-CL-Condition,o=XYZ, c=US 1568 Objectclass: IPPolicyCondition 1569 SourceAddressRange: 1:1.1.0:4 1570 PolicyValidityPeriodRef: cn=non-workinghrs, o=XYZ, c=US 1572 dn: cn=non-workinghrs, o=XYZ, c=US 1573 Objectclass: PolicyValidityPeriod 1574 PolicyValidityTimeOfDayRange: 170000: 090000 1575 dn: cn=S1-RSVP-Action, o=XYZ, c=US 1576 Objectclass: RSVPAction 1577 RSVPFlowServiceType: ControlledLoad 1578 RSVPPermission: Permit 1579 RSVPMaxRatePerFlow: 1000 1580 RSVPResourceGroupReference: cn=S1-RSVPGroup, o=XYZ, c=US 1582 dn: cn=S1-RSVPGroup, o=XYZ, c=US 1583 RSVPMaxFlows: 100 1584 RSVPMaxAggregateRate: 10000 1586 9. Security Considerations 1588 There are two potential security considerations, both of which may 1589 be addressed through standards compliant mechanisms. The first is 1590 the unauthorized access to read or change policy rules and related 1591 objects in the directory repository. The schema in this document 1592 SHOULD be used in conjunction with an LDAP access control mechanisms, 1593 see for instance [12]. The second exposure for violation of security 1594 lies in the communication between policy decision point and the 1595 directory repository. Such communication SHOULD be secured, with 1596 both ends mutually authenticated using SSL/TLS or IPSec. 1598 Acknowledgments 1600 Thanks to Partha Bhattacharya, Ed Ellesson, Tim Moore, Roch Guerin, 1601 Dimitrios Pendarakis and Ellen Stokes for useful discussion and 1602 suggestions in this problem space. In addition, we also thank 1603 numerous others who have read and commented on this draft in various 1604 forms. 1606 References 1608 [1] L. Wells and R. Bartky, Data Link Switching, Switch to Switch 1609 Protocol: AIW DLSW RIG, AIW Closed Pages, DLSW Standard 1.0, 1610 RFC1795, April 1995. 1612 [2] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, 1613 Resource ReSerVation Protocol (RSVP) Version 1 Functional 1614 Specification. RFC2205, Sept. 1997. 1616 [3] S. Herzog, A. Sastry, R. Rajan, R. Cohen, J. Boyle, and 1617 D. Durham, The COPS (Common Open Policy Service) Protocol 1618 Internet-Draft, draft-ietf-rap-cops-00.txt, Jan. 1998. 1620 [4] W. Yeong, T. Howes and S. Kille, Lightweight Directory Access 1621 Protocol, RFC1777, Mar. 1995. 1623 [5] R. Droms, Dynamic Host Configuration Protocol, RFC1541, Oct. 1624 1993. 1626 [6] K. Nichols and S. Blake, Differentiated Services 1627 Operational Model and Definitions, Internet-Draft, 1628 draft-nichols-dsopdef-00.txt, Feb. 1998. 1630 [7] M. Wahl, A. Coulbeck, T. Howes and S. Kille, Lightweight 1631 Directory Access Protocol (v3): Attribute Syntax Definitions 1632 Internet Draft draft-ietf-asid-ldapv3-attributes-07.txt, August 1633 1997. 1635 [8] R. Yavatkar, R. Guerin and D. Pendarakis, A Framework 1636 for Policy-based Admission Control Internet Draft, 1637 draft-ietf-rap-framework-00.txt, Nov. 1997. 1639 [9] S. Judd and J. Strassner, Directory Enabled Networks - 1640 Information Model and Base Schema - Draft v3.0c5 DEN 1641 Specifications, Sep. 1998. 1643 [10] P. Bhattacharya et. al., An LDAP Schema for Configuration and 1644 Administration of IPSec-based Virtual Private Networks, Internet 1645 Draft, draft-ietf-ipsec-policy-ldapschema-00.txt, Oct. 1998. 1647 [11] Desktop Management Task Force, Common Information Model (CIM) 1648 Specification, Version 2.0, Mar. 1998. 1650 [12] E. Stokes, D. Byrne, B. Blakeley and P. Behera, Access Control 1651 Requirements for LDAP, Internet Draft, Sep. 1998. 1653 [13] J. Strassner and E. Ellesson, Terminology for describing network 1654 policy and services Internet draft, draft-strassner-policy-terms-00.txt, 1655 Aug. 1998.