Internet Engineering Task Force Authors: INTERNET DRAFT R. Rajan/S. Kamat/J. C. Martin AT&T/IBM/Sun Microsystems M. See/ R. Chaudhury IBM/Xylan/ Telstra D. Verma/ G. Powers/ R. Yavatkar IBM/ Packeteer/ Intel 5/ April/1999 Policy Action Classes for Differentiated Services and Integrated Services draft-rajan-policy-qosschema-01.txt Status of Memo This document is an Internet-Draft and is in full conformance with all provisions of Section 10 of RFC2026 except for the right to produce derivative works. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as ``work in progress.'' The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This draft is in accordance with the policy information model presented in draft-ietf-policy-core-schema-02.txt, and elaborates on the action class for specifying quality of service (QoS) related policies. This draft replaces draft-rajan-policy-qosschema-00.txt by modeling networking QoS policy actions as subclass of policyAction. Discussion of this draft will be carried on the policy mailing list (policy@raleigh.ibm.com). Suggestions for improvement may also be sent to rajan@research.att.com. rajan, kamat, martin, see Expires 5/ October/1999 [Page i] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (1999). All Rights Reserved. Abstract This document describes the structure of a directory schema to enable and support administration of QoS policies in networks through regulation or configuration of nodes that support Differentiated Services and/or Integrated Services with RSVP signaling. This draft is consistent with the core schema described in draft-ietf-policy-core-schema-02.txt and must be used in conjunction with draft-ietf-rajan-policy-conditions-00.txt for definition of complete QoS policies. 1. Purpose and Overview As protocol aspects of providing quality of service in IP networks begin to get standardized, there is a need for corresponding standards towards enabling policy based administration of these protocols. Supporting QoS in a network consumes network resources and policy based administration seeks to regulate such resource usage to ensure that it is consistent with the network service provider's objectives or Service Level Agreements. The contents or nature of the high level objectives or SLAs are clearly not within IETF scope. However, there is a need to standardize lower level schema definitions that facilitate the administration of QoS protocols to ensure interoperability among network devices from multiple vendors. Currently, there are two sets of standards for providing QoS in IP networks. Integrated services with RSVP [8] signaling approach allows providing per-flow QoS assurances with dynamic resource reservation. A flow is defined by the 5-tuple (source address, destination address, protocol, source port, destination port). In this context, there is a need to provide policy control of individual flows, and to regulate their ability to reserve network resources. (See [9] for a discussion of policy based admission control framework and sample policies). Differentiated services [4], on the other hand, are aimed at traffic aggregates that are identified by the DS code point (part of TOS field) in IP headers of packets. This approach primarily relies on administrative control of bandwidth, delay or dropping preferences through simple policies and configuration rather than per-flow signaling protocols to communicate rajan, kamat, martin, see Expires 5/ October/1999 [Page ii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 the service level information to network elements [3]. For such services we wish to enable flexible definition of class-based packet handling behaviors and class-based policy control. (See [7] for a discussion of DiffServ framework and sample behavior/service descriptions). In either of these environments, network administrators need the ability to specify different classes of packets and appropriate bounds on the usage of network resources by packets from these classes. For example, with the signaled QoS approach of IntServ with RSVP, a policy may specify an upper limit on the total number of active controlled load reservations from receivers in a particular subnet or the size of individual controlled load or guaranteed service reservations in terms of the request parameters such as token buket rates, delay, etc. In the DiffServ scenario, a policy may specify that an ingress router classify packets from a specific set of applications as requiring DiffServ Expedited Forwarding (EF) [6] treatment, and specify the token bucket parameters for conditioning (policing and shaping) the traffic. In order to provide the desired level of service through consistent per hop behaviours at all nodes for this traffic, the DiffServ policy may also specify the resource allocation information at all network nodes to ensure that the aggregate EF traffic has the well defined minimum departure rate at Similarly, for the Assured Forwarding (AF) [5] class, policies for ingress routers may specify that packets from a certain set of sources be classified into a particular AF class, and further, assign different drop precedence values to packets based on additional criteria. Furthermore, for ensuring the desired level of service, the DiffServ policy may specify traffic conditioning actions at the ingress to ensure that the aggregate traffic belonging to the two lowest drop precedence values in each AF class is within specified limits and appropriate levels of bandwidth and buffer resoures are allocated for the class at all nodes. 1.1. Objectives and Scope [1] defines five very general classes for defining policies: policyGroup, policyRule, policyCondition, policyTimePeriodCondition, and policyAction. Policy solutions for specific areas, such as QoS and security are expected to use some of these classes directly while creating their own subclasses derived from policyCondition and policyAction in order to represent their own application-specific needs. A subclass of policyCondition to facilitate definition of packet classifiers applicable for both QoS and security policies is proposed in [2]. This draft defines subclasses of policyAction for QoS related policies and is consistent with the above proposals. rajan, kamat, martin, see Expires 5/ October/1999 [Page iii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 This document aims to support QoS policies for differentiated and integrated services networks that fall within the following three broad scenarios: - Integrated services secured through the use of RSVP signaling, within or across domains. The use of policy in such an environment allows enterprises to be able to police QoS requests on a per-flow, per-user or per-application basis. Directory schema are meant to be used in conjunction with the use of the policy elements in RSVP signaling messages, to enable routers to identify users and applications to which policy must be applied. - Differentiated services secured through provisioning within a domain, and, in an inter-domain scenario, bilateral agreements across peer network boundaries. In such cases, policies are used to map across the two domain specific semantics, and enforce access control restrictions, such as ensuring that the amount of in-profile traffic is within the specified contractual limits. More specifically, policies for DiffServ facilitate specification of the following: 1. packet classification filters to be installed into DS-compliant nodes allowing wide granularity for edge nodes and simple DSCP based aggregate traffic filters for DS interior nodes; 2. appropriate traffic conditioning actions to be performed at different nodes, specifically allowing for marking, metering, policing, shaping and dropping; 3. bandwidth and buffer resources to be allocated at DS-compliant nodes for different traffic aggregates identified by DS code points. - Integrated services secured within a domain, being mapped onto differentiated services across domains. In such cases, policies are needed at the domain boundary to translate between integrated and differentiated service semantics, to enforce traffic monitoring and to provide access control to network resources. Two important scenarios, not explicitly supported by the schema in this draft, but which may be covered by extensions to it are: - RSVP aggregation, i.e., the mapping of several RSVP flows into pre-configured RSVP tunnels, - Support of differentiated services using RSVP tunnels. rajan, kamat, martin, see Expires 5/ October/1999 [Page iv] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 We have the following objectives in defining this schema. 1. We want to cover a broad range of PEP clients that enforce QoS policies. These include: 1) an edge device that marks/drops/buffers/schedules certain packets to enforce a service differentiation policy, 2) an RSVP capable router that accepts/denies resource reservation requests based on allowed policies, and 3) hosts capable of packet marking and traffic conditioning. We would like the schema definition to be generic enough to support a wide range of resource control environments including the clients mentioned above. 2. We want to describe QoS actions in terms of observable or measurable behaviors rather than implementation specific configuration parameters. We believe that adminstrators specifying QoS policies in a heterogeneous multi-vendor network would prefer such descriptive semantics instead of detailed prescription of configuration parameters for specific scheduling or buffer management mechanisms used in network nodes. We assume that translation of QoS action directives to implementation specific actions will be carried out in the policy clients (within PDP/PEP/proxies). 1.2. Class Hierarchy The new classes and subclasses added to support QoS policy actions are depicted in the class hierarchy below: Top | | |------- policyCondition | | | networkingPolicyCondition | |------- policyAction | | | |--- RSVPAction | |--- diffServAction | |------- diffServResourceGroup | |------- RSVPResourceGroup rajan, kamat, martin, see Expires 5/ October/1999 [Page v] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 2. The Subclass diffServAction The class policyRule specifies a sequence of actions to be employed on a sub-stream of packets identified through a simple or complex set of conditions. Assuming that a packet substream has been identified (for details, see drafts [1] and [2]), the diffServAction class describes a component per-hop behaviour (PHB) in force at a network device. The diffServAction class does not seek to describe in detail resource reservations, packet treatment and configuration of every possible network device. Instead, it provides a high-level description of QoS services through a simple model that uses the following three descriptors -- traffic profile descriptors, packet marking descriptors and resource group descriptors. Of these, traffic profile descriptors and packet marking descriptors constitute attributes of diffServAction itself, while resource group descriptors are used through reference to another class diffServResourceGroup. The traffic profile descriptor is used to describe precisely, the portion of the packets of the identified sub-stream that are to be regarded as in-profile, with the understanding that the remaining packets are to be regarded as out-of-profile (or excess traffic). To this end we employ a leaky bucket model with three attributes -- a mean rate, a peak rate and a bucket size. Of course, the sorting of packets into in-profile and out-of-profile packets is possible only under the assumption that a policing device is present at the policy enforcement point; otherwise the attributes may be omitted or will be ignored (i.e., all packets will be regarded as in-profile). The packet marking descriptor provides an edge device with the ability to mark the DS byte for enabling simpler QoS classification at downstream network devices. We allow for differential marking of in and out of profile traffic (which makes sense if policing is present); as well as for the enforcement point to mark or remark the DS code point portion of the DS byte in the packet header. The latter is facilitated by allowing masking certain bits of the DS byte while modifying others. The resource group descriptor describes the treatment expected by packets within a common service group (identified by the forwarding class). The descriptor does NOT aim to describe how the service is to be provided, i.e., scheduling, buffer management, and other resource control details cannot be dictated by policy. The resource group descriptor instead encapsulates the (qualitative/quantitative) nature of the service to be accorded to identified packets. There are two aspects of such a description: (a) The treatment of in-profile traffic: The principal service descriptors are rate, delay and loss. These may be defined deterministically, stochastically or qualitiatively. For instance, rajan, kamat, martin, see Expires 5/ October/1999 [Page vi] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 a rate may be defined deterministically through the transmission of a certain number of bits over time period, stochastically through an on-off Markov process, or qualititatively as Class 1 traffic. We allow for deterministic and qualitative descriptions; stochastic descriptors may be introduced as future extension. (b) Treatment of out-of-profile traffic: Excess traffic may be tolerated, reshaped, provided a different class of service or dropped. It is important to note that trafficProfileDescriptor and resourceGroupDescriptor objects refer to states created in the network device. To understand this better, consider two policy rules, as follows. Rule1: If PolicyCondition1 then PolicyDSAction1 Rule2: If PolicyCondition2 then PolicyDSAction1 PolicyDSAction1: TrafficProfileDescriptor1 PacketMarkingDescriptor1 ResourceGroupDescriptor1 Now, all packets described either by PolicyCondition1 or by PolicyCondition2 will be policed together, and share the same rate resource reservations. This is different from the case where we have Rule1: If PolicyCondition1 then PolicyDSAction1 Rule2: If PolicyCondition2 then PolicyDSAction2 PolicyDSAction1: TrafficProfileDescriptor1 PacketMarkingDescriptor1 ResourceGroupDescriptor1 PolicyDSAction2: TrafficProfileDescriptor2 PacketMarkingDescriptor2 ResourceGroupDescriptor2 Even if the two traffic profile descriptors were numerically identical, the two streams will not be policed together by the same policer -- they will be policed by identical policers. Similarly, they will not share the same buffer or bandwidth resources. In fact, the resource requirements for the second example will be twice those of the first (ignoring multiplexing gains). The class description of diffServAction is as follows: NAME diffServAction rajan, kamat, martin, see Expires 5/ October/1999 [Page vii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 TYPE Structural DERIVED FROM policyAction AUXILIARY CLASSES NONE MUST CommonName diffServPermission MAY diffServInProfileRate, diffServInProfilePeakRate, diffServInProfileTokenBucket, diffServInProfileTransmittedTOSByte, diffServOutProfileTransmittedTOSByte, diffServResourceGroupRef, diffServActionName The first three MAY attributes describe the traffic profile, the next two specify the marking, and next is a reference to the resource group. The following set of attributes are currently defined for the DiffServ policy clients, namely hosts, edge devices, and routers that do traffic conditioning (packet marking, dropping, shaping, etc). NAME diffServPermission DESC Allow/drop data packets SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT The currently defined values for this attribute are: Accept Deny With the permission attribute set to ``Accept'', and no other attribute present, the packets matching the PolicyCondition are given the ``default'' service. NAME diffServActionName DESC The user friendly name of this entry. SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED DEFAULT No name NAME diffServInProfileRate DESC Specifies the token rate for the in-profile traffic descriptor in kbps SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED rajan, kamat, martin, see Expires 5/ October/1999 [Page viii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 SEMANTICS All packets in the behavior aggregate are measured against a leaky bucket with this token rate. Traffic that passes the leaky bucket check is considered in-profile. DEFAULT All packets considered in-profile, i.e., infinity NAME diffServInProfilePeakRate DESC Specifies the peak rate for the in-profile traffic descriptor in kbps SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED SEMANTICS All packets in the behaviour aggregate are measured against a leaky bucket with this peak rate. DEFAULT Same value as diffServInProfileRate NAME diffServInProfileTokenBucket DESC Specifies the token bucket size for in-profile traffic descriptor in kilobits SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED SEMANTICS All packets in the behaviour aggregate are measured against a leaky bucket with this token bucket size. DEFAULT Defaults to the maximum IP packet size. NAME diffServInProfileTransmittedTOSByte DESC Specifies the outgoing TOS byte for in profile packet marking descriptor SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT String(s) of the form xxxxxxxx:xxxxxxxx, where each of the `x's is either 0 or 1. SINGLE-VALUED SEMANTICS Each of the two substrings is treated as specifying an 8-bit field. The left substring is termed Mask and the right substring Modify. 0's in the Mask specify the bit locations in the TOS byte that must not be changed and 1's specify those that must be changed to match the corresponding ones in the Modify field. The operation involved is: newTOSByte = (Mask' & oldTOSbyte) | (Mask & Modify), where Mask' is the bitwise complement of Mask and '&' and '|' denote the bit-wise AND and OR operations respectively. EXAMPLE Consider a policy rule that specifies 11100000:11001010 as the value for this attribute. The Mask of 11100000 means that when this rule is applied, the 5 least significant bits in the TOS byte must be left unchanged but the 3 most significant bits must be changed to make them identical to rajan, kamat, martin, see Expires 5/ October/1999 [Page ix] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 the corresponding ones in the Modify field. Thus, if this rule were to be applicable to a packet whose TOS byte is 10101010, then the TOS byte will be changed to 11001010 before transmission. DEFAULT Don't modify any bit, i.e., Mask 00000000 Modify 00000000 NAME diffServOutProfileTransmittedTOSByte DESC Specifies the outgoing TOS byte for out-of-profile packet marking descriptor SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT same as `DiffServInProfileTransmittedTOSByte' attribute SINGLE-VALUED SEMANTICS same as `diffServInProfileTransmittedTOSByte' attribute DEFAULT same as `diffServInProfileTransmittedTOSByte' attribute NAME diffServResourceGroupRef DESC Absolute distinguished name of LDAP entry, from the objectclass diffServResourceGroup, that identifies the service category and resource group descriptors that apply to the traffic. SYNTAX DN EQUALITY distinguishedNameMatch SINGLE-VALUED DEFAULT Best Effort Service 2.0.1. The class diffServResourceGroup Objects of this class fully specify the treatment accorded to in-profile and out-of-profile traffic, in terms of their access to QoS resources. The class description of diffServResourceGroup is as follows: NAME diffServResourceGroup TYPE Structural DERIVED FROM Top AUXILIARY CLASSES NONE MUST CommonName MAY diffServLossParameter, diffServDelayParameter, diffServBandwidthShare, diffServExcessTrafficTreatment diffServAutoStart rajan, kamat, martin, see Expires 5/ October/1999 [Page x] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 diffServResourceGroupName The attributes are described below. NAME diffServResourceGroupName DESC The user friendly name of this entry. SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED DEFAULT No name NAME diffServLossParameter DESC Packet loss paremeters for in-profile traffic for this class of service SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT Colon seperate numeric strings, A:B, where at most A packets may be dropped for every B packets received. SINGLE-VALUED EXAMPLE 2:1000 implies a maximum loss rate of .002. DEFAULT Best Effort NAME diffServDelayParameters DESC Packet delay paremeters for out-of-profile traffic for this class of service SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT Colon seperated integer:string pair. Currently defined 1: where the absolute delay is expressed in msec 2: where the relative delay is expressed as a priority (1 means best effort) SINGLE-VALUED DEFAULT Best Effort NAME diffServBandwidthShare DESC Bandwidth share for this class of service SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT Colon seperated integer:string pair. Currently defined 1: where the absolute bw is expressed in kilobits/sec 2: where the bandwidth percent is a number between 0 and 100 expressing the share of the bandwidth allowed to this class SINGLE-VALUED SEMANTICS The intervals over which bandwidths are delivered are PEP-specific. Percentages are provided for instances where the policy rule is unaware of the link capacity at the enforcement entity. Percentages for all rajan, kamat, martin, see Expires 5/ October/1999 [Page xi] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 classes must add to less than 100. EXAMPLES 1:200 -- This class is allocated a 200kbps 2:40 -- This class is allocated 40% of the link bandwidth DEFAULT 0, i.e., No reserved share NAME diffServExcessTrafficTreatment DESC Describes how excess traffic is to be treated. SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT The following values are defined `Drop' -- Allow no excess traffic `Best Effort' -- Treat excess traffic as best effort `Reshape'--Reshape excess traffic SINGLE-VALUED SEMANTICS This field specifes the actions that must be taken if an incoming packet cannot be placed within the reserved buffer allocation of the stream. DEFAULT Best Effort NAME diffServAutoStart DESC Indicates if the resource allocation for this service should be done at time of enforcement entity startup, or should be packet driven. This attribute is for guidance only, and its interpretation is implementation specific. SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT The following strings are defined `AutoStart' --- Allocate resources at device startup `NoAutoStart' --- Allocate resources when packets for flow are seen. SINGLE-VALUED DEFAULT Autostart 2.1. The Class RSVPAction The class RSVPAction contains policies to be applied to RSVP signalling packets, i.e., PATH messages and RESV messages, satisfying the conditions specified in the policy conditions. In this draft of the schema we allow for simple forms of policy based control, where administrative restrictions may be placed on the amount of resources that a single RSVP flow, or group of flows, may consume. We also allow for an RSVP reservation to be supported through a mapping into a DiffServ service category. Support for additional rules based on richer classes of policy information such as user ids for signalled QoS will be supported in future extensions to this schema. rajan, kamat, martin, see Expires 5/ October/1999 [Page xii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 Currently, there are two kinds of restrictions that we may place on resource usage by RSVP flows -- individual restrictions and group restrictions. The class description of RSVPAction is as follows: NAME RSVPAction TYPE Structural DERIVED FROM policyAction AUXILIARY CLASSES NONE MUST CommonName RSVPFlowServiceType, RSVPPermission MAY RSVPActionName RSVPMaxRatePerFlow, RSVPMaxTokenBucketPerFlow, RSVPMinDelay, RSVPMaxFlowDuration, RSVPResourceGroupRef, diffServActionRef The syntax and semantics of the attributes of an `RSVPAction' entry are described below. NAME RSVPFlowServiceType DESC IntServ service type that a flow can request SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT: String with allowed values ControlledLoad GuaranteedService MULTI-VALUED Name RSVPPermission DESC Allow/Dissallow RSVP flows SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT: String with allowed values Accept Deny SEMANTICS Accept or deny RSVP sessions of the specified Service Type(s). The remaining attributes make sense only in the case of `Accept' SINGLE-VALUED NAME RSVPActionName DESC The user friendly name of this entry. rajan, kamat, martin, see Expires 5/ October/1999 [Page xiii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED DEFAULT No Name NAME RSVPMaxRatePerFlow DESC The maximum token rate for any individual flow in kilobits per second SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED SEMANTICS Reservation requests for higher per-flow bandwidth are denied. DEFAULT No limit NAME RSVPMaxPeakRatePerFlow DESC The maximum peak rate for any individual flow in kilobits per second SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED SEMANTICS Reservation requests for higher per-flow peak rate are denied. DEFAULT Assigned the same value as RSVPMaxRatePerFlow. NAME RSVPMaxTokenBucketPerFlow DESC The maximum token bucket size for any individual flow in kilobits SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED SEMANTICS: Reservation requests for higher per-flow token bucket size are denied. DEFAULT Implementation Specific. NAME RSVPMinDelay DESC The minimum delay value an individual flow may request in millisec SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED DEFAULT No limit NAME RSVPMaxFlowDuration DESC Maximum time (in seconds) an RSVP flow matching the profile may last SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED DEFAULT No limit NAME RSVPUserAuthPolicy DESC Manner of authentication to be performed to authenticate user SYNTAX IA5String rajan, kamat, martin, see Expires 5/ October/1999 [Page xiv] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT: String, currently defined values are Plain (Plain text password) Kerberos (Kerberos ticket authentication) Public-Key (Public Key authentication) None (for no authentication) DEFAULT None All the policy attributes hitherto described for RSVPAction refer to an individual flow for which a reservation is sought to be made. Often an adminstrator might wish to place group restrictions on flows described as an aggregation of multiple policy condition objects. For instance, the administrator might wish to restrict the total number of active RSVP reservations. To facilitate such group restrictions, we allow the reference attribute RSVPResourceGroupRef. The reason for making this a reference is not difficult to see. The group that the adminstrator wishes to control may not be describable through a single profile, or a single profile might belong to different groups in terms of resource control. In such cases, multiple policy rules ``point'' to the same group. Note that policies described through group rules require that the enforcement entity maintain some state; in the example suggested above, the enforcement entity would have to track the number of active flows in order to enforce the policy. NAME RSVPResourceGroupRef DESC Absolute distinguished name(s) of LDAP entry, from the objectclass RSVPResourceGroup, which specifies constraints on a group of RSVP flows. SYNTAX DN EQUALITY distinguishedNameMatch MULTI-VALUED DEFAULT No Resource Group The next attribute allows the enforcement entity to map RSVP flows onto DiffServ resource groups. NAME DiffServActionRef DESC Absolute distinguished name of an LDAP entry, from the objectclass DiffServAction, which specifies the class of service that the RSVP flow must be mapped into. EQUALITY distinguishedNameMatch SINGLE-VALUED SYNTAX DN DEFAULT No RSVP to DiffServ Translation rajan, kamat, martin, see Expires 5/ October/1999 [Page xv] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 2.2. The Class RSVPResourceGroup The class description of RSVPResourceGroup is as follows: NAME RSVPResourceGroup TYPE Structural DERIVED FROM Top AUXILIARY CLASSES NONE MUST CommonName MAY RSVPMaxFlows RSVPMaxAggregateRate RSVPMaxAggregateTokenBucket RSVPResourceGroupName The syntax and semantics of individual attributes are described below. NAME RSVPResourceGroupName DESC The user friendly name of this entry. SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED DEFAULT No Name NAME RSVPMaxFlows DESC The maximum allowed number of reserved flows belonging to the group SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED DEFAULT No limit NAME RSVPMaxAggregateRate DESC The aggregate maximum token rate for all flows in the group SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED SEMANTICS Reservation requests that result in a higher aggregate bandwidth reservation are denied. Default No limit NAME RSVPMaxAggregateTokenBucket DESC The maximum token bucket size for the aggregate traffic matching the profile in kilobits SYNTAX INTEGER EQUALITY integerMatch rajan, kamat, martin, see Expires 5/ October/1999 [Page xvi] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 SINGLE-VALUED DEFAULT No limit 3. QoS Schema Usage Examples In this section we describe some usage scenarios for defining QoS policies for different contexts. We use LDIF notation. These examples broadly adhere to the core Policy schema as defined in [1], and to the policyCondition class as defined in [2]. However, for clarity of exposition we simplify certain attribute syntaxes (policyRuleConditionList, for instance). 3.1. DiffServ PHB The requirements are: - All web traffic originating from two server clusters S1 (1.1.1.0 mask 255.255.255.0) and S2 (2.2.2.0 mask 255.255.255.0) traversing a router must be assigned a low delay, low loss service with a shared reservation of 40Mbps. - This traffic must be marked with the TOS bits set to 10100000. The following rules achieve the above objective: dn: cn=S1-Web-Rule, o=XYZ, c=US Objectclass: policyRule policyRuleConditionList: cn=S1-Web-Condition,o=XYZ, c=US, policyRuleActionList: cn=DSGoldService, o=XYZ, c=US dn: cn=S2-Web-Rule, o=XYZ, c=US Objectclass: policyRule PolicyRuleConditionList: cn=S2-Web-Condition,o=XYZ, c=US, PolicyRuleActionList: cn=DSGoldService, o=XYZ, c=US The conditions and actions referred to in the above rules are: dn: cn=S1-Web-Condition, o=XYZ, c=US Objectclass: networkingPolicyCondition Objectclass: hostConditionAuxClass Objectclass: applicationConditionAuxClass sourceIPAddressRange: 1:1.1.0:24 SourcePortRange: 8000:8080 protocolNumber: 4 (TCP) rajan, kamat, martin, see Expires 5/ October/1999 [Page xvii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 dn: cn=S2-Web-Condition, o=XYZ, c=US objectclass: networkingPolicyCondition objectclass: hostConditionAuxClass objectclass: applicationConditionAuxClass sourceIPAddressRange: 1:2.2.2.0:24 sourcePortRange: 8000:8080 protocolNumber: 4 (TCP) dn: cn=DSGoldService, o=XYZ, c=US Objectclass: DiffServAction DiffServPermission: Permit DiffServInProfileTransmittedTOSByte: 11111111:1010000 DiffServResourceGroupRef: cn=S1-S2-WebDSResourceGroup, o=XYZ, c=US dn: cn=S1-S2-WebDSResourceGroup, o=XYZ, c=US ObjectClass: DiffServResourceGroup DiffServQueuePriority: 1 (implementation specific) DiffServLossParameter: 1:1000000 DiffServDelayParameter: 1:1 DiffServBandwidthShare: 40000 (kbps) DiffServAutoStart: AutoStart 3.2. DiffServ Policing Now, consider a policy rule that allows for no more than an aggregate of 5000 kilobits/second of best effort traffic from sources in subnet S3 (range 139.24.2.12 to 139.24.2.255). dn: cn=S3-Policing-Rule, o=XYZ, c=US objectclass: policyRule policyRuleConditionList: cn=S3-Condition,o=XYZ, c=US, policyRuleActionList: cn=S3-DS-Action, o=XYZ, c=US dn: cn=S3-Condition,o=XYZ, c=US, objectclass: networkingPolicyCondition objectclass: hostConditionAuxClass sourceIPAddressRange: 2:139.24.2.12:139.24.2.255 dn: cn=S3-DS-Action, o=XYZ, c=US Objectclass: PolicyAction DiffServInProfileRate: 5000 DiffServInProfileTokenBucket: 1024 DiffServResourceGroupRef: cn=BestEffortPolicing, o=XYZ, c=US dn: cn=BestEffortPolicing, o=XYZ, c=US DiffServQueuePriority: 1 rajan, kamat, martin, see Expires 5/ October/1999 [Page xviii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 DiffServExcessTrafficTreatment: drop DiffServAutoStart: NoAutoStart Here, we have allocated a nominal token bucket to take care of the maximum packet size. 3.3. Forbidding RSVP Sessions Suppose that RSVP traffic from a subnet S1 is to be denied access to the network during the working day (9 am to 5 pm). We have the following entry to express this policy. dn: cn=S1-RSVP-Rule, o=XYZ, c=US objectclass: Policy policyRuleConditionList: cn=S1-RSVP-Condition,o=XYZ, c=US, policyRuleActionList: cn=S1-RSVP-Action, o=XYZ, c=US policyRuleValidityPeriodList: cn=workinghrs, o=XYZ, c=US dn: cn=S1-RSVP-Condition,o=XYZ, c=US objectclass: networkingPolicyCondition objectclass: hostConditionAuxClass sourceIPAddressRange: 1:1.1.0:4 dn: cn=workinghrs, o=XYZ, c=US Objectclass: PolicyValidityPeriod PolicyValidityTimeOfDayRange: 090000:170000 dn: cn=S1-RSVP-Action, o=XYZ, c=US Objectclass: RSVPAction RSVPFlowServiceType: ControlledLoad RSVPFlowServiceType: GuaranteedService (multi-valued) RSVPPermission: Deny 3.4. Controlling RSVP Reservations Consider a policy that specifies that during after hours (5 pm to 9am) each RSVP controlled load reservation for outgoing traffic from subnet S1 have a token rate of no more than 1 Mbps, that there be no more than 100 such reservations active at any time, and that the aggregate reservable amount from that subnet total to no more than 10 Mbps. dn: cn=S1-CL-nw-Rule, o=XYZ, c=US objectclass: policyRule policyRuleConditionList: cn=S1-CL-nw-Condition,o=XYZ, c=US, policyRuleActionList: cn=S1-CL-nw-Action, o=XYZ, c=US rajan, kamat, martin, see Expires 5/ October/1999 [Page xix] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 PolicyValidityPeriodList: cn=non-workinghrs, o=XYZ, c=US dn: cn=S1-CL-Condition,o=XYZ, c=US objectclass: networkingPolicyCondition objectclass: hostConditionAuxClass sourceIPAddressRange: 1:1.1.0:4 dn: cn=non-workinghrs, o=XYZ, c=US Objectclass: PolicyValidityPeriod PolicyValidityTimeOfDayRange: 170000: 090000 dn: cn=S1-RSVP-Action, o=XYZ, c=US Objectclass: RSVPAction RSVPFlowServiceType: ControlledLoad RSVPPermission: Permit RSVPMaxRatePerFlow: 1000 RSVPResourceGroupReference: cn=S1-RSVPGroup, o=XYZ, c=US dn: cn=S1-RSVPGroup, o=XYZ, c=US RSVPMaxFlows: 100 RSVPMaxAggregateRate: 10000 4. Security Considerations There are two potential security considerations, both of which may be addressed through standards compliant mechanisms. The first is the unauthorized access to read or change policy rules and related objects in the directory repository. The schema in this document SHOULD be used in conjunction with an LDAP access control mechanisms, see for instance [15]. The second exposure for violation of security lies in the communication between policy decision point and the directory repository. Such communication SHOULD be secured, with both ends mutually authenticated using SSL/TLS or IPSec. Acknowledgments Thanks to Partha Bhattacharya, Tim Moore, Roch Guerin, Dimitrios Pendarakis and Ellen Stokes for useful discussion and suggestions in this problem space. In addition, we also thank numerous others who have read and commented on this draft in various forms. rajan, kamat, martin, see Expires 5/ October/1999 [Page xx] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 References [1] J. Strassner, E. Ellesson, and B. Moore (editor), Policy Framework Core Information Model, Internet Draft, draft-ietf-policy-core-schema-02.txt, Feb. 1999. [2] R. Rajan, S. Kamat, and P. Bhattacharya, Networking Policy Condition Information Model, Internet Draft, draft-ietf-policy-conditions-01.txt, Apr. 1999. [3] K. Nichols, S. Blake, F. Baker and D. Black, Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers, RFC2474, Dec. 1998. [4] S. Blake, D. Black, M. Carlson, E. Davies, Z. Wang, and W. Weiss, An Architecture for Differentiated Services, RFC2475, Dec. 1998. [5] J. Heinanen, F. Baker, W. Weiss, and J. Wroclawski, Assured Forwarding PHB Group Internet Draft, draft-ietf-diffserv-af-06.txt, Feb. 1999. [6] V. Jacobson, K. Nichols, and K. Poduri, An Expedited Forwarding PHB, Internet Draft, draft-ietf-diffserv-phb-ef-02.txt, Feb. 1999. [7] Y. Bernet, et al, A Framework for Differentiated Services, Internet Draft, draft-ietf-diffserv-framework-02.txt, Feb. 1999. [8] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. RFC2205, Sept. 1997. [9] R. Yavatkar, R. Guerin and D. Pendarakis, A Framework for Policy-based Admission Control Internet Draft, draft-ietf-rap-framework-01.txt, Nov. 1998. [10] S. Herzog, A. Sastry, R. Rajan, R. Cohen, J. Boyle, and D. Durham, The COPS (Common Open Policy Service) Protocol Internet-Draft, draft-ietf-rap-cops-06.txt, Feb. 1999. [11] W. Yeong, T. Howes and S. Kille, Lightweight Directory Access Protocol, RFC1777, Mar. 1995. [12] M. Wahl, A. Coulbeck, T. Howes and S. Kille, Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions Internet Draft draft-ietf-asid-ldapv3-attributes-07.txt, August 1997. rajan, kamat, martin, see Expires 5/ October/1999 [Page xxi] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 [13] S. Judd and J. Strassner, Directory Enabled Networks - Information Model and Base Schema - Draft v3.0c5 DEN Specifications, Sep. 1998. [14] Desktop Management Task Force, Common Information Model (CIM) Specification, Version 2.0, Mar. 1998. [15] E. Stokes, D. Byrne, B. Blakeley and P. Behera, Access Control Requirements for LDAP, Internet Draft, Sep. 1998. [16] R. Droms, Dynamic Host Configuration Protocol, RFC1541, Oct. 1993. AUTHORS' ADDRESS Raju Rajan AT&T Labs - Research 180 Park Avenue, P.O. Box 971 Florham Park, NJ 07932-0971 email: rajan@research.att.com Sanjay Kamat IBM Research 30 Saw Mill River Road Hawthorne, NY 10532 email: sanjay@watson.ibm.com Jean-Christophe Martin Solaris and Network Software Group Sun Microsystems France email:jean-christophe.martin@sun.com Michael See email: Michael.See@xylan.com Rajiv Chaudhury email: rchaudhu@telstra.com.au rajan, kamat, martin, see Expires 5/ October/1999 [Page xxii] Internet Draft draft-rajan-policy-qosschema-01.txt 5/ April/1999 Dinesh Verma IBM Research 30 Saw Mill River Road Hawthorne, NY 10532 email: dverma@watson.ibm.com George Powers email: george@packeteer.com Raj Yavatkar Intel Corporation, JF3-206 2111 NE 25th Avenue, Hillsboro, OR 97124 email: raj.yavatkar@intel.com Full Copyright Statement Copyright (C) The Internet Society (1997). All Rights Reserved. This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English. The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns. This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. rajan, kamat, martin, see Expires 5/ October/1999 [Page xxiii]