Internet Engineering Task Force Authors INTERNET DRAFT R. Rajan/J. C. Martin IBM/Sun Microsystems S. Kamat/M. See/ R. Chaudhury IBM/Xylan/ Telstra D. Verma/ G. Powers/ R. Yavatkar IBM/ Packeteer/ Intel 23/ October/1998 Schema for Differentiated Services and Integrated Services in Networks draft-rajan-policy-qosschema-00.txt Status of Memo This document is an Internet-Draft. 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.'' To learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.ietf.org (US East Coast), nic.nordu.net (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim). Abstract This document describes the structure of a directory schema to enable and support administration of differentiated services and/or integrated services within and among Internet domains, intranets, and extranets. This draft replaces draft-ellesson-sla-schema-00.txt. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page i]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 1. Overview Integrated services with RSVP [2] signaling approach seeks to provide 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 regulate their ability to reserve network resources. (See [8] for a discussion of policy based admission control framework and sample policies). Differentiated services[6], on the other hand, are aimed at traffic aggregates that may not correspond to fine grained flows. This approach may rely more on administrative control of bandwidth, delay or dropping preferences, rather than per-flow signaling protocols to communicate the service level information to network elements. For such services we wish to enable flexible definition of class-based packet handling behaviors and class-based policy control. (See [6] for a discussion of DiffServ framework and sample behavior/service descriptions). In either of these environments, network administrators need the ability to define and administer different types of services for customers. Administrative policies tend to change infrequently, and can be conveniently stored in a directory based repository which may be distributed across multiple physical servers, but is administered as a single entity by the network administrator. Furthermore, this information must be propagated to network elements such as hosts, proxies and routers, that actually implement the policies and preferences by classifying traffic to identify its level of service, and apportioning resources according to defined resource regulation policies. This document describes a common language for describing administrative policies for integrated services and differentiated services in terms of an LDAP schema. Currently, LDAP [4] is a widely deployed industry standard for accessing directory information, and hence LDAP based administration of these customer service level preferences and the associated resource regulation policies seems a natural approach. We envision that policies embodied as LDAP schema will be stored on directories and downloaded to devices such as hosts, routers, policy servers, proxies, etc., that implement the policies. The use of LDAP assures a standard, widely deployed and simple protocol for directory access. The details of the architecture within which this schema will be deployed, is presented in a seperate draft (citation TBDs). This architecture for network resource control involves a management tool, a policy repository, a policy decision point and a policy enforcement entity. The network administrator uses the management tool to rajan, martin, kamat, see Expires 23/ April/ 1999 [Page ii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 populate the policy repository with a number of policy rules that regulate access/use of network resources. These rules could specify for instance, the service category to be employed for a particular application, how much bandwidth is allocated to a particular flow or TOS category, the maximum number of flows to be supported between two subnets, etc. In any case, the administrator-specified rules are stored in the policy repository in a well understood format or schema. The decision entity downloads the policy rules. The enforcement entity is the host or router which encounters (data or signaling) packet flowing across the network. It queries the decision entity for specific actions that are to be applied in conditioning the packet stream. The next section describes the scope of the schema, following which we discuss policy rule matching and present the detailed schema. The draft concludes with a section on examples. For an explanation of terminology employed to describe network policy and services in this document, please refer to [13]. 1.1. Objectives and Scope This document aims to support QoS policies for differentiated and integrated services networks that fall within the following three 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. - 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: rajan, martin, kamat, see Expires 23/ April/ 1999 [Page iii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 - RSVP aggregation, i.e., the mapping of several RSVP flows into pre-configured RSVP tunnels, - Support of differentiated services using RSVP tunnels. We have the following objectives in defining this schema. 1. The directory provides a convenient repository of the resource regulation policies, which may be used by a wide variety of clients that actually enforce the resource regulation rules. As illustrated before, there are at least three such potential clients for the near term: 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. When viewed in the context of resource control policies, the associated schema can be considered to provide a ``language'' for defining these policies. From this perspective, we desire that the schema should facilitate definition of a wide range of policies varying in their complexity. Simple policies (the common case) should be easy to specify, and there should be sufficient hooks to define sophisticated policies within the schema. Using the language analogy, an administrator's ability to define sophisticated resource regulation policies should not be limited by the structure of the schema, although it may be limited by the available implementation of the policy enforcement environment. 3. The schema should facilitate simple addition and deletion of new rules, automated checks for rule ambiguities, and allow for diverse methods (varying in efficiency and ease of implementation) to be employed in the policy decision entity to search through rules. 2. Class Hierarchy In this section, we describe the inheritance hierarchy and the relationship between various classes. We define a structural LDAP object class called Policy as the container for policy rules. An object of this class will ``piece together'' several policy components relating to differentiated services, RSVP and IPSec based VPNs [10]. In this section we largely focus on the rajan, martin, kamat, see Expires 23/ April/ 1999 [Page iv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 PolicyRules object class itself and not on where it is placed in the organization's existing directory tree. However, the Policy class described here is best understaod within the Common Information Model [11] of the Directory Management Task Force or the directory structure proposed by the Directory Enabled Networks specification [9]. The class hierarchy in the schema is given below. Top |----Policy | |----PolicyCondition | | | |--IPPolicyCondition | |-----UserIDCondition | |----PolicyValidityPeriod | |----PolicyAction | |----RSVPAction | |----DiffServAction | |----TCPAction | |----ISAKMPAction | |----IPSecSecurityAction | |----DiffServResourceGroup |----RSVPResourceGroup |----IPSecProposal |----ISAKMPProposal |----IPSecTransform |----IPSecPrivateDiffieHellmanGroup | |----PolicyContainmentAuxClass The schema described above closely follows the policy class hierarchy described in the document ``Information Model and Base Schema'' version 3.0r5 released by the Directory Enabled Network AdHoc Group. The schema described in this document expands on the DEN specification but differs in a few significant details. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page v]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 3. Policy Rules The Policy object class is instantiated by LDAP entries, where each entry encodes a policy rule that specifies the resources and services that are allowed (or denied) to a stream of packets. An entry is composed of several attributes. Each attribute is of a certain type, and has one or more values. The two principal components of a policy rule are objects of the type PolicyCondition and and PolicyAction. These two objects describe a rule through the relation if <PolicyCondition> then <PolicyAction>. A PolicyCondition object is defined by the values of a collection of certain attributes that are typically used to determine when a policy rule applies. A typical condition is, for instance, a range of source addresses (or a source address and mask) to which the policy applies. An action is defined by a collection of attributes that detail permissions or additional behaviours that the policy enforcement entity should perform for the given condition. For instance, the value of attribute PolicyConditionRef could be the distinguished name of an object that places restrictions on the source address range of IP packets, while PolicyActionRef could be the distinguished name of a DiffServAction object that fully describes the treatment of a flow with respect to TOS marking and QoS requirements. Conditions and actions may each be of different types. For instance, a PolicyCondition object may place restrictions on, or otherwise refer to information contained in IP header fields such as source addresses, or to information contained inside signalling packets as with RSVP PATH or RESV messages, or may refer to information regarding the layer 2 protocol such as restrictions on MAC addresses. In this draft we take a simple, first cut approach to such issues, covering the most common policy cases, but allowing for future extensions to this draft or to policy standards. We allow the class PolicyCondition to be expanded through an auxillary class IPPolicyAuxCondition which allows for conditions based on IP header fields, or through the class UserIDPolicyAuxCondition which allows for conditions based on user IDs. Similarly, the class PolicyAction is subclassed into a number of protocol or service specific actions -- DiffServAction, RSVPAction, IPSecSecurityAction and IPSecISAKMPAction. Both the PolicyCondition class and the PolicyAction class may be easily extended in future. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page vi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 4. Ascertaining Applicability of Policy Rules Typically, the policy decision entity needs to ascertain which actions to apply to a particular (data or signalling) packet based on the rules that it has downloaded from the repository. In doing so, it must combine logical information that has been organized through the schema structure where policy rules are made up of condition and action attributes, and these attributes may assume one or more values. We now explain the process of ascertaining whether a packet meets a condition. Consider a PolicyCondition object composed of several attributes attribute1, attribute2, ..., each potentially assuming one or more values (value1-1, value1-2,...), (value2-1,value2-2,...),..., respectively. The packet header has several fields (field1, field2,...). We say that the packet meets the condition if field1 belongs to any of the sets value1-1, value1-2 AND if field2 belongs to any of the sets value 2-1, value2-2, AND so on. Thus, the check of if packet matches condition can be written as if (((field1 belongs to value1-1) OR (field1 belongs to value1-2) OR ...) AND ((field2 belongs to value2-1) OR (field2 belongs to value2-2) OR ...) AND ... ) Most attributes are NOT multi-valued, and exceptions such as Interface (denoting the incoming and outgoing interfaces on which the rule is applicable) or TimeOfDay (denoting the time of day when the rule is applicable) have been introduced only where unavoidable. As an example, consider a packet with source address 8.2.3.1, source port 50, destination address 7.2.3.1, destination port 51, protocol 22 arriving at a router on the interface 3, departing on interface 5 being matched against the following condition. Attribute Values SourceAddressRange 8.0.0.0 : 8.255.255.255 SourcePortRange 50 : 51 DestinationAddressRange 7.2.0.0 : 7.2.255.255 DestinationPortRange 50 : 51 Protocol 0 : 100000 (May be omitted) Interface 1 : 5 (format - incoming:outgoing) 2 : 5 3 : 5 rajan, martin, kamat, see Expires 23/ April/ 1999 [Page vii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 It is easy to check that the packet meets the condition, but another packet destined to the address 9.2.19.250 would not. Now, the policy decision point successively evaluates multiple rules and in order to choose the one that matches. Thus, it checks RULE 1: if (packet meets condition1) then perform (action1-1, action1-2, ...) RULE 2: if (packet meets condition2) then perform (action2-1, action2-1, ...) etc. Here the logical operator that is used to combine the rules is an AND, i.e., RULE 1 AND RULE 2 If the rules are mutually exclusive, i.e., no packet can ever meet both conditions, then the actions corresponding to the one that applies are performed. What does the decision entity do if both conditions are applicable? In some cases, action 1 could be compatible with action 2, i.e., it may be possible to perform both actions. As an example, if action1 is a directive to encapsulate the packet, and action2 indicates the QoS stream the packet belongs to, then the packet is encapsulated and then given the right QoS. On the other hand, if the actions are incompatible, then the operation of the decision entity could be undefined. Rule consistency is desirable whenever possible. However, for purposes of administrative convenience, it is often useful to introduce temporary rules that override others, without having to remove the overriden rule -- for example, special rules for New Year's day. We allow for this by optionally attaching priorities to rules. Potential ambiguities are thus resolved by assigning a higher priority to the overriding rule. In the earlier example, for instance, if rule 2 has higher priority, then the decision point performs all the actions specified in rule 2, and all the compatible actions specified in rule 1. Hence, the right interpretation of the rule set is: if (packet meets condition2) then perform (action2-1, ...) AND if (packet meets condition1) then if (action1-1) is compatible then perform it if (action1-2) is compatible then perform it ... It is very simple to check for compatibility. Actions correspond a few basic scopes -- RSVP, DiffServ, IPSec, and so on. We need to collect no more than one action of a particular scope. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page viii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 5. The class Policy The Policy object class is the container class for the policy rules. It contains a number of entries, each entry encodes a policy rule that specifies the resources and services that are allowed (or denied) to a stream of packets. An overview of the class Policy is presented below, followed by the detailed sytax and semantics of various attributes. NAME Policy TYPE Structural DERIVED FROM Top MUST CommonName, PolicyScope, PolicyConditionRef, PolicyActionRef, PolicyVersion MAY PolicyRulePriority, PolicyKeyword, PolicyType, PolicyName, PolicyEnabled The syntax and semantics of the attributes of the class Policy are as follows: NAME CommonName DESC The common name for objects of this class. Used as relative distinguished name to identify object within a branch of directory tree. SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED NAME PolicyScope DESC Lists the services that are controlled through this policy SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT The currently defined values for this attribute are: DiffServ RSVP IPSec ISAKMP SEMANTICS This attribute is used by the appropriate directory clients to fetch only those policy rules that are relevant for their rajan, martin, kamat, see Expires 23/ April/ 1999 [Page ix]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 functionality. The value DiffServ' means the policy rule specifies DiffServ packet classification and traffic treatment. The value `RSVP' means specifes an RSVP policy decision point. The value `IPSec' means the policy refers to an IPSec action rule. The value `ISAKMP' means the policy refers to an ISAKMP action rule. Note that this is a multi- valued attribute, and the same rule may regulate multiple services for a packet stream. NAME PolicyConditionRef DESC Absolute Distinguished name of LDAP entry of the objectclass PolicyCondition, that identify the packets that the policy rule applies to. SYNTAX DN EQUALITY distinguishedNameMatch SINGLE-VALUED The following reference attributes specify the treatment of packets that match the condition specified in the policy rule. The value of a reference attribute is the distinguished name of an LDAP entry which is an object corresponding to a prespecified class. For instance, if the value of the attribute PolicyActionRef is the distinguished name of an entry in the class RSVPAction, then the policy rule specifies the policy relating to the handling of RSVP signalling messages. NAME PolicyActionRef DESC Absolute Distinguished name(s) of LDAP entry, of the objectclass PolicyAction, that specifies permissions and restrictions that apply to the packets identified by the policy condition SYNTAX DN EQUALITY distinguishedNameMatch MULTI-VALUED SEMANTICS Multiple values are understood as logical AND; that is, all the actions must be performed NAME PolicyVersion DESC The version of the policy schema embodied by this policy. SYNTAX IA5String EQUALITY caseExactIA5Match FORMAT The current draft specifies version ``1.0'' SINGLE-VALUED NAME PolicyKeyword DESC List of keywords that assist in locating this policy SYNTAX IA5String rajan, martin, kamat, see Expires 23/ April/ 1999 [Page x]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 EQUALITY caseExactIA5Match MULTI-VALUED DEFAULT No Keywords NAME PolicyType DESC Describes the types of a policy SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT The following values are allowed: ISAKMPPhase1 ISAKMPPhase2 IPSecDataLocal IPSecDataRemote RSVPSignalling RSVP-DiffServ DiffServ SEMANTICS ISAKMPPhase1 denotes an ISAKMP Phase 1 policy ISAKMPPhase2 denotes an ISAKMP Phase 2 or Quick Mode policy IPSecDataLocal denotes a policy for securing locally originating data by IPSec. Local means either originating from the same host or from an host for which this host acts as a proxy IPSecDataRemote denotes a policy for securing remotely originating data by IPSec. Remote is the opposite of Local as defined before. RSVPSignalling denotes an RSVP signalling policy RSVP-DiffServ denotes a policy for mapping an RSVP traffic into a DiffServ pipe DiffServ denotes a DiffServ policy DEFAULT Unnamed Type NAME PolicyName DESC A user friendly name of this policy class SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED DEFAULT No Name The following attribute defines relationships among multiple related rules within the policy repository. NAME PolicyRulePriority DESC Priority level for this rule. Used to resolve ambiguity in condition matching when the ranges specified in the Policy conditions overlap. Higher values of this attribute imply higher priority of the rule. SYNTAX INTEGER rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 EQUALITY integerMatch SINGLE-VALUED DEFAULT The default value is 0 (lowest priority) SEMANTICS Whenever a packet matches two rules of different priority, the rule with the higher value of PolicyRulePriority is applied. NAME PolicyEnabled DESC A flag describing whether the policy is currently enabled or disabled SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT The currently defined values for this attribute are: Enabled Disabled DEFAULT Enabled 5.1. PolicyContainmentAuxClass Policy rules may need to be grouped together for a number of different purposes -- organizational, security, ease of administration, or ease of retrieval by a policy decision point. We reproduce the PolicyContainmentAuxClass from the DEN specification [9] that serves the useful purpose of grouping policies together. This auxillary class definition is as follows: NAME PolicyContainmentAuxClass TYPE Auxillary DERIVED FROM Top AUXILIARY CLASS None POSSIBLE SUPERIORS Organization, OrganizationalUnit, Group, GroupOfDevices MUST PoliciesContainedRef MAY The syntax and semantics of its sole attribute are as follows: NAME PoliciesContainedRef DESC Absolute distinguished names of policies grouped together for some (context-dependent) purpose. SYNTAX DN EQUALITY distinguishedNameMatch MULTI-VALUED rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 6. Policy Conditions In this section we define the abstract class PolicyCondition, its subclass IPPolicyCondition, and the class UserIDCondition. These classes list the conditions that must be statisfied by a stream of packets in order for the referring rule to apply to that packet stream. The reason for subclassing PolicyCondition is to allow extensibility to other networking protocols through sub-classes such as ATMPolicyCondition (for instance). NAME PolicyCondition TYPE Abstract DERIVED FROM Top AUXILIARY CLASS None MUST CommonName MAY PolicyConditionName PolicyValidityPeriodRef The detailed syntax and semantics of the attributes is as below: NAME CommonName DESC The common name of the policy condition object. Unique within a limited scope and used to identify the object within the directory tree. SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED NAME PolicyConditionName DESC The user friendly name of this entry.The Name related attributes are only for ease of user administration. EQUALITY caseExactIA5Match SYNTAX IA5String SINGLE-VALUED The next attribute is a reference to PolicyValdityPeriod object that identifies the entry that limits the temporal scope of the policy to specified periods of time. NAME PolicyValidityPeriodRef DESC Absolute distinguished name(s) of an PolicyValidityPeriod object that specifies the times that the policy is active. SYNTAX DN EQUALITY distinguishedNameMatch MULTI-VALUED DEFAULT Policy applies at all times rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xiii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 6.1. The class IPPolicyCondition The class PolicyCondition is now specialized to deal with IPv4 packet headers in the class IPPolicyCondition. NAME IPPolicyCondition TYPE Structural DERIVED FROM PolicyCondition AUXILIARY CLASSES none MAY Interface, SourceIPAddressRange, DestinationIPAddressRange, SourcePortRange, DestinationPortRange, IPProtocolNumberRange, ReceivedTOSByteCheck HostUserIDRef The first attribute limits the spatial scope of the policy rule by identifying specific router interfaces where the policy is to be applied. NAME Interface DESC An attribute that limits the scope of the policy to packets on specified interface(s) and the direction(s) of traffic on these. SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT Three colon seperated strings. The left-most string is a numeral denoting the type of the specification, followed by the incoming and outgoing interface identifiers. Currently defined type/value formats are 1:<IPv4Address>:<IPv4Address> 2:<InterfaceID>:<InterfaceID> The IP addresses are in dotted decimal notation. The interface IDs are integers unique to the host device. The first address string specifies a restriction of the rule to traffic inbound on the interface, and the rightmost string specifies a corresponding restriction of the rule to traffic outbound from that interface. An unspecified interface(s) defaults to all interfaces on the device that this rule applies to. DEFAULTS Defaults to traffic inbound on all interfaces, outbound on all interfaces. EXAMPLE 1:9.3.1.52:9.2.1.54 (Applies to traffic inbound on 9.3.1.52 and outbound on 9.3.1.54) rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xiv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 1:9.3.1.32: (Applies to traffic inbound on 9.3.1.52 outgoing from any interface) 2::3 (Applies to traffic outbound on interface 3 arriving on any interface) NAME SourceIPAddressRange DESC Source IP addresses to which the policy applies SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT SourceIPAddressRange is of the following form: three colon (':') separated strings denoting a range of IP addresses. The formats currently defined are: 1:<IPv4Address>:<CIDRPrefixLength> The IP v4 address is in dotted decimal format. The CIDRPrefixLength is the number of unmasked leading bits. A packet matches the condition if the unmasked bits on the packet are identical to the unmasked bits on the condition. 2:<IPv4Address>:<IPv4Address> IP addresses in dotted decimal format. The second address must be no smaller than the first. The first denotes the start of the range, and the second denotes the end of the range. A packet matches the condition if its source address is no smaller than the first IP address in the condition, and no larger than the second. 3 Indicates policy applies to locally generated packets. DEFAULT Defaults to the entire address range, i.e., every packet matches the source address range condition. EXAMPLE 1:83.23.23.1:24 A packet with source address 83.23.23.5 matches. A packet with source address 83.23.24.1 does not. 2:83.23.23.0:83.28.28.0 A packet with source address 83.23.23.5 matches. A packet with source address 83.29.24.1 does not. NAME DestinationIPAddressRange DESC Destination IP addresses to which policy applies SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT Identical to that of SourceIPAddressRange above. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 The value of ``3''indicates a locally destined packet. DEFAULT Defaults to the entire address range, i.e., every packet matches the destination address range condition. NAME SourcePortRange DESC Source Ports to which policy applies SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT String consisting of two colon separated positive integers, the second no smaller than the first, or one positive integer. DEFAULT Defaults to the entire port range 0 to 65535, i.e., every packet matches the destination address range condition. EXAMPLE 8000:8080 (ports 8000 to 8080), 8000 (only port 8000) NAME DestinationPortRange DESC Destination Ports to which policy applies SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT String consisting of two colon separated positive integers, the second no smaller than the first, or one positive integer. DEFAULT Defaults to the entire port range 0 to 65535, i.e., every packet matches the source address range condition. NAME IPProtocolNumberRange DESC Protocol numbers to which policy applies SYNTAX INTEGER EQUALITY integerMatch SINGLE-VALUED FORMAT String consisting of two colon separated positive integers, the second no smaller than the first, or one positive integer. DEFAULT Defaults to the entire protocol range 0 to 255, i.e., every packet matches the ip protocol range condition. EXAMPLE 50:51 (protocol 50 to 51), 50 (only protocol 50) NAME ReceivedTOSByteCheck DESC A condition attribute used to select traffic based on the contents of the TOS byte of the received packet's IP header SYNTAX IA5String EQUALITY caseExactIA5Match rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xvi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 SINGLE-VALUED FORMAT String of the form xxxxxxxx:xxxxxxxx, where each of the x's is either 0 or 1. SEMANTICS Each of the substrings is treated as specifying an 8-bit field. The left substring is termed Mask and the right substring Match. The TOS byte of the received packet's IP header is ANDed with Mask and the result is compared against Match. The combination of Mask and Match allows definition of TOS byte based conditions where certain bits in the TOS byte may be ignored for the purpose of comparison. EXAMPLE An incoming packet with TOS byte 11001010 matches the condition specified by a value of 00111100:00001000 for ReceivedTOSByte. NAME UserIDConditionRef DESC Absolute Distinguished name(s) of LDAP entry or entries, of an UserIDCondition object that identify the user or host whose packets that the policy rule applies to. SYNTAX DN EQUALITY distinguishedNameMatch MULTI-VALUED 6.2. The Class UserIDCondition In many scenarios, for instance an end host IPSec, policy needs to be specified for a user or a host ID instead of an IP address. A standard example is a corporate worker connecting from home via an ISP. The policy would be specified by Host FQDN, UserFQDN, X500 DN etc. To accomodate this source and destination ids are required. NAME HostUserID TYPE Structural DERIVED FROM Top AUXILIARY CLASS None MUST CommonName MAY SourceID, DestinationID, NAME SourceID DESC Source Host Identifier SYNTAX IA5String EQUALITY caseExact1A5Match MULTI-VALUED FORMAT Two strings , colon (`:') seperated, the first describing the rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xvii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 ID type and the second the ID value. The valid IdTypes and their corresponding values are defined in [Piper98]. These include: Host-FQDN:<ID> User-FQDN:<ID> X500-DN:<ID> X500-GN:<ID> Key-Id:<ID> DEFAULT Any ID is considered valid. NAME DestinationID DESC Destination Host Identifier SYNTAX IA5String EQUALITY caseExact1A5Match MULTI-VALUED DEFAULT Any ID is considered valid. FORMAT Same as Source ID. 7. The class PolicyValidityPeriod Objects of this class describe conditions that restrict the validity period of the policy rule. The class definition is as follows: NAME PolicyValidityPeriod TYPE Structural DERIVED FROM Top AUXILIARY CLASSES NONE MUST CommonName MAY PolicyValidityPeriodName, PolicyValidityTime, PolicyValidityMonthMask, PolicyValidityDayOfWeekMask, PolicyValidityTimeOfDayRange The syntax and semantics of various attributes are as given below NAME PolicyValidityPeriodName DESC The user friendly name of this entry. SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED NAME PolicyValidityTime DESC When this policy is valid SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xviii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 FORMAT String(s) of the form yyyymmddhhmmss:yyyymmddhhmmss:<TZ> SEMANTICS The first two substrings must be valid times, (year-month-date-hour-minute- second) the second larger than the first. The last substring is optional and describes the time zone. DEFAULT If the time zone is omitted then the time is local time at the policy decision point. If the attribute itself is absent then the policy is always valid. EXAMPLE 19980121060000:19991231133000:GMT (meaning Policy in effect from 6:00 AM on January 21, 1998 to 1:30 PM on December 31, 1999, Greenwich Mean Time). NAME PolicyValidityMonthMask DESC Months during which policy is valid SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT String denoting a mask of 12 0s and 1s. SEMANTICS 1's corresponding to months in the January to December range when the policy is valid. EXAMPLE 000111111100 (Valid from April until October) DEFAULT 111111111111, i.e., valid always NAME PolicyValidityDayOfWeekMask DESC days during which policy is valid SYNTAX IA5String EQUALITY caseExactIA5Match SINGLE-VALUED FORMAT String representing a mask of 7 0s and 1s. SEMANTICS 1's correspond to days in the Monday to Sunday range when the policy is valid. EXAMPLE 1111100 (Valid weekdays) DEFAULT 1111111, i.e., valid always NAME PolicyValidityTimeOfDayRange DESC Time(s) of day during which policy is valid SYNTAX IA5String EQUALITY caseExactIA5Match MULTI-VALUED FORMAT String(s) of the form hhmmss:hhmmss SEMANTICS Substrings on either side of the colon must be be valid time of day values. If the second string is not larger than the first, then a wrap around midnight is assumed. DEFAULT 000000:235959 EXAMPLE 090000:170000 (Policy valid from 9 AM to 5 PM) rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xix]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 7.1. The class DiffServAction Each object of type DiffServAction 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 descriptors, packet marking descriptors and resource group descriptors. The traffic descriptor assumes a leaky bucket model with three attributes -- a mean rate, a peak rate and a bucket size -- to specify the characteristics of what is to be considered in-profile traffic, with the understanding that the rest is out-of-profile or excess traffic. The traffic descriptor makes sense only with the assumption that a policing device is present at the policy enforcement point; if not the attributes may be omitted or will be ignored. The packet marking descriptor provides an edge device with the ability to mark the DS byte for simple 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 mask certain bits while modifying others. The resource group descriptor describes the treatment expected by packets within a common service group. It is not a description of how the service is to be provided, but simply a high-level view of the service to be accorded to the in-profile traffic, its delay and loss requirements, for instance, as well as the treatment of excess traffic, whether this is to be tolerated, reshaped or dropped. It is important to note that TrafficDescriptor 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: TrafficDescriptor1 PacketMarkingDescriptor1 ResourceGroupDescriptor1 rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xx]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 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: TrafficDescriptor1 PacketMarkingDescriptor1 ResourceGroupDescriptor1 PolicyDSAction2: TrafficDescriptor2 PacketMarkingDescriptor2 ResourceGroupDescriptor2 Even if the two traffic descriptors are 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 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, 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 Directory Clients, namely hosts, edge devices, and routers that do traffic conditioning (packet marking, dropping, shaping, etc). rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 NAME DiffServPermission DESC Allow/drop data packets matching the profile EQUALITY caseExactIA5Match SYNTAX IA5String 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 ``Best Effort'' service. NAME DiffServActionName DESC The user friendly name of this entry. EQUALITY caseExactIA5Match SYNTAX IA5String SINGLE-VALUED DEFAULT No name NAME DiffServInProfileRate DESC Specifies the token rate for the in-profile traffic descriptor in kbps EQUALITY integerMatch SYNTAX INTEGER SINGLE-VALUED 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 EQUALITY integerMatch SYNTAX INTEGER 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 kilobits EQUALITY integerMatch SYNTAX INTEGER SINGLE-VALUED rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 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 EQUALITY caseExactIA5Match SYNTAX IA5String 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 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 Dont modify any bit, i.e., Mask 00000000 Modify 00000000 NAME DiffServOutProfileTransmittedTOSByte DESC Specifies the outgoing TOS byte for out-of-profile packet marking descriptor EQUALITY caseExactIA5Match SYNTAX IA5String 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 rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxiii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 resource group descriptors that apply to the traffic. EQUALITY distinguishedNameMatch SINGLE-VALUED SYNTAX DN DEFAULT Best Effort Service 7.1.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. NAME DiffServResourceGroup TYPE Structural DERIVED FROM Top AUXILIARY CLASSES NONE MUST CommonName MAY DiffServLossParameter, DiffServDelayParameter, DiffServBandwidthShare, DiffServExcessTrafficTreatment DiffServAutoStart DiffServResourceGroupName NAME DiffServResourceGroupName DESC The user friendly name of this entry. EQUALITY caseExactIA5Match SYNTAX IA5String SINGLE-VALUED DEFAULT No name NAME DiffServLossParameter DESC Packet loss paremeters for in-profile traffic for this class of service EQUALITY caseExactIA5Match SYNTAX IA5String 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 rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxiv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 EQUALITY caseExactIA5Match SYNTAX IA5String FORMAT Colon seperated integer:string pair. Currently defined 1:<absolute delay> where the absolute delay is expressed in msec 2:<relative delay > 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 EQUALITY caseExactIA5Match SYNTAX IA5String FORMAT Colon seperated integer:string pair. Currently defined 1:<absolute bandwidth> where the absolute bw is expressed in kilobits/sec 2:<bandwidth percent> 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 bandwidth weight is converted into a bandwidth share at the enforcement entity by adding the weights of all DiffServ classes and then taking the appropriate ratios. The second case is provided for instances where the policy rule is unaware of the link capacity at the enforcement entity. 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. EQUALITY caseExactIA5Match SYNTAX IA5String 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 rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 interpretation is implementation specific. EQUALITY caseExactIA5Match SYNTAX IA5String 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 7.2. 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. As RSVP policy evolves to support the signalling of richer classes of policy information such as user ids, we may extend schema to provide for restrictions based on this information as well. Currently, there are two kinds of restrictions that we may place on resource usage by RSVP flows -- individual restrictions and group restrictions. 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. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxvi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 NAME RSVPFlowServiceType DESC IntServ service type that a flow can request EQUALITY caseExactIA5Match SYNTAX IA5String FORMAT: String with allowed values ControlledLoad GuaranteedService MULTI-VALUED Name RSVPPermission DESC Allow/Dissallow RSVP flows EQUALITY caseExactIA5Match SYNTAX IA5String 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. EQUALITY caseExactIA5Match SYNTAX IA5String SINGLE-VALUED DEFAULT No Name NAME RSVPMaxRatePerFlow DESC The maximum token rate for any individual flow in kilobits per second EQUALITY integerMatch SYNTAX INTEGER 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 EQUALITY integerMatch SYNTAX INTEGER 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 EQUALITY integerMatch rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxvii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 SYNTAX INTEGER 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 EQUALITY integerMatch SYNTAX INTEGER 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 EQUALITY caseExactIA5Match SYNTAX IA5String 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 rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxviii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 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. EQUALITY distinguishedNameMatch MULTI-VALUED SYNTAX DN 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 7.2.1. The Class RSVPResourceGroup NAME RSVPResourceGroup TYPE Structural DERIVED FROM Top AUXILIARY CLASSES NONE MUST CommonName MAY RSVPMaxFlows RSVPMaxAggregateRate RSVPMaxAggregateTokenBucket RSVPResourceGroupName NAME RSVPResourceGroupName DESC The user friendly name of this entry. EQUALITY caseExactIA5Match SYNTAX IA5String SINGLE-VALUED DEFAULT No Name NAME RSVPMaxFlows DESC The maximum allowed number of reserved flows belonging to the rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxix]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 group EQUALITY integerMatch SYNTAX INTEGER SINGLE-VALUED DEFAULT No limit NAME RSVPMaxAggregateRate DESC The aggregate maximum token rate for all flows in the group EQUALITY integerMatch SYNTAX INTEGER 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 EQUALITY integerMatch SYNTAX INTEGER SINGLE-VALUED DEFAULT No limit 7.3. The class TCPAction End hosts and firewalls often control the number and nature of active TCP connections. Each object of type TCPaction describes policies used to control TCP behaviour. The class description of TCPAction is as follows: NAME TCPAction TYPE Structural DERIVED FROM PolicyAction AUXILIARY CLASSES NONE MUST CommonName, TCPPermission MAY TCPFlag, MaxTCPSessions, MaxRatePerTCPSession NAME TCPPermission DESC Allow/drop data packets matching the profile EQUALITY caseExactIA5Match SYNTAX IA5String rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxx]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 SINGLE-VALUED FORMAT The currently defined values for this attribute are: Accept Deny NAME TCPFlag DESC The types of TCP packets to which the policy action applies. EQUALITY caseExactIA5Match SYNTAX IA5String MULTI-VALUED FORMAT The following strings are recognized: ``SYN'' ``ACK'' ``FIN'' ``All'' DEFAULT ``All'' NAME TCPActionName DESC The user friendly name of this entry. EQUALITY caseExactIA5Match SYNTAX IA5String SINGLE-VALUED DEFAULT No name NAME MaxTCPSessions DESC The maximum number of simultaneously open TCP sessions. EQUALITY integerMatch SYNTAX integer SINGLE-VALUED DEFAULT No limit NAME MaxRatePerTCPSession DESC The maximum rate in kilobits/sec that is allowed. EQUALITY integerMatch SYNTAX integer SINGLE-VALUED DEFAULT No limit 8. QoS Schema Usage Examples In this section we describe some usage scenarios for QoS using LDIF notation. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxi]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 8.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 achieves the above objective dn: cn=S1-Web-Rule, o=XYZ, c=US Objectclass: Policy PolicyScope: DiffServ PolicyType: DiffServ PolicyConditionRef: cn=S1-Web-Condition,o=XYZ, c=US, PolicyActionRef: cn=DSGoldService, o=XYZ, c=US dn: cn=S2-Web-Rule, o=XYZ, c=US Objectclass: Policy PolicyScope: DiffServ PolicyType: DiffServ PolicyConditionRef: cn=S2-Web-Condition,o=XYZ, c=US, PolicyActionRef: 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: IPPolicyCondition SourceAddressRange: 1:1.1.0:24 SourcePortRange: 8000:8080 IPProtocolRange: 4 (TCP) dn: cn=S2-Web-Condition, o=XYZ, c=US Objectclass: IPPolicyCondition SourceAddressRange: 1:2.2.2.0:24 SourcePortRange: 8000:8080 IPProtocolRange: 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 rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 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 8.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: Policy PolicyScope: DiffServ PolicyType: DiffServ PolicyConditionRef: cn=S3-Condition,o=XYZ, c=US, PolicyActionRef: cn=S3-DS-Action, o=XYZ, c=US dn: cn=S3-Condition,o=XYZ, c=US, Objectclass: PolicyCondition SourceAddressRange: 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 DiffServExcessTrafficTreatment: drop DiffServAutoStart: NoAutoStart Here, we have allocated a nominal token bucket to take care of the maximum packet size. 8.3. Forbidding RSVP Sessions Suppose that non-RSVP datatraffic 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. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxiii]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 dn: cn=S1-RSVP-Rule, o=XYZ, c=US Objectclass: Policy PolicyScope: RSVP PolicyType: RSVP PolicyConditionRef: cn=S1-RSVP-Condition,o=XYZ, c=US, PolicyActionRef: cn=S1-RSVP-Action, o=XYZ, c=US dn: cn=S1-RSVP-Condition,o=XYZ, c=US Objectclass: IPPolicyCondition SourceAddressRange: 1:1.1.0:4 PolicyValidityPeriodRef: cn=workinghrs, o=XYZ, c=US 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 8.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: Policy PolicyScope: RSVP PolicyType: RSVP PolicyConditionRef: cn=S1-CL-nw-Condition,o=XYZ, c=US, PolicyActionRef: cn=S1-CL-nw-Action, o=XYZ, c=US dn: cn=S1-CL-Condition,o=XYZ, c=US Objectclass: IPPolicyCondition SourceAddressRange: 1:1.1.0:4 PolicyValidityPeriodRef: cn=non-workinghrs, o=XYZ, c=US dn: cn=non-workinghrs, o=XYZ, c=US Objectclass: PolicyValidityPeriod PolicyValidityTimeOfDayRange: 170000: 090000 rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxiv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 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 9. 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 [12]. 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, Ed Ellesson, 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. References [1] L. Wells and R. Bartky, Data Link Switching, Switch to Switch Protocol: AIW DLSW RIG, AIW Closed Pages, DLSW Standard 1.0, RFC1795, April 1995. [2] R. Braden, L. Zhang, S. Berson, S. Herzog, and S. Jamin, Resource ReSerVation Protocol (RSVP) Version 1 Functional Specification. RFC2205, Sept. 1997. [3] 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-00.txt, Jan. 1998. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxv]
Internet Draft draft-rajan-policy-qosschema-00.txt 23/ October/1998 [4] W. Yeong, T. Howes and S. Kille, Lightweight Directory Access Protocol, RFC1777, Mar. 1995. [5] R. Droms, Dynamic Host Configuration Protocol, RFC1541, Oct. 1993. [6] K. Nichols and S. Blake, Differentiated Services Operational Model and Definitions, Internet-Draft, draft-nichols-dsopdef-00.txt, Feb. 1998. [7] 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. [8] R. Yavatkar, R. Guerin and D. Pendarakis, A Framework for Policy-based Admission Control Internet Draft, draft-ietf-rap-framework-00.txt, Nov. 1997. [9] S. Judd and J. Strassner, Directory Enabled Networks - Information Model and Base Schema - Draft v3.0c5 DEN Specifications, Sep. 1998. [10] P. Bhattacharya et. al., An LDAP Schema for Configuration and Administration of IPSec-based Virtual Private Networks, Internet Draft, draft-ietf-ipsec-policy-ldapschema-00.txt, Oct. 1998. [11] Desktop Management Task Force, Common Information Model (CIM) Specification, Version 2.0, Mar. 1998. [12] E. Stokes, D. Byrne, B. Blakeley and P. Behera, Access Control Requirements for LDAP, Internet Draft, Sep. 1998. [13] J. Strassner and E. Ellesson, Terminology for describing network policy and services Internet draft, draft-strassner-policy-terms-00.txt, Aug. 1998. rajan, martin, kamat, see Expires 23/ April/ 1999 [Page xxxvi]